perchè il goto è il male?

[Edward Gein]

boom è arrivato il bulletto delle elementari.
Vabbé tralasciando, so benissimo che java rilascia le variabili, ho fatto un semplice copia incolla del tuo metodo e l'ho riscritto alla bell'e meglio in java.

A questo punto mi sento ancora più autorizzato a dire: intanto hai sbagliato a rispondere.

[working_mad]

fate pure l'esempio mio con il try catch per favore
voglio anche io non essere più ancorato al NEFANDISSIMO goto

[Haruki]

fate pure l'esempio mio con il try catch per favore
voglio anche io non essere più ancorato al NEFANDISSIMO goto

Ma ti piace trollare o cosa?

Ti piace il goto? Usalo, ma se qualcuno ha una opinione contraria alla tua, accettala.

Tanto alla fine, sono tutte scelte soggettive, non sono certo le parole chiave a far funzionare il codice, ma il modo in cui ce le piazzi. E mi pare che su questo, siamo tutti d'accordo.

[working_mad]

a me piace trollare... a te invece no...

l'ho detto al primo post che il goto è usato in maniera GIUSTA soltanto nel problema che ho inserito come esempio. Anche io me ne scampo dal goto quando posso ma di certo non vado a dire che chi lo usa non capisce un cazzo di niente di programmazione.

e poi io ho dato una soluzione ad un problema che è la più EFFICIENTE possibile in tutti i sensi (compattezza, size, velocità, mantenibilità) e tu continui a dire di no e a ribattere con cose false e che non c'entrano niente.

Che ti devo dire, continua a pensare che chi usa il goto è un coglione.
io continuerò a pensarlo di chi non realizza codice efficiente


EDIT: tanto per inciso e per concludere, il mio esempio non si può risolvere con un solo try catch

[Cherno]

Nel frattempo consiglierei un corso di lettura a Bl@k, cioè... ti hanno postato degli esempi con determinate specifiche dove il goto serve e tu rispondi con un pezzo di codice in java con tanto di metodo ilGotoServeAiNiubbi?!?!

Poi sarebbe working_mad a trollare?

Il punto è questo: non vi siete mai sporcati le mani con del vero codice e parlate tanto per dare aria ai tasti.... ahimè mi tocca pure dare ragione ad un programmatore metallaro, e già lì ci sarebbe da dire, che oltretuttto ha Burzum.org in sign.

[Haruki]

Il punto è questo: non vi siete mai sporcati le mani con del vero codice e parlate tanto per dare aria ai tasti...

No infatti, a lavoro usiamo quello finto

[hendor]

No ma sto thread è fantastico

Aspetto con ansia quello su "Programmatori C vs Programmatori Java".


Con il dovuto rispetto, ma secondo me state facendo degli esempi a cazzo. Per dimostrare che un GOTO è pulito, postate un codice di 30 righe?? E' OVVIO che in situazioni semplici il GOTO non crea problemi, anzi può tranquillamente snellire (per quanto la ridondanza del codice, che qualcuno citava, si toglie di mezzo con metodi di supporto, che è una soluzione decisamente più elegante). Il motivo per cui è sconsigliato è che di solito si scrive codice decisamente più complesso, e sparpagliare GOTO a destra e a manca come farebbe il 95% di programmatori smanettoni non è proprio il massimo.

Il punto non è che il GOTO è male. Il punto è che di solito viene usato male. E siccome uno standard di programmazione non si è mai riuscito a diffondere (a mala pena ci è riuscito, POCO, la Sun), si sconsiglia il suo utilizzo.

Poi ognuno fa quello che vuole, può pure programmare con questo: http://it.wikipedia.org/wiki/Malbolge

Tanto poi sono sempre cazzi di chi viene dopo e deve mettere le mani sul tuo codice...

[Cherno]

No infatti, a lavoro usiamo quello finto

A lavoro non avete bisogno di preoccuparvi di performance probabilmente. Siccome il mondo non è il "tuo lavoro", ma è composto da situazioni differenti tipo requisiti, limitazioni, perfomance richieste e tante altre cose che non si limitano a "fai la query sul db e metti il risultato in una text box"(cosa nobilissima, però l'informatica si dirama appunto in molti altri campi), sono costretto a dirti che hai scritto un'altra stronzata.

Nonostante l'intervento a gamba tesa del novello Burzum, questo ha scritto un caso possibile dove l'utilizzo del goto non solo è possibile, ma anche estremamente utile, se non d'obbligo a meno di scrivere una poltiglia di codice, motivando anche a livello di performance(e quindi non solo stilistiche, che sinceramente lo stile dopo un pò rompe anche le palle) il perchè della scelta compiuta.

Quindi ancora non capisco questo atteggiamento da parte vostra.

Abbaiate che il goto non si usa mai, vi dicono di no, vi portano esempi, non li leggete e ritornate ad abbaiare...uno cosa deve pensare? o non avete letto, oppure non sapete leggere.

Delle due l'una.

[Cherno]

No ma sto thread è fantastico

Aspetto con ansia quello su "Programmatori C vs Programmatori Java".


Con il dovuto rispetto, ma secondo me state facendo degli esempi a cazzo. Per dimostrare che un GOTO è pulito, postate un codice di 30 righe?? E' OVVIO che in situazioni semplici il GOTO non crea problemi, anzi può tranquillamente snellire (per quanto la ridondanza del codice, che qualcuno citava, si toglie di mezzo con metodi di supporto, che è una soluzione decisamente più elegante). Il motivo per cui è sconsigliato è che di solito si scrive codice decisamente più complesso, e sparpagliare GOTO a destra e a manca come farebbe il 95% di programmatori smanettoni non è proprio il massimo.

Il punto non è che il GOTO è male. Il punto è che di solito viene usato male. E siccome uno standard di programmazione non si è mai riuscito a diffondere (a mala pena ci è riuscito, POCO, la Sun), si sconsiglia il suo utilizzo.

Poi ognuno fa quello che vuole, può pure programmare con questo: http://it.wikipedia.org/wiki/Malbolge

Tanto poi sono sempre cazzi di chi viene dopo e deve mettere le mani sul tuo codice...

Scusa cos'avrebbe fatto la SUN?

[Haruki]

A lavoro non avete bisogno di preoccuparvi di performance probabilmente. Siccome il mondo non è il "tuo lavoro", ma è composto da situazioni differenti tipo requisiti, limitazioni, perfomance richieste e tante altre cose che non si limitano a "fai la query sul db e metti il risultato in una text box"(cosa nobilissima, però l'informatica si dirama appunto in molti altri campi), sono costretto a dirti che hai scritto un'altra stronzata.

Nonostante l'intervento a gamba tesa del novello Burzum, questo ha scritto un caso possibile dove l'utilizzo del goto non solo è possibile, ma anche estremamente utile, se non d'obbligo a meno di scrivere una poltiglia di codice, motivando anche a livello di performance(e quindi non solo stilistiche, che sinceramente lo stile dopo un pò rompe anche le palle) il perchè della scelta compiuta.

Quindi ancora non capisco questo atteggiamento da parte vostra.

Abbaiate che il goto non si usa mai, vi dicono di no, vi portano esempi, non li leggete e ritornate ad abbaiare...uno cosa deve pensare? o non avete letto, oppure non sapete leggere.

Delle due l'una.

Guarda, dopo sta risposta ricolma di presunzione, m'è del tutto passata la voglia di rispondere

[Cherno]

Non è che ti è passata, è che ti mancano gli argomenti. Pazienza

[hendor]

Scusa cos'avrebbe fatto la SUN?

http://www.oracle.com/technetwork/ja...nv-138413.html

Ovviamente mi riferivo solo al mondo Java.

[giuseppemag]

tanto per inciso e per concludere, il mio esempio non si può risolvere con un solo try catch

http://www.cs.cmu.edu/~pattis/15-1XX...ons/index.html

Per quanto riguarda l'esempio dell'early exit da cicli annidati, le eccezioni possono essere usate anche li:
http://lambda-the-ultimate.org/node/2892

Se poi uno vuole andare oltre e rendere il flusso di controllo completamente generico e gestibile, allora la monade di continuazione è molto elegante e permette di avere un controllo fine-grained tipo con i goto ma in un framework piú predicibile:
http://en.wikipedia.org/wiki/Continuation

[giuseppemag]

A lavoro non avete bisogno di preoccuparvi di performance probabilmente. Siccome il mondo non è il "tuo lavoro", ma è composto da situazioni differenti tipo requisiti, limitazioni, perfomance richieste e tante altre cose che non si limitano a "fai la query sul db e metti il risultato in una text box"(cosa nobilissima, però l'informatica si dirama appunto in molti altri campi), sono costretto a dirti che hai scritto un'altra stronzata.

Nonostante l'intervento a gamba tesa del novello Burzum, questo ha scritto un caso possibile dove l'utilizzo del goto non solo è possibile, ma anche estremamente utile, se non d'obbligo a meno di scrivere una poltiglia di codice, motivando anche a livello di performance(e quindi non solo stilistiche, che sinceramente lo stile dopo un pò rompe anche le palle) il perchè della scelta compiuta.

Quindi ancora non capisco questo atteggiamento da parte vostra.

Abbaiate che il goto non si usa mai, vi dicono di no, vi portano esempi, non li leggete e ritornate ad abbaiare...uno cosa deve pensare? o non avete letto, oppure non sapete leggere.

Delle due l'una.

Boh, considerato che ho sempre fatto sviluppo di codice ad alta performance diviso tra mobile/embedded/game dev/image processing devo dire che non provo questo amore infinito per i linguaggi e i costrutti di basso livello. Anzi, è da un po' che sono finito ad occuparmi di un ambito molto accademico, ossia la compilazione di linguaggi di altissimo livello (F# in particolare) in modo che corrano alla massima velocitá. La mia sensazione è che i costrutti come il GoTo che stanno venendo difesi a spada tratta sono principalmente un modo per ingarbugliare il codice, in quanto permettono di rompere le invarianti di cicli, funzioni e strutture dati molto facilmente. Non a caso sono stati fatti due esempi giocattolo in cui usi estremamente strutturati e formalizzabili del goto sono utili:

- cicli for annidati con early exit
- gestione degli errori di terminazione di una funzione (ricordo che questo si faceva spesso in D3DX, che bei ricordi )

invece vi propongo qualche altro caso: goto che salta fuori dai metodi di una classe; goto che va da un pezzo di una funzione ad un pezzo di un'altra; in generale goto che non rispettano il flusso logico del codice. Non a caso i vostri esempi a favore sono casi molto ben noti e facili da esprimere con linguaggi seri e tramite le cosiddette continuazioni.


Comunque visto che siamo in vena di sparare cazzate (è un thread scherzo per trollare in compagnia, immagino), dico anche la mia: la difesa dei GoTo è sintomo dell'arretratezza del panorama informatico italiano, fatto di gestionali scritti da ingegneri elettronici matti convertiti in informatici che lavorano in Cobol con tanti GoTo e credono che risparmiare il e-10 di capacitá di una CPU moderna valga piú di 10 bug

[giuseppemag]

Boh, considerato che ho sempre fatto sviluppo di codice ad alta performance diviso tra mobile/embedded/game dev/image processing devo dire che non provo questo amore infinito per i linguaggi e i costrutti di basso livello. Anzi, è da un po' che sono finito ad occuparmi di un ambito molto accademico, ossia la compilazione di linguaggi di altissimo livello (F# in particolare) in modo che corrano alla massima velocitá. La mia sensazione è che i costrutti come il GoTo che stanno venendo difesi a spada tratta sono principalmente un modo per ingarbugliare il codice, in quanto permettono di rompere le invarianti di cicli, funzioni e strutture dati molto facilmente. Non a caso sono stati fatti due esempi giocattolo in cui usi estremamente strutturati e formalizzabili del goto sono utili:

- cicli for annidati con early exit
- gestione degli errori di terminazione di una funzione (ricordo che questo si faceva spesso in D3DX, che bei ricordi )

invece vi propongo qualche altro caso: goto che salta fuori dai metodi di una classe; goto che va da un pezzo di una funzione ad un pezzo di un'altra; in generale goto che non rispettano il flusso logico del codice. Non a caso i vostri esempi a favore sono casi molto ben noti e facili da esprimere con linguaggi seri e tramite le cosiddette continuazioni.


Comunque visto che siamo in vena di sparare cazzate (è un thread scherzo per trollare in compagnia, immagino), dico anche la mia: la difesa dei GoTo è sintomo dell'arretratezza del panorama informatico italiano, fatto di gestionali scritti da ingegneri elettronici matti convertiti in informatici che lavorano in Cobol con tanti GoTo e credono che risparmiare il e-10 di capacitá di una CPU moderna valga piú di 10 bug

Anzi, per divertirci un pochino, vi propongo il caso dei tre errori diversi in pseudo-Haskell:

let f(x,y) =
let body f_res f_err1 f_err2 =
if x = 0 then f_err1()
else if y = 0 then f_err2()
else f_res(((x+1)/y) / x)
in body (\x -> print x) (\() -> print "errore") (\() -> f(x+1,y-1))

Niente impedisce ad un compilatore di compilare questa cosa con i goto, ovviamente...

[LordOrion]

questo topic è bellissimo perché ci sono alcuni che non capiscono nulla e pretendono di aver ragione

metto io un esempio per far capire che il goto SERVE

int funz(....) {
    ....
    if (err1)
        goto exit1;
    ....
    if (err2)
        goto exit2;
    ....
    if (err3)
        goto exit3;
    ....
exit3:
    ....
exit2:
    ....
exit1:
    ....
    return rc;
}

fino ad ora questo è l'unico costrutto in cui è veramente utile l'uso del goto, per le altre cose, se serve utilizzare il goto significa che c'è un problema di fondo (ossia si può sicuramente riprogettare il codice in maniera migliore)
(ovviamente parlo per esperienza personale)

Mi permetto:

int funz(....) {
    ....
    switch( err ) 
    {
       case err1:
          // operazioni di exit1 
          break;

       case err2:
          // operazioni di exit2 
          break;

       case err3:
          // operazioni di exit3 
          break;
       ... 
   }
    ...
    return rc;
}

Stessa cosa, niente goto.

[Ronin]

Stessa cosa, niente goto.

il tuo costrutto non riproduce la funzionalità di quello di working mad, perchè in quest'ultimo in caso di err3 si eseguono sia le istruzioni di exit3 che quelle di exit2 ed exit1 (che vengono in sequenza), mentre nel tuo caso si esegue solo il blocco exit3

anche se fosse valido, il tuo costrutto inoltre vale solo se err è una funzione calcolabile prima delle istruzioni del ciclo, ed err1-err2-err3 sono valori costanti e non espressioni che cambiano durante il blocco di istruzioni all'interno del ciclo, mentre se ho bisogno del goto è proprio perchè così NON è

[LordOrion]

solo se err è una funzione calcolabile prima, ed err1-err2-err3 sono valori costanti e non espressioni che cambiano durante il blocco di istruzioni all'interno del ciclo, cosa che di solito NON è

Ok, ma allora hai posto male il problema: Spiega magari bene cosa sono i vari err ( magari dichiarali nel codice ). Sembra quasi che siano stati lasciati appositamente non definiti per "confondere in nemco"

A lavoro non avete bisogno di preoccuparvi di performance probabilmente. Siccome il mondo non è il "tuo lavoro", ma è composto da situazioni differenti tipo requisiti, limitazioni, perfomance richieste e tante altre cose che non si limitano a "fai la query sul db e metti il risultato in una text box"(cosa nobilissima, però l'informatica si dirama appunto in molti altri campi), sono costretto a dirti che hai scritto un'altra stronzata.

Nonostante l'intervento a gamba tesa del novello Burzum, questo ha scritto un caso possibile dove l'utilizzo del goto non solo è possibile, ma anche estremamente utile, se non d'obbligo a meno di scrivere una poltiglia di codice, motivando anche a livello di performance(e quindi non solo stilistiche, che sinceramente lo stile dopo un pò rompe anche le palle) il perchè della scelta compiuta.

Quindi ancora non capisco questo atteggiamento da parte vostra.

Cherno, come sviluppatore di Software di Sistema & applicazioni multimediali per macchine embedded mi trovo ad affrontare il problema dell performances tutti i giorni (anche adesso in teoria invece di rispondere a questo thread dovrei cercare di ottimizzare il rendering e la ricezione dei dati di una immagine ricevuta da un dispositivo radar marino tramite ethernet su una macchina con CPU ARM-based sulla quale gira WindowsCE). Cio nonostante in 10 anni di esperienza lavorativa non ho mai usato una sola volta il goto per vari motivi. Lasciando a parte quelli goto-fobici (il classico "usi il goto = ti do 0 nel compito / ti boccio all'esame" che ti inculcano all' ITIS/Universita') il primo che posso citarti e' il fatto che il goto altera il normale flusso logico del codice lendndolo molto meno comprensibile (e tutti sappiamo che tra una settimana non ci ricorderemo come quel codice finziona e la sua logica, commenti o non commenti). Il secondo e' che comunque il codice puo' essere sempre riscritto e/o riorganizzato in modo da rendere non necessario il suo uso, anche senza dover necessariamente fare delle poltiglie come tu dici. Per quanto riguarda l'ottimizzazione ti ricordo la buona vecchia regola del 90-10: Ovvero il 90% del tempo di esecuzione e speso sul 10% del codice e quindi solo quello va' ottimizzato (inutile quindi spargere goto a destra e a manca per "ottimizzare"). Se poi le performances di quel 10% e' sono critiche allora forse vale la pena di scriverle quelle funzioni in assembly (come si faceva e si fa ancora nei VG), che di sicuro consente performances ancora migliori (per quanto non portabili ovviamente).

Ogniuno poi e' ovviamente libero di pensare come vuole riguardo all'uso del goto, io per quel che mi riguarda non lo uso mai.

[Ronin]

non l'ho mica fatto io l'esempio.
a parte che il tuo codice non riproduce il comportamento, ma è chiaro che l'uso del goto si giustifica solo se le condizioni di uscita cambiano dinamicamente a seconda delle istruzioni del ciclo (ed in particolare se i cicli da cui uscire sono multipli annidati), altrimenti hai pienamente ragione tu, e in quel caso il goto è inutile e anzi dannoso.

[LordOrion]

non l'ho mica fatto io l'esempio.

Hops

a parte che il tuo codice non riproduce il comportamento,

ha gia'... se si salta a exit3 si eseguno tutte le label in cascata. Io lo risolverei a lato pratico cosi:

int funz(....) {
    ....
    if (err1)
    {
       // Op exit1
        return rc;
    }
    ....
    if (err2)
    {
       // Op exit2
       // Op exit1
        return rc;
    }
    ....
    if (err3)
    {
       // Op exit3
       // Op exit2
       // Op exit1
         return rc;
     }
    ....
    return rc
}

E' una situazione che mi capita spesso ad es l'inizializzazione di un componente che in caso di errore deve essere disabilitato in maniera "gracefull". Mano mano che si avanza nel processo le operazioi da fare per chiudere aumentano ma preferisco replicarle in ogni if. La minore quantita' di codice non giustifica l'uso del goto.

[working_mad]

mi reintrometto solo perché chiamato indirettamente in causa

bella merda il codice qua sopra. senza offesa ovviamente.

se aumentano le condizioni di errore (che sono OVVIAMENTE dinamiche a seconda delle istruzioni che si eseguono) aumenta il codice da replicare

questo implica:
- mantenibilità che cala
- illeggibilità che aumenta
- size che cresce

il tutto per non usare dei goto.
bah.

ma contenti voi.
l'importante è che capiate che questo codice qui su è MENO EFFICIENTE di quello postato da me.
Fate il favore anche di non formalizzarvi troppo su condizioni, numero di errori, ecc...
quello è un esempio generico, potevo anche scriverne 50 di condizioni di errore, il succo non cambiava.

E poi mi sembra anche di esser stato abbastanza chiaro nel primo post che ho fatto: a parte quella particolare logica, nella mia esperienza non ho MAI trovato l'uso del goto difendibile.
Questo non fa quindi di me un difensore del goto, anzi. In altre parole: c'è 1 (una, UNA) soluzione in cui usare il goto non fa male e fa risparmiare, in tutte le altre ce la si cava egregiamente anche senza.

[LordOrion]

bella merda il codice qua sopra. senza offesa ovviamente.

No, non mi offendo stai tranquillo

se aumentano le condizioni di errore (che sono OVVIAMENTE dinamiche a seconda delle istruzioni che si eseguono) aumenta il codice da replicare

questo implica:
- mantenibilità che cala
- illeggibilità che aumenta
- size che cresce

Ok, ma sai bene che ci sono parecchi modi per migliorare il mio snippet in modo da aumentare manutenibilita' leggibilita' e diminuire la dimensione del codice.

l'importante è che capiate che questo codice qui su è MENO EFFICIENTE di quello postato da me.

Certo ma la differenza in termini di tempo di esecuzione e' irrosoria.

Fate il favore anche di non formalizzarvi troppo su condizioni, numero di errori, ecc...
quello è un esempio generico, potevo anche scriverne 50 di condizioni di errore, il succo non cambiava.

No, il succo cambiava: L'esempio che hai scritto e' aperto alla libera interpretazione in quanto non hai definito i suoi elementi in modo univoco.

E poi mi sembra anche di esser stato abbastanza chiaro nel primo post che ho fatto: a parte quella particolare logica, nella mia esperienza non ho MAI trovato l'uso del goto difendibile.
Questo non fa quindi di me un difensore del goto, anzi. In altre parole: c'è 1 (una, UNA) soluzione in cui usare il goto non fa male e fa risparmiare, in tutte le altre ce la si cava egregiamente anche senza.

Nessuno ti voleva attaccare e neppure bollare come eretico-gotoiano (bella questa ). Semplicemete volevo mostrarti che c'e' una via alternativa per fare la medesima cosa con praticamente la stessa efficenza e che non usa il goto.

[blue_tech]

Mi permetto:

int funz(....) {
    ....
    switch( err ) 
    {
       case err1:
          // operazioni di exit1 
          break;

       case err2:
          // operazioni di exit2 
          break;

       case err3:
          // operazioni di exit3 
          break;
       ... 
   }
    ...
    return rc;
}

Stessa cosa, niente goto.

il tuo costrutto non riproduce la funzionalità di quello di working mad, perchè in quest'ultimo in caso di err3 si eseguono sia le istruzioni di exit3 che quelle di exit2 ed exit1 (che vengono in sequenza), mentre nel tuo caso si esegue solo il blocco exit3

anche se fosse valido, il tuo costrutto inoltre vale solo se err è una funzione calcolabile prima delle istruzioni del ciclo, ed err1-err2-err3 sono valori costanti e non espressioni che cambiano durante il blocco di istruzioni all'interno del ciclo, mentre se ho bisogno del goto è proprio perchè così NON è

perdonate ma basta invertire l'ordine dei case e non mettere i break

int funz(....) {
    ....
    switch( err ) 
    {
       case err3:
          // operazioni di exit3
          

       case err2:
          // operazioni di exit2 
          

       case err1:
          // operazioni di exit1
          
       ... 
   }
    ...
    return rc;
}

senza contare che di norma se si dividono i vari casi si presume che il comportamento sia diverso per ognuno e quindi il break serve... avere l'err3 e dover eseguire il suo codice più quello di err2 e err1 non è che sia così bello eh

[Haruki]

ecco, quoto bluecoso

[working_mad]

sì ma come ci si arriva allo switch?

se bisogna replicarlo allora va bene anche senza,
se ne serve uno allora ci si arriva, udite udite, con i goto