[C++]Unire più file .exe

[MasterDany]

adesso cionci

per favore fek

[gugoXX]

Originariamente inviato da DioBrando

Alla luce di quanto è stato scritto non mi sembra così fuori dal mondo sostituire C# a Python: posso disporre delle librerie C/C++, del framework NET (tanto + che IronPython è scritto a sua volta in C# quindi è perfettamente coerente con l'ambiente NET), insomma non mi sembra così malvagio.

Ma e' la stessa cosa che dico io.
Usate Python, usate C#, usate quello che volete.
Pero' non dite ai Niubbi che Python e' 10 volte piu' veloce a scriversi e 10 volte meglio del C#, perche' questo e' opinabile, e secondo me non e' vero.
La mia critica era solo per il fattore 10.

E sul dynamic typing, del quale non sono per nulla un fan.
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#.

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.

[cionci]

Originariamente inviato da DioBrando

Tipo quali?

Se magari ti prendevi la briga di leggere le ultime pagine le trovavi.

Originariamente inviato da DioBrando

Meglio informarsi prima e poi discuterne no?

Credi che mi sia messo a discutere su Python senza averlo osservato bene ? Dire studiato, certo sarebbe dire troppo. E' altresì chiaro che non posso saperne quanto uno che ci lavora tutti i giorni.

Originariamente inviato da DioBrando

Poi vedi tu, non puoi pretendere però che a certe persone non dia fastidio un atteggiamento simile.

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

Originariamente inviato da DioBrando

E da un mod magari magari mi aspetterei dell'altro, pur fatti patti saldi che il "de gustibus..." vale per tutti, mod compresi.

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 ?

[cionci]

Originariamente inviato da DioBrando

Il discorso cmq era partito dalla richiesta di fare un percorso didattico e sono state proposte due alternative.

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.

Originariamente inviato da fek

E cosi' avanti per venti pagine... Qui qualcuno ha perso di vista il concetto "Lo strumento giusto per il problema da risolvere".

Sinceramente...cosa avresti consigliato ?

[fek]

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.

Sinceramente...cosa avresti consigliato ?

C# + C++/CLI

[dupa]

Originariamente inviato da gugoXX

Eh. Purtroppo mi sa che al giorno d'oggi vengono fuori 3 righe di codice.

Confrontare il C# e il Python (o altri, ce ne sono tanti e tutti equivalenti) per decidere cosa usare per imparare a programmare secondo me e' una stortura.

Ma per Mazda sarebbe, secondo me, utile affrontare questo problema in modo classico. Con le Input (o scanf che dir si voglia), gli array, i cicli, etc.
Cosi' impara a programmare.
Il QBasic e' carino perche' puo' anche tralasciare lo studio dell'IDE, di compilatori, di linker, di runtime, Virtual Machine o altro.
Schiaccia un pulsante e gli viene fuori un exe
Ne schiaccia un altro e fa il debug.
80 colonne, pochi menu' per sbagliarsi (Se aprissi visualStudio 2008 oggi per la prima volta mi spaventerei e forse lascerei perdere tutto)

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

[gugoXX]

Originariamente inviato da dupa

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

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.
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.

[^TiGeRShArK^]

Originariamente inviato da dupa

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

e fu la fine

peccato che n + 1 persone ti hanno detto n! volte di essere partite da lì e di aver bestemmiato in aramaico per passare alla programmazione ad oggetti VERA dovendo estirpare a forza dalla mente la programmazione procedurale

[fek]

Originariamente inviato da dupa

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

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.

[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.

[gugoXX]

Originariamente inviato da cdimauro

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.

Non ho mai detto di rinunciare alle stored procedure.
Solo non vorrei vederle scritte nel linguaggio proprietario del DB di turno, che peraltro e' praticamente sempre un procedurale che puzza di vecchio (Con i controsensi che sto intuendo proprio in questo periodo dell'avere un linguaggio procedurale per gestire i dati strutturati di un DB)
E infatti sia in Oracle che in SqlServer (che sono tra i migliori, potete dire cosa volete), si possono scrivere StoredProcedure in Java nel primo, e in C# nel secondo.
Codice C# compilato, richiamabile dal C# di altri parti, debuggabile e testabile senza troppi problemi e con le possibilita' che permette tale linguaggio.
Sono pezzi di codice che vanno comunque a finire dentro il DB, ma scritti in un linguaggio che e' ben diverso dal PL/SQL o dal T-SQL.
Tutto all'interno della stessa soluzione, in progetti diversi, tanto che non ti sembra neppure di avere delle stored procedure.
E non ti sembra neppure di avere un database, dato che anche la definizione delle tabelle e delle viste si puo' fare "disegnando" un diagramma E-R, sempre in un opportuno modulo della soluzione.
Con la possibilita' non indifferente di usare, senza troppi salti mortali, i vari prodotti di SourceSafe, SubVersion & C.

E comunque non sarebbe neppure vero che il programmare in C# e basta genererebbe tanto traffico di rete.
Prima si', era facile cadere nella trappola. Ora con il LINQ non sarebbe piu' cosi' tanto vero, e lo sto sperimentando proprio in questi giorni.
Il motore LINQ genera al volo le istruzioni SQL da sottomettere al database, sono progettate per essere funzionali, e l'istruzione SQL viene generata tutta insieme e sottomessa al database senza dover scartare nulla, se l'ho sfruttata bene.

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.

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.

Ma sono d'accordo.
Sono stato tra i primi nell'azienda dove lavoravo prima a sfruttare il test driven development.
Pero' quello che appunto e' che se il linguaggio mi permette di fare meno test, tanto di guadagnato.
Ripeto, un test fatto bene in javascript dovrebbe controllare, per ciascuna funzione, la validita' di tutti i parametri.
E sono chili di codice di test che qualcuno deve scrivere, e che in C# non dovrebbe fare.
Se vado a leggere i test che sono stati fatti sul progetto in cui sto lavorando ora, sono tutti test che servono per coprire problemi a runtime, tipo valori inseriti o derivati dagli utenti o simili.
Se il linguaggio mi permette di avere meno errori a runtime, meno test dovro' scrivere.
Idem per le biforcazioni che suggerisci. E comunque il test dovrebbe essere scritto prima e a prescindere dalla implementazione dello sviluppatore, e idealmente da una persona diversa. Non dovresti sapere quali biforcazioni far fare ai test, dovrebbe essere tutto astratto.

Da qualche tempo nella cartella di ogni progetto a cui lavoro ne è spuntata un'altra chiamata "Test" ...
E' l'obiettivo che mi sono posto

E fai benissimo. In azienda da noi si usa uno stile di programmazione che si chiama Extreme Programming, uno dei cui pilastri e' proprio il test driven development.
Per come ci e' stato insegnato nei corsi iniziali, dopo la debita progettazione da parte degli architetti, i quali preparano anche i principali moduli da riempire, parte anche la QA. La QA e' il gruppo che si occupera' alla fine di ogni step, della Quality Assurance, ovvero in pratica a cercare i bachi.
Ma all'inzio di ogni step, intanto che non ha nulla da testare, dovrebbe (e dico dovrebbe perche' onestamente non lo fa quasi mai) scrivere i test per i vari moduli, indipendentemente dagli sviluppatori.
I quali aggiungeranno ovviamente i loro test, ma il concetto e' chiaro.

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

for (int u=0;u<100;u++)
   Console.WriteLine(u);

Enumerable.Range(1,100).ForEach( t => Console.Writeline(t) );

Secondo me cosi' non si impara a programmare.
Troppe cose insieme, non sai cosa fa veramente la macchina.
Non mi sembra che risolvano il cocetto mentale di algoritmo.

A me sembra servirebbe di piu' partire proprio con
- il concetto di variabile
- di assegnazione di valori ad una variabile
- di if.then.else
- di goto

Poi posso sbagliare, non sono un professore.

[DioBrando]

Originariamente inviato da gugoXX

Ma e' la stessa cosa che dico io.
Usate Python, usate C#, usate quello che volete.
Pero' non dite ai Niubbi che Python e' 10 volte piu' veloce a scriversi e 10 volte meglio del C#, perche' questo e' opinabile, e secondo me non e' vero.
La mia critica era solo per il fattore 10.

La parte a cui ti avevo risposto è quella che hai scelto di non quotare.
Te la ribadisco: Cesare ha scritto fattore 10 ammettendo poi però di aver esagerato non conoscendo in ogni caso granchè bene C#.
Fin qui ci siamo?

E sul dynamic typing, del quale non sono per nulla un fan.
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#.

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.

Al di là del discorso sui test, premesso che i linguaggi dinamicamente tipati mi piacciono, la comparazione con Javascript è un po' debole, nel senso che lì i problemi sono tanti e derivano oltre che dal design anche dalle scelte burocratiche.
Di fatto gli sviluppatori web sono in balia di standard-nonstandard, di implementazioni che dipendono poi a monte dalle SWHouse che rilasciano i browser e se vuoi anche dalla libertà dell'utente (perchè nel momento in cui javascript è disabilitato, puoi spesso e volentieri dire addio alla tua bella webapp AJAX...ecco perchè predico a lavoro siti accessibili, fintantochè posso).
Ci sono framework, ci sono tentativi di darci un linguaggio di scripting client-side che sia un minimo + coerente e omogeneo ma nzomma...la strada è lunga al di là dei proclami MS-Mozilla.

[gugoXX]

Originariamente inviato da DioBrando

La parte a cui ti avevo risposto è quella che hai scelto di non quotare.
Te la ribadisco: Cesare ha scritto fattore 10 ammettendo poi però di aver esagerato non conoscendo in ogni caso granchè bene C#.
Fin qui ci siamo?

Si', ok, ho capito che forse ho travisato io e me ne scuso.
Quello su cui infatti stavo dibattendo prima con lui non era sul fattore 10 o 2.
Volevo far passare che secondo me non c'e' proprio alcun fattore, e sulla velocita' di sviluppo sono tanto uguali.
P.Es. Mi e' sembrato a tratti di intuire che non si conoscesse la versione Funzionale del C#, e che fosse usata come vessillo per muovere il consenso verso Python.

Poi ripeto, per me quello che fa di piu' e' la libreria.
Non servira' a nulla, ma in 8 righe di codice posso far dire "Good Morning Vietnam", posso leggere la temperatura della CPU e intanto (E' asincrono ) suonare in streaming una WebRadio.
Sono tutti giochini che servono a poco, ma mi sembra che 9 interventi su 10 su questo forum siano proprio per questi giochini.
E che magari si potranno anche fare in IronPython, ma mi sembra di aver capito che qui nessuno possa aiutare in questa direzione.

PS: L'ho scaricato IronPython. Ma ho delle domande da fare...

[cdimauro]

Originariamente inviato da gugoXX

Non ho mai detto di rinunciare alle stored procedure.
Solo non vorrei vederle scritte nel linguaggio proprietario del DB di turno, che peraltro e' praticamente sempre un procedurale che puzza di vecchio (Con i controsensi che sto intuendo proprio in questo periodo dell'avere un linguaggio procedurale per gestire i dati strutturati di un DB)
E infatti sia in Oracle che in SqlServer (che sono tra i migliori, potete dire cosa volete), si possono scrivere StoredProcedure in Java nel primo, e in C# nel secondo.
Codice C# compilato, richiamabile dal C# di altri parti, debuggabile e testabile senza troppi problemi e con le possibilita' che permette tale linguaggio.
Sono pezzi di codice che vanno comunque a finire dentro il DB, ma scritti in un linguaggio che e' ben diverso dal PL/SQL o dal T-SQL.
Tutto all'interno della stessa soluzione, in progetti diversi, tanto che non ti sembra neppure di avere delle stored procedure.
E non ti sembra neppure di avere un database, dato che anche la definizione delle tabelle e delle viste si puo' fare "disegnando" un diagramma E-R, sempre in un opportuno modulo della soluzione.
Con la possibilita' non indifferente di usare, senza troppi salti mortali, i vari prodotti di SourceSafe, SubVersion & C.

Adesso il discorso cambia completamente e sono d'accordo. Tra l'altro è proprio l'orientamento degli engine SQL quello di integrare il supporto ai linguaggi di programmazione tradizionali.

E comunque non sarebbe neppure vero che il programmare in C# e basta genererebbe tanto traffico di rete.
Prima si', era facile cadere nella trappola. Ora con il LINQ non sarebbe piu' cosi' tanto vero, e lo sto sperimentando proprio in questi giorni.
Il motore LINQ genera al volo le istruzioni SQL da sottomettere al database, sono progettate per essere funzionali, e l'istruzione SQL viene generata tutta insieme e sottomessa al database senza dover scartare nulla, se l'ho sfruttata bene.

Non penso risolva pienamente il problema.

In una SP capita, ad esempio, di eseguire un ciclo su un certo numero n di record per poi lavorarci, scartarne alcuni e infine tornare soltanto gli m <= n i dati che servono.

Delegando all'esterno le operazioni, in ogni caso i dati degli n record dovranno essere prelevati dall'applicazione, elaborarli, e poi si dovranno eseguire eventuali altre m <= n query per recuperare le informazioni finali.

C'è un passaggio di dati inutile fra client e server: con le SP il primo riceve soltanto i dati che gli servono.

Non so se sono stato chiaro.

Ma sono d'accordo.
Sono stato tra i primi nell'azienda dove lavoravo prima a sfruttare il test driven development.
Pero' quello che appunto e' che se il linguaggio mi permette di fare meno test, tanto di guadagnato.
Ripeto, un test fatto bene in javascript dovrebbe controllare, per ciascuna funzione, la validita' di tutti i parametri.
E sono chili di codice di test che qualcuno deve scrivere, e che in C# non dovrebbe fare.
Se vado a leggere i test che sono stati fatti sul progetto in cui sto lavorando ora, sono tutti test che servono per coprire problemi a runtime, tipo valori inseriti o derivati dagli utenti o simili.
Se il linguaggio mi permette di avere meno errori a runtime, meno test dovro' scrivere.
Idem per le biforcazioni che suggerisci. E comunque il test dovrebbe essere scritto prima e a prescindere dalla implementazione dello sviluppatore, e idealmente da una persona diversa. Non dovresti sapere quali biforcazioni far fare ai test, dovrebbe essere tutto astratto.

E fai benissimo. In azienda da noi si usa uno stile di programmazione che si chiama Extreme Programming, uno dei cui pilastri e' proprio il test driven development.
Per come ci e' stato insegnato nei corsi iniziali, dopo la debita progettazione da parte degli architetti, i quali preparano anche i principali moduli da riempire, parte anche la QA. La QA e' il gruppo che si occupera' alla fine di ogni step, della Quality Assurance, ovvero in pratica a cercare i bachi.
Ma all'inzio di ogni step, intanto che non ha nulla da testare, dovrebbe (e dico dovrebbe perche' onestamente non lo fa quasi mai) scrivere i test per i vari moduli, indipendentemente dagli sviluppatori.
I quali aggiungeranno ovviamente i loro test, ma il concetto e' chiaro.

Mumble. Con la TDD ho imparato che prima si scrivono i test, e poi il codice (che, all'inizio, deve far fallire il test per indicare la condizione d'errore -> il requisito non soddisfatto oppure il bug che viene "esercitato").

Il codice non va progettato in maniera tradizionale: viene costruito in maniera evolutiva in base anche alle condizioni che, e lo sappiamo benissimo, cambiano col tempo.

Ecco qui http://martinfowler.com/articles/designDead.html un ECCELLENTE articolo sull'argomento. E' lunghetto, ma ne vale la pena.

for (int u=0;u<100;u++)
   Console.WriteLine(u);

Enumerable.Range(1,100).ForEach( t => Console.Writeline(t) );

Secondo me cosi' non si impara a programmare.
Troppe cose insieme, non sai cosa fa veramente la macchina.
Non mi sembra che risolvano il cocetto mentale di algoritmo.

Non c'è alcun bisogno di conoscere cosa fa "veramente" la macchina per imparare a programmare: i programmatori devono risolvere problemi, non studiarsi le architetture su cui girano le applicazioni (che tra l'altro possono anche cambiare).

A me sembra servirebbe di piu' partire proprio con
- il concetto di variabile
- di assegnazione di valori ad una variabile
- di if.then.else
- di goto

Poi posso sbagliare, non sono un professore.

Nooo. Ti prego, il goto nooooo!!!

IMHO bisogna partire dal concetto di dato, tipo di dato, operazione, condizione, e così via.

[DioBrando]

Originariamente inviato da cionci

Se magari ti prendevi la briga di leggere le ultime pagine le trovavi.

Ah scusa no perchè io rispondo senza leggere quello che gli altri mi scrivono...naturalmente quoto anche a caso perchè non leggendo n posso fare altro.

I discorsi sugli IDE sono stati enucleati, accesso a framework NET, disponibilità di librerie C/C++ idem.
C'è altro? (e due)

Credi che mi sia messo a discutere su Python senza averlo osservato bene ? Dire studiato, certo sarebbe dire troppo. E' altresì chiaro che non posso saperne quanto uno che ci lavora tutti i giorni.

Non l'ho mai detto che non hai nemmeno dato un occhiata al codice che produce, ma permettimi che se spari nel mucchio dicendo che non è supportato dal framework NET oppure te ne esci non sapendo che in Python realmente tutto è un oggetto, non mi dai l'idea di saperne così tanto da poter confutare opinioni di chi ci ha lavorato dimostrando di essere produttivo + di prima quando usava evidentemente strumenti diversi.
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.

Ed io ti ribadisco che non è così, state esagerando.
Riprendete i thread in cui sono intervenuto io o Cesare e leggete

Mi sembrava appunto una politica di evangelizzazione che sinceramente non mi va bene in sezione.

A parte il fatto che il termine evangelizzazione mi sembra improprio (perchè in italiano ha una valenza religiosa che proprio per questo si basa su argomentazioni che non sono confutabili: o credi o non credi...quindi la traduzione dall'inglese "evangelist" non è corretta perchè ha una connotazione semantica totalmente diversa), ti ripeto che
1) sono stati dati tanti suggerimenti su richieste da parte di n utenti che non fossero solo "Python", ma strumenti che io o chi altri riteniamo fossero in quello specifico consigliabili.
Quindi mi fai la cortesia prima di ripetere per la decima volta "consigliate solo Python", di riprendere quei thread e guardarteli con attenzione.
Se non lo fai tu, lo faccio io e te li linko qui.
Basta che la si smetta con questa nenia, che è oltre che noiosa piuttosto offensiva (mi ritengo una persona un pelo pià intelligente di un automa che ripete quella e sempre quella).

2) i consigli sono sempre stati circostanziati, con argomentazioni che ovviamente possono essere criticabili e a cui si può obiettare con delle altre, ma sono ben lontano dal concetto di "evangelizzare"

Ora abbiamo appurato che Cesare ci crede davvero, anche tu ci credi.

Ma credo in cosa?
Stai cominciando ad irritarmi, dico davvero.
Anche perchè distorci fatti e parole a tuo uso e consumo.
Da una persona equilibrata oltre che super parte mi aspetto dell'altro e di meglio soprattutto.

Puoi permettere che io non ci creda ? Oppure ti provoca fastidio ?

Tu puoi credere o non credere in quello che ti pare.
Sono mai venuto a sindacare?
Non lo farei mai e visto che mi hai visto scrivere da qualche anno non serve che te lo spieghi.
Quello che mi dà fastidio è che primo si faccia di un'erba un fascio, secondo si parli a volte senza cognizione di causa.
Questo sì mi dà molto fastidio.

[DioBrando]

Originariamente inviato da gugoXX

Si', ok, ho capito che forse ho travisato io e me ne scuso.
Quello su cui infatti stavo dibattendo prima con lui non era sul fattore 10 o 2.
Volevo far passare che secondo me non c'e' proprio alcun fattore, e sulla velocita' di sviluppo sono tanto uguali.
P.Es. Mi e' sembrato a tratti di intuire che non si conoscesse la versione Funzionale del C#, e che fosse usata come vessillo per muovere il consenso verso Python.

Poi ripeto, per me quello che fa di piu' e' la libreria.
Non servira' a nulla, ma in 8 righe di codice posso far dire "Good Morning Vietnam", posso leggere la temperatura della CPU e intanto (E' asincrono ) suonare in streaming una WebRadio.
Sono tutti giochini che servono a poco, ma mi sembra che 9 interventi su 10 su questo forum siano proprio per questi giochini.
E che magari si potranno anche fare in IronPython, ma mi sembra di aver capito che qui nessuno possa aiutare in questa direzione.

PS: L'ho scaricato IronPython. Ma ho delle domande da fare...

Ok non c'è problema fraintendimento risolto

Io ci ho smanettato l'anno scorso scoprendolo alla conferenza, poi per motivi di tempo ecc. non ho approfondito e non è che mi ricordi moltissimo.
Boh puoi provare a chiedermi.
Mmm pvt? Vabbè che qui con gli OT...

[gugoXX]

Originariamente inviato da cdimauro

Non penso risolva pienamente il problema.

In una SP capita, ad esempio, di eseguire un ciclo su un certo numero n di record per poi lavorarci, scartarne alcuni e infine tornare soltanto gli m <= n i dati che servono.

Delegando all'esterno le operazioni, in ogni caso i dati degli n record dovranno essere prelevati dall'applicazione, elaborarli, e poi si dovranno eseguire eventuali altre m <= n query per recuperare le informazioni finali.

C'è un passaggio di dati inutile fra client e server: con le SP il primo riceve soltanto i dati che gli servono.

Non so se sono stato chiaro.

Ho capito benissimo. Proprio in questo periodo sto cercando di capire il limite di questo approccio "puro".
Muovi pero' il LINQ sulle stored procedure del database scritte in C#. Una pacchia.

Nooo. Ti prego, il goto nooooo!!!

IMHO bisogna partire dal concetto di dato, tipo di dato, operazione, condizione, e così via.

E' il discorso - se lo conosci lo eviti -.
A parte gli scherzi mi sembra concettualmente corretto insegnare il goto.
E' insito anche nei flow-chart (ma si insegnano ancora?)
Per il resto sono d'accordo.

[DioBrando]

Originariamente inviato da ^TiGeRShArK^

e fu la fine

peccato che n + 1 persone ti hanno detto n! volte di essere partite da lì e di aver bestemmiato in aramaico per passare alla programmazione ad oggetti VERA dovendo estirpare a forza dalla mente la programmazione procedurale

Cmq il K&R per l'età che ha è stato pioneristico nell'impaginazione

Cerco di sorridere di fronte ai discorsi in loop che saltano puntualmente fuori

[cdimauro]

Originariamente inviato da gugoXX

Ho capito benissimo. Proprio in questo periodo sto cercando di capire il limite di questo approccio "puro".
Muovi pero' il LINQ sulle stored procedure del database scritte in C#. Una pacchia.

Immagino, e lo vedrai sicuramente a breve.

E' il discorso - se lo conosci lo eviti -.
A parte gli scherzi mi sembra concettualmente corretto insegnare il goto.
E' insito anche nei flow-chart (ma si insegnano ancora?)
Per il resto sono d'accordo.

Li insegnano suppongo, ma dovrebbero anche insegnare un famosissimo (non per Torvalds ) teorema che dimostra la possibilità di eliminare completamente il goto usando gli altri costrutti iterativi (eventualmente con l'aggiunta di opportune variabili booleane).

GOTO IS EVIL!

Tra l'altro esistono linguaggi come Python (ma anche Modula & derivati / successori) che NON hanno proprio il goto come istruzione.

P.S. Comunque la versione "funzionale" del C# la conosco fin da quando Fran mi passò, molto tempo fa, il link a un articolo che parlava della versione 3.0 del linguaggio che a breve sarebbe arrivata.

[fek]

Originariamente inviato da DioBrando

A parte il fatto che il termine evangelizzazione mi sembra improprio (perchè in italiano ha una valenza religiosa che proprio per questo si basa su argomentazioni che non sono confutabili: o credi o non credi...quindi la traduzione dall'inglese "evangelist" non è corretta perchè ha una connotazione semantica totalmente diversa), ti ripeto che

Anche a me sembra un tentativo di evangelizzazione e non nella terminologia inglese. Mi ricorda da vicinissimo l'evangelizzazione degli Apple fanatici