quale ?

[rafpro]

salve ...vorrei imparare un linguaggio di programmazione semplice ma che mi permetta di fare applicazioni ......nulla di che ma giusto qualcosa
cosa mi consigliate?

[ndakota]

python ha le caratteristiche da te descritte :O

fuggi, sciocco [cit. modificata]:D

[71104]

python ha le caratteristiche da te descritte :O se il discepolo di Bjarne ha consigliato Python, adesso attendo un cdimauro che consigli C++ :asd:

[71104]

seriamente comunque...

salve ...vorrei imparare un linguaggio di programmazione semplice ma che mi permetta di fare applicazioni ......nulla di che ma giusto qualcosa
cosa mi consigliate? guarda qua:
http://www.microsoft.com/express/

ed in particolare vedi se ti interessa questo:
http://www.microsoft.com/express/vcsharp/Default.aspx

[ndakota]

se il discepolo di Bjarne ha consigliato Python, adesso attendo un cdimauro che consigli C++ :asd:

ha scritto programmazione semplice con che coraggio gli consigliavo il C++? :stordita:

[DanieleC88]

Però il C# andava bene. :O

[rafpro]

beh applicazioni semplici sotto win
dato che sono a 0 come programmazione
vorrei proprio cominciare da cose semplici poi magari se mi appassiono passero' a qualcosa di piu complicato
potete mandarmi in privato un link con qualche guida?
grazie :D

[khelidan1980]

beh applicazioni semplici sotto win
dato che sono a 0 come programmazione
vorrei proprio cominciare da cose semplici poi magari se mi appassiono passero' a qualcosa di piu complicato
potete mandarmi in privato un link con qualche guida?
grazie :D

python
http://www.python.it/doc/Howtothink/Howtothink-html-it/index.htm

java
http://www.claudiodesio.com/

C#
passo,ma sicuramente ti indirizzeranno

scegli uno dei tre,l'ordine è il mio personalissimo parere

[rafpro]

python
http://www.python.it/doc/Howtothink/Howtothink-html-it/index.htm

java
http://www.claudiodesio.com/

C#
passo,ma sicuramente ti indirizzeranno

scegli uno dei tre,l'ordine è il mio personalissimo parere

ma questo python va bene per win? sto leggendo alcune sintassi come faccio ad eseguirle sotto winxp? mi date una dritta?

[khelidan1980]

ma questo python va bene per win? sto leggendo alcune sintassi come faccio ad eseguirle sotto winxp? mi date una dritta?

certo che va bene,studia il primo capitolo ed installa un ide,tipo:

http://pythonide.blogspot.com/

ma devi prima leggere qualcosa,e chiarirti un po le idee

[demos88]

secondo me il Java.
Versatile, multipiattaforma, sicuro. Una volta che comprendi il concetto di classe, oggetto ed ereditarietà sei a cavallo. Di manuali ce ne sono a tonnellate.

C++ mi sembra un pò più complicato, il C# lo snobbo solo per la sua paternità :asd:

[rafpro]

[QUOTE=demos88;23197409]secondo me il Java.
Versatile, multipiattaforma, sicuro. Una volta che comprendi il concetto di classe, oggetto ed ereditarietà sei a cavallo. Di manuali ce ne sono a tonnellate.

e dove sono questi manuali? sapresti indicarmene uno chiaro e semplice? grazie :D

[khelidan1980]

[QUOTE=demos88;23197409]secondo me il Java.
Versatile, multipiattaforma, sicuro. Una volta che comprendi il concetto di classe, oggetto ed ereditarietà sei a cavallo. Di manuali ce ne sono a tonnellate.

e dove sono questi manuali? sapresti indicarmene uno chiaro e semplice? grazie :D

te lo scritto io sopra

[grigor91]

java secondo me assomiglia troppo a C/C++ per consigliarlo ad qualcuno che parte da zero.
python è il più adatto per questa categoria, oltretutto il manuale consigliato sopra è stato sviluppato appunto per chi vuole iniziare da programmare.

[71104]

il C# lo snobbo solo per la sua paternità :asd:
quest'ultima frase invalida qualunque tuo consiglio

[71104]

e dove sono questi manuali? sapresti indicarmene uno chiaro e semplice? grazie :D c'è il tutorial ufficiale se vuoi:
http://java.sun.com/docs/books/tutorial/index.html

[dreadknight]

secondo me ti conviene partire dal C e poi passare alla programmazione ad oggetti (C++, Java,...).

Un ottimo manuale è il Deitel

[banryu79]

java secondo me assomiglia troppo a C/C++ per consigliarlo ad qualcuno che parte da zero...
Per me non gli somiglia affatto, a parte lo stile sintattico.

E non è certo la sintassi a rendere più difficile lo sforzo di padroneggiare C++ rispetto ad altri linguaggi.
Sul C neanche commento: non ci azzecca molto con Java

[variabilepippo]

secondo me ti conviene partire dal C e poi passare alla programmazione ad oggetti


Io partirei dal linguaggio macchina, poi passerei all'Assembly (almeno 15/20 diversi), poi studierei il C, poi un linguaggio ad oggetti (che non c'azzecca nulla con il C a livello di "filosofia di programmazione")... :rolleyes:

[rafpro]

non ci sto capendo piu nulla su cosa fare ....:muro:

[ndakota]

io ho detto fuggi sciocco non per niente eh :D

[banryu79]

Viste le tue neccessità, espresse nel tuo primo post, io ti consiglio di scegliere un linguaggio di elevata astrazione (quindi lascia stare il C/C++), possibilmente semplice e mirato a quello che devi fare.

Nonostante sia un "Javista" convinto, avendo letto il tuo post io ti consiglio o Python [per la semplicità] o C# [visto che siamo strettamente su piattaforme Windows].

L'importante è che ti procuri della solida documentazione e un buon manuale da seguire con metodo, se vuoi imparare qualcosa in tempi decenti.

Per entrambi questi linguaggi trovi molte risorse online, io però non ti so indirizzare su qualcosa di più specifico.

[arcer]

scusate ma perche non si sticka un 3d con scritto per chi inizia a programmare ecco i nostri consigli...


perche c'è un post del genere almeno ogni 6 giorni e ogni 6 giorni si ripetono le stesse cose sempre...

[DanieleC88]

io ho detto fuggi sciocco non per niente eh :D
Come non citare:
(EN) Fly, you fools!
(IT) Fuggite, sciocchi!
:D

[cdimauro]

salve ...vorrei imparare un linguaggio di programmazione semplice ma che mi permetta di fare applicazioni ......nulla di che ma giusto qualcosa
cosa mi consigliate?
Risposta più che scontata: Python è il linguaggio migliore per imparare a programmare. :cool:
python ha le caratteristiche da te descritte :O

fuggi, sciocco [cit. modificata]:D
"Ormai è tardi..." :D
se il discepolo di Bjarne ha consigliato Python, adesso attendo un cdimauro che consigli C++ :asd:
:tie:
sil C# lo snobbo solo per la sua paternità :asd:
Lo sai, vero, chi è il padre di C#?

[demos88]

quest'ultima frase invalida qualunque tuo consiglio
non credo potrebbe, visto che sono io a snobbarlo, e l'autore del thread ha chiesto un nostro personale parere e io ho dato il mio consiglio e lo giustifico anche, avendo visto centinaia di persone uscite pure da liceo classico impararlo in 1 mese al corso di fondamenti di informatica all'università.
asd il C# l'ho solo sfiorato, non posso dire di averlo approfondito, ma mi sa troppo di limitativo il fatto di lavorare per forza in ambiente microsoft. Il Java mi sembra un buon linguaggio per iniziare, e programmi per qualsiasi cosa: programmi java per pc con qualsiasi OS, per dispositivi mobili, per applet da pubblicare in pagine web ecc...
Risposta più che scontata: Python è il linguaggio
Lo sai, vero, chi è il padre di C#?
Il padre naturale? asd
ora come ora che io sappia è utilizzato per sviluppare applicativi sotto windows e dovrebbe avere a che fare con il .NET.
Sarà general purpose quanto si vuole, magari lo fai girare anche sotto linux o dove vuoi, ma allora non vedo perchè nn andare tranquilli con il java... il c# è nato soprattutto per contrastarlo.
Se poi tu ne sai una in più bene, il mio consiglio non varia, col Java mi sono trovato sempre di lusso. :D

[Albi89]

Povero rafpro :D

Purtroppo questi topic seguono un canovaccio preciso: arriva anzitutto qualcuno che propone Python, poi Java, poi il C#.
Poi qualcuno dice che il C++ è più versatile.
Infine qualcun'altro dice che non si può programmare a oggetti se non sai programmare procedurale, quindi si consiglia di provare con il C.
Poi qualcuno inizia a scherzare e propone qualche assembly esotico.
Infine arriva cdimauro e, puntualmente, convince tutti a usare Python :sofico:

Ciò non toglie che se proprio il pitone non ti affascina, per programmare in ambito windows C# è un linguaggio interessantissimo... e pieno di differenze interessanti e novità succose rispetto a Java, non ultima Windows Presentation Foundation per lo sviluppo di interfacce grafiche "Vista style"... avendo finito finalmente i miei esamozzi sul C++, sono sinceramente indeciso anche io tra lo studio di Python o del C#, ma qualunque linguaggio sceglierai, farai la scelta giusta perchè quì saremo tutti pronti ad aiutarti e a "sostenerti moralmente" negli attimi di sconforto informatico :fagiano:

P.S. demos penso che tu ti riferissi alla Microsoft quando parlavi di paternità (su questo non commento, ma capirai che in un forum 'serio' come la sezione programmazione è vietato attaccare Microsoft o chi per lei senza un motivo valido, motivi validi che per altro non escono mai).
Quello che forse non sai è che il creatore di C# è anche il creatore di Delphi e del Turbo Pascal... insomma, dovrebbe essere una garanzia nell'ambito di sviluppo di applicazioni per desktop ;)

[DanieleC88]

e lo giustifico anche, avendo visto centinaia di persone uscite pure da liceo classico impararlo in 1 mese al corso di fondamenti di informatica all'università.
Mantenere una sintassi C-like e introdurre una semplicità tale che anche i neofiti sappiano programmare in poco tempo per me è un vantaggio, non un punto di demerito.
E poi anche io sono uscito da un liceo classico, cosa vorresti dire con ciò? :banned: :Prrr:

Essere anti-Microsoft a priori non ha molto senso, se un prodotto è buono bisogna riconoscerglielo (non voglio intessere le lodi del C#, non lo uso da abbastanza tempo per paragornarlo a Java, però è una questione di mentalità). E lo dico io che non sono e non sono mai stato pro-Microsoft a priori (anzi), altri del forum te lo potranno confermare... :D

[DanieleC88]

e pieno di differenze interessanti e novità succose rispetto a Java, non ultima Windows Presentation Foundation per lo sviluppo di interfacce grafiche "Vista style"...
Più che le interfacce grafiche Vista-style, che pure possono essere interessanti, ultimamente ho intravisto LINQ nei post di alcuni utenti e mi pare molto più... succoso. :D

[^TiGeRShArK^]

Più che le interfacce grafiche Vista-style, che pure possono essere interessanti, ultimamente ho intravisto LINQ nei post di alcuni utenti e mi pare molto più... succoso. :D

confermo, con java te le sogni (purtroppo) certe cose.
linq, quando si devono trattare dei dati (ovvero praticamente nel 90% dei casi) è assolutamente spettacolare...
e senza contare che tramite PLINQ sfrutti praticamente in maniera automatica il parallelismo nel tuo programma suddividendo le operazioni in un numero di thread congruo per il numero di core presenti sul tuo sistema :D
e questo semplicemente aggiungendo una chiamata ad asParallel() nella query linq che si sta utilizzando :p

[khelidan1980]

si però urge davvero uno sticky,quantomeno sulle linee guida per iniziare,gli svantaggi e i vantaggi di cominciare con un linguaggio tipo python ecc...

[^TiGeRShArK^]

quoto :O
e propongo di introdurre il ban per chi propone c / assembly :asd:

[Albi89]

Carrellata di risposte:
LINQ è spettacolare, ma avevo sottolineato la questione gui perchè molti utenti arrivano sparati dicendo che vogliono imparare il visual basic perchè permette di creare facilmente applicazioni windows... non conto le volte che ho sentito cose tipo "uaah ma che schifo il c++ ci fai la roba dos" :eek:

demos, quello che dici a proposito di Java è parzialmente giusto, ti smentisco solo al volo su due cose: primo, anche io ho studiato al liceo classico e pur non permettondomi neanche di definirmi "programmatore", do tranquillamente la paga a tutti i miei compagni di corso che hanno studiato a licei scientifici o istituti tecnici...
Per il resto, non credo che il livello di conoscenze che da un corso di fondamenti di informatica sia indicativo delle effettive capacità di un linguaggio, e se per questo neanche gli altri corsi di Programmazione del primo anno.

Per quanto riguarda C#, capisco che parlare male di microsoft fa troppa gola, ma non te la caverai dicendo "vista la paternità non ne parlo neanche" per poi uscirtene, chiamato in causa, con un "asd il C# l'ho solo sfiorato, non posso dire di averlo approfondito".
Quando passerà 71104, ti fustigherà a dovere :stordita:

[demos88]

Carrellata di risposte:
LINQ è spettacolare, ma avevo sottolineato la questione gui perchè molti utenti arrivano sparati dicendo che vogliono imparare il visual basic perchè permette di creare facilmente applicazioni windows... non conto le volte che ho sentito cose tipo "uaah ma che schifo il c++ ci fai la roba dos" :eek:

demos, quello che dici a proposito di Java è parzialmente giusto, ti smentisco solo al volo su due cose: primo, anche io ho studiato al liceo classico e pur non permettondomi neanche di definirmi "programmatore", do tranquillamente la paga a tutti i miei compagni di corso che hanno studiato a licei scientifici o istituti tecnici...
Per il resto, non credo che il livello di conoscenze che da un corso di fondamenti di informatica sia indicativo delle effettive capacità di un linguaggio, e se per questo neanche gli altri corsi di Programmazione del primo anno.

Per quanto riguarda C#, capisco che parlare male di microsoft fa troppa gola, ma non te la caverai dicendo "vista la paternità non ne parlo neanche" per poi uscirtene, chiamato in causa, con un "asd il C# l'ho solo sfiorato, non posso dire di averlo approfondito".
Quando passerà 71104, ti fustigherà a dovere :stordita:
nanananana state tutti esagerando, meglio se spiego...
allora... in primis io, ma chiunque credo, può consigliare qualcosa solo se l'ha provata. Il c# sharp pur avendo scritto la solita caxxata "hello world" non posso dire di averlo provato veramente. Di linguaggi di programmazione io ho studiato in modo decente (un programmatore che pensa di essere bravo al 95% dei casi è un pagliaccio) C/C++, Java, VB, PHP e ho preso in giro quello che mi serviva. Quindi il mio consiglio deve per forza ricadere tra questi e secondo me il più indicato per un principiante è il Java e credo sia anche piuttosto divertente. Il C# so che tipo di linguaggio è, ma per motivi vari, non mi desta interesse provarlo almeno per ora. Non ho niente da ridire alla casa produttrice a riguardo del suo prodotto, ma credo che sia più utile conoscere un linguaggio più adattabile. Anche il C# è abbastanza portabile ma il Java lo è per eccellenza. Ovviamente se parliamo di "oh che bella l'interfaccia grafica di WVista" per forza il C# è un passo avanti... sono della stessa casa :fagiano:
Per programmare sotto OS microsoft credo approfondirò il VC++.
Per quanto riguarda il corso universitario... offre una preparazione di base sui linguaggi ad oggetti e, nulla contro i liceali, ma ho visto che se la sono cavata tutti benissimo e hanno dato l'esame al primo appello. E questo non c'entra nulla con le capacità del linguaggio... io parlo di facilità di apprendimento e di sviluppo; in fondo quale pc non ha una JVM installata, indifferentemente dall'OS?
Ripeto il mio è il parere di uno che ha provato dei linguaggi e può suggerire solo tra quelli. La battuta sulla paternità rimane una battuta, forse dovevo specificarlo prima, visto che qualcuno l'ha presa come un affronto... :rolleyes:

ps: suggerisco all'autore del thread di creare una poll :asd:

[variabilepippo]

in fondo quale pc non ha una JVM installata, indifferentemente dall'OS?


Io mi chiederei quali sistemi operativi abbiano una JVM ufficiale installata per default... MSJVM è morta con Windows XP (http://www.microsoft.com/mscorp/java/faq.mspx) (per fortuna!), il Sun JRE va installato a parte dall'utente su quasi tutti gli OS mainstream. In molte distribuzioni Linux, fino a non molto tempo fa, il pacchetto JRE andava installato da repositories non "ufficiali". :rolleyes:

[DanieleC88]

si però urge davvero uno sticky,quantomeno sulle linee guida per iniziare,gli svantaggi e i vantaggi di cominciare con un linguaggio tipo python ecc...
In effetti avrebbe dovuto essere la prima cosa fatta da anni a questa parte. Si potrebbe pensare magari di aprire adesso un thread solo e soltanto per discutere dei linguaggi (senza flame), per individuarne punti di forza e limiti. Il primo post andrebbe poi costantemente aggiornato con una sintesi di tali informazioni... almeno quelli che si affacciano da subito alla programmazione avrebbero una lista di pro e contro per ogni linguaggio, potendo scegliere di testa propria.

Lo iniziamo? :stordita: (con il via libera di cionci, possibilmente)
non conto le volte che ho sentito cose tipo "uaah ma che schifo il c++ ci fai la roba dos" :eek:
Vabbe' però questo lo puoi aver sentito solo a Napoli, non sui forum! :p (senza offesa per i napoletani, sia ben chiaro)

:D

[cdimauro]

asd il C# l'ho solo sfiorato, non posso dire di averlo approfondito, ma mi sa troppo di limitativo il fatto di lavorare per forza in ambiente microsoft. Il Java mi sembra un buon linguaggio per iniziare, e programmi per qualsiasi cosa: programmi java per pc con qualsiasi OS, per dispositivi mobili, per applet da pubblicare in pagine web ecc...

Il padre naturale? asd
ora come ora che io sappia è utilizzato per sviluppare applicativi sotto windows e dovrebbe avere a che fare con il .NET.
Sarà general purpose quanto si vuole, magari lo fai girare anche sotto linux o dove vuoi, ma allora non vedo perchè nn andare tranquilli con il java... il c# è nato soprattutto per contrastarlo.
Se poi tu ne sai una in più bene, il mio consiglio non varia, col Java mi sono trovato sempre di lusso. :D
Questo è un altro discorso, ma fra riportare le classiche leggende metropolitane (come in questo messaggio) e il silenzio, al tuo posto preferirei il silenzio, non foss'altro per una questione di immagine.
Mantenere una sintassi C-like
:Puke:
E lo dico io che non sono e non sono mai stato pro-Microsoft a priori (anzi), altri del forum te lo potranno confermare... :D
Già, ma stiamo lavorando duramente per farti cambiare idea. :asd:
confermo, con java te le sogni (purtroppo) certe cose.
linq, quando si devono trattare dei dati (ovvero praticamente nel 90% dei casi) è assolutamente spettacolare...
e senza contare che tramite PLINQ sfrutti praticamente in maniera automatica il parallelismo nel tuo programma suddividendo le operazioni in un numero di thread congruo per il numero di core presenti sul tuo sistema :D
e questo semplicemente aggiungendo una chiamata ad asParallel() nella query linq che si sta utilizzando :p
Questa è una cosa veramente fica. Non tanto per LINQ, che bene o male si riesce a "emulare", quanto per PLINQ, che mi ha veramente impressionato quanto a facilità nel tirare fuori un'applicazione che tiene conto del parallelismo in maniera semplice, "naturale", ma soprattutto... efficiente.
quoto :O
e propongo di introdurre il ban per chi propone c / assembly :asd:
+(1 << 64 - 1) :D
nanananana state tutti esagerando, meglio se spiego...
allora... in primis io, ma chiunque credo, può consigliare qualcosa solo se l'ha provata. Il c# sharp pur avendo scritto la solita caxxata "hello world" non posso dire di averlo provato veramente. Di linguaggi di programmazione io ho studiato in modo decente (un programmatore che pensa di essere bravo al 95% dei casi è un pagliaccio) C/C++, Java, VB, PHP e ho preso in giro quello che mi serviva. Quindi il mio consiglio deve per forza ricadere tra questi e secondo me il più indicato per un principiante è il Java e credo sia anche piuttosto divertente. Il C# so che tipo di linguaggio è, ma per motivi vari, non mi desta interesse provarlo almeno per ora. Non ho niente da ridire alla casa produttrice a riguardo del suo prodotto, ma credo che sia più utile conoscere un linguaggio più adattabile. Anche il C# è abbastanza portabile ma il Java lo è per eccellenza. Ovviamente se parliamo di "oh che bella l'interfaccia grafica di WVista" per forza il C# è un passo avanti... sono della stessa casa :fagiano:
Per programmare sotto OS microsoft credo approfondirò il VC++.
Per quanto riguarda il corso universitario... offre una preparazione di base sui linguaggi ad oggetti e, nulla contro i liceali, ma ho visto che se la sono cavata tutti benissimo e hanno dato l'esame al primo appello. E questo non c'entra nulla con le capacità del linguaggio... io parlo di facilità di apprendimento e di sviluppo; in fondo quale pc non ha una JVM installata, indifferentemente dall'OS?
Ripeto il mio è il parere di uno che ha provato dei linguaggi e può suggerire solo tra quelli. La battuta sulla paternità rimane una battuta, forse dovevo specificarlo prima, visto che qualcuno l'ha presa come un affronto... :rolleyes:

ps: suggerisco all'autore del thread di creare una poll :asd:
Altro post a conferma di quanto scritto prima (vedi parte evidenziata).
Io mi chiederei quali sistemi operativi abbiano una JVM ufficiale installata per default... MSJVM è morta con Windows XP (http://www.microsoft.com/mscorp/java/faq.mspx) (per fortuna!), il Sun JRE va installato a parte dall'utente su quasi tutti gli OS mainstream. In molte distribuzioni Linux, fino a non molto tempo fa, il pacchetto JRE andava installato da repositories non "ufficiali". :rolleyes:
Esattamente. E, a parte questo, Sun non supporta allo stesso modo tutte le piattaforme. Questo vuol dire che non tutte JVM espongo le stesse API e/o funzionalità.

Questo sempre a proposito della famosa "compatibilità universale" che viene spesso tirata in ballo senza cognizione di causa...
In effetti avrebbe dovuto essere la prima cosa fatta da anni a questa parte. Si potrebbe pensare magari di aprire adesso un thread solo e soltanto per discutere dei linguaggi (senza flame), per individuarne punti di forza e limiti. Il primo post andrebbe poi costantemente aggiornato con una sintesi di tali informazioni... almeno quelli che si affacciano da subito alla programmazione avrebbero una lista di pro e contro per ogni linguaggio, potendo scegliere di testa propria.

Lo iniziamo? :stordita: (con il via libera di cionci, possibilmente)

Vabbe' però questo lo puoi aver sentito solo a Napoli, non sui forum! :p (senza offesa per i napoletani, sia ben chiaro)

:D
C'è già questo (http://www.hwupgrade.it/forum/showthread.php?t=1563542) thread allo scopo: basta metterlo in evidenza. ;)

[k0nt3]

secondo me bisogna veramente aprire un thread in evidenza intitolato "per chi vuole imparare a programmare" e contenente il seguente testo:

- cerca su google
- RTFM
- programma
- programma
- programma
- programma
repeat:
-- leggi un buon libro
-- programma
-- programma
-- programma
until death :tie:

[k0nt3]

Io mi chiederei quali sistemi operativi abbiano una JVM ufficiale installata per default... MSJVM è morta con Windows XP (http://www.microsoft.com/mscorp/java/faq.mspx) (per fortuna!), il Sun JRE va installato a parte dall'utente su quasi tutti gli OS mainstream. In molte distribuzioni Linux, fino a non molto tempo fa, il pacchetto JRE andava installato da repositories non "ufficiali". :rolleyes:
la JRE non è difficile da installare, in ogni caso Java si può anche compilare in maniera nativa volendo

[cdimauro]

Peccato che non funzioni bene, se ti riferisci a GCJ (che è ancora incompleto come progetto).

[variabilepippo]

la JRE non è difficile da installare


Lo so, ma è una cosa che va fatta, la Sun JVM non viene fornita in dotazione con i sistemi operativi ed io contestavo l'affermazione "in fondo quale pc non ha una JVM installata, indifferentemente dall'OS". :rolleyes:

[k0nt3]

Peccato che non funzioni bene, se ti riferisci a GCJ (che è ancora incompleto come progetto).
questo sembra molto meglio http://www.excelsior-usa.com/jet.html
Lo so, ma è una cosa che va fatta, la Sun JVM non viene fornita in dotazione con i sistemi operativi ed io contestavo l'affermazione "in fondo quale pc non ha una JVM installata, indifferentemente dall'OS". :rolleyes:
beh ma qui stiamo parlando di imparare a programmare, mica del deployment delle applicazioni.
anche python va installato per esempio (lo so che non è la stessa cosa in termini di dimensioni, ma concettualmente non cambia molto)

[variabilepippo]

beh ma qui stiamo parlando di imparare a programmare


Sì, ma affermare "in fondo quale pc non ha una JVM installata, indifferentemente dall'OS" significa dire una cosa non vera, ci sono moltissimi PC sui quali non è installata una JVM (decente/recente) perché:

1) La JVM non fa parte della dotazione standard di un sistema operativo
2) Molti utenti comuni (non sviluppatori) non sanno cosa sia una JVM, dunque non è loro preoccupazione installarne una.
3) Il mercato è dominato da Windows e la MSJVM (una schifezza) non viene più distribuita a partire da Windows XP SP1.
4) Le JVM non sono tutte uguali

[DanieleC88]

Già, ma stiamo lavorando duramente per farti cambiare idea. :asd:
Avrete da lavorare allora! :p
C'è già questo (http://www.hwupgrade.it/forum/showthread.php?t=1563542) thread allo scopo: basta metterlo in evidenza. ;)
Uhm, però io intendevo proprio un thread dove fare una bella raccolta di queste discussioni, con un post iniziale che faccia da resoconto. Diciamo, un riassunto significativo dei consigli che solitamente si danno, in modo da non costringere i nuovi arrivati a leggersi 20 pagine di discussione (perché non lo farebbero: rinuncerebbero ed aprirebbero un nuovo thread dicendo "ho provato a leggere quello sticky ma sono rimasto ancora disorientato" :D).

[cdimauro]

questo sembra molto meglio http://www.excelsior-usa.com/jet.html
Mi sembra un ottimo prodotto, sebbene a pagamento (costa cara anche la licenza standard), ma per la mia esperienza dovrei vedere se effettivamente funziona con le applicazioni sviluppate.
beh ma qui stiamo parlando di imparare a programmare, mica del deployment delle applicazioni.
anche python va installato per esempio (lo so che non è la stessa cosa in termini di dimensioni, ma concettualmente non cambia molto)
Python (compresi i pacchetti che ti servono) puoi anche non installarlo: a casa mia ho fatto così, e mi funziona tutto. ;)
Avrete da lavorare allora! :p
Siamo sulla buona strada. Già il fatto che hai detto di apprezzare Visual Studio è un segnale.

Il lato oscuro ti aspetta. :cool:
Uhm, però io intendevo proprio un thread dove fare una bella raccolta di queste discussioni, con un post iniziale che faccia da resoconto. Diciamo, un riassunto significativo dei consigli che solitamente si danno, in modo da non costringere i nuovi arrivati a leggersi 20 pagine di discussione (perché non lo farebbero: rinuncerebbero ed aprirebbero un nuovo thread dicendo "ho provato a leggere quello sticky ma sono rimasto ancora disorientato" :D).
Sì, hai ragione: così andrebbe meglio e sarebbe molto meno dispersivo. :)

[k0nt3]

Mi sembra un ottimo prodotto, sebbene a pagamento (costa cara anche la licenza standard), ma per la mia esperienza dovrei vedere se effettivamente funziona con le applicazioni sviluppate.

questi sono alcuni esempi di applicazioni che ne fanno uso http://www.excelsior-usa.com/jetgallery.html
io ho provato tuxguitar e funziona alla perfezione.
la cosa interessante è che per scopi non commerciali è un prodotto gratuito

Python (compresi i pacchetti che ti servono) puoi anche non installarlo: a casa mia ho fatto così, e mi funziona tutto. ;)

ma di sicuro python non è incluso nel SO e va scaricato, se poi l'installazione consiste nello scompattare un archivio è un'altro discorso ;)

[DanieleC88]

Siamo sulla buona strada. Già il fatto che hai detto di apprezzare Visual Studio è un segnale.

Il lato oscuro ti aspetta. :cool:
Vero, ma io sono un integralista Linuxiano di mentalità aperta: i prodotti buoni li riconosco. :D
Sì, hai ragione: così andrebbe meglio e sarebbe molto meno dispersivo. :)
Allora nei prossimi giorni potremmo crearlo con la collaborazione di tutti. :)

[Albi89]

Vero, ma io sono un integralista Linuxiano di mentalità aperta: i prodotti buoni li riconosco. :D

Allora nei prossimi giorni potremmo crearlo con la collaborazione di tutti. :)

Sarebbe ottimo, soprattutto con un bel post iniziale con links a siti di riferimento, uno o due volumi consigliati e una breve descrizione delle caratteristiche e degli effettivi domini di utilizzo del linguaggio (ad esempio a proposito di python e ruby sarebbero da sottolineare i "succosi" (anche loro) framework per lo sviluppo web)

[DanieleC88]

Era precisamente la mia idea. Vedo che siamo già in 3 ad essere d'accordo! Altri volontari? :D

[dreadknight]

Io partirei dal linguaggio macchina, poi passerei all'Assembly (almeno 15/20 diversi), poi studierei il C, poi un linguaggio ad oggetti (che non c'azzecca nulla con il C a livello di "filosofia di programmazione")... :rolleyes:


ma va, infatti ho consigliato di iniziare col C per poi passare a imparare la programmazione orientata agli oggetti.

Eppure è italiano, non è difficile :rolleyes:

[wizard_at]

Era precisamente la mia idea. Vedo che siamo già in 3 ad essere d'accordo! Altri volontari? :D

bella idea..peccato che domani parto senno' darei una mano...non dimenticatevi LOLCODE!

[variabilepippo]

Infatti l'italiano non è così difficile, apri il dizionario e leggi il significato della parola "sarcasmo". :fagiano:

Per guidare un aereo non ti serve saper andare in moto, la programmazione in linguaggio C induce a worst practices nella OOP. Puoi sempre argomentare il tuo consiglio, se lo ritieni opportuno...

[k0nt3]

Per guidare un aereo non ti serve saper andare in moto, la programmazione in linguaggio C induce a worst practices nella OOP. Puoi sempre argomentare il tuo consiglio, se lo ritieni opportuno...

qualsiasi persona prima di imparare a programmare a oggetti non sa programmare a oggetti, non vale solo per chi inizia con il C.
la differenza è che chi inizia con il C impara essenzialmente la programmazione strutturata (che serve anche nei linguaggi a oggetti) e quindi gli rimane meno da imparare

[dreadknight]

Infatti l'italiano non è così difficile, apri il dizionario e leggi il significato della parola "sarcasmo". :fagiano:

Per guidare un aereo non ti serve saper andare in moto, la programmazione in linguaggio C induce a worst practices nella OOP. Puoi sempre argomentare il tuo consiglio, se lo ritieni opportuno...

se ne sei convinto...

io penso che in ogni cosa si parte dalla base per poi fare via via argomenti più complessi. Il C ti serve per acquisire la logica della programmazione, successivamente puoi imparare a lavorare con gli oggetti.

Altrimenti è come voler risolvere un integrale senza conoscere le derivate (scusate l'esempio matematico, ma la mia facoltà mi impone ciò :D )

[Albi89]

Infatti l'italiano non è così difficile, apri il dizionario e leggi il significato della parola "sarcasmo". :fagiano:

Per guidare un aereo non ti serve saper andare in moto, la programmazione in linguaggio C induce a worst practices nella OOP. Puoi sempre argomentare il tuo consiglio, se lo ritieni opportuno...
Va che l'italiano è difficile, forse più difficile del C++ :fagiano:

Edit: in ogni caso il punto della questione è che nessuno riuscirà ad argomentare nessuna delle due posizioni.
La verità è che anche quando si sceglie di imparare un linguaggio puramente a oggetti, le prime soluzioni ai piccoli problemi saranno squisitamente procedurali, anche perchè il programmatore in erba non sarà ancora in grado di applicare l'approccio bottom-up proprio del linguaggio non conoscendo gli strumenti a sua disposizione.

Diverso il fatto invece che dire "studia il C" può essere controproducente come consiglio, anche perchè quello che nel seguito può servire è semplicemente il concetto di programmazione procedurale... in questo caso, allora, meglio il sottoinsieme C del C++ perchè avrai un compilatore più zelante e tante piccole semplificazioni (non ultimi gli stream).
In generale comunque penso che per il novizio di oggi sia superfluo, partire con un linguaggio della "triade" citata e stracitata penso sia più che sufficiente ;)

[dreadknight]

qualsiasi persona prima di imparare a programmare a oggetti non sa programmare a oggetti, non vale solo per chi inizia con il C.
la differenza è che chi inizia con il C impara essenzialmente la programmazione strutturata (che serve anche nei linguaggi a oggetti) e quindi gli rimane meno da imparare

sono d'accordo. D'altronde basta prendere un qualsiasi manuale di C++, le classi vengono introdotte dopo aver imparato la programmazione strutturata

[variabilepippo]

Il C ti serve per acquisire la logica della programmazione, successivamente puoi imparare a lavorare con gli oggetti.



: in ogni caso il punto della questione è che nessuno riuscirà ad argomentare nessuna delle due posizioni.



la differenza è che chi inizia con il C impara essenzialmente la programmazione strutturata (che serve anche nei linguaggi a oggetti) e quindi gli rimane meno da imparare

Si tratta di due paradigmi diversi, molto diversi, e purtroppo è difficile "scrollarsi di dosso" un modo di ragionare o un approccio alla risoluzione dei problemi. Si può tranquillamente partire da un linguaggio OO (possibilmente MODERNO), senza perdere tempo con cose che andranno disimparate. Perché fare 3 fatiche (imparare il C con tutte le sue caratteristiche low-level e le sue peculiarità, capire che buona parte delle cose imparate non serviranno quando si passa al un linguaggio OO [anzi!], iniziare a ragionare in termini di oggetti che interagiscono tra loro per poi apprendere una libreria standard o un framework), quando se ne può fare solo una partendo direttamente dalla programmazione ad oggetti (SE quello è l'obiettivo)?! Poi fate vobis... :muro:

Basta vedere come molta gente programmi in C pensando di programmare in C++...

[k0nt3]

Si tratta di due paradigmi diversi, molto diversi, e purtroppo è difficile "scrollarsi di dosso" un modo di ragionare o un approccio alla risoluzione dei problemi. Si può tranquillamente partire da un linguaggio OO (possibilmente MODERNO), senza perdere tempo con cose che andranno disimparate. Perché fare 3 fatiche (imparare il C con tutte le sue caratteristiche low-level e le sue peculiarità, capire che buona parte delle cose imparate non serviranno quando si passa al un linguaggio OO [anzi!], iniziare a ragionare in termini di oggetti che interagiscono tra loro per poi apprendere una libreria standard o un framework), quando se ne può fare solo una partendo direttamente dalla programmazione ad oggetti (SE quello è l'obiettivo)?! Poi fate vobis... :muro:
sono due paradigmi diversi che però hanno molte cose in comune e cioè tutto quello che riguarda la programmazione strutturata (che non significa procedurale).
io non ho detto cosa è meglio o cosa è peggio, ma penso solamente non è affatto vero che tutto quello che si impara con il C va dimenticato quando si affronta un linguaggio a oggetti. e non penso nemmeno che causi danni alla formazione visto che imparare paradigmi diversi è molto importante per la formazione di un qualsiasi programmatore.
ovvio che non bisogna fossilizzarsi su un paradigma, altrimenti si fa fatica a impararne uno nuovo.
poi ognuno sceglie quello che vuole

[k0nt3]

Basta vedere come molta gente programmi in C pensando di programmare in C++...

in effetti C++ è sia procedurale che a oggetti, quindi si può benissimo programmare alla C per intenderci (sono daccordo con te delle schifezze che vengono fuori comunque).
in java ad esempio non si può fare perchè Java non supporta la programmazione procedurale.
dove "supportare" significa che offre gli strumenti necessari per quel tipo di programmazione

[^TiGeRShArK^]

in effetti C++ è sia procedurale che a oggetti, quindi si può benissimo programmare alla C per intenderci (sono daccordo con te delle schifezze che vengono fuori comunque).
in java ad esempio non si può fare perchè Java non supporta la programmazione procedurale.
dove "supportare" significa che offre gli strumenti necessari per quel tipo di programmazione

veramente è possibilissimo scrivere porcherie prettamente procedurali anche in java :mbe:
quello che ti sfugge mi sa è proprio la differenza di mentalità.
Mentre con un linguaggio come il python o il java o il C# è possibile imparare sia le basi della programamzione che la programmazione ad oggetti, in maniera del tutto congruente, col C NON è possibile ed inoltre, per imparare a programmare in C, devi mettere mano a tutta la porcheria della gestione della memoria che in un linguaggio ad alto livello puoi completamente ignorare.
E non ti serve assolutamente a nulla impazzire per un segmentation fault e cose del genere ai fini di imparare a programmare.

[k0nt3]

veramente è possibilissimo scrivere porcherie prettamente procedurali anche in java :mbe:
se cerchi bene su google vedrai che è possibile "programmare a oggetti" anche in C e addirittura in assembly. ma io quella non la chiamerei programmazione a oggetti, come non chiamerei programmazione procedurale quella che puoi fare in java.
ho pure definito il concetto di "supportare" per evitare simili discorsi

quello che ti sfugge mi sa è proprio la differenza di mentalità.
Mentre con un linguaggio come il python o il java o il C# è possibile imparare sia le basi della programamzione che la programmazione ad oggetti, in maniera del tutto congruente, col C NON è possibile ed inoltre, per imparare a programmare in C, devi mettere mano a tutta la porcheria della gestione della memoria che in un linguaggio ad alto livello puoi completamente ignorare.
mica è obbligatorio imparare tutto quello che c'è da imparare senza cambiare linguaggio. anzi secondo me cambiare linguaggio fa bene

E non ti serve assolutamente a nulla impazzire per un segmentation fault e cose del genere ai fini di imparare a programmare.
puoi anche non usare i puntatori, mica è obbligatorio. se proprio li devi usare non fa male visto che nei linguaggi a oggetti si incontra il concetto di riferimento (e chi conosce i puntatori non fa molta fatica a capire come funzionano)

[DanieleC88]

puoi anche non usare i puntatori, mica è obbligatorio.
Non è un obbligo, in teoria, ma nella pratica lo è. :D

[variabilepippo]

quello che ti sfugge mi sa è proprio la differenza di mentalità.
Mentre con un linguaggio come il python o il java o il C# è possibile imparare sia le basi della programamzione che la programmazione ad oggetti, in maniera del tutto congruente, col C NON è possibile ed inoltre, per imparare a programmare in C, devi mettere mano a tutta la porcheria della gestione della memoria che in un linguaggio ad alto livello puoi completamente ignorare.
E non ti serve assolutamente a nulla impazzire per un segmentation fault e cose del genere ai fini di imparare a programmare.


Sottoscrivo al 101%. :)

[demos88]

Questo è un altro discorso, ma fra riportare le classiche leggende metropolitane (come in questo messaggio) e il silenzio, al tuo posto preferirei il silenzio, non foss'altro per una questione di immagine.

Caspita se siamo un pelo arroganti... chiedo perdono per le mie imprecisioni, andrò a contestarle al mio docente di corso quando ne avrò il tempo (tanto l'esame l'ho già dato...).
in ogni caso si chiedeva un consiglio soggettivo e a mio parere era Java.
Grazie in ogni caso per la dritta, proverò Python quando ne avrò l'occasione.

col C NON è possibile ed inoltre, per imparare a programmare in C, devi mettere mano a tutta la porcheria della gestione della memoria che in un linguaggio ad alto livello puoi completamente ignorare.
E non ti serve assolutamente a nulla impazzire per un segmentation fault e cose del genere ai fini di imparare a programmare.
forse il C è stato un pò "declassato" a linguaggio didattico per far capire un pò la programmazione, i cicli iterativi e appunto la gestione della memoria. Quando me l'hanno insegnato, 3/4 dell'insegnamento erano dediti a puntatori, allocazione, memoria ecc...

[^TiGeRShArK^]

se cerchi bene su google vedrai che è possibile "programmare a oggetti" anche in C e addirittura in assembly. ma io quella non la chiamerei programmazione a oggetti, come non chiamerei programmazione procedurale quella che puoi fare in java.
ho pure definito il concetto di "supportare" per evitare simili discorsi

:mbe:
che java metta a disposizione strutture che supportino la programmazione ad oggetti non implica assolutamente che ogni cosa che fai in java sia programmazione ad oggetti.
Se scrivi tutto nel main di una classe unica quella, per quanto tu ti possa impegnare, non è e non sarà MAI programmazione ad oggetti.

mica è obbligatorio imparare tutto quello che c'è da imparare senza cambiare linguaggio. anzi secondo me cambiare linguaggio fa bene

:mbe:
ovvio, per uno alle prime armi, che non è già abbastanza confuso, facciamolo saltare da un linguaggio all'altro per imparare le diverse cose.. :mbe:
anzi no..
ancora meglio.
Facciamogli imparare per bene solo la programmazione procedurale in C e poi le bestemmie che tirerà quando dovrà entrare nell'ottica di programmazione ad oggetti (Quella vera, non quella che tu chiami ad oggetti solo perchè è fatta in un linguaggio che supporta il paradigma OO) e dovrà cambiare completamente la mentalità le ascolti tu.

puoi anche non usare i puntatori, mica è obbligatorio. se proprio li devi usare non fa male visto che nei linguaggi a oggetti si incontra il concetto di riferimento (e chi conosce i puntatori non fa molta fatica a capire come funzionano)
ovvio.
A questo punto perchè non iniziare con l'assembly? :)
tanto usare i registri e capire quanto siano importanti nellla cpu è essenziale. :)
senza questo concetto non puoi nemmeno scrivere una riga di codice :)
Anzi, a questo punto meglio iniziare col codice macchina...
no, ma che dico!
perchè non gli facciamo anche studiare lo schema elettrico del full-adder, la disposizione dei transistor della cache di primo livello, e magari l'implementazione hardware dello scheduler e dell'unita FP o SSE? :)
tanto se proprio li devi usare non fa male e almeno impari per bene a cosa servono. :)

[k0nt3]

:mbe:
che java metta a disposizione strutture che supportino la programmazione ad oggetti non è affatto automatico che ogni cosa che fai in java è programmazione ad oggetti.
Se scrivi tutto nel main di una classe unica quella, per quanto tu ti possa impegnare, non è e non sarà MAI programmazione ad oggetti.

è come usare lo spazzolino da denti per pettinarsi
che Java non supporta la programmazione procedurale è condiviso da tutto il mondo, altrimenti dovremmo dire che C supporta la programmazione a oggetti visto che qualcuno sostiene di programmare a oggetti in C, ma non mi sembra il caso.
ovvio che qualcuno che vuole farsi del male c'è sempre

:mbe:
ovvio, per uno alle prime armi, che non è già abbatanza confuso, facciamolo saltare da un linguaggio all'altro per imparare le diverse cose.. :mbe:
anzi no..
ancora meglio.
Facciamogli imparare per bene solo la programmazione procedurale in C e poi le bestemmie che tirerà quando dovrà entrare nell'ottica di programmazione ad oggetti (Quella vera, non quella che tu chiami ad oggetti solo perchè è fatta in un linguaggio che supporta il paradigma OO) e dovrà cambiare completamente la mentalità le ascolti tu.

mi sembrava scontato che prima di cambiare linguaggio dovesse conoscere quello corrente molto bene.
a me invece non piacciono i linguaggi multiparadigma perchè va a finire che puoi fare la stessa cosa in 4000 modi diversi, questione di gusti.
comunque sembra che parlate di bambini di 4 anni confusi, non di gente che vuole imparare a programmare

ps. non sapevo che esisteva anche la programmazione a oggetti finta, se dico a oggetti intendo a oggetti, non procedurale usando un linguaggio a oggetti

ovvio.
A questo punto perchè non iniziare con l'assembly? :)
tanto usare i registri e capire quanto siano importanti nellla cpu è essenziale. :)
senza questo concetto non puoi nemmeno scrivere una riga di codice :)
Anzi, a questo punto meglio iniziare col codice macchina...
no, ma che dico!
perchè non gli facciamo anche studiare lo schema elettrico del full-adder, la disposizione dei transistor della cache di primo livello, e magari l'implementazione hardware dello scheduler e dell'unita FP o SSE? :)
tanto se proprio li devi usare non fa male e almeno impari per bene a cosa servono. :)
invece di cambiare discorso potresti sempre dimostrare che per capire i riferimenti non serve assolutamente a nulla conoscere i puntatori.
poi ci lamentiamo di quelli che credono che in java esiste il passaggio (EDIT: dei parametri) per riferimento..

[Albi89]

:mbe:
che java metta a disposizione strutture che supportino la programmazione ad oggetti non implica assolutamente che ogni cosa che fai in java è programmazione ad oggetti.
Se scrivi tutto nel main di una classe unica quella, per quanto tu ti possa impegnare, non è e non sarà MAI programmazione ad oggetti.
Esattamente, ed è quello che si farà nei propri primi esperimenti.
Il minimo indispensabile per assumere un'idea del concetto di flusso del programma.
Sicuramente meglio è più economico in quanto a sforzo e tempo dello studiare un linguaggio solo per assimilare questi concetti.
Il punto però rimane quello: un principiante difficilmente riuscirà ad organizzare il proprio codice "ad oggetti", quindi per quanto si sforzerà, per le prime settimane/mesi della sua formazione applicherà una forma di programmazione più vicina a quella procedurale (ossia studiando le azioni conseguenti che il mio programma esegue, e non quelle che eseguono le componenti, collaborando tra loro).

Caspita se siamo un pelo arroganti... chiedo perdono per le mie imprecisioni, andrò a contestarle al mio docente di corso quando ne avrò il tempo (tanto l'esame l'ho già dato...).
in ogni caso si chiedeva un consiglio soggettivo e a mio parere era Java.
Grazie in ogni caso per la dritta, proverò Python quando ne avrò l'occasione.
Non penso che stesse criticando il tuo consiglio, semplicemente il "il C# non lo considero proprio perchè è Microsoft" (ok, non hai scritto così, ma insomma, era chiaro)

forse il C è stato un pò "declassato" a linguaggio didattico per far capire un pò la programmazione, i cicli iterativi e appunto la gestione della memoria. Quando me l'hanno insegnato, 3/4 dell'insegnamento erano dediti a puntatori, allocazione, memoria ecc...
A parte che non credo proprio sia stato declassato: c'è tanto software C in giro, tantissimo, ed è facile che se vorrai lavorare su un progetto open source ti ritroverai a doverlo usare, per non parlare del fatto che potresti avere la sfortuna di trovarti a svolgere compiti di manutenzione su vecchio software C scritto secondo metodologie vecchie come il cucco.
In ogni caso, non la reputo una cosa bella... è un peccato perdere 3/4 di corso a parlare di puntatori e allocazione quando si potrebbero dedicare a cose davvero utili e interessanti.

[demos88]

Non penso che stesse criticando il tuo consiglio, semplicemente il "il C# non lo considero proprio perchè è Microsoft" (ok, non hai scritto così, ma insomma, era chiaro)

credo pure io fosse per quello, ma la linea ironica non l'ha percepita proprio nessuno?


A parte che non credo proprio sia stato declassato: c'è tanto software C in giro, tantissimo, ed è facile che se vorrai lavorare su un progetto open source ti ritroverai a doverlo usare, per non parlare del fatto che potresti avere la sfortuna di trovarti a svolgere compiti di manutenzione su vecchio software C scritto secondo metodologie vecchie come il cucco.
In ogni caso, non la reputo una cosa bella... è un peccato perdere 3/4 di corso a parlare di puntatori e allocazione quando si potrebbero dedicare a cose davvero utili e interessanti.
"declassato" fra virgolette... di C so perfettamente che si possono fare diverse cose interessanti. Ma stiamo parlando di linguaggi per imparare a programmare, non per sviluppare applicazioni sofisticate... e in tal senso il C è più "grezzo" di altri linguaggi e il fatto che permetta digiocare molto con la memoria in modo diretto, può complicare la vita di chi ha poca esperienza nel campo.
Pure io sono d'accordo con te che nn sia il massimo spendere tutto quel tempo nell'imparare qualcosa di così poco interessante (vabè magari a qualcuno piace).

[das]

beh applicazioni semplici sotto win
dato che sono a 0 come programmazione
vorrei proprio cominciare da cose semplici poi magari se mi appassiono passero' a qualcosa di piu complicato
potete mandarmi in privato un link con qualche guida?
grazie :D

Io ti consiglio di usare un RAD, ovvero un ambiente che ti consente di disegnare le finestre e i bottoni come con il Paint. Con python ti tocca scrivere tutto a mano, io ti suggerisco Delphi della Borland o il suo clone Open Lazarus.

Consentono di fare quasi tutto quello (a meno che tu non sviluppi driver o simili) che fa il c++ ma in molto meno tempo e con un linguaggio molto molto più
intuitivo.
Tanto per darti un esempio:

&&(C++)----> AND (delphi)
i++(C++)---->inc(i)(delphi)

Inoltre puoi compilare sia per Linux che Windows e se usi Lazarus anche per MAC ma per quello ti conviene aspettare la prox versione.

[^TiGeRShArK^]

è come usare lo spazzolino da denti per pettinarsi
che Java non supporta la programmazione procedurale è condiviso da tutto il mondo, altrimenti dovremmo dire che C supporta la programmazione a oggetti visto che qualcuno sostiene di programmare a oggetti in C, ma non mi sembra il caso.
ovvio che qualcuno che vuole farsi del male c'è sempre

Come credo che sia condiviso in tutto il mondo il fatto che è possibile scrivere schifezze simil-procedurali anche in java.
Che tu debba per forza creare almeno un oggetto in java non significa assolutamente che stai programmando ad oggetti.
Altrimenti, in quel caso, sarebbe davvero equivalente imparare a programmare in c o in java, perchè l'unica differenza sarebbe che in c non usi nemmeno un oggeto ed in java ne usi uno.
Però dovresti ben sapere che la programmazione ad oggetti è cosa BEN diversa :)

mi sembrava scontato che prima di cambiare linguaggio dovesse conoscere quello corrente molto bene.

Per conoscere il C MOLTO bene (io l'ho abbandonato ben prima di arrivare a conoscerlo MOLTO bene) si deve fare due palle così con segmentation fault, aritmetica dei puntatori e tutte le porcherie di basso livello legate alla gestione della memoria del c.
E deve programmare per ANNI con quel linguaggio per arrivare a conoscerlo MOLTO bene.

a me invece non piacciono i linguaggi multiparadigma perchè va a finire che puoi fare la stessa cosa in 4000 modi diversi, questione di gusti.
comunque sembra che parlate di bambini di 4 anni confusi, non di gente che vuole imparare a programmare

Una persona che non ha mai visto niente di programmazione è del tutto equivalente ad un bambino di 4 anni che sta imparando a leggere.
Deve partire da zero per imparare a leggere e a scrivere in un determinato linguaggio.

ps. non sapevo che esisteva anche la programmazione a oggetti finta, se dico a oggetti intendo a oggetti, non procedurale usando un linguaggio a oggetti

E' inutile che fai il finto tonto... :rolleyes:
se tu hai un progetto da 20K LOC che fa tutto in una classe unica dentro il main per te quella è programmazione ad oggetti? :rolleyes:
Se è così mi sa che non hai ben chiaro cosa voglia dire programmare ad oggetti.
In quel modo al massimo puoi dire di utilizzare in maniera prettamente procedurale degli oggetti, che è ben diverso dal programmare ad oggetti.

invece di cambiare discorso potresti sempre dimostrare che per capire i riferimenti non serve assolutamente a nulla conoscere i puntatori.
poi ci lamentiamo di quelli che credono che in java esiste il passaggio (EDIT: dei parametri) per riferimento..
:mbe:
secondo te per capire cos'è un riferimento devo smazzarmi l'aritmetica dei puntatori, devo capire quanto occupa un determinato tipo di dato per poter utilizzare un array senza fare danni e cose del genere ?:mbe:
un reference è semplicemente un oggetto che contiene delle informazioni sul DOVE sono memorizzati alcuni dati.
è del tutto equivalente ad un insieme di coordinate nel piano cartesiano, che determinano un punto, o ad una chiave univoca su un tabella di un database, che punta ad una riga contente i dati che ci servono.
Tramite un reference è quindi possibile accedere a tali dati.
Non vedo che problema ci sia ad apprendere questo concetto, che dovrebbe essere per altro già noto da altre materie, senza infognarsi con l'aritmetica dei puntatori, la grandezza variabile dei tipi di dati, il controllo sula dimensione del buffer e menate simili :fagiano:

[^TiGeRShArK^]

Io ti consiglio di usare un RAD, ovvero un ambiente che ti consente di disegnare le finestre e i bottoni come con il Paint. Con python ti tocca scrivere tutto a mano, io ti suggerisco Delphi della Borland o il suo clone Open Lazarus.

Consentono di fare quasi tutto quello (a meno che tu non sviluppi driver o simili) che fa il c++ ma in molto meno tempo e con un linguaggio molto molto più
intuitivo.
Tanto per darti un esempio:

&&(C++)----> AND (delphi)
i++(C++)---->inc(i)(delphi)

Inoltre puoi compilare sia per Linux che Windows e se usi Lazarus anche per MAC ma per quello ti conviene aspettare la prox versione.
Con Visual Studio o con Netbeans può benissimo disegnare i controlli con un ambiente RAD....
Delphi ormai sinceramente mi pare piuttosto in declino rispetto ai suo anni d'oro...
Con tutto che uno dei miei programmi preferiti, Context, è proprio scritto in delphi :p

[k0nt3]

ricordo comunque che io non suggerisco di iniziare con il C, perchè ormai credo che la questione del linguaggio sia secondaria e molto soggettiva.
a me ad esempio piace il pascal come linguaggio didattico, "qualcuno" ( :asd: ) preferisce python, altri C#, Java e chi più ne ha più ne metta.
Come credo che sia condiviso in tutto il mondo il fatto che è possibile scrivere schifezze simil-procedurali anche in java.
Che tu debba per forza creare almeno un oggetto in java non significa assolutamente che stai programmando ad oggetti.
Altrimenti, in quel caso, sarebbe davvero equivalente imparare a programmare in c o in java, perchè l'unica differenza sarebbe che in c non usi nemmeno un oggeto ed in java ne usi uno.
Però dovresti ben sapere che la programmazione ad oggetti è cosa BEN diversa :)


E' inutile che fai il finto tonto... :rolleyes:
se tu hai un progetto da 20K LOC che fa tutto in una classe unica dentro il main per te quella è programmazione ad oggetti? :rolleyes:
Se è così mi sa che non hai ben chiaro cosa voglia dire programmare ad oggetti.
In quel modo al massimo puoi dire di utilizzare in maniera prettamente procedurale degli oggetti, che è ben diverso dal programmare ad oggetti.
ah lo so bene, ho avuto a che fare con progetto in cui la dimensione media di una classe era di 6000 righe di codice con punte di 8000 :muro:
e come se non bastasse faceva largo uso di variabili "globali" :muro: :muro:
così anche con tutta la buona volontà che ci ho messo a rifattorizzare non facevo che rompere le cose.
in ogni caso questo non dimostra che in java si può programmare in maniera procedurale, ma solo che si può programmare in maniera sbagliata.
java offre solo gli strumenti che permettono di programmare a oggetti, se qualcuno cerca di programmare in maniera procedurale non fa altro che usare lo spazzolino per pettinarsi :)

Per conoscere il C MOLTO bene (io l'ho abbandonato ben prima di arrivare a conoscerlo MOLTO bene) si deve fare due palle così con segmentation fault, aritmetica dei puntatori e tutte le porcherie di basso livello legate alla gestione della memoria del c.
E deve programmare per ANNI con quel linguaggio per arrivare a conoscerlo MOLTO bene.
io parlavo soprattutto del linguaggio, non delle librerie (standard e non).
C come linguaggio non è molto complesso, visto che praticamente usa solo concetti primitivi.

Una persona che non ha mai visto niente di programmazione è del tutto equivalente ad un bambino di 4 anni che sta imparando a leggere.
Deve partire da zero per imparare a leggere e a scrivere in un determinato linguaggio.

secondo me farebbe meglio a imparare a programmare, piuttosto che imparare a leggere e scrivere in un determinato linguaggio.
per questo dico che imparare più di un linguaggio e più di un paradigma è fondamentale per un programmatore.
la cosa sottointesa in tutto questo è che non si impara a programmare in due giorni.

:mbe:
secondo te per capire cos'è un riferimento devo smazzarmi l'aritmetica dei puntatori, devo capire quanto occupa un determinato tipo di dato per poter utilizzare un array senza fare danni e cose del genere ?:mbe:
un reference è semplicemente un oggetto che contiene delle informazioni sul DOVE sono memorizzati alcuni dati.
no, sono daccordo.
però se uno conosce i puntatori non deve aggiungere altro alle sue conoscenze per capire i riferimenti.
questo lo dicevo per chi sostiene che bisogna dimenticare tutto quello che si impara dal C (la cosa più importante che si impara con il C in ogni caso è la programmazione strutturata)

è del tutto equivalente ad un insieme di coordinate nel piano cartesiano, che determinano un punto, o ad una chiave univoca su un tabella di un database, che punta ad una riga contente i dati che ci servono.
Tramite un reference è quindi possibile accedere a tali dati.
Non vedo che problema ci sia ad apprendere questo concetto, che dovrebbe essere per altro già noto da altre materie, senza infognarsi con l'aritmetica dei puntatori, la grandezza variabile dei tipi di dati, il controllo sula dimensione del buffer e menate simili :fagiano:
eh guarda non lo vedo nemmeno io il problema, ma di gente che non riesce a capire i riferimenti ne ho vista parecchia.
la maggiorparte delle volte gli va bene, ma poi quando si tratta di passare oggetti come parametro ai metodi cozzano contro un muro. o peggio ancora quando si ha a che fare con la copia di un oggetto

[dreadknight]

e lì se non progetti bene il costruttore di copia (e quindi devi aver capito bene i riferimenti e come vengono gestiti i puntatori) non capirai mai il problema

[^TiGeRShArK^]

e lì se non progetti bene il costruttore di copia (e quindi devi aver capito bene i riferimenti e come vengono gestiti i puntatori) non capirai mai il problema

appunto in C il problema è gestire correttamente i puntatori..
non risolvere il VERO problema che devi affrontare.
E' proprio questo il motivo per cui NON è assolutamente adatto ad un principiante.
Anzichè preoccuparti di risolvere il problema ti devi preoccupare di MILLE altre cose che non c'entrano assolutamente nulla col tuo problema e quindi sprechi del tempo che avresti potuto impiegare per apprendere meglio la programmazione.

[^TiGeRShArK^]

secondo me farebbe meglio a imparare a programmare, piuttosto che imparare a leggere e scrivere in un determinato linguaggio.

appunto per questo imparare a scrivere un italiano corretto è ben diverso dallo scrivere qualcosa del tipo: "io Tarzhan tu giane volHer tu tromb with muà?".
Un programmatore alle prime armi si trova appunto a comunicare in maniera corretta col computer (quindi a scrivere cose sintatticamente giuste), ad imparare la differenza semantica tra i vari concetti e infine a migliorare il suo stile, chiedendo a Jane di dargliela nella maniera + elegante possibile ;)

per questo dico che imparare più di un linguaggio e più di un paradigma è fondamentale per un programmatore.

E infatti io sono d'accordissimo.
Ma il paradigma procedurale lo abolirei del tutto dato che è assolutamente inutile, oltre che dannoso.

la cosa sottointesa in tutto questo è che non si impara a programmare in due giorni.

e nemmeno in due anni :p

no, sono daccordo.
però se uno conosce i puntatori non deve aggiungere altro alle sue conoscenze per capire i riferimenti.
questo lo dicevo per chi sostiene che bisogna dimenticare tutto quello che si impara dal C (la cosa più importante che si impara con il C in ogni caso è la programmazione strutturata)

Il 99% allora va bene?
cosa ti rimane oltre al concetto di puntatore che non potresti imparare in qualsiasi altro linguaggio OO? :fagiano:

[Strat]

Prima regola del neofita della programmazione: non chiedere mai ad un programmatore quale linguaggio dovresti imparare ?

Il pensiero di Bjarne Stroustrup

Howard Dierking:
Perché tra i linguaggi di programmazione e le persone si stabilisce una relazione talmente stretta e profonda da portare alla creazione di community di veri e propri fanatici dei linguaggi?

Bjarne Stroustrup:
Questa domanda dovrebbe essere posta a uno psicologo, un sociologo o probabilmente un economista, piuttosto che a un informatico. Suppongo che i linguaggi che utilizziamo per esprimere le nostre idee diventino parte di noi stessi e, pertanto, se si conosce un solo linguaggio, i sostenitori di altri linguaggi potrebbero essere percepiti come "personalmente pericolosi". In tal caso, la soluzione sembra essere quella di apprendere il maggior numero di linguaggi possibili. Ritengo che non si possa diventare professionisti nel settore del software conoscendo un solo linguaggio di programmazione. È anche possibile che esista una ragione economica: la conoscenza delle nozioni di base, a differenza dell'esperienza pratica, trascende i limiti dei linguaggi di programmazione. Quindi, se conosco solo il linguaggio X e i relativi set di strumenti, mentre un altro utente sostiene il linguaggio Y e i set di strumenti associati, questa persona rappresenta una minaccia per la mia sussistenza. Ancora una volta, la soluzione sembra essere quella di conoscere più linguaggi e set di strumenti (oltre che avere una solida conoscenza dei concetti di base). Purtroppo, le soluzioni che ho suggerito non tengono conto del fatto che alla maggior parte delle persone resta poco tempo a disposizione dopo aver fatto il necessario per restare a galla. Tuttavia, non esistono scusanti per il fanatismo.

A mio modesto parere da ogni linguaggio può imparare qualcosa di utile che ti servirà per diventare un programmatore migliore.
Io sono un programmatore .NET che però negli anni dell'uni ha sempre programmato in java, e prima in c++ e prima ancora in pascal e basic, e tutto mi è stato utile.
Perfino ora, che a malincuore sono costretto ad usare fox pro, sono convinto che lavorare a così stretto contatto coi dati mi insegnerà qualcosa.

Io comunque, se dovessi partire da zero, userei c++ come linguaggio, ma soprattutto mi farei il c**lo sui concetti di base, sull'architettura, sui pattern, sull'uso della memoria, ecc...
Il linguaggio è l'ultimo dei problemi ....

[k0nt3]

appunto per questo imparare a scrivere un italiano corretto è ben diverso dallo scrivere qualcosa del tipo: "io Tarzhan tu giane volHer tu tromb with muà?".
Un programmatore alle prime armi si trova appunto a comunicare in maniera corretta col computer (quindi a scrivere cose sintatticamente giuste), ad imparare la differenza semantica tra i vari concetti e infine a migliorare il suo stile, chiedendo a Jane di dargliela nella maniera + elegante possibile ;)
:sbonk:
a parte gli scherzi su questo credo che si possa discutere per giorni senza approdare a nulla :fagiano:
questo perchè "comunicare nella maniera corretta" con il computer potrebbe assumere significati diversi a seconda del contesto (attitudini del soggetto, scopi che si prefigge, il caso :D ecc...)

E infatti io sono d'accordissimo.
Ma il paradigma procedurale lo abolirei del tutto dato che è assolutamente inutile, oltre che dannoso.

dai che è la volta buona che python sparisce dalla faccia della terra :asd:
eh si anche lui supporta la programmazione procedurale :O (oltre che quella a oggetti e quella funzionale :O )
comunque non si può nascondere che i primi programmi che si scrivono tipicamente sono tentativi di codice procedurale.
e non è un caso, perchè prima bisogna perlomeno conoscere le strutture di controllo, le variabili e un paio di altri concetti basilari. la programmazione procedurale ha il pregio di contenere il minimo essenziale per imparare questi concetti. senza dubbio avrà anche dei difetti, ma sta di fatto che non ho mai visto qualcuno che al primo tentativo tira fuori una gerarchia di classi magari usando il polimorfismo :stordita:
probabilmente si potrebbe fare un discorso diverso per certi linguaggi esotici (come prolog ad esempio), ma nel caso generico no

Il 99% allora va bene?
cosa ti rimane oltre al concetto di puntatore che non potresti imparare in qualsiasi altro linguaggio OO? :fagiano:
l'ho già detto, la programmazione strutturata (strutture di controllo ecc..) è l'unica cosa su cui bisogna soffermarsi veramente quando si programma in C. sono tutte cose che servono anche quando programmi a oggetti e sono completamente ortogonali alla filosofia object oriented

[k0nt3]

aggiungo che di solito nei corsi base di programmazione si usa C e non un altro linguaggio procedurale (come pascal) proprio perchè espone dei problemi legati alla memoria. potrebbe sembrare un controsenso, ma allo stesso tempo potrebbe avere senso perchè solitamente si affianca lo studio del linguaggio allo studio della macchina di von neumann.

[marco.r]

Si tratta di due paradigmi diversi, molto diversi, e purtroppo è difficile "scrollarsi di dosso" un modo di ragionare o un approccio alla risoluzione dei problemi.

Proprio per questa difficolta' non sarebbe male imparare non solo questi due paradigmi, ma avere un panorama generale di quelli presenti in letteratura. Aiuta a capire quali sono gli aspetti generali e quali no, e a non restare intrappolati nelle idiosincrasie dell'uno o dell'altro. Ovviamente e' un obiettivo a lungo termine, e resta il problema del linugaggio con cui iniziare :p. Proprio per andare al sodo il prima possibile, consiglio anch'io di partire direttamente da un linguaggio OO di alto livello (non necessariamente moderno, Smalltalk ha vent'anni piu' di Java ma secondo me e' ancora una spanna sopra :p). E' vero che alcune cose che si imparano in C si possono riciclare, ma quelle che poi non servono piu' sono tante e tali che il gioco non vale la candela. Tanto vale partire con qualcos'altro ed essere pienamente produttivi in meno tempo.
Dal punto di vista prettamente tecnico sarebbe un'ottima idea anche partire direttamente con la programmazione funzionale, ma ci sono anche altri aspetti che la rendono meno consigliabile (diffusione, tools disponibili ... )

[cdimauro]

questi sono alcuni esempi di applicazioni che ne fanno uso http://www.excelsior-usa.com/jetgallery.html
io ho provato tuxguitar e funziona alla perfezione.
la cosa interessante è che per scopi non commerciali è un prodotto gratuito
Grazie per le informazioni. :)
ma di sicuro python non è incluso nel SO e va scaricato,
Questo vale anche per Java, C# e quant'altro.
se poi l'installazione consiste nello scompattare un archivio è un'altro discorso ;)
L'installazione standard di Python è... standard, appunto. :D Roba per chiunque: Setup, Avanti, Avanti, Fine.

Ma Python, come dicevo, non necessita di essere installato: è sufficiente copiarsi la cartella in cui sta per farlo girare ovunque, come ho fatto io. :cool:
Vero, ma io sono un integralista Linuxiano di mentalità aperta: i prodotti buoni li riconosco. :D
Noto due contraddizioni in una sola frase. :asd:
Allora nei prossimi giorni potremmo crearlo con la collaborazione di tutti. :)
Io, quando potrò, cercherò qualche link a discussioni passate, segnalando i post più interessanti (i miei ovviamente :asd:).
Sarebbe ottimo, soprattutto con un bel post iniziale con links a siti di riferimento, uno o due volumi consigliati e una breve descrizione delle caratteristiche e degli effettivi domini di utilizzo del linguaggio (ad esempio a proposito di python e ruby sarebbero da sottolineare i "succosi" (anche loro) framework per lo sviluppo web)
Per Python c'è django che è ottimo. Ci stanno lavorando due miei colleghi "PHPisti" e si stanno trovando benissimo. :cool:
qualsiasi persona prima di imparare a programmare a oggetti non sa programmare a oggetti, non vale solo per chi inizia con il C.
la differenza è che chi inizia con il C impara essenzialmente la programmazione strutturata (che serve anche nei linguaggi a oggetti) e quindi gli rimane meno da imparare
Di meno? O di più? :O

Sicuramente impara a soffrire di più, com'è giusto che sia. :asd:
se ne sei convinto...

io penso che in ogni cosa si parte dalla base per poi fare via via argomenti più complessi. Il C ti serve per acquisire la logica della programmazione, successivamente puoi imparare a lavorare con gli oggetti.

Altrimenti è come voler risolvere un integrale senza conoscere le derivate (scusate l'esempio matematico, ma la mia facoltà mi impone ciò :D )
A me sfugge il nesso fra "base" / logica della programmazione e C: potresti spiegarmelo, cortesemente?
se cerchi bene su google vedrai che è possibile "programmare a oggetti" anche in C e addirittura in assembly. ma io quella non la chiamerei programmazione a oggetti, come non chiamerei programmazione procedurale quella che puoi fare in java.
ho pure definito il concetto di "supportare" per evitare simili discorsi
Ne abbiamo già parlato infatti: bisogna essere mentalmente contorti / depravati per sviluppare applicazioni a oggetti con linguaggi come C, o addirittura assembly.

Insomma, roba da giapponesi. :asd:
mica è obbligatorio imparare tutto quello che c'è da imparare senza cambiare linguaggio. anzi secondo me cambiare linguaggio fa bene
Quando è necessario, sì.
puoi anche non usare i puntatori, mica è obbligatorio. se proprio li devi usare non fa male visto che nei linguaggi a oggetti si incontra il concetto di riferimento (e chi conosce i puntatori non fa molta fatica a capire come funzionano)
Fammi vedere come puoi programmare a oggetti in C (o, peggio ancora, in assembly) senza usare i puntatori. :O
Caspita se siamo un pelo arroganti... chiedo perdono per le mie imprecisioni, andrò a contestarle al mio docente di corso quando ne avrò il tempo (tanto l'esame l'ho già dato...).
Digli di aggiornarsi allora. :D

Quanto all'arroganza, beh, certe frasi te le potevi risparmiare: è stato arrogante il tuo atteggiamento nei confronti di un linguaggio che per tua stessa ammissione conosci ben poco.
in ogni caso si chiedeva un consiglio soggettivo e a mio parere era Java.
Grazie in ogni caso per la dritta, proverò Python quando ne avrò l'occasione.
Di niente.
forse il C è stato un pò "declassato" a linguaggio didattico per far capire un pò la programmazione, i cicli iterativi e appunto la gestione della memoria. Quando me l'hanno insegnato, 3/4 dell'insegnamento erano dediti a puntatori, allocazione, memoria ecc...
Tutte cose che con la didattica ti assicuro che non c'entrano proprio nulla.

Il problema è che tanta gente (non mi sto rivolgendo a te: è un discorso in generale) è convinta che basi della programmazione = quella roba che hai scritto sopra. Niente di più falso, ovviamente.

Purtroppo confondono i dettagli di basso di livello con le basi della programmazione, che hanno a che fare invece col concetto di dato, tipo, operazione, condizione, ecc.

[cdimauro]

A questo punto perchè non iniziare con l'assembly? :)
tanto usare i registri e capire quanto siano importanti nellla cpu è essenziale. :)
senza questo concetto non puoi nemmeno scrivere una riga di codice :)
Anzi, a questo punto meglio iniziare col codice macchina...
no, ma che dico!
perchè non gli facciamo anche studiare lo schema elettrico del full-adder, la disposizione dei transistor della cache di primo livello, e magari l'implementazione hardware dello scheduler e dell'unita FP o SSE? :)
tanto se proprio li devi usare non fa male e almeno impari per bene a cosa servono. :)
Io sono per iniziare con la programmazione in linguaggio macchina, per la famiglia Intel Itanium: non c'è nulla di meglio per farsi del mal, ehm, per partire col piede giusto dalle "basi".

Se sopravvivono a questo saranno sicuramente dei Veri Programmatori. :p
Il punto però rimane quello: un principiante difficilmente riuscirà ad organizzare il proprio codice "ad oggetti", quindi per quanto si sforzerà, per le prime settimane/mesi della sua formazione applicherà una forma di programmazione più vicina a quella procedurale (ossia studiando le azioni conseguenti che il mio programma esegue, e non quelle che eseguono le componenti, collaborando tra loro).
Su questo non concordo.
A parte che non credo proprio sia stato declassato: c'è tanto software C in giro, tantissimo, ed è facile che se vorrai lavorare su un progetto open source ti ritroverai a doverlo usare,
Già. Purtroppo c'è gente che non è capace di andare oltre quest'orribile e giurassico linguaggio di programmazione...
per non parlare del fatto che potresti avere la sfortuna di trovarti a svolgere compiti di manutenzione su vecchio software C scritto secondo metodologie vecchie come il cucco.
Esattamente.
In ogni caso, non la reputo una cosa bella... è un peccato perdere 3/4 di corso a parlare di puntatori e allocazione quando si potrebbero dedicare a cose davvero utili e interessanti.
Concordo.
Io ti consiglio di usare un RAD, ovvero un ambiente che ti consente di disegnare le finestre e i bottoni come con il Paint. Con python ti tocca scrivere tutto a mano, io ti suggerisco Delphi della Borland o il suo clone Open Lazarus.

Consentono di fare quasi tutto quello (a meno che tu non sviluppi driver o simili) che fa il c++ ma in molto meno tempo e con un linguaggio molto molto più
intuitivo.
Tanto per darti un esempio:

&&(C++)----> AND (delphi)
i++(C++)---->inc(i)(delphi)

Inoltre puoi compilare sia per Linux che Windows e se usi Lazarus anche per MAC ma per quello ti conviene aspettare la prox versione.
Tutto a mano no, ma sicuramente con un RAD come Delphi si va più spediti per lo sviluppo di applicazioni dotate di GUI.

In questo caso, quando mi capita, uso Delphi per lo scheletro dell'applicazione / interfaccia grafica, e cerco di spostare su Python quanta più logica possibile.

Insomma, cerco di sfruttare il meglio dei due mondi (grazie anche a ottimi strumenti, come Python4Delphi, che permettono ai due mondi di comunicare agevolmente).

Lazarus purtroppo è ancora molto immaturo, e ha una frazione (incompleta) delle classi che la VCL di Delphi mette a disposizione.
appunto in C il problema è gestire correttamente i puntatori..
non risolvere il VERO problema che devi affrontare.
E' proprio questo il motivo per cui NON è assolutamente adatto ad un principiante.
Anzichè preoccuparti di risolvere il problema ti devi preoccupare di MILLE altre cose che non c'entrano assolutamente nulla col tuo problema e quindi sprechi del tempo che avresti potuto impiegare per apprendere meglio la programmazione.
Concordo con tutto quello che hai scritto, ma quoto soltanto questo perché IMHO il nocciolo della discussione sta tutto qui, riassunto benissimo in poche righe. :)
Io comunque, se dovessi partire da zero, userei c++ come linguaggio, ma soprattutto mi farei il c**lo sui concetti di base, sull'architettura, sui pattern, sull'uso della memoria, ecc...
Il linguaggio è l'ultimo dei problemi ....
I concetti che hai esposto sono l'ultimo dei problemi per chi deve imparare a programmare (e anche, tante volte, per chi programma professionalmente).
dai che è la volta buona che python sparisce dalla faccia della terra :asd:
eh si anche lui supporta la programmazione procedurale :O (oltre che quella a oggetti e quella funzionale :O )
Purtroppo vedo che ritorni sempre sullo stesso tasto, nonostanto sia stato battuto una quantità smodata di volte e in un'occasione ti ho dimostrato che Python è un linguaggio orientato agli oggetti. :rolleyes:

[^TiGeRShArK^]

dai che è la volta buona che python sparisce dalla faccia della terra :asd:
eh si anche lui supporta la programmazione procedurale :O (oltre che quella a oggetti e quella funzionale :O )
comunque non si può nascondere che i primi programmi che si scrivono tipicamente sono tentativi di codice procedurale.
e non è un caso, perchè prima bisogna perlomeno conoscere le strutture di controllo, le variabili e un paio di altri concetti basilari. la programmazione procedurale ha il pregio di contenere il minimo essenziale per imparare questi concetti. senza dubbio avrà anche dei difetti, ma sta di fatto che non ho mai visto qualcuno che al primo tentativo tira fuori una gerarchia di classi magari usando il polimorfismo :stordita:
probabilmente si potrebbe fare un discorso diverso per certi linguaggi esotici (come prolog ad esempio), ma nel caso generico no

Beh, anch'io scrivo codice procedurale se devo fare uno spike oppure se devo fare un programmino da 30 righe di codice....
Ma quella non è assolutamente programmazione.
Per me programmare vuol dire risolvere problemi complessi utilizzando gli strumenti migliori che si hanno a disposizione e focalizzandosi sul problema da risolvere.
Ovviamente un problema complesso può solitamente essere scomposto in n problemi semplici, ma iniziando a programmare col paradigma procedurale, non si acquisiscono le nozioni necessarie a fare da "collante" per il nostro codice.
In quel modo si rischia di scrivere semplicemente codice procedurale con qualche chiamata a funzione utilizzata tipo macro.
Mi rendo conto che è difficile all'inizio apprendere questi concetti, ma è proprio per questo motivo che imho è assolutamente necessario concentrarsi su questo.

[cdimauro]

aggiungo che di solito nei corsi base di programmazione si usa C e non un altro linguaggio procedurale (come pascal) proprio perchè espone dei problemi legati alla memoria. potrebbe sembrare un controsenso, ma allo stesso tempo potrebbe avere senso perchè solitamente si affianca lo studio del linguaggio allo studio della macchina di von neumann.
Non vedo cos'abbia il Pascal meno del C per queste cose. :O
Proprio per questa difficolta' non sarebbe male imparare non solo questi due paradigmi, ma avere un panorama generale di quelli presenti in letteratura. Aiuta a capire quali sono gli aspetti generali e quali no, e a non restare intrappolati nelle idiosincrasie dell'uno o dell'altro. Ovviamente e' un obiettivo a lungo termine, e resta il problema del linugaggio con cui iniziare :p. Proprio per andare al sodo il prima possibile, consiglio anch'io di partire direttamente da un linguaggio OO di alto livello (non necessariamente moderno, Smalltalk ha vent'anni piu' di Java ma secondo me e' ancora una spanna sopra :p). E' vero che alcune cose che si imparano in C si possono riciclare, ma quelle che poi non servono piu' sono tante e tali che il gioco non vale la candela. Tanto vale partire con qualcos'altro ed essere pienamente produttivi in meno tempo.
Dal punto di vista prettamente tecnico sarebbe un'ottima idea anche partire direttamente con la programmazione funzionale, ma ci sono anche altri aspetti che la rendono meno consigliabile (diffusione, tools disponibili ... )
Concordo, a parte che con Python si potrebbe agevolmente passare in rassegna ogni paradigma di programmazione grazie alle capacità degli oggetti che espone. :cool:

[k0nt3]

Purtroppo vedo che ritorni sempre sullo stesso tasto, nonostanto sia stato battuto una quantità smodata di volte e in un'occasione ti ho dimostrato che Python è un linguaggio orientato agli oggetti. :rolleyes:
questa è programmazione a oggetti?

a, b = 0, 1
while b < 10:
print b
a, b = b, a+b

non vedo nulla di particolare.. a parte l'uso di istruzioni inutilmente contorte come: a, b = b, a+b
python che piaccia o no è multiparadigma

[k0nt3]

Per me programmare vuol dire risolvere problemi complessi utilizzando gli strumenti migliori che si hanno a disposizione e focalizzandosi sul problema da risolvere.

esattamente.. questo è programmare.
imparare a programmare invece significa risolvere problemi semplici utilizzando strumenti semplici (quindi non necessariamente migliori) e focalizzarsi nel tradurre le soluzioni ai problemi in algoritmi.
se non si sa fare questo difficilmente si impara a programmare

[Albi89]

questa è programmazione a oggetti?

a, b = 0, 1
while b < 10:
print b
a, b = b, a+b

non vedo nulla di particolare.. a parte l'uso di istruzioni inutilmente contorte come: a, b = b, a+b
python che piaccia o no è multiparadigma
Beh sul fatto che Python sia multiparadigma non c'è dubbio, d'altra parte non ti costringe ad avere almeno una classe, così come il C++.
Allora il C++ non è un linguaggio a oggetti? :mbe:
Che l'uso della , possa essere un po' disorientante per chi non lo conosce, è ok, ma non vedo in che modo renda un linguaggio "meno a oggetti".
Peraltro, sarei curioso di sapere se la soluzione che adotteresti in Java per questo frammento è molto più OO :sofico:

[marco.r]

questa è programmazione a oggetti?

a, b = 0, 1
while b < 10:
print b
a, b = b, a+b

non vedo nulla di particolare.. a parte l'uso di istruzioni inutilmente contorte come: a, b = b, a+b
python che piaccia o no è multiparadigma
non definirei contorto l'assegnamento parallelo. Soprattutto non lo reputo inutile in quanto permette di evitare l'uso di variabili temporanee e di rendere un po' piu' chiaro il codice.
In un mondo perfetto programmeremo (perlopiu') con variabili immutabili e senza side effects, rendendolo inutile, nell'attesa dell'avvento ci si accontententa :O :p
Per inciso l'esempio sopra e' poco indicativo... le strutture di controllo per il loop ci sono praticamente in tutti i linguaggi, compresi quelli OO.

[k0nt3]

Beh sul fatto che Python sia multiparadigma non c'è dubbio, d'altra parte non ti costringe ad avere almeno una classe, così come il C++.
Allora il C++ non è un linguaggio a oggetti? :mbe:
Che l'uso della , possa essere un po' disorientante per chi non lo conosce, è ok, ma non vedo in che modo renda un linguaggio "meno a oggetti".
Peraltro, sarei curioso di sapere se la soluzione che adotteresti in Java per questo frammento è molto più OO :sofico:
C++ supporta sia la programmazione a oggetti che quella procedurale, questo è poco ma è sicuro perchè include totalmente il C (trascuriamo le poche eccezioni).
l'uso della , è solo un particolare che ho notato al momento, ma non rende meno a oggetti il linguaggio, solo più contorto :p
il creatore di python non ha capito che scrivere due istruzioni sulla stessa riga non migliora la leggibilità.
in java si potrebbe (idea scema) creare una classe Fibonacci con un metodo next() che calcola il prossimo numero della serie.
più probabilmente però uno che inizia a programmare cercherà di creare codice procedurale mettendo tutto nel main, ma a me ste cose fanno rabbrividire :asd: a sto punto userei un linguaggio procedurale (EDIT:almeno non mi costringe a creare un oggetto di cui non ne comprendo il significato) :cool:

[k0nt3]

non definirei contorto l'assegnamento parallelo. Soprattutto non lo reputo inutile in quanto permette di evitare l'uso di variabili temporanee e di rendere un po' piu' chiaro il codice.
In un mondo perfetto programmeremo (perlopiu') con variabili immutabili e senza side effects, rendendolo inutile, nell'attesa dell'avvento ci si accontententa :O :p
Per inciso l'esempio sopra e' poco indicativo... le strutture di controllo per il loop ci sono praticamente in tutti i linguaggi, compresi quelli OO.

quindi non è perfettamente equivalente a:

a = 0
b = 1
while b < 10:
print b
a = b
b = a+b

:confused: :huh:

[shinya]

In un mondo perfetto programmeremo (perlopiu') con variabili immutabili e senza side effects

Smettila di usare haskell. :P

Per curiosità, hai dato un'occhiata a Factor? http://factorcode.org/

[Albi89]

C++ supporta sia la programmazione a oggetti che quella procedurale, questo è poco ma è sicuro perchè include totalmente il C (trascuriamo le poche eccezioni).
Certo, è lo stesso fa Python.
(No, non include il C, ma permette un approccio sia procedurale che a oggetti, oltre che funzionale)

l'uso della , è solo un particolare che ho notato al momento, ma non rende meno a oggetti il linguaggio, solo più contorto :p
il creatore di python non ha capito che scrivere due istruzioni sulla stessa riga non migliora la leggibilità.
Dipende, in casi dove è palese il collegamento tra le variabili può risparmiare spazio: mentre segui i nuovi valori, separati da virgole, devi poter tracciare in mente lo schema delle assegnazioni. Se non puoi farlo, è un caso in cui conviene fare assegnazioni su righe separate.
Comunque è un piccolo problema, male che vada puoi non usarlo :D
E poi direi che in generale Python non pecca certo di leggibilità, già solo la possibilità di scrivere:a = 0 if a < 0 else 1 invece di a = (a < 0) ? 0 : 1; è impagabile :fagiano:

in java si potrebbe (idea scema) creare una classe Fibonacci con un metodo next() che calcola il prossimo numero della serie.
più probabilmente però uno che inizia a programmare cercherà di creare codice procedurale mettendo tutto nel main, ma a me ste cose fanno rabbrividire :asd: a sto punto userei un linguaggio procedurale (EDIT:almeno non mi costringe a creare un oggetto di cui non ne comprendo il significato) :cool:
Ok, venendo al succo del messaggio.
Potrebbe farlo non vuol dire molto, potrebbe farlo anche in Python.
Se non ha le conoscenze per farlo in Python, non lo farà neanche in Java.
La risposta, in sostanza, te la sei data tu, dicendo che probabilmente scriverà tutto nel main :D
Quì comunque Python fa questo: ti permette di non creare un oggetto se non ti serve. Per piccoli script è accettabile, e aggiunge solo alla sua versatilità.

Che poi puoi creare codice COMPLETAMENTE procedurale è vero, ma senza dubbio il concetto di oggetto è fortemente radicato in Python.

Un po' però mi dispiace che alcune cose, come le funzioni di conversione o la funzione che restituisce la lunghezza di una stringa, non siano implementate come metodi. Confido in cdimauro che mi illustri il perchè :fagiano:

[cdimauro]

questa è programmazione a oggetti?

a, b = 0, 1
while b < 10:
print b
a, b = b, a+b

non vedo nulla di particolare.. a parte l'uso di istruzioni inutilmente contorte come: a, b = b, a+b
python che piaccia o no è multiparadigma
Ti ha già risposto Marco: l'assegnazione multipla è molto comoda e, al contrario di ciò che affermi, rende il codice più leggibile, se usata con raziocinio:
Info = DB.Gets('SELECT Nome, Cognome, CodiceFiscale, Residenza, Cittadinanza FROM Utenti WHERE ID = %s', (12345, ))

Nome, Cognome, CodiceFiscale, Residenza, Cittadinanza = Info
Casualmente, guarda cosa succede con la (prima, per comodità) assegnazione multipla che hai scritto:
>>> a, b = 0, 1
>>> a, b
(0, 1)
>>> 0, 1
(0, 1)
>>> type((0, 1))
<type 'tuple'>
>>> isinstance((0, 1), object)
True
>>>
Ma guarda un po': Python crea degli OGGETTI di tipo tupla che contengono i valori 0 e 1.

Chi l'avrebbe mai detto: oggetti. :p
l'uso della , è solo un particolare che ho notato al momento,
E' questo il punto: tu sconosci perfino dei concetti BASILARI di Python, quali le tuple, e ti permetti di pontificare.
ma non rende meno a oggetti il linguaggio, solo più contorto :p
il creatore di python non ha capito che scrivere due istruzioni sulla stessa riga non migliora la leggibilità.
No, è diverso: è che tu non hai capito niente del linguaggio, e continui a tirare in ballo cose prese a casaccio perché ti sembrano "strane" pur di spalare letame su Python.

Peccato che, proprio perché ti mancano le basi, è facile dimostrare dove vuoi andare a parare...
in java si potrebbe (idea scema) creare una classe Fibonacci con un metodo next() che calcola il prossimo numero della serie.
def fib():
a, b = 0, 1
while True:
yield b
a, b = b, a + b

for n in fib():
print n
Fallo in Java adesso, e fammi vedere come verrebbe fuori. :O

[cdimauro]

Che poi puoi creare codice COMPLETAMENTE procedurale è vero, ma senza dubbio il concetto di oggetto è fortemente radicato in Python.
Esattamente. Anche perché... qualsiasi cosa è un oggetto in Python. :p
Un po' però mi dispiace che alcune cose, come le funzioni di conversione o la funzione che restituisce la lunghezza di una stringa, non siano implementate come metodi. Confido in cdimauro che mi illustri il perchè :fagiano:
Scelte di Guido. Personalmente li avrei implementati come metodi d'istanza.

Per quanto riguarda le funzioni di conversione, suppongo che ti riferisca a str e repr. Perché int(), float(), bool(), ecc. non sono funzioni, ma costruttori. ;)

[k0nt3]

Certo, è lo stesso fa Python.
(No, non include il C, ma permette un approccio sia procedurale che a oggetti, oltre che funzionale)
certo che lo include, la quasi totalità dei sorgenti validi in C sono validi anche in C++


Dipende, in casi dove è palese il collegamento tra le variabili può risparmiare spazio: mentre segui i nuovi valori, separati da virgole, devi poter tracciare in mente lo schema delle assegnazioni. Se non puoi farlo, è un caso in cui conviene fare assegnazioni su righe separate.
Comunque è un piccolo problema, male che vada puoi non usarlo :D
E poi direi che in generale Python non pecca certo di leggibilità, già solo la possibilità di scrivere:a = 0 if a < 0 else 1 invece di a = (a < 0) ? 0 : 1; è impagabile :fagiano:

a = (a < 0) ? 0 : 1;
è una di quelle cose che non sopporto :D di solito infatti non viene insegnata questa sintassi.
per quanto riguarda python.. dopo che ho scoperto che:

b == ('a' and 'b')

restituisce TRUE non mi stupisco più di niente :asd:



Ok, venendo al succo del messaggio.
Potrebbe farlo non vuol dire molto, potrebbe farlo anche in Python.
Se non ha le conoscenze per farlo in Python, non lo farà neanche in Java.
La risposta, in sostanza, te la sei data tu, dicendo che probabilmente scriverà tutto nel main :D
Quì comunque Python fa questo: ti permette di non creare un oggetto se non ti serve. Per piccoli script è accettabile, e aggiunge solo alla sua versatilità.

Che poi puoi creare codice COMPLETAMENTE procedurale è vero, ma senza dubbio il concetto di oggetto è fortemente radicato in Python.

Un po' però mi dispiace che alcune cose, come le funzioni di conversione o la funzione che restituisce la lunghezza di una stringa, non siano implementate come metodi. Confido in cdimauro che mi illustri il perchè :fagiano:
certamente, ma la differenza è sottile. java non offre gli strumenti per programmare in maniera completamente procedurale e la dimostrazione è il fatto che bisogna per forza creare un oggetto.
senza dubbio uno può concludere che non cambia molto.. però è evidente che java non è stato creato per programmare in quel modo, mentre in python viene naturale quanto programmare a oggetti

[k0nt3]

E' questo il punto: tu sconosci perfino dei concetti BASILARI di Python, quali le tuple, e ti permetti di pontificare.

No, è diverso: è che tu non hai capito niente del linguaggio, e continui a tirare in ballo cose prese a casaccio perché ti sembrano "strane" pur di spalare letame su Python.

Peccato che, proprio perché ti mancano le basi, è facile dimostrare dove vuoi andare a parare...


purtroppo ho dovuto imparare python, e so benissimo che qualsiasi cosa è un oggetto. ma non basta chiamare ogni cosa "oggetto" per programmare a oggetti

[Albi89]

Scelte di Guido. Personalmente li avrei implementati come metodi d'istanza.

Per quanto riguarda le funzioni di conversione, suppongo che ti riferisca a str e repr. Perché int(), float(), bool(), ecc. non sono funzioni, ma costruttori. ;)
Personalmente pensavo al perchè non ci fossero metodi come "toString" o "toInt", però non sapevo che quelli fossero i costruttori (per altro non ci voleva molto ad arrivarci :muro: )
Mia superficialità ;)

certamente, ma la differenza è sottile. java non offre gli strumenti per programmare in maniera completamente procedurale e la dimostrazione è il fatto che bisogna per forza creare un oggetto.
senza dubbio uno può concludere che non cambia molto.. però è evidente che java non è stato creato per programmare in quel modo, mentre in python viene naturale quanto programmare a oggetti
Penso che questo sia il ragionevole punto di incontro del nostro discorso, oltre il quale non ci muoveremo di un cm entrambi :D
Comunque ovviamente non intendevo dire che il C++ non include il C, ma che il Python non include il C (insomma, stavo solo scherzando perchè la mia frase precedente era "equivoca" :oink: )

[cdimauro]

certo che lo include, la quasi totalità dei sorgenti validi in C sono validi anche in C++


a = (a < 0) ? 0 : 1;
è una di quelle cose che non sopporto :D di solito infatti non viene insegnata questa sintassi.
Purtroppo sì, invece.
per quanto riguarda python.. dopo che ho scoperto che:

b == ('a' and 'b')

restituisce TRUE non mi stupisco più di niente :asd:
Anche di questo ne abbiamo abbondantemente parlato, ma al solito fai orecchie da mercante e torni a ripetere la solita litania. :rolleyes:
certamente, ma la differenza è sottile. java non offre gli strumenti per programmare in maniera completamente procedurale e la dimostrazione è il fatto che bisogna per forza creare un oggetto.
senza dubbio uno può concludere che non cambia molto.. però è evidente che java non è stato creato per programmare in quel modo, mentre in python viene naturale quanto programmare a oggetti
purtroppo ho dovuto imparare python, e so benissimo che qualsiasi cosa è un oggetto. ma non basta chiamare ogni cosa "oggetto" per programmare a oggetti
Indubbiamente. Ci sarebbe da chiedersi: "se in Python qualsiasi cosa è un oggetto, perché non imparare cosa sono gli oggetti, quali proprietà hanno e in che modo si usano?"

Domanda che chi ha una mentalità da programmatore procedurale nemmeno si pone...

[rafpro]

io avevo solo chiesto da dove partire....poi magari studio il C il java ecc
per ora mi serve una cosa semplice che mi permetta di fare applicazioni semplici sotto win tutto qui:D

[cdimauro]

Personalmente pensavo al perchè non ci fossero metodi come "toString" o "toInt", però non sapevo che quelli fossero i costruttori (per altro non ci voleva molto ad arrivarci :muro: )
Mia superficialità ;)
Piccolo lapsus: anche str(), ovviamente, invoca un costruttore, visto che str è la classe "base" delle stringhe, ma poi viene controllata la presenza del metodo __str__ all'interno dell'oggetto che è stato passato come argomento per effettuare la conversione vera e propria.

repr, però, l'avrei visto come metodo d'istanza dei vari oggetti, perché non esiste una classe repr, in quanto... non repr non è un tipo.
Idem per abs(), len(), ecc.: li avrei preferiti come metodi d'istanza.

[cdimauro]

io avevo solo chiesto da dove partire....poi magari studio il C il java ecc
per ora mi serve una cosa semplice che mi permetta di fare applicazioni semplici sotto win tutto qui:D
Se devi imparare a programmare, parti con Python.

Passare a sviluppare applicazioni dotate di interfaccia grafica adesso è pura follia: prima devi farti le ossa.

[k0nt3]

io avevo solo chiesto da dove partire....poi magari studio il C il java ecc
per ora mi serve una cosa semplice che mi permetta di fare applicazioni semplici sotto win tutto qui:D

ti consiglio di partire lontano da un forum frequentato da programmatori :O

:asd:

[DanieleC88]

Noto due contraddizioni in una sola frase. :asd:
:eekk:

Sacrilego! :D

[shinya]

def fib():
a, b = 0, 1
while True:
yield b
a, b = b, a + b

for n in fib():
print n
Fallo in Java adesso, e fammi vedere come verrebbe fuori. :O


Sembra che nessuno ne abbia avuto il coraggio... cmq viene fuori una merda tipo questa (se non ho sbagliato qualcosa):


import java.util.*;
import java.math.*;

class FibonacciSucks implements Iterable<BigInteger> {
public static void main(String [] args) {
for (BigInteger f : new FibonacciSucks())
System.out.println(f);
}

private BigInteger a, b;

public FibonacciSucks() {
a = BigInteger.ZERO; b = BigInteger.ONE;
}

public Iterator<BigInteger> iterator() {
return new FibIter();
}

private class FibIter implements Iterator<BigInteger> {
public boolean hasNext() {
return true;
}

public BigInteger next() {
BigInteger t = b;
b = a.add(b); a = t;
return t;
}

public void remove() {
}
}
}


che bello che è java...

[cdimauro]

Il coraggio non c'è proprio per quello che hai detto: è una merda. :D

Però per consigliare Java, C/C++ per imparare a programmare non si fanno problemi... :muro:

[DanieleC88]

Così chiudiamo il discorso un po' per tutti. :D
http://wiki.theory.org/YourLanguageSucks

(mezza cazzata, lo so...)

[marco.r]

Sembra che nessuno ne abbia avuto il coraggio... cmq viene fuori una merda tipo questa (se non ho sbagliato qualcosa):


<lots of code>




fibs = 1 : 1 : [ x + y | x <- fibs | y <- tail fibs ]
fib n = fibs !! n

Uguale uguale :P

[marco.r]

Smettila di usare haskell. :P

Per curiosità, hai dato un'occhiata a Factor? http://factorcode.org/

Si' :p, sembra carino, anche se ho avuto poco tempo per guardamelo bene... mi sto gia' guardando FORTH per cui per il dopo direi che calza a pennello :D

[gugoXX]

Così chiudiamo il discorso un po' per tutti. :D
http://wiki.theory.org/YourLanguageSucks

(mezza cazzata, lo so...)

C# doesn't suck :D

[DanieleC88]

C# doesn't suck :D
Vero. Almeno, non ancora. :D

[gugoXX]

Vero. Almeno, non ancora. :D

Oh, almeno per una cosa sucks pure lui.
Mai avuto bisogno, ma forse per usi matematici la mancanza di un vincolo sull'uso di generics che implementino un operatore specifico (tipo la somma) potrebbe farsi sentire.

[DanieleC88]

Ad esempio? Scusa ma a quest'ora non connetto molto. :muro:

[cdimauro]

Così chiudiamo il discorso un po' per tutti. :D
http://wiki.theory.org/YourLanguageSucks

(mezza cazzata, lo so...)
Sostanzialmente corretto, tranne per Python ovviamente.
Non per essere di parte, ma la sintassi delle tuple è ben definita e gli esempi esposti dimostrano soltanto una scarsa conoscenza sull'argomento.
Sugli argomenti di default in parte posso capire l'autore: è un meccanismo diverso da quello che ci aspetterebbe provenendo da altri linguaggi di programmazione, ma ovviamente ha una sua (forte) motivazione.
Sulla mancanza di break e continue "etichettati", assolutamente no: completamente in disaccordo.

Comunque, come vedi, si tratta di pochi punti, e per lo più opinabili. ;)

fibs = 1 : 1 : [ x + y | x <- fibs | y <- tail fibs ]
fib n = fibs !! n

Uguale uguale :P
Solo leggermente illeggibile per me. :stordita:
Si' :p, sembra carino, anche se ho avuto poco tempo per guardamelo bene... mi sto gia' guardando FORTH per cui per il dopo direi che calza a pennello :D
Il Forth... Quanto tempo. Ricordo che su MC MicroComputer, se non ricordo male, c'era una rubrica su questo linguaggio che si chiamava "Parla più Forth!". :D
Oh, almeno per una cosa sucks pure lui.
Mai avuto bisogno, ma forse per usi matematici la mancanza di un vincolo sull'uso di generics che implementino un operatore specifico (tipo la somma) potrebbe farsi sentire.
Avevi aperto un post un po' di tempo fa sull'argomento. Era un periodo in cui c'era un thread infuocato in cui "casualmente" con fek eravamo finiti a parlare di Python. :p

[gugoXX]

Avevi aperto un post un po' di tempo fa sull'argomento. Era un periodo in cui c'era un thread infuocato in cui "casualmente" con fek eravamo finiti a parlare di Python. :p

Si' esatto.
Prova a scrivere una funzione Generics che, lavorando su "NUMERI SOMMABILI", dato in ingresso un'istanza della classe/struttura scelta, ne restituisca il valore successivo.

qualcosa tipo


public static T NextValue<T>(T input) where T : ISommable
{
return input + 1;
}


(Come loro solito la sintassi di costruzione di un nuovo Generics fa abbastanza pena e non e' elegantissima.
Nell'uso almeno tutta la complessita' e' nascosta, e 99% delle volte i Generics si usano, non si scrivono)

Peccato che ISommable (o simili) non esista.
Non esiste neppure la dichiarazione generica INumber (o simili), in modo da dire: E' un numero come quelli che conosciamo. Nel corpo della funzione potrai usare gli operatori +-*/ etc.

Non mi capacito della mancanza. Un tempo pensavo che fosse per colpa della scelta di ottimizzazione in velocita' che si vuole dare al linguaggio. Intendo, quando si scrive a+b, dove a e b possono essere interi, double, etc. il C# non invoca veramente una funzione, ma compila direttamente l'istruzione macchina relativa al + (che puo' essere la assembly ADD per gli interi).
Questo non trovo difficile pensare che possa complicare la compilazione di un generics, se si volesse includere gli operatori nel ragionamento.
Ma poi mi sono detto, esiste l'interfaccia IComparable, che serve per confontare 2 istanze della classe, usata largamente e p.es. internamente nel codice degli ordinatori (Sort, OrderBy, OrderByDescending).
E quindi mi sono detto: O la scusa che stavo dando prima e' una bufala, oppure quando implemento IComparable per gli interi il compilatore non fa uso del'opcode Assembly CMP.
Spero per la prima, ovvero che sia una bufala prima o poi risolvibile.

Utilizzo ipotetico del tutto: Una funzione generica che si possa applicare a int, double, float, decimal e quante altre classi possano essere dichiarate sommabili, che restituisca la successione di Fibonacci.

[shinya]

Solo leggermente illeggibile per me. :stordita:


Lo puoi scrivere pure cosi se ti sembra più chiaro:

fibs = 0 : 1 : [ a + b | (a, b) <- zip fibs (tail fibs)]



Si' , sembra carino, anche se ho avuto poco tempo per guardamelo bene... mi sto gia' guardando FORTH per cui per il dopo direi che calza a pennello

Si in effetti dovrebbe essere un misto tra forth, lisp e un altro linguaggio che si chiamava joy di cui non avevo mai sentito parlare; ma ancora non sono pronto per i linguaggi a stack. Ho letto un pò la documentazione e mi si è arricciato il cervello... :cry:

[k0nt3]

Sembra che nessuno ne abbia avuto il coraggio... cmq viene fuori una merda tipo questa (se non ho sbagliato qualcosa):


import java.util.*;
import java.math.*;

class FibonacciSucks implements Iterable<BigInteger> {
public static void main(String [] args) {
for (BigInteger f : new FibonacciSucks())
System.out.println(f);

}

private BigInteger a, b;

public FibonacciSucks() {
a = BigInteger.ZERO; b = BigInteger.ONE;
}

public Iterator<BigInteger> iterator() {
return new FibIter();
}

private class FibIter implements Iterator<BigInteger> {
public boolean hasNext() {
return true;
}

public BigInteger next() {
BigInteger t = b;
b = a.add(b); a = t;
return t;
}

public void remove() {
}
}
}


che bello che è java...

ah non c'è bisogno del coraggio, non ho scritto il codice perchè tendo a evitare i discorsi tipo: il mio è più lungo del tuo gnegne :D
il tuo codice è una "merda" perchè è sovraingegnerizzato, non perchè è scritto in java.
una soluzione più consona è:

public class Fibonacci {
private int next = 1, current = 0;

public static void main(String[] args) {
Fibonacci fibonacci = new Fibonacci();
int i = 0;
while(i < 10) {
System.out.println(fibonacci.next());
++i;
}
}

private int next() {
int result = current;
current = next;
next = result + next;
return result;
}
}

la differenza sostanziale tra questa implementazione e quella che è stata postata prima in python è che questa è programmazione a oggetti, mentre quella in python è puramente procedurale.
questa invece:
fibs = 0 : 1 : [ a + b | (a, b) <- zip fibs (tail fibs)]
è programmazione a geroglifici

[k0nt3]

ah non sforzatevi a trovare l'implementazione migliore.. purtroppo esiste già ed è scritta in scala:

def fib( n: Int): Int = n match {
case 0 => 0
case 1 => 1
case _ => fib( n -1) + fib( n-2)
}

questo codice ha una corrispondenza 1:1 con la definizione di serie di fibonacci

EDIT:
ok mi è venuto in mente che è stupido cercare una soluzione iterativa a una successione che per definizione è ricorsiva. in java la soluzione ricorsiva sarebbe così:

public class Fibonacci {
public static void main(String[] args) {
Fibonacci fibonacci = new Fibonacci();
int i = 0;
while(i < 10) {
System.out.println(fibonacci.element(i));
++i;
}
}

private int element(int index) {
switch (index) {
case 0:
return 0;
case 1:
return 1;
default:
return element(index-1) + element(index-2);
}
}
}

[shinya]

ah non c'è bisogno del coraggio, non ho scritto il codice perchè tendo a evitare i discorsi tipo: il mio è più lungo del tuo gnegne :D
il tuo codice è una "merda" perchè è sovraingegnerizzato, non perchè è scritto in java.
una soluzione più consona è:

...cut!....



Umh...non so. Sicuramente il mio codice era sovraingegnerizzato per quello che si deve fare (calcolare la serie di fibonacci), ma quello che hai scritto non è, secondo me, la traduzione "letterale" del codice in python che è stato postato.

Il punto era generare uno stream di fibonacci sul quale iterare, e riusabile. Nell'esempio in python prendi la funzione che genera lo stream e la usi in un costrutto 'for'. Per fare questo in java devi creare un'iterable, c'è poco da fare.
Altra cosa, di dettaglio. Tu usi gli int, ma sei disonesto. Python, da quel che ne so io (non lo conosco benissimo), degrada i tipi numerici a seconda delle necessità. Quindi una traduzione al 100% avrebbe dovuto tener conto di questo. Usare gli int, poi quando non ci stai più i long, poi numeri a precisione arbitraria...per semplicità sono partito dai BigInteger subito. Con gli int invece non fai molta strada.



questa invece:
fibs = 0 : 1 : [ a + b | (a, b) <- zip fibs (tail fibs)]
è programmazione a geroglifici

La leggibilità dipende dal lettore.

[shinya]

ah non sforzatevi a trovare l'implementazione migliore.. purtroppo esiste già ed è scritta in scala:

def fib( n: Int): Int = n match {
case 0 => 0
case 1 => 1
case _ => fib( n -1) + fib( n-2)
}

questo codice ha una corrispondenza 1:1 con la definizione di serie di fibonacci


Si, peccato che abbia un tempo esponenziale. Calcola fib(80) e vedi quante volte ricalcoli gli stessi valori. Con un disegnino.

[marco.r]

fibs = 1 : 1 : [ x + y | x <- fibs | y <- tail fibs ]

Solo leggermente illeggibile per me. :stordita:

Sicuramente bisogna farci un po' di mano in quanto i ragionamenti coinvolti sono molto diversi dal solito, dopo un po' di pratica diventa molto leggibile (per me perlomeno).
L'importante e' leggerlo in forma dichiarativa e non procedurate.
"la sequenza dei numeri di fibonacci e' la sequenza che comincia con 1, 1 e continua con le somme x+y, dove x e' un numero di fibonacci e y e' il successore di x".
La notazione e' un po' meno chiara dell'ideale perche' la posizione e' definita implicitamente e senza indici (per non dover scorrere tutta la lista ad ogni passaggio).

[k0nt3]

Umh...non so. Sicuramente il mio codice era sovraingegnerizzato per quello che si deve fare (calcolare la serie di fibonacci), ma quello che hai scritto non è, secondo me, la traduzione "letterale" del codice in python che è stato postato.

Il punto era generare uno stream di fibonacci sul quale iterare, e riusabile. Nell'esempio in python prendi la funzione che genera lo stream e la usi in un costrutto 'for'. Per fare questo in java devi creare un'iterable, c'è poco da fare.
Altra cosa, di dettaglio. Tu usi gli int, ma sei disonesto. Python, da quel che ne so io (non lo conosco benissimo), degrada i tipi numerici a seconda delle necessità. Quindi una traduzione al 100% avrebbe dovuto tener conto di questo. Usare gli int, poi quando non ci stai più i long, poi numeri a precisione arbitraria...per semplicità sono partito dai BigInteger subito. Con gli int invece non fai molta strada.

non è una traduzione letterale del codice python perchè il codice python è procedurale mentre quello che ho postato è a oggetti.
ho usato int perchè funziona e non vedo la necessità di usare qualcosa di diverso


La leggibilità dipende dal lettore.
anche dallo scrittore :asd:
se vuoi facciamo a votazione :fagiano:

Si, peccato che abbia un tempo esponenziale. Calcola fib(80) e vedi quante volte ricalcoli gli stessi valori. Con un disegnino.
c'era un tale che diceva: premature optimization is the root of all evil in programming

[gugoXX]

ah non sforzatevi a trovare l'implementazione migliore.. purtroppo esiste già ed è scritta in scala:

def fib( n: Int): Int = n match {
case 0 => 0
case 1 => 1
case _ => fib( n -1) + fib( n-2)
}

questo codice ha una corrispondenza 1:1 con la definizione di serie di fibonacci


Penso che questa implementazione si scrivere altrettanto bene in praticamente tutti i linguaggi, anche in C standard...
Come detto e' pero' tragica dal punto di vista algoritmico.

Es: C#.

public static int Fibo(int input)
{
switch (input)
{
case 0: return 0;
case 1: return 1;
default: return Fibo(input - 1) + Fibo(input - 2);
}
}

[shinya]

non è una traduzione letterale del codice python perchè il codice python è procedurale mentre quello che ho postato è a oggetti.
ho usato int perchè funziona e non vedo la necessità di usare qualcosa di diverso


Non conosco python a questo livello, ma mi sentirei di dire che in molti casi gli oggetti sono nascosti. Il fatto che tu non li veda non vuol dire che non ci siano. cdimauro aveva fatto un esempio con le tuple mi pare... si può estendere il discorso.
E poi la programmazione procedurale ha una sua dignità, non è sempre una scelta peggiore rispetto ad un altro approccio.

Se usi gli int il tuo codice fa molte meno cose di quello che fa il pezzettino in python. Tu dopo poco ti fermi, lui continua.


anche dallo scrittore :asd:
se vuoi facciamo a votazione :fagiano:


No no, dipende sempre dal lettore. Se a mia nonna faccio leggere...
printf("Hello World!\n");
...lei non capisce niente.


c'era un tale che diceva: premature optimization is the root of all evil in programming

Non è una questione di premature optimization. E' sbagliato usare un algoritmo con un tempo esponenziale quando ce n'è uno con un tempo lineare ugualmente semplice da implementare. E prega che il tuo compilatore adotti un qualche tipo di tail-call optimization se usi la ricorsione in quel modo. E' un pessimo esempio per illustrare la ricorsione. Un pessimo esempio, anche se lo usano tutti, rimane un pessimo esempio.

[k0nt3]

Penso che questa implementazione si scrivere altrettanto bene in praticamente tutti i linguaggi, anche in C standard...
Come detto e' pero' tragica dal punto di vista algoritmico.

Es: C#.

public static int Fibo(int input)
{
switch (input)
{
case 0: return 0;
case 1: return 1;
default: return Fibo(input - 1) + Fibo(input - 2);
}
}
già.. è lì che ho capito che le versioni più leggibili sono ricorsive. le versioni iterative sono più veloci, ma se uno deve imparare a programmare sono anche inutili. l'obiettivo è tramutare le soluzioni in algoritmi, non in algoritmi ultraveloci
mi piacerebbe compilare il geroglifico di prima comunque.. qualcuno sa come si fa? :fagiano:

[das]

In questo caso, quando mi capita, uso Delphi per lo scheletro dell'applicazione / interfaccia grafica, e cerco di spostare su Python quanta più logica possibile.

Insomma, cerco di sfruttare il meglio dei due mondi (grazie anche a ottimi strumenti, come Python4Delphi, che permettono ai due mondi di comunicare agevolmente).


Grazie, mi hai appena fatto conoscere una cosa che mi interessa molto: Python4Delphi

[shinya]

già.. è lì che ho capito che le versioni più leggibili sono ricorsive. le versioni iterative sono più veloci, ma se uno deve imparare a programmare sono anche inutili. l'obiettivo è tramutare le soluzioni in algoritmi, non in algoritmi ultraveloci

No no no. Non è una questione di "più veloce". E' una questione di uso sbagliato della ricorsione. Fibonacci è solo un esempio. Se uno deve imparare a programmare, spero che non impari ad usare la ricorsione a quel modo. E' sbagliato, non so come dirtelo. La soluzione che hai riscritto in java qualche messaggio fa è peggiore di quella che avevi scritto prima. Di molto. Solitamente, usare la ricorsione per calcolare fibonacci si usa per illustrare una tecnica che si chiama dynamic programming, ed è quello il modo giusto di usare la ricorsione per questo tipo di problemi.

E ritornando a fibonacci.py vs fibonacci.java: la serie di fibonacci è infinita. La soluzione in python la genera "tutta". La tua soluzione solo fino a 2^32, e con la soluzione ricorsiva senza dynamic programming che hai riscritto, neanche fino a li.


mi piacerebbe compilare il geroglifico di prima comunque.. qualcuno sa come si fa? :fagiano:

Ti scarichi GHC, lo installi e vedi...

[k0nt3]

No no no. Non è una questione di "più veloce". E' una questione di uso sbagliato della ricorsione. Fibonacci è solo un esempio. Se uno deve imparare a programmare, spero che non impari ad usare la ricorsione a quel modo. E' sbagliato, non so come dirtelo. La soluzione che hai riscritto in java qualche messaggio fa è peggiore di quella che avevi scritto prima. Di molto. Solitamente, usare la ricorsione per calcolare fibonacci si usa per illustrare una tecnica che si chiama dynamic programming, ed è quello il modo giusto di usare la ricorsione per questo tipo di problemi.

non capisco :fagiano: quando ti insegnano la successione di fibonacci si usa la ricorsione. per quale motivo dovrebbe essere un uso sbagliato della ricorsione? io vedo solo un problema di performance

Ti scarichi GHC, lo installi e vedi...
si ok ma devi capire che di haskell non ci capisco una mazza.. per me è come perl (tanto per rendere l'idea :asd: )
ho scritto:

fibs = 0 : 1 : [ a + b | (a, b) <- zip fibs (tail fibs)]
fib n = fibs !! n

in un file che si chiama fib.hc e poi ho dato il comando
ghc -o fib fib.hc
e mi dice:

fibo.hc:1:0: warning: data definition has no type or storage class

fibo.hc:1:0:
warning: type defaults to ‘int’ in declaration of ‘fibs’

fibo.hc:1:0:
error: expected ‘,’ or ‘;’ before ‘:’ token

[shinya]

OT: lancia ghci e poi scrivi al prompt


let fibs = 0 : 1 : [ a + b | (a, b) <- zip fibs (tail fibs)]


e poi la provi scrivendo, sempre al prompt, qualcosa tipo fibs !! 42.

[k0nt3]

denghiù :)

[cdimauro]

Si' esatto.
Prova a scrivere una funzione Generics che, lavorando su "NUMERI SOMMABILI", dato in ingresso un'istanza della classe/struttura scelta, ne restituisca il valore successivo.

qualcosa tipo


public static T NextValue<T>(T input) where T : ISommable
{
return input + 1;
}


(Come loro solito la sintassi di costruzione di un nuovo Generics fa abbastanza pena e non e' elegantissima.
Nell'uso almeno tutta la complessita' e' nascosta, e 99% delle volte i Generics si usano, non si scrivono)

Peccato che ISommable (o simili) non esista.
Non esiste neppure la dichiarazione generica INumber (o simili), in modo da dire: E' un numero come quelli che conosciamo. Nel corpo della funzione potrai usare gli operatori +-*/ etc.

Non mi capacito della mancanza. Un tempo pensavo che fosse per colpa della scelta di ottimizzazione in velocita' che si vuole dare al linguaggio. Intendo, quando si scrive a+b, dove a e b possono essere interi, double, etc. il C# non invoca veramente una funzione, ma compila direttamente l'istruzione macchina relativa al + (che puo' essere la assembly ADD per gli interi).
Questo non trovo difficile pensare che possa complicare la compilazione di un generics, se si volesse includere gli operatori nel ragionamento.
Ma poi mi sono detto, esiste l'interfaccia IComparable, che serve per confontare 2 istanze della classe, usata largamente e p.es. internamente nel codice degli ordinatori (Sort, OrderBy, OrderByDescending).
E quindi mi sono detto: O la scusa che stavo dando prima e' una bufala, oppure quando implemento IComparable per gli interi il compilatore non fa uso del'opcode Assembly CMP.
Spero per la prima, ovvero che sia una bufala prima o poi risolvibile.

Utilizzo ipotetico del tutto: Una funzione generica che si possa applicare a int, double, float, decimal e quante altre classi possano essere dichiarate sommabili, che restituisca la successione di Fibonacci.
Condivido: è incomprensibile e spero che risolveranno presto.
Lo puoi scrivere pure cosi se ti sembra più chiaro:

fibs = 0 : 1 : [ a + b | (a, b) <- zip fibs (tail fibs)]

Anche così non mi è molto chiaro... :|
ah non c'è bisogno del coraggio, non ho scritto il codice perchè tendo a evitare i discorsi tipo: il mio è più lungo del tuo gnegne :D
il tuo codice è una "merda" perchè è sovraingegnerizzato, non perchè è scritto in java.
una soluzione più consona è:

public class Fibonacci {
private int next = 1, current = 0;

public static void main(String[] args) {
Fibonacci fibonacci = new Fibonacci();
int i = 0;
while(i < 10) {
System.out.println(fibonacci.next());
++i;
}
}

private int next() {
int result = current;
current = next;
next = result + next;
return result;
}
}

la differenza sostanziale tra questa implementazione e quella che è stata postata prima in python è che questa è programmazione a oggetti, mentre quella in python è puramente procedurale.
Questa soluzione che hai proposto NON risolve lo STESSO problema, che prevedeva la generazione di un numero virtualmente illimitato di valori.

Quella precedente non era una sovraingegnerizzazione: assolveva pienamente allo scopo.

Quanto a Python, continui a non capire che è un linguaggio completamente orientato agli oggetti. Ecco qui:
>>> def fib():
... a, b = 0, 1
... while True:
... a, b = b, a + b
... yield a
...
>>> f = fib()
>>> f
<generator object at 0x02422D50>
>>> dir(f)
['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__iter__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'close', 'gi_frame', 'gi_running', 'next', 'send', 'throw']
>>> f.next()
1
>>> f.next()
1
>>> f.next()
2
>>> f.next()
3
>>> f.next()
5
>>> f.next()
8
>>> f.next()
13
>>> f.next()
21
>>> for n in f: print n
...
34
55
89
144
233
377
610
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyboardInterrupt
Come vedi fib() crea un generatore, che... è un oggetto, i cui membri puoi vedere utilizzando la funzione built-in dir.

Fra questi, next() è il METODO (lo sottolineo, perché ti potrebbe sfuggire l'importanza di questa parola) che permette di richiamare il generatore per recuperare via via i risultati della sua computazione.

Come puoi vedere, posso recuperare tutti i valori che voglio, e l'OGGETTO f mantiene memoria del suo stato, tanto che utilizzando il costrutto for non si ricomincia dall'inizio, ma l'elenco generato prosegue dall'ultima INVOCAZIONE AL METODO next.

Se quella forma non ti soddisfa, puoi usare questa:
>>> class fib():
... def __init__(self):
... self.a, self.b = 0, 1
... def __iter__(self):
... return self
... def next(self):
... self.a, self.b = self.b, self.a + self.b
... return self.a
...
>>> f = fib()
>>> f
<__main__.fib instance at 0x024225A8>
>>> dir(f)
['__doc__', '__init__', '__iter__', '__module__', 'a', 'b', 'next']
>>> f.next()
1
>>> f.next()
1
>>> f.next()
2
>>> f.next()
3
>>> f.next()
5
>>> f.next()
8
>>> f.next()
13
>>> f.next()
21
>>> for n in f: print n
...
34
55
89
144
233
377
610
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyboardInterrupt
>>>
Ma, come vedi, abbiamo sempre a che fare con OGGETTI che espongo dei ben precisi METODI che vengono poi invocati a seconda delle necessità.

E' l'n-esima volta che hai bisogno di dimostrare a tutti che sconosci del tutto Python.
Purtroppo continui a vederlo come i linguaggi di programmazione che hai studiato o con cui sei abituato a lavorare, e commetti il grosso errore di fare assunzioni sul suo conto.
D'altra parte l'errore ancora più grosso è quello di non utilizzarlo per comprenderne appieno le potenzialità e in che modo funziona.
ah non sforzatevi a trovare l'implementazione migliore.. purtroppo esiste già ed è scritta in scala:

def fib( n: Int): Int = n match {
case 0 => 0
case 1 => 1
case _ => fib( n -1) + fib( n-2)
}

questo codice ha una corrispondenza 1:1 con la definizione di serie di fibonacci

EDIT:
ok mi è venuto in mente che è stupido cercare una soluzione iterativa a una successione che per definizione è ricorsiva. in java la soluzione ricorsiva sarebbe così:

public class Fibonacci {
public static void main(String[] args) {
Fibonacci fibonacci = new Fibonacci();
int i = 0;
while(i < 10) {
System.out.println(fibonacci.element(i));
++i;
}
}

private int element(int index) {
switch (index) {
case 0:
return 0;
case 1:
return 1;
default:
return element(index-1) + element(index-2);
}
}
}

In Python:
>>> def fib(n):
... return 1 if n <= 1 else fib(n - 2) + fib(n - 1)
...
>>> for i in range(10): print fib(i)
...
1
1
2
3
5
8
13
21
34
55
Umh...non so. Sicuramente il mio codice era sovraingegnerizzato per quello che si deve fare (calcolare la serie di fibonacci), ma quello che hai scritto non è, secondo me, la traduzione "letterale" del codice in python che è stato postato.

Il punto era generare uno stream di fibonacci sul quale iterare, e riusabile. Nell'esempio in python prendi la funzione che genera lo stream e la usi in un costrutto 'for'. Per fare questo in java devi creare un'iterable, c'è poco da fare.
Esattamente.
Altra cosa, di dettaglio. Tu usi gli int, ma sei disonesto. Python, da quel che ne so io (non lo conosco benissimo), degrada i tipi numerici a seconda delle necessità. Quindi una traduzione al 100% avrebbe dovuto tener conto di questo. Usare gli int, poi quando non ci stai più i long, poi numeri a precisione arbitraria...per semplicità sono partito dai BigInteger subito. Con gli int invece non fai molta strada.
Infatti in Python il risultato di un'operazione viene automaticamente passato da int a long se l'int non è sufficiente a poterlo rappresentare (in Python 3.0 non ci saranno più int e long: int sarà equivalente a quello che adesso è long, quindi ci sarà un solo tipo di interi: quelli "lunghi").

In Java devi ricorrere a BigInteger, c'è poco da fare.
La leggibilità dipende dal lettore.
Concordo.
Sicuramente bisogna farci un po' di mano in quanto i ragionamenti coinvolti sono molto diversi dal solito, dopo un po' di pratica diventa molto leggibile (per me perlomeno).
L'importante e' leggerlo in forma dichiarativa e non procedurate.
"la sequenza dei numeri di fibonacci e' la sequenza che comincia con 1, 1 e continua con le somme x+y, dove x e' un numero di fibonacci e y e' il successore di x".
La notazione e' un po' meno chiara dell'ideale perche' la posizione e' definita implicitamente e senza indici (per non dover scorrere tutta la lista ad ogni passaggio).
OK, adesso mi è chiaro. :)

Comunque il problema era mio, come avevo scritto: non conoscendo Haskell non riuscivo a capire cosa volesse significare quello che avevi scritto...

x das: di niente. :)

[dreadknight]

Il coraggio non c'è proprio per quello che hai detto: è una merda. :D

Però per consigliare Java, C/C++ per imparare a programmare non si fanno problemi... :muro:


in C verrebbe una cosa del genere:


#include <stdio.h>

int fibonacci(int i)
{
if (i < 0) return -1;
if (i == 0) return 0;
else if (i == 1) return 1;
else return fibonacci(i-1) + fibonacci(i-2);
}

int main(void)
{
int n;
printf("Inserire intero >= 0 : ");
scanf("%d", &n);
printf("L' %do numero di Fibonacci e' %d.\n", n, fibonacci(n));
return 0;
}


ammazza, è proprio un codice lunghissimo e complicatissimo :O

[^TiGeRShArK^]

beh..
son pur sempre 18 righe di codice contro le 3 di python, e inoltre con python funziona anche con interi + lunghi di 32 bit.... :stordita:

[shinya]

in C verrebbe una cosa del genere:


... cut...


ammazza, è proprio un codice lunghissimo e complicatissimo :O

No, ci sono due cose che non vanno. Almeno.

1) il tuo algoritmo è esponenziale. Prova a dare '80' come input al tuo programma. Intanto vado in ferie. Quando torno mi dici qual'è l'ottantesimo numero nella sequenza di fibonacci.

2) il punto del problema non era "scrivere un programma che calcola la serie di fibonacci fino a N". Il punto era più o meno "scrivere un componente che generi l'intera serie di fibonacci. Che è infinita."

[Albi89]

beh..
son pur sempre 18 righe di codice contro le 3 di python, e inoltre con python funziona anche con interi + lunghi di 32 bit.... :stordita:
E poi
fib = lambda n : [0, 1][n < 3] or fib(n-1) + fib(n-2)
e l'hai fatta in ben 1 rigo :sofico:
(solito algoritmo ricorsivo e pesantissimo, ovviamente)

[DanieleC88]

Vabbe', ma vuoi mettere l'eleganza e l'efficacia del BrainFuck?


+++++++++++
>+>>>>++++++++++++++++++++++++++++++++++++++++++++
>++++++++++++++++++++++++++++++++<<<<<<[>[>>>>>>+>
+<<<<<<<-]>>>>>>>[<<<<<<<+>>>>>>>-]<[>++++++++++[-
<-[>>+>+<<<-]>>>[<<<+>>>-]+<[>[-]<[-]]>[<<[>>>+<<<
-]>>[-]]<<]>>>[>>+>+<<<-]>>>[<<<+>>>-]+<[>[-]<[-]]
>[<<+>>[-]]<<<<<<<]>>>>>[+++++++++++++++++++++++++
+++++++++++++++++++++++.[-]]++++++++++<[->-<]>++++
++++++++++++++++++++++++++++++++++++++++++++.[-]<<
<<<<<<<<<<[>>>+>+<<<<-]>>>>[<<<<+>>>>-]<-[>>.>.<<<
[-]]<<[>>+>+<<<-]>>>[<<<+>>>-]<<[<+>-]>[<+>-]<<<-]


:D

[Albi89]

Vabbe', ma vuoi mettere l'eleganza e l'efficacia del BrainFuck?
Non mi permetterei mai :eek:
Tra l'altro se non sbaglio l'autore di brainfuck ogni tanto sforna qualche altro linguaggio sullo stesso stile... tipo un linguaggio basato sui taxi e successive fermate :sofico:

[cdimauro]

E poi
fib = lambda n : [0, 1][n < 3] or fib(n-1) + fib(n-2)
e l'hai fatta in ben 1 rigo :sofico:
(solito algoritmo ricorsivo e pesantissimo, ovviamente)
GLOM. Così fa concorrenza a Perl. :stordita:

Per averla in una sola linea:
def fib(n): return 1 if n <= 1 else fib(n - 2) + fib(n - 1)
ed è molto più leggibile. :)

Per il resto quoto "Tiger" e shinya. ;)

[Albi89]

...
Ma sì, era un rigo di pura cattiveria :fagiano:

[k0nt3]

scrivere meno righe di codice secondo me significa soltanto una cosa: scrivere meno righe di codice :P
è sbagliato pensare che le soluzioni più corte sono sempre più leggibili (anche se molte volte lo sono tuttavia), c'è un limite inferiore sotto il quale l'informazione è così compressa che risulta difficile risalire al suo significato.
io preferisco scrivere due righe in più quando necessario, non trovo nessun interesse nel far stare tutto in una riga.
ad esempio l'assegnazione parallela di python (per riprendere un esempio visto in questo thread) è più difficile da capire rispetto all'uso di una variabile temporanea. questo perchè la semantica dell'assegnazione parallela è più complicata di quella dell'assegnazione normale (e qui sfido a dimostrare il contrario).
poi non c'è dubbio che chi li conosce li ritiene strumenti utilissimi e indispensabili.. ma dal punto di vista didattico mi sembrano solo inutili complicazioni (come il fatto di pensare se l'algoritmo è in O(n^n) piuttosto che in O(6).. ma chissenefrega :p )

[71104]

in C verrebbe una cosa del genere:


#include <stdio.h>

int fibonacci(int i)
{
if (i < 0) return -1;
if (i == 0) return 0;
else if (i == 1) return 1;
else return fibonacci(i-1) + fibonacci(i-2);
}

int main(void)
{
int n;
printf("Inserire intero >= 0 : ");
scanf("%d", &n);
printf("L' %do numero di Fibonacci e' %d.\n", n, fibonacci(n));
return 0;
}


ammazza, è proprio un codice lunghissimo e complicatissimo :O
è illeggibile: mi spieghi che cavolo è %d? e che minchiazza significa in inglese "scanf"? e "printf" sarebbe un comando di stampa subito dopo il quale è scappato uno starnuto? o hai premuto per errore la F subito dopo la T, visto che sulla tastiera stanno vicine?

non ti sprecare a rispondere, programmo in C e C++ da anni. e tra parentesi, per quanto sia criptico anche in C++ (mi spiegate una volta per tutte perché cin e cout si chiamano così? :muro: cin poi sembra un mezzo brindisi) si legge persino meglio della versione C :D

#include <iostream>

using namespace std;

int fibonacci(int i)
{
if (i < 0) return -1;
if (i == 0) return 0;
else if (i == 1) return 1;
else return fibonacci(i-1) + fibonacci(i-2);
}

int main()
{
cout << "Inserire intero >= 0 : ";
int n;
cin >> n;
cout << "L' " << n << "o numero di Fibonacci e' " << fibonacci(n) << ".\n";
return 0;
}

[71104]

beh..
son pur sempre 18 righe di codice contro le 3 di python, volevi dire due righe di C:

#include <stdio.h>
int fibonacci(int i){if (i < 0) return -1;if (i == 0) return 0;else if (i == 1) return 1;else return fibonacci(i-1) + fibonacci(i-2);}int main(void){int n;printf("Inserire intero >= 0 : ");scanf("%d", &n);printf("L' %do numero di Fibonacci e' %d.\n", n, fibonacci(n));return 0;}

:D :D :D


e inoltre con python funziona anche con interi + lunghi di 32 bit.... :stordita: anche in C volendo, anche se è necessario l'aiuto del compilatore* :stordita:

#include <stdio.h>

long long fibonacci(long long i)
{
if (i < 0) return -1;
if (i == 0) return 0;
else if (i == 1) return 1;
else return fibonacci(i-1) + fibonacci(i-2);
}

int main(void)
{
int n;
printf("Inserire intero >= 0 : ");
scanf("%d", &n);
printf("L' %do numero di Fibonacci e' %lld.\n", n, fibonacci(n));
return 0;
}

*credo che long long non sia standard


Vabbe', ma vuoi mettere l'eleganza e l'efficacia del BrainFuck?

:D finalmente un post intelligente :rotfl: :D :D

[71104]

Non mi permetterei mai :eek:
Tra l'altro se non sbaglio l'autore di brainfuck ogni tanto sforna qualche altro linguaggio sullo stesso stile... tipo un linguaggio basato sui taxi e successive fermate :sofico: non lo sfottete, quell'uomo è un genio :O

il BrainFuck è utilissimo per progettare sistemi antipirateria: immaginate un poveraccio di hacker che deve crackare dei dati criptati tramite uno script BrainFuck interpretato just-in-time :D
ce lo voglio :asd:

[shinya]

ma dal punto di vista didattico mi sembrano solo inutili complicazioni (come il fatto di pensare se l'algoritmo è in O(n^n) piuttosto che in O(6).. ma chissenefrega :p )

Si, se non fai girare i programmi che scrivi, sono inutili complicazioni.
Altrimenti, usare un algoritmo ugualmente semplice ma con un tempo lineare invece di uno con un tempo esponenziale, fa la differenza tra un programma che funziona, e uno che non funziona.
Perchè ripeto, nell'esempio che hai scritto sei stato disonesto.

Hai messo un bel "if (i < 10) ..." e poi hai detto:"Funziona!". Adesso metti "i < 80".
Funziona ancora? Funziona "abbastanza"? Secondo me l'approccio del "chissenefrega, tanto metto i < 10 e parte..." è fare le cose a braccio. E non c'è metodologia che riesca a raddrizzare questa mentalità. A me non piace il TDD, ma il motivo per il quale è richiesto scrivere dei test per tutto non è fine a se stesso. Il motivo è spingere il programmatore a pensare a fondo a quello che sta scrivendo.

[k0nt3]

Si, se non fai girare i programmi che scrivi, sono inutili complicazioni.
Altrimenti, usare deliberatamente un algoritmo ugualmente semplice ma con un tempo lineare invece di uno con un tempo esponenziale, fa la differenza tra un programma che funziona, e uno che non funziona.
Perchè ripeto, nell'esempio che hai scritto sei stato disonesto.

Hai messo un bel "if (i < 10) ..." e poi hai detto:"Funziona!". Adesso metti "i < 80".
Funziona ancora? Funziona "abbastanza"? Secondo me l'approccio del "chissenefrega, tanto metto i < 10 e parte..." è fare le cose a braccio. E non c'è metodologia che riesca a raddrizzare questa mentalità. A me non piace il TDD, ma il motivo per il quale è richiesto scrivere dei test per tutto non è fine a se stesso. Il motivo è spingere il programmatore a pensare a fondo a quello che sta scrivendo.
ma lo scopo è calcolare il numero più grande che appartiene alla serie di fibonacci o forse per caso è solamente implementare un algoritmo che la calcola? :confused:
per me la seconda, quindi il mio programma soddisfa pienamente i vincoli, già sapere i primi 25 numeri della serie è di utilità relativa.. ne bastano anche 10 per capire se l'algoritmo è corretto o no.
il motivo dell'esistenza dei test comunque non è quello di far pensare a quello che si scrive, ma quello di isolare il comportamento di un modulo per poterlo testare, altrimenti dovremmo aspettare che il programma sia completo per poterne testare anche una piccola parte.
questa cosa già si faceva in maniera più scomoda e macchinosa prima del TDD usando dei main fittizzi ecc.. ovviamente in maniera molto meno esasperata. il TDD ha portato all'automatizzazione di questo processo
tornando al nostro discorso... uno che impara a programmare non deve assolutamente pensare all'efficienza dei suoi algoritmi, ma soltanto alla correttezza. per l'efficienza c'è sempre tempo dopo e solo quando serve

[Albi89]

#include <stdio.h>

long long fibonacci(long long i)
{
if (i < 0) return -1;
if (i == 0) return 0;
else if (i == 1) return 1;
else return fibonacci(i-1) + fibonacci(i-2);
}

Cioè e poi sono io il napoletanaccio... e "long long" come me lo chiamate? :O
Comunque no, non dovrebbe essere standard, che compilatore lo supporta? (immagino il Visual C++ ma sono troppo pigro per controllare :fagiano: )

Edit: ok, dovevo pensare prima di parlare: mi correggo, lo supporta anche gcc, codificando su 64 bit :D

[cdimauro]

scrivere meno righe di codice secondo me significa soltanto una cosa: scrivere meno righe di codice :P
è sbagliato pensare che le soluzioni più corte sono sempre più leggibili (anche se molte volte lo sono tuttavia), c'è un limite inferiore sotto il quale l'informazione è così compressa che risulta difficile risalire al suo significato.
io preferisco scrivere due righe in più quando necessario, non trovo nessun interesse nel far stare tutto in una riga.
Non mi pare che qualcuno qui abbia detto qualcosa di diverso.

Fermo restando il calcolo del numero bug per linea di codice è una metrica abbastanza usata in informatica.
ad esempio l'assegnazione parallela di python (per riprendere un esempio visto in questo thread) è più difficile da capire rispetto all'uso di una variabile temporanea. questo perchè la semantica dell'assegnazione parallela è più complicata di quella dell'assegnazione normale (e qui sfido a dimostrare il contrario).
La dimostrazione te l'avevo già fornita:
Info = DB.Gets('SELECT Nome, Cognome, CodiceFiscale, Residenza, Cittadinanza FROM Utenti WHERE ID = %s', (12345, ))

Nome, Cognome, CodiceFiscale, Residenza, Cittadinanza = Info
Ovviamente Info è una tupla, che viene "spacchettata" grazie all'assegnamento multiplo.

La versione senza assegnamento multiplo sarebbe questa:
Info = DB.Gets('SELECT Nome, Cognome, CodiceFiscale, Residenza, Cittadinanza FROM Utenti WHERE ID = %s', (12345, ))

Nome = Info[0]
Cognome = Info[1]
CodiceFiscale = Info[2]
Residenza = Info[3]
Cittadinanza = Info[4]
poi non c'è dubbio che chi li conosce li ritiene strumenti utilissimi e indispensabili.. ma dal punto di vista didattico mi sembrano solo inutili complicazioni
Lascia decidere a chi deve imparare quale delle due soluzioni di cui sopra è più complicata.
(come il fatto di pensare se l'algoritmo è in O(n^n) piuttosto che in O(6).. ma chissenefrega :p )
Certo: è noto che un algoritmo superesponenziale e uno lineare sono la stessa cosa.
anche in C volendo, anche se è necessario l'aiuto del compilatore* :stordita:

#include <stdio.h>

long long fibonacci(long long i)
{
if (i < 0) return -1;
if (i == 0) return 0;
else if (i == 1) return 1;
else return fibonacci(i-1) + fibonacci(i-2);
}

int main(void)
{
int n;
printf("Inserire intero >= 0 : ");
scanf("%d", &n);
printf("L' %do numero di Fibonacci e' %lld.\n", n, fibonacci(n));
return 0;
}

*credo che long long non sia standard
Anche se lo fosse (e mi pare che col C99 lo è), non sta scritto da nessuna parte che long long = intero a 64 bit. Come non sta scritto da nessuna parte che int o long debbano essere a 32 bit. ;)

In ogni caso, superati i 64 bit il problema col C si riproporrebbe. Con Python no. :cool:
ma lo scopo è calcolare il numero più grande che appartiene alla serie di fibonacci o forse per caso è solamente implementare un algoritmo che la calcola? :confused:
per me la seconda, quindi il mio programma soddisfa pienamente i vincoli, già sapere i primi 25 numeri della serie è di utilità relativa.. ne bastano anche 10 per capire se l'algoritmo è corretto o no.
Non è né la prima né la seconda. Il problema era di generare la sequenza di Fibonacci, quindi avere uno stream di dati virtualmente illimitato. Cosa che la tua applicazione NON fa. Quella in Java, invece, risolveva perfettamente il problema.

Io avevo chiesto di tirare fuori l'EQUIVALENTE di un'applicazione di cui avevo fornito il codice in Python.

Tu, come programmatore, non puoi fare di testa tua e assumere cose diverse: sei tenuto COME MINIMO a rispettare i REQUISITI del problema.

Sull'implementazione io non avrò nulla da dire, purché però i requisiti siano rispettati alla lettera. Quindi anche la tua soluzione ricorsiva sarebbe andata bene, seppur estremamente inefficiente, posto che avesse risolto il problema.
tornando al nostro discorso... uno che impara a programmare non deve assolutamente pensare all'efficienza dei suoi algoritmi, ma soltanto alla correttezza. per l'efficienza c'è sempre tempo dopo e solo quando serve
Va benissimo, non c'è problema, ma la condizione NECESSARIA è che almeno i requisiti debbano essere rispettati.

[k0nt3]

quindi? :mbe: voglio vedere come dimostri che la versione ricorsiva non è corretta.. è la trascrizione 1:1 della definizione di successione di fibonacci praticamente :mbe:

ps. probabilmente ti è sfuggito il fatto che nessun software può calcolare tutta la successione.. è infinita, mentre la memoria di un PC è finita, quindi tutti gli algoritmi sarebbero sbagliati secondo la tua curiosa interpretazione. ma se la memoria fosse infinita sia la soluzione ricorsiva che quella non ricorsiva riuscirebbero a calcolare tutta la serie

[Albi89]

quindi? :mbe: voglio vedere come dimostri che la versione ricorsiva non è corretta.. è la trascrizione 1:1 della definizione di successione di fibonacci praticamente :mbe:

ps. probabilmente ti è sfuggito il fatto che nessun software può calcolare tutta la successione.. è infinita, mentre la memoria di un PC è finita, quindi tutti gli algoritmi sarebbero sbagliati secondo la tua curiosa interpretazione. ma se la memoria fosse infinita sia la soluzione ricorsiva che quella non ricorsiva riuscirebbero a calcolare tutta la serie

Secondo me ti stai un po' "scostando" dal discorso... la questione non era "quale implementazione di fib è più bellina" (e le ultime pagine erano finite così) ma "è meglio iniziare con linguaggi a oggetti? python è un linguaggio a oggetti?".
Il frammento di codice di cdimauro era, perlappunto, un'oggetto su cui poter iterare col for "foreachoso" di python e che mantenesse nota dell'ultimo valore stampato; nella mia vita non credo che mi troverò mai a iterare su fib, ma è un esempio che si può adattare a qualunque sequenza virtualmente infinita di numeri.
Le altre (a parte quella di shinya) non solo sono semplici funzioni, ma non assolvono allo scopo iniziale.

(come il fatto di pensare se l'algoritmo è in O(n^n) piuttosto che in O(6).. ma chissenefrega )
Penso che sia uno scherzo... penso che se ci fosse la possibilità di rendere tutti gli algoritmi "O(6)" cioè COSTANTI, neanche lineari, i nostri pc sarebbero scheggiozze :sofico:

[cdimauro]

quindi? :mbe: voglio vedere come dimostri che la versione ricorsiva non è corretta.. è la trascrizione 1:1 della definizione di successione di fibonacci praticamente :mbe:
Qui o non hai capito il problema o stai cercando di cambiare discorso.

La versione che hai fornito NON è corretta perché NON è in grado di generare una sequenza virtualmente illimitata di numeri della successione di Fibonacci.
ps. probabilmente ti è sfuggito il fatto che nessun software può calcolare tutta la successione.. è infinita, mentre la memoria di un PC è finita, quindi tutti gli algoritmi sarebbero sbagliati secondo la tua curiosa interpretazione. ma se la memoria fosse infinita sia la soluzione ricorsiva che quella non ricorsiva riuscirebbero a calcolare tutta la serie
Nessuno ha mai detto questo. Infatti ho scritto "VIRTUALMENTE illimitata" proprio per questo motivo.

Il concetto è che tu, intanto, mi devi garantire di generare numeri fino a quando io lo riterrò opportuno. Questo significa che potenzialmente potrei anche arrivare a occupare tutta la memoria del PC e mandarlo in crash, ma non me ne frega niente: intanto genera i numeri e non ti fermare.

Esempio pratico:

for n in fib(): print n

Questa continua a generare numeri fino a quando non decido di premere Ctrl-C o di chiudere l'applicazione. Non c'è nessun limite fissato A PRIORI.

[k0nt3]

Esempio pratico:

for n in fib(): print n

Questa continua a generare numeri fino a quando non decido di premere Ctrl-C o di chiudere l'applicazione. Non c'è nessun limite fissato A PRIORI.
dubito fortemente che questo programma possa generare tutta la serie di fibonacci. anche in questo caso finisce la memoria prima o poi (se non altro perchè il numero n è monotono crescente, quindi i bit occupati crescono in continuazione).
quindi a livello concettuale non c'è nessuna differenza: entrambi gli algoritmi generano tutta la successione solo se la memoria disponibile è illimitata.
l'unica differenza è che quello ricorsivo si ferma prima mentre quello iterativo dopo

[cdimauro]

:mc:

[Albi89]

dubito fortemente che questo programma possa generare tutta la serie di fibonacci. anche in questo caso finisce la memoria prima o poi (se non altro perchè il numero n è monotono crescente, quindi i bit occupati crescono in continuazione).
quindi a livello concettuale non c'è nessuna differenza: entrambi gli algoritmi generano tutta la successione solo se la memoria disponibile è illimitata.
l'unica differenza è che quello ricorsivo si ferma prima mentre quello iterativo dopo

No concettualmente c'è una differenza molto più forte.
Il for del python è in pratica un for each, itera sugli elementi che sono contenuti nell'oggetto fib.
Dunque fib concettualmente "contiene" tutti gli elementi della successione di fibonacci, così come lo potrebbe fare un array infinito che contenga tutta la successione.
Quando usi la tua funzione fib invece gli dai un limite superiore e lui calcola fin lì, si ferma e ti restituisce il valore.

Edit: in ogni caso propongo di cambiare argomento... so dai tanti altri tuoi post che sei competente ed esperto, quindi non credo proprio che tu davvero non colga la differenza... penso semplicemente che vuoi farci uscire pazzi ripetendo le stesse cose fib(50) volte ;)

[k0nt3]

No concettualmente c'è una differenza molto più forte.
Il for del python è in pratica un for each, itera sugli elementi che sono contenuti nell'oggetto fib.
Dunque fib concettualmente "contiene" tutti gli elementi della successione di fibonacci, così come lo potrebbe fare un array infinito che contenga tutta la successione.
concettualmente anche la soluzione ricorsiva genera tutta la successione, ma in pratica non è possibile per nessun algoritmo

[k0nt3]

Secondo me ti stai un po' "scostando" dal discorso... la questione non era "quale implementazione di fib è più bellina" (e le ultime pagine erano finite così) ma "è meglio iniziare con linguaggi a oggetti? python è un linguaggio a oggetti?".

no sto cercando di dire che chi inizia a programmare se ne deve fregare dell'efficienza degli algoritmi, è molto più importante creare algoritmi corretti. per l'efficienza c'è tutta una letteratura che uno si può studiare in un momento successivo senza problemi.
ma veniamo al dunque:

è meglio iniziare con un linguaggio a oggetti?
dipende

python è un linguaggio a oggetti?
certamente, ma è anche procedurale e funzionale

[cdimauro]

E' inutile: con te è una causa persa in partenza.

Ti ho fatto vedere come funziona Python, e torni nuovamente sul solito discorso dei paradigmi.

Ti ho fatto vedere quali erano i REQUISITI della generazione dei numeri di Fibonacci e, da "buon" informatico, li hai puntualmente disattesi cercando di spostare la discussione verso altri lidi.

Vuoi sempre cadere in piedi anche sei hai torto marcio. Per fortuna scripta manent, come dicevano gli antichi latini: gli altri utenti possono verificare come sono andate le cose.

[k0nt3]

i "requisiti" sarebbero generare "tutta" la successione di fibonacci? no perchè se è così non mi sforzo nemmeno di pensare un algoritmo visto che sarebbe una fatica inutile

[cdimauro]

I requisiti li trovi nell'ultima parte di questo messaggio: http://www.hwupgrade.it/forum/showpost.php?p=23217076&postcount=92

[k0nt3]

penso che sia abbastanza inutile (anche difficile e sostanzialmente OT) cercare di fare un programma "perfettamente" equivalente a quello in java, ogni linguaggio ha le sue caratteristiche

[cdimauro]

Le tue opinioni non contano: i requisiti sono quelli, e li devi rispettare.

L'implementazione ovviamente è libera.

La soluzione di shinya risponde PERFETTAMENTE ai requisiti. La tua NO, e non venirmi a dire che in C non si potrebbe fare.

[k0nt3]

ah beh allora facciamo che anche le tue opinioni non contano e la discussione finisce qui :fagiano:
se vuoi puoi aprire un forum dove ci sei solo te :asd:

[cdimauro]

:mc:

[variabilepippo]

ah beh allora facciamo che anche le tue opinioni non contano e la discussione finisce qui


:mc:

[k0nt3]

@cdimauro
non mi dire che hai fatto tutto questo casino perchè ho usato int al posto di BigInteger... ho messo int solo perchè:
1) è più facile da trattare in questo caso (tendo sempre a fare le cose più facili se non è necessario il contrario)
2) non dovendo implementare una navicella spaziale mi sembrava che 2147483647 fosse un numero sufficientemente alto

[cdimauro]

Nessun casino: chiedo soltanto che siano rispettati i requisiti del problema, come dovrebbe fare qualunque programmatore che si possa fregiare di questo titolo.

I problemi sono due, ma correlati:
- generare una sequenza di numeri senza conoscerne a priori la fine;
- poiché non si conosce la loro fine, non si conosce a priori nemmeno la loro dimensione.

Il codice Python che avevo mostrato serviva a mostrare ciò che volevo, e l'avevo scritto chiaramente di fare la STESSA cosa, ma in Java. Tu l'hai voluto fare in C, ma NON hai rispettato i requisiti, appunto.

[Albi89]

@cdimauro
non mi dire che hai fatto tutto questo casino perchè ho usato int al posto di BigInteger... ho messo int solo perchè:
1) è più facile da trattare in questo caso (tendo sempre a fare le cose più facili se non è necessario il contrario)
2) non dovendo implementare una navicella spaziale mi sembrava che 2147483647 fosse un numero sufficientemente alto

Stavo scrivendo una risposta ma poi mi sono accorto che sarebbe stata identica all'ultimo post che ho scritto.
E quando succede questo, capisco che è il momento giusto per abbandonare una conversazione :fagiano:

[k0nt3]

uhm.. qua mi sa che siete voi che avete perso il filo
è così importante per uno che inizia a programmare generare i primi cento milioni di miliardi numeri della serie di fibonacci? la risposta è NO
è importante riuscire a creare un algoritmo che genera correttamente la serie di fibonacci? la risposta è SI ed è esattamente ciò che faceva il mio algoritmo

ps. io l'avevo fatto in java comunque

[gugoXX]

Vabbe'. Mi piazzo qui a scrivere 2 versioni in C#.
La prima funzionale, molto simile alla versione Python, ma con la pecca di attendere ere geologiche per valori altri di n.
Niente di diverso dall'algoritmo ricorsivo classico che si puo' scrivere anche in C, ma che non risolve il testo del problema.

La seconda, Iterativa, per rispondere al problema come meglio puo' il C# oggi senza scomodare classi con "numeri Grossi", per le quali esistono innumerevoli implementazioni (ma appunto non nativi, perche' effettivamente poco usati al di fuori di ambiti accademici o di calcoli particolari).
La seconda implementazione e' virtualmente infinita, ma termina con il raggiungere il limite superiore dei decimal ovvero 10^28 circa. Ma che raggiunge in pochi istantesimi di secondo, e che fa uso delle MMX (!) per gestire appunto i decimal (che sono virgola fissa a 128 bit)


public Func<decimal, decimal> FiboLambda = t => (t <= 2) ? 1 : FiboLambda(t - 2) + FiboLambda(t - 1);

public IEnumerable<decimal> FiboBuilder()
{
decimal menouno = 1;
decimal current = 1;
while(true)
{
decimal tmp = menouno;
menouno = current;
current += tmp;
yield return current;
}
}

[DanieleC88]

Chiedo perdono per l'ignoranza... Che significato ha yeld?

[gugoXX]

Chiedo perdono per l'ignoranza... Che significato ha yeld?

yield in inglese significa consegnare, rilasciare.

In C# e' una keyword che serve espressamente nella costruzione di enumeratori e pipeline.
In pratica ogni volta che hai un valore pronto per il chiamante lo restituisci immediatamente e poi continui a calcolare i successivi.

In pratica il chiamante puo' scrivere qualcosa tipo:


foreach(decimal d in FiboBuilder())
{
Console.WriteLine(d);
}


Oppure, in versione funzionale

FiboBuilder().ForEach(Console.WriteLine);

[DanieleC88]

Grazie! :)

[cdimauro]

uhm.. qua mi sa che siete voi che avete perso il filo
è così importante per uno che inizia a programmare generare i primi cento milioni di miliardi numeri della serie di fibonacci? la risposta è NO
Questo è UN ALTRO DISCORSO.
è importante riuscire a creare un algoritmo che genera correttamente la serie di fibonacci? la risposta è SI ed è esattamente ciò che faceva il mio algoritmo
Il problema esposto NON era semplicemente di generare un numero LIMITATO di numeri di Fibonacci, quindi il tuo algoritmo NON lo faceva.
ps. io l'avevo fatto in java comunque
La versione corretta NON era la tua. Qualcuno, che sa cosa significa rispettare i REQUISITI di un problema, l'ha implementato correttamente.
Vabbe'. Mi piazzo qui a scrivere 2 versioni in C#.
La prima funzionale, molto simile alla versione Python, ma con la pecca di attendere ere geologiche per valori altri di n.
Niente di diverso dall'algoritmo ricorsivo classico che si puo' scrivere anche in C, ma che non risolve il testo del problema.
Un buon informatico lo riconosce. :)
La seconda, Iterativa, per rispondere al problema come meglio puo' il C# oggi senza scomodare classi con "numeri Grossi", per le quali esistono innumerevoli implementazioni (ma appunto non nativi, perche' effettivamente poco usati al di fuori di ambiti accademici o di calcoli particolari).
La seconda implementazione e' virtualmente infinita, ma termina con il raggiungere il limite superiore dei decimal ovvero 10^28 circa. Ma che raggiunge in pochi istantesimi di secondo, e che fa uso delle MMX (!) per gestire appunto i decimal (che sono virgola fissa a 128 bit)


public Func<decimal, decimal> FiboLambda = t => (t <= 2) ? 1 : FiboLambda(t - 2) + FiboLambda(t - 1);

public IEnumerable<decimal> FiboBuilder()
{
decimal menouno = 1;
decimal current = 1;
while(true)
{
decimal tmp = menouno;
menouno = current;
current += tmp;
yield return current;
}
}

Sei sicuro che usi le MMX? Perché i registri mmx sono a 64 bit, non a 128, e non supportano nemmeno le operazioni di somma o sottrazione di interi (quindi nemmeno fixed point) a 64 bit.

Le SSE supportano interi (sempre non fixed point) a 128 bit, ma soltanto per le somme e le sottrazione.

Il tipo decimal di cui parli, considerato anche il range che hai esposto, si dovrebbe mappare sul tipo BCD della FPU x87.

[gugoXX]

Ho dato una scorsa veloce al disassembly, e mi sembra che li usi.

decimal tmp = menouno;
000000ab lea edi,[ebx+3Ch]
000000ae cmp ecx,dword ptr [edi]
000000b0 lea esi,[ebx+1Ch]
000000b3 cmp ecx,dword ptr [esi]
000000b5 movq xmm0,mmword ptr [esi]
000000b9 movq mmword ptr [edi],xmm0
000000bd movq xmm0,mmword ptr [esi+8]
000000c2 movq mmword ptr [edi+8],xmm0


da cosa vedo muove 2 volte un registro a 64bit (8 byte, mmword)
Forse fa poi lo stesso giochino che si faceva con EAX e EDX, che si faceva per ottenere una somma su 64bit avendo 2 registri a 32bit, nell'analogo risultato 128bit partendo da 2 registri da 64bit.

Ma non ti so dire come implementi effettivamente la somma, in quanto il codice dell'operatore di somma non mi e' visibile.

[^TiGeRShArK^]

ma xmm0 non era un registro delle SSE? :mbe:
o ricordo male io? :stordita:

[k0nt3]

@cdimauro
sono dettagli implementativi, non ha nessuna importanza in questo contesto calcolare numeri immensi

[cdimauro]

Ho dato una scorsa veloce al disassembly, e mi sembra che li usi.

da cosa vedo muove 2 volte un registro a 64bit (8 byte, mmword)
Forse fa poi lo stesso giochino che si faceva con EAX e EDX, che si faceva per ottenere una somma su 64bit avendo 2 registri a 32bit, nell'analogo risultato 128bit partendo da 2 registri da 64bit.

Ma non ti so dire come implementi effettivamente la somma, in quanto il codice dell'operatore di somma non mi e' visibile.
ma xmm0 non era un registro delle SSE? :mbe:
o ricordo male io? :stordita:
Sì, è SSE.

La cosa strana è che utilizza soltanto i 64 bit bassi per lavorare con questi interi, quando potrebbe benissimo utilizzare 128 bit per aumentare notevolmente il range di numeri trattabili.
@cdimauro
sono dettagli implementativi, non ha nessuna importanza in questo contesto calcolare numeri immensi
Sono REQUISITI del problema precedentemente esposto, e come vedi tanta gente che sa il fatto suo li rispetta.

Tu sei un caso a parte, al solito.

[rеpne scasb]

La cosa strana è che utilizza soltanto i 64 bit bassi per lavorare con questi interi, quando potrebbe benissimo utilizzare 128 bit per aumentare notevolmente il range di numeri trattabili.

'movq' non puo' utilizzare 128-bit, anche in SSE e con riferimento ad un registro xmmx. solo la quadword bassa viene trasferita, la quadword alta, o rimane invariata (xmmx->mem), oppure viene settata a '0' (mem->xmmx). Avrebbe invece potuto utilizzare al posto di:


000000b5 movq xmm0,mmword ptr [esi]
000000b9 movq mmword ptr [edi],xmm0
000000bd movq xmm0,mmword ptr [esi+8]
000000c2 movq mmword ptr [edi+8],xmm0


il codice SS2:


000000b5 movdqa xmm0,[esi]
000000ba movdqa [edi],xmm0


con esi e edi allineati a 10h.

[^TiGeRShArK^]

:ave:

:D

[rеpne scasb]

:ave:

:D

Esagerato!:D :Prrr:

[^TiGeRShArK^]

:nonsifa:

:Prrr:

[cdimauro]

'movq' non puo' utilizzare 128-bit, anche in SSE e con riferimento ad un registro xmmx. solo la quadword bassa viene trasferita, la quadword alta, o rimane invariata (xmmx->mem), oppure viene settata a '0' (mem->xmmx). Avrebbe invece potuto utilizzare al posto di:


000000b5 movq xmm0,mmword ptr [esi]
000000b9 movq mmword ptr [edi],xmm0
000000bd movq xmm0,mmword ptr [esi+8]
000000c2 movq mmword ptr [edi+8],xmm0


il codice SS2:


000000b5 movdqa xmm0,[esi]
000000ba movdqa [edi],xmm0


con esi e edi allineati a 10h.
Ma infatti mi lamentavo proprio di questo: vengono utilizzate le SSE, e quindi i registri sono a 128 bit, e poi ne usano soltanto la metà. :p

[DanieleC88]

:ave:

:D
Quotissimo. :ave:

[rеpne scasb]

Ma infatti mi lamentavo proprio di questo: vengono utilizzate le SSE, e quindi i registri sono a 128 bit, e poi ne usano soltanto la metà. :p

Se il compitatore/interprete che ha generato il codice di trasferimento:

000000b5 movq xmm0,mmword ptr [esi]
000000b9 movq mmword ptr [edi],xmm0
000000bd movq xmm0,mmword ptr [esi+8]
000000c2 movq mmword ptr [edi+8],xmm0

e' impostato per utilizzare solo le istruzioni SSE e non SSE2, quello e' il codice che deve generare, in quanto nel set di istruzioni SSE, nonostante i registri a 128-bit, manca un'istruzione di trasferimento a 128-bit. Certo poi ci sono sempre le scappatoie:

000000b5 movaps xmm0,[esi]
000000b9 movaps [edi],xmm0

con esi e edi allineati a 10h. Non e' certo una 'bella cosa', ed un compilatore/interprete non "dovrebbe" generare un simile codice assembly.

[RobyG_08]

W C#!!!!

(sono off topic? :D )

[cdimauro]

Se il compitatore/interprete che ha generato il codice di trasferimento:

000000b5 movq xmm0,mmword ptr [esi]
000000b9 movq mmword ptr [edi],xmm0
000000bd movq xmm0,mmword ptr [esi+8]
000000c2 movq mmword ptr [edi+8],xmm0

e' impostato per utilizzare solo le istruzioni SSE e non SSE2, quello e' il codice che deve generare, in quanto nel set di istruzioni SSE, nonostante i registri a 128-bit, manca un'istruzione di trasferimento a 128-bit. Certo poi ci sono sempre le scappatoie:

000000b5 movaps xmm0,[esi]
000000b9 movaps [edi],xmm0

con esi e edi allineati a 10h. Non e' certo una 'bella cosa', ed un compilatore/interprete non "dovrebbe" generare un simile codice assembly.
Forse non mi sono spiegato bene.

Il problema non sta nel trasferimento di quantità a 64 bit anziché a 128 bit, quanto nell'utilizzo di tutti e 128 bit dei registri, visto che sta utilizzando le SSE (e non le MMX) e la loro capienza è quella.

In soldoni: utilizzando tutti e 128 i bit dei registri per i calcoli avrebbe permesso di rappresentare numeri più grandi.

A questo punto tanto valeva sfruttare le MMX, o la FPU x87, se si dovevano utilizzare soltanto interi a 64 bit.

[71104]

ah beh allora facciamo che anche le tue opinioni non contano e la discussione finisce qui :fagiano:
se vuoi puoi aprire un forum dove ci sei solo te :asd:
oppure un forum dove la gente dice cose vere; non è la prima volta che ti si riprende per eccesso di IMHO :asd:

[rеpne scasb]

Il problema non sta nel trasferimento di quantità a 64 bit anziché a 128 bit, quanto nell'utilizzo di tutti e 128 bit dei registri, visto che sta utilizzando le SSE (e non le MMX) e la loro capienza è quella.

I registri sono a 128-bit/SSE ci sono, sono le istruzioni che agiscano su un dato a 128-bit che mancano. Non ci sono. Come la fai una ADD a 128-bit con SSE?

In soldoni: utilizzando tutti e 128 i bit dei registri per i calcoli avrebbe permesso di rappresentare numeri più grandi.

No. Per le istruzioni SSE un registro xmmx viene visto come un registro composto da 4 float a 32-bit impacchettati a formarne 128. Non c'e' un tipo di dato a 128-bit. Per le double-quadword (128-bit) come tipo di dato e necessario almeno il set di istruzioni SSE2.

A questo punto tanto valeva sfruttare le MMX, o la FPU x87, se si dovevano utilizzare soltanto interi a 64 bit.

Anche questo no. Se si hanno a disposizione le istruzioni SSE, l'uso dei registri MMX, e da avitare nel modo piu' assoluto specialmente in combinazione con FP87, in quanto tali registri nonostante siano definiti come registri separati, sono in realta' un alias dei registri FP, un sofware che utilizzi MMX+FP87 e' di complessa realizzazione, in quanto il passaggio di stato tra MMX e FP87 e' lento e complesso.

[k0nt3]

oppure un forum dove la gente dice cose vere; non è la prima volta che ti si riprende per eccesso di IMHO :asd:
meglio un IMHO in più che far passare le proprie opinioni personali per verità assolute.
morale della favola: nessuno è ancora riuscito a dimostrare che imparare C è inutile e che python è il miglior linguaggio della terra.
io mi guardo bene da certe affermazioni assolutistiche.

[cdimauro]

I registri sono a 128-bit/SSE ci sono, sono le istruzioni che agiscano su un dato a 128-bit che mancano. Non ci sono. Come la fai una ADD a 128-bit con SSE?
Appunto: non la fai, e non la fai nemmeno a 64 bit, visto che manca anche questa.

Quindi la scelta delle SSE è a dir poco grottesca.
No. Per le istruzioni SSE un registro xmmx viene visto come un registro composto da 4 float a 32-bit impacchettati a formarne 128. Non c'e' un tipo di dato a 128-bit. Per le double-quadword (128-bit) come tipo di dato e necessario almeno il set di istruzioni SSE2.
Esattamente.
Anche questo no. Se si hanno a disposizione le istruzioni SSE, l'uso dei registri MMX, e da avitare nel modo piu' assoluto specialmente in combinazione con FP87, in quanto tali registri nonostante siano definiti come registri separati, sono in realta' un alias dei registri FP, un sofware che utilizzi MMX+FP87 e' di complessa realizzazione, in quanto il passaggio di stato tra MMX e FP87 e' lento e complesso.
Proprio per questo avevo scritto MMX o FPU x87. ;)

[variabilepippo]

nessuno è ancora riuscito a dimostrare che imparare C è inutile e che python è il miglior linguaggio della terra

Come nessuno ha dimostrato che il masochismo è una perversione... Ma tutti sanno che se a qualcuno piace darsi delle martellate sugli zebedei, quel qualcuno troppo bene non deve stare. :D

Python non sarà il migliore linguaggio del mondo, però tra farsi del male con il C (a meno che non sia l'unica strada percorribile, ma per fortuna questi casi sono molto rari) e divertirsi scrivendo codice in un linguaggio ad alto livello non c'è paragone.

[shinya]

Se il compitatore/interprete che ha generato il codice di trasferimento:

000000b5 movq xmm0,mmword ptr [esi]
000000b9 movq mmword ptr [edi],xmm0
000000bd movq xmm0,mmword ptr [esi+8]
000000c2 movq mmword ptr [edi+8],xmm0

e' impostato per utilizzare solo le istruzioni SSE e non SSE2, quello e' il codice che deve generare, in quanto nel set di istruzioni SSE, nonostante i registri a 128-bit, manca un'istruzione di trasferimento a 128-bit. Certo poi ci sono sempre le scappatoie:

000000b5 movaps xmm0,[esi]
000000b9 movaps [edi],xmm0

con esi e edi allineati a 10h. Non e' certo una 'bella cosa', ed un compilatore/interprete non "dovrebbe" generare un simile codice assembly.

Sono basito dalle conoscenze di repne scasb...complimenti! Ma sono solo io che comincia a trovare più comprensibile la serie di fibonacci in haskell?? :fagiano:

fibs = 1 : 1 : [ x + y | x <- fibs | y <- tail fibs ]

[cdimauro]

Come nessuno ha dimostrato che il masochismo è una perversione... Ma tutti sanno che se a qualcuno piace darsi delle martellate sugli zebedei, quel qualcuno troppo bene non deve stare. :D

Python non sarà il migliore linguaggio del mondo, però tra farsi del male con il C (a meno che non sia l'unica strada percorribile, ma per fortuna questi casi sono molto rari) e divertirsi scrivendo codice in un linguaggio ad alto livello non c'è paragone.
Quoto integralmente. :p
Sono basito dalle conoscenze di repne scasb...complimenti! Ma sono solo io che comincia a trovare più comprensibile la serie di fibonacci in haskell?? :fagiano:

fibs = 1 : 1 : [ x + y | x <- fibs | y <- tail fibs ]

Non sei il solo: da parecchio tempo preferisco di gran lunga i linguaggi di alto livello per sviluppare codice, e ho ritrovato il gusto di programmare. :cool:

[gugoXX]

Appunto: non la fai, e non la fai nemmeno a 64 bit, visto che manca anche questa.


Nono, la somma su 64bit c'e'.
PADDQ
Che somma 2 QWord da 64bit ad altre 2 QWord da 64bit.


B.5.39 PADDQ: Add Packed Quadword Integers
PADDQ mm1,mm2/m64 ; 0F D4 /r [PENT,MMX]

PADDQ adds the quadwords in the source and destination operands, and stores the result in the destination register.

When an individual result is too large to fit in its destination, it is wrapped around and the low bits are stored, with the carry bit discarded.

[cdimauro]

E' per le MMX, non per le SSE. E' stata introdotta per le SSE soltanto con le SSE2.

[gugoXX]

E' per le MMX, non per le SSE. E' stata introdotta per le SSE soltanto con le SSE2.

Ah, non avevo capito il "Dominio".
Comunque non riesco ad andare a vedere come e' stata fatta la somma. Potrebbe essere interessante leggerla.

Noto come costante di questo tipo di discussioni che il richiedente scappa dopo un paio di pagine, e noi per inerzia continuiamo con voli pindarici per altre 20...

[^TiGeRShArK^]

:asd:
aveva ragione chi scriveva: "fuggi, sciocco [cit. modificata]"
:asd:

[Albi89]

:asd:
aveva ragione chi scriveva: "fuggi, sciocco [cit. modificata]"
:asd:

Eh vabè ma diciamolo, ogni volta è uno spettacolo :D

[ndakota]

:asd:
aveva ragione chi scriveva: "fuggi, sciocco [cit. modificata]"
:asd:

ero io modestamente :O ora ditemi che il ragazzino non è scappato dopo tutto questo.. odierà la programmazione per il resto della sua vita..

[cdimauro]

Ah, non avevo capito il "Dominio".
Comunque non riesco ad andare a vedere come e' stata fatta la somma. Potrebbe essere interessante leggerla.
E' strano. Quella parte di codice sì e quella della somma non si vede. :|
Noto come costante di questo tipo di discussioni che il richiedente scappa dopo un paio di pagine, e noi per inerzia continuiamo con voli pindarici per altre 20...
Però produciamo un bel po' di materiale interessante. :cool:
ero io modestamente :O ora ditemi che il ragazzino non è scappato dopo tutto questo.. odierà la programmazione per il resto della sua vita..
Non gli do tutti i torti. :D

[gugoXX]

E' strano. Quella parte di codice sì e quella della somma non si vede. :|


Il problema e' che con il disassemblatore in dotazione non si vedono ottimizzazioni come le inline function, che vengono eventualmente ricompilate a runtime.
E la somma tra due decimal e' fatta mediante una chiamata a subroutine del framework (decimal.Sum), e non riesco ad entrarci.
Questo a differenza della somma di 64bit e di quella di 32bit, che invece sono piazzate direttamente.

In effetti disassemblare in assembly nativo del microprocessore i linguaggi che passano attraverso una virtual machine e' un po' una stortura.
Oggi in ufficio provo a compilare per 64bit e vedo cosa viene fuori.

Niente. Arrivo alla chiamata di una funzione statica esterna che si chiama FCallAdd, ma neppure google e' mio amico. Solo 1 pagina.

[71104]

Quoto integralmente. :p quoti anche che Python non sarà il miglior linguaggio del mondo?? :eek: :D

[cdimauro]

Il problema e' che con il disassemblatore in dotazione non si vedono ottimizzazioni come le inline function, che vengono eventualmente ricompilate a runtime.
E la somma tra due decimal e' fatta mediante una chiamata a subroutine del framework (decimal.Sum), e non riesco ad entrarci.
Questo a differenza della somma di 64bit e di quella di 32bit, che invece sono piazzate direttamente.

In effetti disassemblare in assembly nativo del microprocessore i linguaggi che passano attraverso una virtual machine e' un po' una stortura.
Oggi in ufficio provo a compilare per 64bit e vedo cosa viene fuori.

Niente. Arrivo alla chiamata di una funzione statica esterna che si chiama FCallAdd, ma neppure google e' mio amico. Solo 1 pagina.
Capito. Ma non erano disponibili i sorgenti di .NET per poterli ispezionare?

Comunque da quello che scrivi è evidente che Decimal non è un tipo "nativo" di .NET, per cui viene trattato diversamente.

Peccato, perché sarebbe interessante che fossero esposti tipi di dati che fossero direttamente mappabili sulle unità SIMD (e, quindi, per i quali fossero generate direttamente inline le istruzioni per manipolarli).
quoti anche che Python non sarà il miglior linguaggio del mondo?? :eek: :D
Certamente. Non esiste il miglior linguaggio: esiste quello utile per risolvere il particolare problema. :O

"Casualmente" finora Python è stata quasi sempre la soluzione ai miei problemi. :cool: