consiglio su come iniziare a programmare

[fek]

Originariamente inviato da k0nt3

ps. aggiungo che secondo me dovreste mettere il sorgente di diamond nel vostro sito (e se c'è già dovreste metterlo più visibile perchè io non l'ho visto)

http://fcarucci.homeip.net:8080/crui...sults/diamonds

Sotto Build Artifacts trovi l'eseguibile e tutti i sorgenti dopo ogni commit.

[PGI-Bis]

Originariamente inviato da fek

Sai perche' senza if e' migliore? Perche' hai scritto 50 righe di testo, giustissime, quando pero' il concetto era solo: e' migliore perche' e' piu' semplice e chiaro. Bastavano tre parole: sintesi, semplicita' e chiarezza

Solo Fowler (tiè ) può ritenere che basti dire "sintesi, semplicità e chiarezza" e voltar l'angolo. Perchè se io dico che

strigapumpamphlet()

è più sintetico semplice e chiaro di

leggiIlFile()

hai voglia a dire "non è vero" se non sai perchè o quantomeno se non cerchi di dare un possibile perchè.

Ma ho il sentore che ci stiamo avventurando in una discussione già tentata .

[k0nt3]

Originariamente inviato da fek

http://fcarucci.homeip.net:8080/crui...sults/diamonds

Sotto Build Artifacts trovi l'eseguibile e tutti i sorgenti dopo ogni commit.

ormai l'ho scaricato via SVN

[fek]

Originariamente inviato da PGI-Bis

Non stupirà nessuno sapere che l'if non sia affatto cattivo in sè. Il problema è che sembra avvezzo, per la sua natura "ramificante", a generare strutture di controllo particolarmente "profonde", dove la profondità è misurata nel numero di controlli che devono essere verificati affinchè si giunga ad un'istruzione che non scaturisca in un altra "decisione".

Ti do' una risposta piu' articolata perche' comunque il discorso e' interessante. Quell'if e' cattivo perche' aumenta la complessita' ciclomatica del codice. La complessita' ciclomatica, detto alla buona, misura il numero di test necessari a percorrere tutti i control flow di un metodo, per coprirlo interamente.

Per una formulazione piu' rigorosa, puoi partire da Wikipedia che contiene i link ai paper di McCabe:

http://en.wikipedia.org/wiki/Cyclomatic_complexity

Detto ancora piu' alla buona, la complessita' ciclomatica e' una misura della complessita del codice che si scrive. E' dimostrato empiricamente che il numero di difetti nel codice e' direttamente proporzionale alla sua complessita' ciclomatica. Intuitivamente, codice meno complesso e' piu' facile da mantenere e gestire.

Qui un paper che affronta questa proporzione diretta in maniera piu' rigorosa:

http://www.cs.umd.edu/users/mvz/pub/tian95.pdf

Un modo veloce per misurare la complessita' ciclomatica del codice e' contare il numero di if/for/switch/while. In sintesi: se tolgo quell'if diminuisco la complessita' ciclomatica della mia soluzione, quindi diminuisco la complessita' del codice, quindi diminuisco il numero di test necessari per testarlo e diminuisco la probabilita' di avere difetti nel codice che ho scritto. Lo scopo di molti dei Refactoring di Fowler e' diminuire la complessita' ciclomatica.

Ecco un altro motivo per il quale Java e' preferibile al C per un principiante: e' piu' facile scrivere codice con complessita' ciclomatica bassa.

[k0nt3]

molto interessante questo discorso di 7-+2 e anche di 80 e passa

[fek]

Originariamente inviato da PGI-Bis

Solo Fowler (tiè ) può ritenere che basti dire "sintesi, semplicità e chiarezza" e voltar l'angolo. Perchè se io dico che

strigapumpamphlet()

è più sintetico semplice e chiaro di

leggiIlFile()

hai voglia a dire "non è vero" se non sai perchè o quantomeno se non cerchi di dare un possibile perchè.

Ma ho il sentore che ci stiamo avventurando in una discussione già tentata .

Risposta facile: strigapumpamphlet non descrive quello che il codice fa come leggiIlFile e non fa parte del dominio del problema

[fek]

E infine, gli if sono una brutta cosa nelle architetture in-order come il Cell o l'XCPU, prenche' introducono branch nel codice e la CPU non puo' riordinare le istruzioni da eseguire o fare esecuzione speculativa. I branch sono dei killer di performance su queste CPU. Si', sto lottando contro gli if al lavoro perche' l'XCPU e' un chiodo altrimenti

[71104]

Originariamente inviato da fek

Tu sei pazzo e non conti

sono in tanti, mica solo io

di tanto in tanto all'università la gente mi viene a chiedere spiegazioni su come funzionano cose che i professori non spiegano (che ovviamente sono tante); particolarmente gettonate sono le interfacce grafiche (visto che all'università in C si fanno solo programmi CUI), ma non sono assolutamente l'unico argomento.

a certa gente piace capire molto in dettaglio il funzionamento delle cose, è naturale curiosità e in me è sempre stata particolarmente sviluppata; ricordo ancora quando a 14 anni col debugger entravo nella VCL di Delphi e analizzavo il codice passo-passo perché volevo ASSOLUTAMENTE capire come faceva un programma Delphi a disegnare la GUI...

bei tempi :')

con questo sistema scoprii le API Win32

Fai unit testing in C

domanda non provocatoria: quali sarebbero le difficoltà?

Su Design And Evolution of C++ di Stroustrup c'e' una descrizione di una possibile estensione del C++ che aggiunga il concetto di include al linguaggio e non via direttiva di preprocessing. E' molto interessante. Per altro, e' un libro che DEVI leggere.

ok, lo aggiungo alla wishlist

[fek]

Originariamente inviato da 71104

domanda non provocatoria: quali sarebbero le difficoltà?

Non e' banale ad esempio scrivere un Mock... quando il linguaggio non ha il concetto di classe o interfaccia

[marco.r]

Sulla questione sono fondamentalmente d'accordo con fek (a parte la scelta del linguaggio, visto che preferisco Python, ma de gustibus... ).
Imparare a programmare è come imparare a girare una grossa città. Si può cominciare dalle basi, girandola a piedi, e nel corso degli anni imparare a menadito tutti i vicoli, i sottoscala e le gradinate per arrivare prima a destinazione. Poi pero' quando finalmente cominci a girarla in macchina devi imparare che nonostante lo scopo sia lo stesso, e il metodo fondamentalmente uguale, la strada da percorrere per arrivare all'altro capo della città non sono le viette del centro ma la tangenziale .

[k0nt3]

Originariamente inviato da marco.r

Imparare a programmare è come imparare a girare una grossa città. Si può cominciare dalle basi, girandola a piedi, e nel corso degli anni imparare a menadito tutti i vicoli, i sottoscala e le gradinate per arrivare prima a destinazione. Poi pero' quando finalmente cominci a girarla in macchina devi imparare che nonostante lo scopo sia lo stesso, e il metodo fondamentalmente uguale, la strada da percorrere per arrivare all'altro capo della città non sono le viette del centro ma la tangenziale .

infatti la macchina te la danno a 18 anni per cui non puoi iniziare in macchina

[wingman87]

Originariamente inviato da 71104

fidati, il C++ lo impareresti molto prima se non avessi studiato Visual Basic. fek non può che essere d'accordo con me, almeno se ti riferisci alla versione 6 di VB.

Sì, mi riferisco al 6, comunque anche se non stessi studiando VB andrei alla stessa velocità xk sto semplicemente seguendo il corso di scuola, tempo di lavorare da solo a casa non ne ho molto purtroppo, quindi in fondo mi va bene che stia imparando il VB6, in fondo è sempre un linguaggio in +..

Riguardo al filmato del browser è molto carino, ma pensavo, avendo a disposizione gli stessi oggetti non si potrebbe fare la stessa cosa anche in VB?

[71104]

Originariamente inviato da fek

Non e' banale ad esempio scrivere un Mock... quando il linguaggio non ha il concetto di classe o interfaccia

se facciamo finta che una "translation unit" sia l'analogo di una classe, per crearne un mock basta creare il file contenente le stesse funzioni in versione mock, poi per compilare usando il mock al posto del file vero basta lavorare di path nei makefiles
esempio: nei makefiles puoi definire una macro $(MOCK_PATH) che in configurazione "Run" (per così dire) sia nulla, mentre in configurazione "Test" sia uguale a "Mock/" se per esempio tutti i mock li hai messi in una directory di nome "Mock"; se poi nei makefiles usi questa macro nei path, le translation unit cambiano a seconda che compili in "configurazione Run" o "Test". ti assicuro che si perde molto meno tempo a farlo che a dirlo, sebbene io rimanga d'accordo che con istanze di classi sia tutto più semplice; volevo solo dire che non è impossibile

EDIT: in alternativa, in caso nel testing di certi programmi si debbano usare le versioni mock di alcune translation units in certi test e le versioni originali in altri test, la cosa si complica un po' ma anche qui nulla è impossibile e si fa prima a farlo che a spiegarlo.

sempre agendo nei makefiles, si potrebbe richiedere al compilatore la generazione di tutti i file oggetto, sia originali che mock, e poi si potrebbe effettuare un linking diverso a seconda del test; naturalmente nella configurazione "Run" i mock non sarebbero mai linkati.

il tutto viene molto più efficiente di quello che sembra visto che il make richiama solo le regole le cui dipendenze si risolvono in files con data di modifica anteriore a quella in cui si risolve la regola stessa.

[cdimauro]

Originariamente inviato da 71104

ma io mica ho nulla contro BASIC, tant'è vero che QBasic è stato il secondo linguaggio che ho imparato

Per me è stato il primo, seguito poco dopo l'assembly (6502 ).

il mio è odio razziale verso VISUAL Basic... e non penso ci voglia molto a capire perché

Sinceramente ho difficoltà a capirlo, visto che per parecchio tempo ho sviluppato applicazioni (commercializzate) in VisualBasic. L'ho abbandonato alla versione 6 (sono passato del tutto a Delphi ), ma ho continuato a seguirne l'evoluzione.

[cdimauro]

Originariamente inviato da Th3 Kn0wl3dg3

mi state facendo confondere ancora di più!

Quel che avevo da dire l'ho già detto. Ti riporto l'introduzione del primo link che t'ho segnalato (evidenziandone alcune parti), che non è strettamente tecnica, per farti capire il perché della scelta di Python (o comunque di altri linguaggi di alto livello) nel tuo caso sarebbe l'ideale:

Introduzione

Di David Beazley

In qualità di educatore, ricercatore e autore di libri, sono lieto di assistere alla conclusione della stesura di questo testo. Python è un linguaggio di programmazione divertente e semplice da usare, la cui popolarità è andata via via crescendo nel corso degli ultimi anni. Python è stato sviluppato più di dieci anni fa da Guido van Rossum che ne ha derivato semplicità di sintassi e facilità d'uso in gran parte da ABC, un linguaggio dedicato all'insegnamento sviluppato negli anni '80. Oltre che per questo specifico contesto, Python è stato creato per risolvere problemi reali, dimostrando di possedere un'ampia varietà di caratteristiche tipiche di linguaggi di programmazione quali C++, Java, Modula-3 e Scheme. Questo giustifica una delle sue più rimarchevoli caratteristiche: l'ampio consenso nell'ambito degli sviluppatori professionisti di software, in ambiente scientifico e di ricerca, tra i creativi e gli educatori.

Nonostante l'interesse riscosso da Python in ambienti così disparati, potresti ancora chiederti "Perché Python?" o "Perché insegnare la programmazione con Python?". Rispondere a queste domande non è cosa semplice, specialmente quando l'interesse generale è rivolto ad alternative più masochistiche quali C++ e Java. Penso comunque che la risposta più diretta sia che la programmazione in Python è semplice, divertente e più produttiva.

Quando tengo corsi di informatica, il mio intento è quello di spiegare concetti importanti interessando ed intrattenendo nel contempo gli studenti. Sfortunatamente nei corsi introduttivi c'è la tendenza a focalizzare troppo l'attenzione sull'astrazione matematica e nel caso degli studenti a sentirsi frustrati a causa di fastidiosi problemi legati a dettagli di basso livello della sintassi, della compilazione e dall'imposizione di regole poco intuitive. Sebbene questa astrazione e questo formalismo siano importanti per il progettista di software professionale e per gli studenti che hanno intenzione di proseguire i loro studi di informatica, questo approccio in un corso introduttivo porta solitamente a rendere l'informatica noiosa. Quando tengo un corso non voglio avere davanti una classe di studenti annoiati: preferirei piuttosto vederli impegnati a risolvere problemi interessanti esplorando idee diverse, approcci non convenzionali, infrangendo le regole e imparando dai loro stessi errori.

Inoltre non voglio sprecare mezzo semestre a risolvere oscuri problemi di sintassi, cercando di capire messaggi del compilatore generalmente incomprensibili o di far fronte al centinaio di modi in cui un programma può generare un "general protection fault".

Una delle ragioni per cui mi piace Python è che esso permette un ottimo equilibrio tra l'aspetto pratico e quello concettuale. Dato che Python è interpretato, gli studenti possono fare qualcosa quasi subito senza perdersi in problemi di compilazione e link. Inoltre Python è fornito di un'ampia libreria di moduli che possono essere usati in ogni sorta di contesto, dalla programmazione web alla grafica. Questo aspetto pratico è un ottimo sistema per impegnare gli studenti e permette loro di portare a termine progetti non banali. Python può anche servire come eccellente punto di partenza per introdurre importanti concetti di informatica: dato che supporta procedure e classi, possono essere gradualmente introdotti argomenti quali l'astrazione procedurale, le strutture di dati e la programmazione ad oggetti, tutti solitamente relegati a corsi avanzati di Java o C++. Python prende a prestito un certo numero di caratteristiche da linguaggi di programmazione funzionali e può essere quindi usato per introdurre concetti che sarebbero normalmente trattati in dettaglio in corsi di Scheme o di Lisp.

Leggendo la prefazione di Jeffrey sono rimasto colpito da un suo commento: Python gli ha permesso di ottenere "un livello generale di successo più elevato ed un minore livello di frustrazione", e gli è stato possibile muoversi "con maggiore velocità e con risultati migliori". Questi commenti si riferiscono al suo corso introduttivo: io uso Python per queste stesse ragioni in corsi di informatica avanzata all'Università di Chicago. In questi corsi sono costantemente messo di fronte alla difficoltà di dover coprire molti argomenti complessi in un periodo di appena nove settimane. Sebbene sia certamente possibile per me infliggere un bel po' di sofferenza usando un linguaggio come il C++, ho spesso trovato che questo approccio è controproducente, specialmente nel caso di corsi riguardanti la semplice programmazione. Ritengo che usare Python mi permetta di focalizzare meglio l'attenzione sull'argomento reale della lezione, consentendo nel contempo agli studenti di completare progetti concreti.

Sebbene Python sia un linguaggio ancora giovane ed in continua evoluzione, credo che esso abbia un futuro nel campo dell'insegnamento. Questo libro è un passo importante in questa direzione.

David Beazley, autore di Python Essential Reference
Università di Chicago

T'invito anche a leggere la prefazione dell'autore del libro, anch'essa non strettamente tecnica, in cui spiega com'è arrivato a usare Python, perché lo usa nel corso e perché lo consiglia.

[cdimauro]

Originariamente inviato da 71104

ciò che ha da invidiare cambia da versione a versione; la 6 ad esempio ha da invidiare una OOP decente.

La 6 è una versione vecchia di 10 anni, Alberto!

secondo me il BASIC è un linguaggio del passato forzato nel presente da quell'obbrobbrio di VB; può darsi che le versioni più recenti .NET siano migliori della 6, non saprei... ma ad ogni modo secondo me il BASIC nel 2006 può avere soltanto scopi didattici, niente più; le interfacce grafiche nel 2006 richiedono la OOP, e BASIC non è assolutamente nato per essere OO, quindi non è assolutamente in linea con essa.

Sei rimasto LEGGERMENTE indietro. Ripeto: VB(nella sua ultima incarnazione, .NET) non ha nulla da invidiare ad altri linguaggi blasonati.
Dai un'occhiata a questo link: http://msdn.microsoft.com/vbasic/def...5_overview.asp da cui ti estraggo un esempietto:

Public Class TypedVector(Of T)
    ' Create a one-dimensional array of 
    ' the specified type.
    Private arrayValue() As T

    Public Sub New(ByVal Size As Integer)
        ReDim arrayValue(Size - 1)
    End Sub

    Default Public Property Item(ByVal Index As Integer) As T
        Get
            Return arrayValue(Index)
        End Get
        Set(ByVal Value As T)
            arrayValue(Index) = Value
        End Set
    End Property
End Class

...

Dim myVector As New TypedVector(Of Integer)(4)
myVector(0) = 73
myVector(1) = 27

Un esempio d'uso dei generics.

il C99 non più!
è stato introdotto const, a quanto ne so. se ne sentiva veramente il bisogno, anche le estensioni del compilatore Microsoft (che di base è C89) includono const.

Complimenti: ci sono voluti 35 anni per introdurre questo concetto.

Il problema, Alberto, è che il C è un linguaggio lasciato nel dimenticatoio, la cui evoluzione è stata soffocata dal C++.

Tutto ciò ha portato all'uso e alla richiesta di usare quasi sempre la versione ANSI, ma non la 99.

hum, su questo posso anche essere d'accordo: a causa dell'inclusione manuale il programmatore è sempre costretto a proteggere gli headers dall'inclusione multipla; ma bisognerebbe anche vedere se sia possibile realizzare in C/C++ un sistema di packages (stile Java) che non tolga potenza e controllo al programmatore: più automatizzi meno dai la possibilità di controllare.

E' una cosa che hanno fatto da decenni altri linguaggi, senza per questo intaccare la loro efficienza / potenzialità. Tutt'altro.

Un modulo/unit/package diciamo che è un contenitore di simboli, riferimenti e codice: è qualcosa di più di un semplice file oggetto, insomma, ma NIENTE DI MENO.

A te cambia qualcosa se dentro al .o, oltre ai simboli e al codice, infilano altro? Nulla. In fase di compilazione dell'eseguibile, verranno del tutto rimosse.

E' una grossa mancanza che i produttori di compilatori hanno cercato di sopperire con gli header precompilati, ma non è certo la stessa cosa.

su certe cose il controllo non serve, ma in C il controllo di ogni minimo aspetto della situazione serve sempre perché il C è il linguaggio usato ad esempio per programmare i kernel dei sistemi operativi e altri componenti di sistema.

Il C non è condizione necessaria per sviluppare questo tipo di applicazioni.
http://www.petros-project.com/pages/info.htm

"PETROS® has been designed and built from first principles using a high level language based on Object Pascal. The emphasis at all stages of the PETROS® project has been to apply the KISS principle (Keep It Small and Simple)

Some of the primary features of PETROS® include:
A micro kernel of about 190K, allowing much more memory for applications.
A full working TCP system can be achieved in approximately 300 K
It is fast loading, fast and easy to run.
It runs on 486 and above level of processor.
It has a minimum memory requirement of 2 MB.
Standard peripherals are built in.
It is fully multitasking.
It has loadable driver modules
It has virtual paged memory
It will allow continued use of superceded machine configurations.
It contains industry standard disk structures and executable formats."

certe volte è ancora necessario usare questi linguaggi ormai relativamente vecchi. e potremo evolverci quanto ci pare, potranno arrivare interi sistemi operativi in Java, ma il layer scritto in C e assembly ci sarà sempre, o comunque ancora per molto; trovo molto improbabile che il futuro abbia in serbo macchine con JVM firmware, almeno non quello immediato.

Vedi sopra. Il fatto che vengano COMUNEMENTE usati C e assembly (quest'ultimo è strettamente necessario soltanto per alcuni dettagli) NON vuol dire che siano gli UNICI linguaggi che permettono di realizzare questo tipo di applicazioni.

infatti, nonostante questo Visual Basic sia quello che è, è stato un indubbio successo per Microsoft. la solita storia.

io non son proprio il tipo sai
tutto quello che ho appena scritto lo affermo perché l'ho provato sulla mia pelle (ebbene si: ho provato a programmare in Visual Basic qualche volta).

Allora scaricati VB.NET 2005, che è COMPLETAMENTE GRATUITO per uso personale, e dai un'occhiata a come si è evoluto il linguaggio (e l'IDE).

[cdimauro]

Originariamente inviato da 71104

fidati, il C++ lo impareresti molto prima se non avessi studiato Visual Basic. fek non può che essere d'accordo con me, almeno se ti riferisci alla versione 6 di VB.

e arifidati, che c'è modo anche in C++ di ottenere risultati velocemente; altrimenti se proprio è di primaria importanza che l'informatica ti gratifichi il prima possibile, spostati su un linguaggio più semplice come Java o C#, ma VB è da rimuovere.

Sono assolutamente in disaccordo, per quanto scritto sopra: è come se, parlando del Turbo Pascal, dovessi restare fermo alla versione 3.0, ignorando gli ENORMI miglioramenti apportati al linguaggio e all'IDE in questi ultimi vent'anni.

[cdimauro]

Originariamente inviato da k0nt3

beh su questo credo che non si può non essere d'accordo. io personalmente (per quanto possa valere la mia opinione) penso che in generale "divide&conquer" sia la filosofia che da risultati migliori, cioè scomporre un problema complesso in problemi semplici e risolvere questi problemi semplici nella maniera migliore (dove il concetto di migliore è soggetto a interpretazione di volta in volta).

Quella che hai dato è la definizione di approccio top down.

Divide & conqueror si applica in altri contesti.

[cdimauro]

Originariamente inviato da fek

E infine, gli if sono una brutta cosa nelle architetture in-order come il Cell o l'XCPU, prenche' introducono branch nel codice e la CPU non puo' riordinare le istruzioni da eseguire o fare esecuzione speculativa. I branch sono dei killer di performance su queste CPU. Si', sto lottando contro gli if al lavoro perche' l'XCPU e' un chiodo altrimenti

Concordo.

Tra l'altro, parlando di eliminazione di if, da quando lavoro con linguaggi ad alto livello come Python, Java, ecc. preferisco sostituirli coi costrutti che questi ultimi mettono a disposizione.

Ad esempio, prima scrivevo roba come questa:

if MyDict.has_key("pippo"):
  Value = MyDict["pippo"]
  mio codice
else:
  altro codice

Adesso preferisco questo:

try:
  Value = MyDict["pippo"]
  mio codice
except:
  altro codice

Parlando con uno dei programmatori Java a lavoro, mi diceva che la tendenza è quella di sfruttare i controlli della JVM per evitare di testare condizioni, anche implicitamente, per far andare il codice più velocemente.
Ad esempio scorrere un intero array fermandosi quando la JVM solleva un'eccezione di index out of bound, intrappolandola con un try / catch, anziché far uso del classico for contenente la condizione di controllo sull'ultimo elemento.

EDIT: corretto esempio.

[cdimauro]

Originariamente inviato da wingman87

Sì, mi riferisco al 6, comunque anche se non stessi studiando VB andrei alla stessa velocità xk sto semplicemente seguendo il corso di scuola, tempo di lavorare da solo a casa non ne ho molto purtroppo, quindi in fondo mi va bene che stia imparando il VB6, in fondo è sempre un linguaggio in +..

Perché provare il 6, quando il VB.NET 2005 è MOLTO meglio sia come linguaggio sia come IDE, e tra l'altro è completamente gratuito?

Riguardo al filmato del browser è molto carino, ma pensavo, avendo a disposizione gli stessi oggetti non si potrebbe fare la stessa cosa anche in VB?

Consiglio di vederlo per intero quel filmato, perché:
1) in VB.NET, C#, Delphi, ecc. la stessa cosa si realizza in 1/10 del tempo;
2) si comprende quanto "IDE" come quelli del filmato siano BEN LONTANI dai canoni di comodità e semplicità d'uso degli altri IDE che ho elencato.

Personalmente, quando ho visto aprire il WORDPAD per scrivere il codice per legare la finestrella appena creata, e il PROMPT DEI COMANDI per compilare il tutto e farlo partire, mi sono stropicciato gli occhi e le orecchie ((C) 2006 by Silvio B. ). Poi sono scoppiato in una fragorosa risata...

Veramente, sono ancora fermi ai tempi della clava (informatica). Dovrebbero dare un'occhiata a Delphi 1.0, il primo ambiente RAD creato per Windows, e rendersi conto di quanto devono ancora lavorare per arrivare a qualcosa di appena comparabile...

E stiamo parlando di QT, che non è neppure totalmente "libero", visto che si tratta di un framework proprietario, dotato di doppia licenza (commerciale e GPL).