[cdimauro]

Originariamente inviato da gugoXX

Sto cercando addirittura di eliminare le stored procedure in azienda.
E anche il javascript.
Basta, non ne posso piu' di spendere ore-uomo a debuggare problemi che potrebbero essere tirati fuori dal sistema prima di essere usato (compilazione).
E non parlatemi di test. Siamo pieni di test.
Ma in Javascript bisognerebbe testare tutto, tutto.
E nel passaggio alle chiamate alle Stored Procedure dei database pure.
E in Python forse non tutto, ma molto di piu' del C#.

Alt! Fermiamoci un attimo: spiegami perché non bisognerebbe usare le Stored Procedure. Solo perché si devono testare? E' normale: il codice VA testato, perché nessuno qui mi pare abbia la patente per tirare fuori codice con zero bug.

L'alternativa alle SP è scrivere lo stesso codice all'esterno del db, e quindi interrogandolo continuamente facendo transitare sulla rete TONNELLATE di dati che per lo più verranno SCARTATI perché filtrati in qualche modo dalla business logic.

Insomma, quelle porcate immani di script PHP (o ASP.NET) che fanno collassare i db a causa delle MIRIADI di select (in primis).
E qui hwupgrade ne sa qualcosa mi pare, visto l'enorme stress che hanno i server per gestire soltanto i forum...

Le SP sono una CONQUISTA a cui NON SI PUO' RINUNCIARE, per giunta proprio adesso che blasonati engine come MySQL si sono finalmente degnati di mettere a disposizione dopo che per DECENNI altri engine l'hanno fatto rendendo molto più facile la vita ai programmatori e ai manteiner del db.

In C# almeno se riesco a chiamare una funzione che accetta un intero, sono sicuro che a runtime la variabile esistera', e che non sara' NULL.
In javascript devo spendere ore per mettere tutti sti controlli.
Ore a debuggare o ore a mettere controlli, scegli come vuoi passare il tempo.

Debugger? Vade retro!

Test Driven Development.

I test servono e sono molto importanti. Siamo pieni di test? Io penso che siamo troppo carenti di test. Se siamo pieni di test e ci lamentiamo, per me vuol dire soltanto una cosa: I TEST SONO FATTI MALE.

Perché una unit-test fatta come fek, ehm, come dio comanda permette di dormire sonni tranquilli e lavorare al codice senza avere il terrore che qualcosa salti nel pezzo di codice X soltanto perché s'è cambiato il pezzo di codice Y.

Non dico che coi test si risolvano tutti i problemi: sarei un idiota se sostenessi una cosa del genere. Ma certamente un test ben fatto mette una buona ipoteca alla solidità del codice.

Ad esempio i problemi che hai sulle variabili NULL con JavaScript (ma anche con Python ci sono problematiche simili, eh! E Fran ne sa qualcosa, purtroppo ), sarebbero facilmente risolvibili.
Ti dirò di più: il problema di utilizzare variabili mai inizializzate con Python penso sia risolvibile con dei test che controllino ogni "biforcazione" del codice, che se ci pensi bene è la condizione minimale per testare del codice ("biforcazione" -> il codice segue due strade -> servono due test quanto meno per verificare ognuno dei rami -> se il test controlla ognuno dei rami, se ci sarà l'uso di qualche variabile non inizializzata verrà rilevato a causa dell'eccezione sollevata).

Da qualche tempo nella cartella di ogni progetto a cui lavoro ne è spuntata un'altra chiamata "Test" in cui infilo le varie unit test che sto realizzando.
Non è molto, ma man mano che ho qualche briciola di tempo mi sto organizzando per creare un ambiente simile a quello di Diamonds, con la batteria di test che si può lanciare in qualunque momento e che controlla in automatico tutti i test disponibili.
E' l'obiettivo che mi sono posto, e che devo cercare di raggiungere per migliorare la qualità del mio lavoro, ma soprattutto della mia vita.

Tra l'altro in questi giorni m'è venuta un'ideuzza su come realizzare dei test-case in Python lasciandoli dentro il codice, e devo fare qualche prova per vedere se effettivamente può aprire la strada per semplificare questo processo.

Originariamente inviato da cionci

Anche te non puoi pretendere che non dia fastidio vedere consigliare sempre lo stesso strumento, a ripetizione.

Guarda che io sono intervenuto proprio perché vedevo questa tiritera che si ripeteva ogni volta che si chiedeva quale linguaggio usare e per qualsiasi esigenza si rispondeva Python. Mi sembrava appunto una politica di evangelizzazione che sinceramente non mi va bene in sezione. Ora abbiamo appurato che Cesare ci crede davvero, anche tu ci credi. Puoi permettere che io non ci creda ? Oppure ti provoca fastidio ?

Non ho mai mancato di fornire argomentazioni, e non sono andato OT. Ma ne parlo meglio dopo.

Originariamente inviato da cionci

No, il discorso è partito da voglio fare un programma che legge il CPUID, la frequenza della CPU, la frequenza di bus e le temperature.
Quindi richiesta mirata e non generica.

Appunto. E ho fornito anche una soluzione parziale, ma funzionante, che dimostra che il problema è facilmente risolvibile anche con Python.

Se la mia fosse una politica di evangelizzazione fine a se stessa non avrei speso ORE E ORE del mio tempo ad argomentare, fornire spiegazioni, consigli, e anche codice bello e pronto. Avrei detto: "usa Python che è il più fico", e la cosa sarebbe finita lì.

Siccome non mi considero né un troll né un fanatico integralista, non ho mancato di disquisire e di confrontarmi, e anche di ammettere di aver commesso un errore quando è capitato.

Originariamente inviato da dupa

finalmente qualcuno che la pensa (quasi) come me.
si impara a programmare partendo da qui:

Guarda, sul C da usare per imparare a programmare troverai persino Fran ben disposto a piantarti con sommo piacere i chiodi da 20 per attaccarti alla croce...

Originariamente inviato da gugoXX

Be, forse il C non lo consiglierei per imparare (forse non lo consiglierei piu'), ma sicuramente da qualcosa di semplice senza troppi tecnicismi di linguaggio ne' di IDE.
Qualcosa che permetta di contare da 1 a 100 in fretta, stampando su schermo.
Va benissimo il Python, ma altrettanto bene tanti altri.

for i in range(1, 101): print i

Ancora meglio andrebbe secondo me un bel Commodore Vic20, con 5K di RAM.
Accendi e sei subito pronto per scrivere in Basic. Non puoi fare nient'altro.

GLOM. Lo ricordo fin troppo bene: BASIC di Commodore Vic 20 & 64 = SPAGHETTI BASIC!!! No, grazie.

Con Python hai già una shell interattiva che è comodissima per smanettare e pacioccare liberamente col codice. Ottima per imparare, ma anche per il lavoro di tutti i giorni per provare velocemente pezzi di codice senza necessariamente lanciare un'applicazione. Impagabile.
EDIT:

Originariamente inviato da fek

Eccolo qui.
E' la gara a chi evangelizza il suo linguaggio del cuore, possibilmente senza leggere le decine di volte nelle quali e' stato contraddetto.

C.V.D.