[.NET] Perchè il goto è così usato?

[^TiGeRShArK^]

ma solo a me da alla testa leggere cose del genere?

if  __name__=="__main__":
    unittest.main()

odio gli underscore usati in quel modo

[k0nt3]

io odio gli underscore qualunque sia il motivo per cui vengono usati

[cdimauro]

Originariamente inviato da fek

Nel frattempo quel linguaggio senza goto scritto da una scimmia (Python), mi ha fatto perdere una giornata di lavoro.

Eh si', e' troppo complesso dirmi che ho dimenticato di inizializzare una variabile a tempo di compilazione, o almeno inizializzarsela da solo... Me lo deve dire dopo tre ore di esecuzione e con un messaggio di errore che non c'entra nulla

Quanto amo Python... si' si'.

Fran, ma almeno un check dei sorgenti dovresti farlo con PyCheck o tramite la comodissima iconcina che c'è in SPE: avresti avuto subito la segnalazione dell'uso di una variabile non inizializzata in precedenza.

Dì la verità: usi il notepad per lavorare con Python, vero?

P:S. Le variabili inizializzate da sole non mi piacciono: con quale valore dovrebbe essere fatto? Preferisco le ditine spezzate, così la prossima volta imparo a inizializzarle correttamente.

P.P.S. Come sempre: de gustibus.

Originariamente inviato da ^TiGeRShArK^

ma solo a me da alla testa leggere cose del genere?

if  __name__=="__main__":
    unittest.main()

odio gli underscore usati in quel modo

Una convenzione si doveva usare: in Python costruttori, distruttori, operatori, ecc. sono "first class functions". Essendo funzioni, al pari di qualunque altra, posso farci quello che voglio.

Esempio: posso usare dei mixin (apprò: mi sono fatto qualche giorno fa una comoda funzioncina per emularli, visto che Python non li supporta nativamente ) che me li sovrascrivono, oppure conservo il vecchio valore, lo rimpiazzo col mio, ed eventualmente richiamo il vecchio codice quando voglio (questo modo di lavorare si chiama monkey patch, se non erro; un nome, una garanzia: vedi sopra ).

In C++ o in altri linguaggi non puoi "mettere in frigo" un costruttore, sostituirlo con un altro, e tirare fuori il vecchio quando ti fa comodo.

[cionci]

Originariamente inviato da cdimauro

In C++ o in altri linguaggi non puoi "mettere in frigo" un costruttore, sostituirlo con un altro, e tirare fuori il vecchio quando ti fa comodo.

E meno male

[k0nt3]

Originariamente inviato da cdimauro

In C++ o in altri linguaggi non puoi "mettere in frigo" un costruttore, sostituirlo con un altro, e tirare fuori il vecchio quando ti fa comodo.

a parte che è possibile attraverso un puntatore a funzione... ma per quale assurdo motivo dovrebbe essere utile? non sarebbe meglio avere due costruttori diversi e chiamare quello più adeguato a seconda dei casi? oppure avere un solo costruttore che capisce da solo in che caso si trova?

[fek]

Originariamente inviato da cdimauro

Fran, ma almeno un check dei sorgenti dovresti farlo con PyCheck o tramite la comodissima iconcina che c'è in SPE: avresti avuto subito la segnalazione dell'uso di una variabile non inizializzata in precedenza.

Dì la verità: usi il notepad per lavorare con Python, vero?

Uso Visual Studio, lo stesso tool che uso per scrivere in C++ e in C#. Non capisco perche' devo usare un tool diverso solo perche' il linguaggio e' fondamentalmente "pericoloso", per evitare di perdere ore. Ho perso una giornata su questa e solo per colpa delle scelte di design del linguaggio, non per colpa dei tool che avrei dovuto usare dei quali non conosco neppure l'esistenza. In C++/C#/Java non ne ho bisogno.

P:S. Le variabili inizializzate da sole non mi piacciono: con quale valore dovrebbe essere fatto? Preferisco le ditine spezzate, così la prossima volta imparo a inizializzarle correttamente.

Zero o stringa vuota.

P.P.S. Come sempre: de gustibus.

De gustibus? Una giornata di lavoro buttata nel bidet perche' il design del linguaggio e' fallato

In C++ o in altri linguaggi non puoi "mettere in frigo" un costruttore, sostituirlo con un altro, e tirare fuori il vecchio quando ti fa comodo.

Grazie al cielo. Non rischio di perderci tutte le volte una giornata perche' il linguaggio decide di avvertirmi di un errore sintattico durante l'esecuzione, ore dopo.

Se prima sopportavo poco Python "a pelle", le ultime settimane che mi hanno costretto a lavorarci me lo hanno fatto sopportare sempre meno, ma con ottime motivazioni.

[cdimauro]

Originariamente inviato da cionci

E meno male

Originariamente inviato da k0nt3

a parte che è possibile attraverso un puntatore a funzione... ma per quale assurdo motivo dovrebbe essere utile? non sarebbe meglio avere due costruttori diversi e chiamare quello più adeguato a seconda dei casi? oppure avere un solo costruttore che capisce da solo in che caso si trova?

Il nocciolo della questione è che Python è un linguaggio dinamicamente tipato.

Quando scrivo a = b + c, b e c possono essere oggetti di qualunque tipo, e soltanto in fase di esecuzione "la matassa verrà sbrogliata".

Cosa vuol dire questo? Che se nel codice mi ritrovo pattern di codice che posso utilizzare per tipi che non necessariamente debbono essere "compatibili", ma che funzionalmente devono funzionare allo stesso modo, nulla m'impedisce di racchiudere il tutto in una funzione / costruttore / operatore, magari "ereditati" tramite un apposito mixin.

In soldoni: a me interessa modellare comportamenti.

Questo con un linguaggio staticamente tipato non è assolutamente realizzabile (e in ogni caso non è fattibile: non posso ricavare il puntatore di un operatore, ad esempio).

Originariamente inviato da fek

Uso Visual Studio, lo stesso tool che uso per scrivere in C++ e in C#. Non capisco perche' devo usare un tool diverso solo perche' il linguaggio e' fondamentalmente "pericoloso", per evitare di perdere ore. Ho perso una giornata su questa e solo per colpa delle scelte di design del linguaggio, non per colpa dei tool che avrei dovuto usare dei quali non conosco neppure l'esistenza. In C++/C#/Java non ne ho bisogno.

Zero o stringa vuota.

De gustibus? Una giornata di lavoro buttata nel bidet perche' il design del linguaggio e' fallato

Grazie al cielo. Non rischio di perderci tutte le volte una giornata perche' il linguaggio decide di avvertirmi di un errore sintattico durante l'esecuzione, ore dopo.

Se prima sopportavo poco Python "a pelle", le ultime settimane che mi hanno costretto a lavorarci me lo hanno fatto sopportare sempre meno, ma con ottime motivazioni.

Non è un errore sintattico, Fran: soltanto in fase di esecuzione puoi scoprire se QUELLA variabile esiste o meno, e questo non te lo può garantire nessun PyCheck o editor come SPE, che danno soltanto possibili indicazioni.

Esempio. Io posso avere un modulo (ma anche una classe) chiamato Pippo con soltanto questa funzione:

def Prova():
  print a

che generarà il relativo warning.

Quindi sulla carta quel codice NON dovrebbe funzionare. Ma se scrivo questo:

import Pippo
Pippo.a = 5
Pippo.Prova()

il codice funzionerà in maniera impeccabile.

E casi come questi ce ne sono diversi (esempio: con le metaclassi posso generare automaticamente classi abbiano determinati "requisiti", ivi compresi la definizione di attribuiti / metodi che sulla classe di partenza non esistevano).

Dipende tutto da quel che si deve fare. La sintassi è corretta, e quando il sorgente viene compilato in bytecode, infatti, non viene generato nessun errore.

Sull'uso di valori di default, rientriamo nelle convenzioni: quelli che proponi sono i valori più papali e che, quindi, possono "risolvere" la maggior parte dei casi, ma davanti a = b / c con c non definita si ritorna al punto di partenza, ossia l'errore che ho commesso è stato quello di non definire (correttamente) la variabile prima di averla usata.

Tra l'altro l'uso di valori predefiniti porta a errori di mistyping difficilmente individuali (quando il codice, con un valore di default, non funziona lo stesso).

Sugli editor/IDE nulla da dire, ma già in passato t'avevo avvisato di usarne qualcuno come SPE per evitare problemi come quelli dovuti all'indentazione necessaria in Python, ad esempio.

[gugoXX]

Sembra il Javascript, che tanto mi sta facendo penare in questo periodi perche' i problemi vengono fuori tutti a Runtime.
Peccato che per far partire l'applicazione e raggiungere il punto da testare ci si metta 40 secondi ogni volta, quando va bene.

// Pattern per la creazione di classe in javascript
function pippo()
{
}

//Decorator pattern per javascript
pippo.prototype.Prova = function()
{
   alert(this.a);
}


//Usage
var pippoinstance=new pippo();
pippoinstance.a='Hello World';
pippoinstance.Prova();

Non proponetemi di fare una test before code qui perche' non ce ne si esce.
Tutto dipende da cosa si e' lanciato, eseguito o distrutto prima di lanciare
pippoinstance.Prova();
Non c'e' test che tenga.

Il problema qui e' che
this.a
puo' assumere valore "Undefined", che non e' un valore vero e' proprio.
Semplicemente e' lo stato che tiene conto del fatto che il campo non e' ancora stata dichiarata, e il tentativo di usarla genera un errore a runtime.
Diverso e' avere il valore "NULL", ovvero quando la variabile assume il valore null, che e' un valore come un altro. In questo caso non c'e' errore a Runtime.

Per fare le cose come si deve dovrei costringere tutte le funzioni a controllare l'esistenza di quanto usano, prima anche solo di valutarlo. A quel punto potrei usare i Pattern di Test, che altrimenti si arrabbierebbero subito.

Pero' cosi' facendo il codice diventerebbe decisamente piu' lungo, lento e illeggibile.
E' tanto piu' comodo essere "sicuri" che a Runtime la variabile di classe
this.a
esiste gia', perche' il compilatore ha gia' controllato tutto.

Mannaggia a me che ho accettato di entrare in questo progetto che era stato disegnato da un altro e che si e' licenziato. (Non che avessi molta scelta, comunque)
Dopo 5 mesi di lavoro su questo progetto la mia conclusione e' che il javascript non e' professionale.
Non consco Python ma spero non soffra degli stessi problemi o che almeno abbia i mezzi per poterli gestire.

[cdimauro]

Il comportamento è lo stesso, ma hai i mezzi per controllare l'esistenza di "attributi" (con la funzione bult-in hasattr) prima di usarli, oppure puoi usare la libreria di sistema unittest per gestire agevolmente batterie di test (che risolverebbe il problema alla radice ).

[fek]

Originariamente inviato da cdimauro

Non è un errore sintattico, Fran: soltanto in fase di esecuzione puoi scoprire se QUELLA variabile esiste o meno, e questo non te lo può garantire nessun PyCheck o editor come SPE, che danno soltanto possibili indicazioni.

E' proprio questo il problema: non e' un errore sintattico, quindi l'errore nel mio codice spuntera' dopo ore, facendomi perdere una marea di tempo e andando contro il principio "Fail early, fail loud".

Esempio. Io posso avere un modulo (ma anche una classe) chiamato Pippo con soltanto questa funzione:

def Prova():
  print a

che generarà il relativo warning.

Quindi sulla carta quel codice NON dovrebbe funzionare. Ma se scrivo questo:

import Pippo
Pippo.a = 5
Pippo.Prova()

il codice funzionerà in maniera impeccabile.

In altre parole un metodo e' sintatticamente corretto in base a chi lo invoca. Quanto lo odio

[cdimauro]

Fran, è un problema relativo a buona parte dei linguaggi "dinamici", Ruby compreso.

Lo si può risolvere in diversi modi, e uno fra questi è la TDD (sarebbe sufficiente coprire con un test ogni "biforcazione" del codice per avere la sicurezza di non essersi dimenticati di inizializzare correttamente tutte le variabili su cui lavora).

Quanto al principio "Fail early, fail loud", se consideri che impieghi anche 1/10 del tempo a scrivere l'applicazione, vuol dire che puoi verificare molto prima se questa fallisce o meno coi dati reali.

Diciamo che un linguaggio "tradizionale" ti permette di applicare (velocemente) il principio sulla base della correttezza "sintattica" del codice, mentre con uno "dinamico" lo applichi ai dati.

Son cose diverse, ma l'obiettivo finale è arrivare alla correttezza dell'applicazione sulla base dei dati reali, e questo non viene a mancare.

[fek]

Originariamente inviato da cdimauro

Fran, è un problema relativo a buona parte dei linguaggi "dinamici", Ruby compreso.

Infatti c'e' un motivo per il quale non gradisco i linguaggi totalmente dinamici

Quanto al principio "Fail early, fail loud", se consideri che impieghi anche 1/10 del tempo a scrivere l'applicazione, vuol dire che puoi verificare molto prima se questa fallisce o meno coi dati reali.

Cesare, ti ricordo che il tempo impiegato a scrivere l'applicazione non e' solo il tempo impiegato a scrivere il codice, ma anche quello a testarlo e fare il debugging. Se un linguaggio mi costringe a ore di esecuzione per trovare un errore sintattico facilmente tracciabile prima dell'esecuzione, mi sta facendo perdere del tempo inutilmente per sola colpa di chi lo ha progettato. Senza se e senza ma.

Non ti ho fatto un esempio campato in aria: ho impiegato una giornata e mezza a scrivere tre righe di Python nel mondo reale su un progetto in produzione.

Poter aggiungere metodi e proprieta' e' una cosa utile in certe situazione, ma doverla pagare sempre e comunque anche quando non mi serve e' un errore di progettazione.

[cdimauro]

Non metto in dubbio che tu abbia perso tempo, ma i bug fanno parte della vita di un programmatore.

Quando ho cominciato a lavorare in Python, commettevo anch'io errori come quello, perché ero troppo abituato ai linguaggi "tradizionali" e al compilatore che ti segnalava l'assenza della dichiarazione di una variabile, perché è la sintassi stessa che lo richiede.
Con Python non si tratta di una questione sintattica, ma prettamente semantica...

Che sia grave non ci sono dubbi: infatti hai perso un bel po' di tempo per quella che ritieni una sciocchezza. Sciocchezze che, però, ritrovi anche in altri linguaggi che hanno una sintassi più "rigorosa":

int i; scanf("%d", i);

ma che ti portano a bug davvero subdoli da andare a individuare (mentre nel caso che t'è capitato dallo stack trace trovi immediatamente sia la causa dell'errore che la riga e colonna precisa).

Non è un caso che siano nati tool come "lint", o PyCheck, e per linguaggi completamente diversi...

Hai pagato un prezzo elevato per una sciochezza, ma per la mia esperienza il gioco vale la candela (ad esempio m'è capitato di realizzare un progetto in 20 giorni, quando lo stesso a un'altra società ha richiesto 6 mesi, e non so quanti c'abbiano lavorato), specialmente alla luce del fatto che una volta pronta l'applicazione la posso immediatamente testare con dati reali e rilevare, quindi, anche errori come quello che ti sono capitati.

Comunque questo http://cobra-language.com/ linguaggio che ha segnalato un utente qualche giorno fa è molto simile a Python, ma non ha i problemi di cui ti lamenti (unica eccezione, l'indentazione).

Ecco qui http://cobra-language.com/docs/python/ un confronto con Python.

[fek]

Originariamente inviato da cdimauro

Non metto in dubbio che tu abbia perso tempo, ma i bug fanno parte della vita di un programmatore.

Allora usiamo strumenti costruiti con i piedi, tanto i bug fanno parte della vita di un programmatore.
E' vero, ma strumenti migliori migliorano anche la vita. Python, per colpe di chi lo ha progettato si e' rivelato per me uno strumento peggiore su un progetto di grandi dimensioni.

Visto che gli errori alla guida fanno parte della vita, andiamo tutti in giro con una macchina con una ruota sgonfia
E cerchiamo di convincere gli altri che sia La Cosa Migliore Possibile (tm).

Con Python non si tratta di una questione sintattica, ma prettamente semantica...

Esatto. Un errore sintattico diventa un errore semantico per problemi di design e porta ad enormi perdite di tempo.

Che sia grave non ci sono dubbi: infatti hai perso un bel po' di tempo per quella che ritieni una sciocchezza. Sciocchezze che, però, ritrovi anche in altri linguaggi che hanno una sintassi più "rigorosa":

int i; scanf("%d", i);

Qui stai cambiando le carte in tavola
Il parallelo di quello che e' successo a me lo fai con questo codice:

scanf("%d", i);

Che ovviamente mi da' un errore di sintassi e non devo aspettare tre ore di esecuzione. Il design di Python trasforma un errore di sintassi in un bug subdolo. Questo e' un grosso problema dello strumento, non una mancanza del programmatore. Buoni strumenti limitano le possibilita' di errore a parita' di espressivita'. Sarebbe bastato, ad esempio, che come in Cobra potessi dichiarare un oggetto non aumentabile a run-time, da controllare staticamente, e senza modificare l'espressivita' del linguaggio avrebbe dato uno strumento piu' sicuro.

Hai pagato un prezzo elevato per una sciochezza, ma per la mia esperienza il gioco vale la candela

Nella mia esperienza e' valso un giorno e mezzo di lavoro perso per colpa di uno strumento inadeguato.

[cdimauro]

Non sto cambiando le carte in tavola, lo sai che non sono il tipo, Fran.

scanf non dà nessun errore sintattico, il codice viene compilato, e dio solo sa se e quando riuscirai a scoprire che mancava un & per passare il puntatore alla variabile anziché il suo valore. In ogni caso lo scopriresti a runtime.

E tutto perché? Perché il C come linguaggio non supporta il passaggio per riferimento e passa tutto per valore (in ogni caso, anche se l'avesse avuto, con funzioni che accettano un numero di argomenti variabile, come scanf appunto, il problema sarebbe rimasto ugualmente).

E' sicuramente colpa di chi l'ha progettato, che ha trasformato un errore sintattico (che linguaggi come il Pascal risolvono con l'uso della keyword VAR nella definizione dell'elenco dei parametri di una procedura/funzione) in uno semantico...

Sono d'accordo sull'uso degli strumenti migliori: lint per il C che ti fa scoprire quell'errore (semantico) con la scanf, e PyChecker per Python che fa saltare fuori la mancata dichiarazione di una variabile (meglio ancora SPE, che ha tutto integrato nell'IDE: Ctrl-Alt-C e il sorgente viene controllato semanticamente, oltre al controllo sintattico che di suo quest'IDE esegue in tempo reale mentre si sta scrivendo il codice).

Oggi come programmatori non possiamo affidarci esclusivamente al linguaggio, che è soltanto uno strumento: abbiamo la necessità di circondarci di diversi strumenti che concorrono a vario titolo alla produzione del codice finale. Non riesco a immaginare di lavorare in Java senza i comodi strumenti che IDE come Eclipse mettono a disposizione (tanto per fare un esempio con un linguaggio diverso da C e Python): la mia produttività ne risentirebbe sicuramente.

[fek]

Originariamente inviato da cdimauro

Non sto cambiando le carte in tavola, lo sai che non sono il tipo, Fran.

scanf non dà nessun errore sintattico, il codice viene compilato, e dio solo sa se e quando riuscirai a scoprire che mancava un & per passare il puntatore alla variabile anziché il suo valore. In ogni caso lo scopriresti a runtime.

Cesare, non mi sono spiegato. L'equivalente in C++ del bug che mi ha creato problemi e' questo:

something = object.m_Member;

m_Member non dichiarato. Questo e' un errore sintattico. Se prendi un altro esempio, puoi dimostrare qualunque cosa e il suo contrario.

Oggi come programmatori non possiamo affidarci esclusivamente al linguaggio,

Sicuramente. Ma se per errori banali che devono essere trovati prima ancora di lanciare l'applicazione, il linguaggio impone (non permette) l'esecuzione, allora il linguaggio ha un gravissimo problema. In altri linguaggi questo non accade, pur supportando la stessa espressivita' di Python, quindi sono strumenti migliori.

[cdimauro]

Non avevo capito che ti riferissi al problema che hai avuto.

Ho soltanto portato un esempio di un costrutto sintatticamente corretto in C, ma che a livello semantico genera problemi. Tutto qui.

[fek]

Originariamente inviato da cdimauro

Non avevo capito che ti riferissi al problema che hai avuto.

Ho soltanto portato un esempio di un costrutto sintatticamente corretto in C, ma che a livello semantico genera problemi. Tutto qui.

Quanti ne vuoi di esempi uguali in C++?
Il mio discorso si basa sul fatto che una cosa fondamentale come la presenza di una variable in un oggetto (dal quale non ho bisogno alcun comportamento dinamico) non sia validata a tempo di compilazione. Figurati che voglio usare un qualche tool che me la validi mentre scrivo il codice, per questo preferisco C#/Java a C++.

Mentre Python mi impone come design del linguaggio di pagare il prezzo di un oggetto dinamico anche quando questa feature non mi serve. Dai un'occhiata a Corba, non derivasse da Python sarebbe un gran linguaggio

A parte gli scherzi, unit testing e design by contract direttamente nel linguaggio, compila per .NET, sintassi pulita, forse un po' troppy Python-like (indentazione... grrrr), tipizzazione statica o dinamica a scelta. E' un linguaggio con un design chiaramente superiore a Python.

[cdimauro]

Proprio per questo l'ho segnalato.

Ha certi aspetti come lo unit testing e il design-by-contract che mi affascinano da sempre (anche la scelta fra tipizzazione statica o dinamica è interessante, ma poi ho visto gli esempi coi generic e mi sono cadute le braccia: è troppo comodo avere un tipo "generico" e... usarlo subito, come faccio adesso). Vedremo come si evolverà, perché promette bene.

Un'altra cosa che forse non hai notato è che non richiede l'indicazione di self come primo parametro nella definizione dei metodi e, per accedere alle variabili di istanza (o di classe, se non ricordo male) è sufficiente premettere il punto (es: .x = 0); e... non usa i due punti alla fine di un costrutto di definizione o controllo.

Mi sa che l'unica cosa che ti farà desistere dal provarlo rimane l'indentazione forzata...

[fek]

Originariamente inviato da cdimauro

Proprio per questo l'ho segnalato.

Ha certi aspetti come lo unit testing e il design-by-contract che mi affascinano da sempre (anche la scelta fra tipizzazione statica o dinamica è interessante, ma poi ho visto gli esempi coi generic e mi sono cadute le braccia: è troppo comodo avere un tipo "generico" e... usarlo subito, come faccio adesso). Vedremo come si evolverà, perché promette bene.

Un'altra cosa che forse non hai notato è che non richiede l'indicazione di self come primo parametro nella definizione dei metodi e, per accedere alle variabili di istanza (o di classe, se non ricordo male) è sufficiente premettere il punto (es: .x = 0); e... non usa i due punti alla fine di un costrutto di definizione o controllo.

Mi sa che l'unica cosa che ti farà desistere dal provarlo rimane l'indentazione forzata...

L'ho scaricato invece!
Ma mi sembra molto acerbo, non c'e' integrazione con VS2005/2008 e non ho capito come creare un oggetto da consumare in .NET. Appena mi sistemano queste due cosette lo provo piu' seriamente. DbC e Unit Testing nel linguaggio mi intrigano moltissimo.