View Full Version : Come posso iniziare?
Salve a tutti!Mi piacerebbe molto, ma molto, ma molto :D , saper programmare ma ahimè non riesco a trovare delle giuste vie. Incomincio un linguaggio di programmazione e lo mollo dopo giorni, addirittura ore!!Praticamente ho letto i primi 3-4 capitoli di libri riguardante:
-C
-Python
-PHP
-HTML
-JAVASCRIPT
Sinceramente non so più che pesci prendere!Escluderei la programmazione Web (dato che momentaneamente non mi interessa) e quindi rimarrebbero C e Python.
Io inizialmente ho cominciato col C, ma poi mi sono un pò bloccato alle funzioni, e da allora mi sono praticamente fermato!
Il Python è un linguaggio sicuramente ottimo per i neofiti, ma ciò che non mi piace è che è un linguaggio interpretato!Chiedo a voi asperti:
Con quale linguaggio mi consigliate iniziare?
Premetto che sono ben fornito, dato che ho libri di testo di C, JavaScript, Bash, HTML, Python e PHP :D
Grazie anticipamente a tutti e ciao!
Forse è un problema di motivazione più che di lingua. Auto-motivazione. I libri sono fondamentali ma, per ragioni di spazio, danno una visione un po' grigia della programmazione. Non è così. La programmazione è creatività, fantasia. E' materia viva e vivace.
Trova un'idea e fanne un programma. E' un gioco, pensa a divertirti.
cdimauro
18-07-2007, 21:27
Salve a tutti!Mi piacerebbe molto, ma molto, ma molto :D , saper programmare ma ahimè non riesco a trovare delle giuste vie. Incomincio un linguaggio di programmazione e lo mollo dopo giorni, addirittura ore!!Praticamente ho letto i primi 3-4 capitoli di libri riguardante:
-C
-Python
-PHP
-HTML
-JAVASCRIPT
Sinceramente non so più che pesci prendere!Escluderei la programmazione Web (dato che momentaneamente non mi interessa) e quindi rimarrebbero C e Python.
Io inizialmente ho cominciato col C, ma poi mi sono un pò bloccato alle funzioni, e da allora mi sono praticamente fermato!
Il Python è un linguaggio sicuramente ottimo per i neofiti, ma ciò che non mi piace è che è un linguaggio interpretato!Chiedo a voi asperti:
Con quale linguaggio mi consigliate iniziare?
Premetto che sono ben fornito, dato che ho libri di testo di C, JavaScript, Bash, HTML, Python e PHP :D
Grazie anticipamente a tutti e ciao!
Python non è interpretato: è compilato in (un suo) bytecode (alla prima esecuzione dello script).
Sono quasi 3 anni che sviluppo con Python a lavoro, e in questo momento c'è il server del CMS aziendale che sta interamente sulle sue spalle, un altro server per un nuovo progetto che è partito giusto l'altro ieri, e per non parlare di tanti altri server e applicazioni che ho scritto e che girano tranquillamente con questo linguaggio.
Ti sembra roba esclusivamente riservata ai neofiti? ;)
Ti segnalo questo http://www.hwupgrade.it/forum/showpost.php?p=17427521&postcount=19 mio post, e il libro in fondo, ma se ti leggi tutto il thread è interessante.
Sicuramente è un ottimo linguaggio, ma come mai in questo forum non se ne parla molto :confused:
Vedo invece molto spesso parlare di C, C++, Java ed etc.
Poi il fatto che un utente debba aver per forza installato python non mi entusiasma molto...
Scegli la lingua che ti attizza di più. Se ti sconfiffera C++, usa C++. Se ti sollazza JavaScript, usa JavaScript. Con HTML è un po' più dura perchè, per quanto ne so, è limitato alla presentazione di informazioni. Che è pur sempre una gran cosa ma un po' di manipolazione ravviva la faccenda.
jepessen
18-07-2007, 22:07
Ormai le cose le hai lette, ma metterti a scrivere codice senza uno scopo è come scrivere un libro senza avere una storia da raccontare. Difficile e noioso dopo poco. Per imparare a programmare veramente, ti serve un problema da risolvere.
Io, per esempio, per un paio d'anni ho sempre cazzeggiato con C e C++ e le Gtkmm, senza mai capirci molto. Adesso ho appena cominciato a lavorare su un programma 'vero' (un CAD elettronico), e devo risolvere problemi veri: matrici sparse, oggetti Canvas delle Gtk e così via. Faccio ricerche, sperimento, provo, e quando trovo la soluzione, nel mio piccolo, godo. Se si prende la cosa nel verso giusto, la ricerca della soluzione può essere una cosa stimolante e creativa come poche altre (a parte l'arte).
Impara prima il C semplice. Capisci così la logica di funzionamento di molti linguaggi procedurali che si fondano sulle stesse basi logiche. Poi passa a tutto il resto. C++ non è facilissimo, ma è la naturale evoluzione del C per la programmazione ad oggetti.
Un buon linguaggio di programmazione, pulito ed elegante, invece, è il C#, che ho cominciato ad apprezzare ultimamente (sempre a livello amatoriale). Imparare la programmazione ad oggetti tramite il C# è decisamente più facile che con Java, C++ o altro. Inoltre, è più facile, sempre grazie alla pulizia del linguaggio, anche trattare argomenti complicati che raramente ci sono nei libri didattici, come la creazione di un'interfaccia grafica per un programma.
C e C# però ti servono più che altro per capire la natura dei problemi; non che non siano utili anzi, completamente il contrario. Sono estremamente potenti e flessibili, per questo te li ho consigliati. Solamente che non dovrebbero essere gli unici linguaggi che un programmatore debba conoscere.
Nella programmazione seria, un programmatore conosce sempre abbastanza bene più di un linguaggio, ed utilizza di volta in volta quello che serve di più per un particolare problema (C++ e Fortran dove serve velocità, Python dove serve rapidità di programmazione, Javascript e PHP per siti dinamici, E per il calcolo distribuito e così via). Le basi sono sempre le stesse (costrutti if, cicli etc), ma dovrai imparare di volta in volta ad utilizzare i comandi specifici del linguaggio, che li differenziano dagli altri. Prova a fare un form HTML in C, oppure un programma di grafica vettoriale in PHP... bisogna utilizzare di volta in volta gli strumenti giusti, se non si vuole complicarsi la vita inutilmente.
Daniele
cdimauro
18-07-2007, 22:37
Sicuramente è un ottimo linguaggio, ma come mai in questo forum non se ne parla molto :confused:
Perché la gente tendenzialmente preferisce i linguaggi più blasonati a quelli più comodi ma meno diffusi.
Vedo invece molto spesso parlare di C, C++, Java ed etc.
Appunto. E ne vedrai parlare sempre spesso per i motivi di cui sopra. Oltre al fatto che spesso ci si lega morbosamente a qualche linguaggio / ambiente, e anche la sola idea di cambiare risulta quanto meno indigesta.
Poi il fatto che un utente debba aver per forza installato python non mi entusiasma molto...
Python è nella stessa situazione di tanti altri linguaggi, compresi quelli che hai elencato: senza ambiente di sviluppo installato non puoi fare niente.
cdimauro
18-07-2007, 22:41
Scegli la lingua che ti attizza di più. Se ti sconfiffera C++, usa C++. Se ti sollazza JavaScript, usa JavaScript. Con HTML è un po' più dura perchè, per quanto ne so, è limitato alla presentazione di informazioni. Che è pur sempre una gran cosa ma un po' di manipolazione ravviva la faccenda.
Visto che chiedeva un consiglio per iniziare a programmare, il linguaggio da usare non può certo essere uno qualunque di quelli che hai elencato. ;)
Decisamente meglio Python o Ruby. Per quanto mi riguarda sceglierei Python che è più semplice e con una sintassi più leggibile.
Parafrasando la battuta di un film, consiglieri Python ad un amico se fossi amico di Hitler.
Avrei detto Java prima dei generici, ora mica tanto e quando finalmente spareranno quella stronzata delle chiusure pregherò che ci facciano il backoffice degli uffici IVA.
Insomma, aspetto e dico "uno vale l'altro". Si vocifera che quelli di Cadence stiano lavorando su un nuovo Smalltalk. Incrociamo le dita che ci sono rimaste.
cdimauro
19-07-2007, 08:01
Non conosco la quella battuta, per cui non posso coglierne il significato.
Comunque PGI io non ti capisco proprio: i linguaggi non sono fatti per contemplarne la "consistenza" ad alcuni assiomi, ma per essere usati.
Le chiusure non ti piacciono? Non le usare. Io in Python le uso, perché sono molto comode (quando è necessario).
SmallTalk lo conosco da una ventina d'anni, e sebbene all'epoca ne sia rimasto a dir poco stregato, conservandone il "culto" (che suona ridicolo detto da un ateo :asd:) nel tempo, confrontandolo oggi con la sintassi semplice e comprensibile di Python non lo trovo adeguato per l'apprendimento della programmazione e per la scrittura di codice che si "legga" facilmente.
E' stato un bell'esperimento, ma ha fatto il suo tempo.
^TiGeRShArK^
19-07-2007, 09:40
Impara prima il C semplice. Capisci così la logica di funzionamento di molti linguaggi procedurali che si fondano sulle stesse basi logiche.
Non ha senso imparare il procedurale e poi disimpararlo per imparare l'Object Oriented :p
Un buon linguaggio di programmazione, pulito ed elegante, invece, è il C#, che ho cominciato ad apprezzare ultimamente (sempre a livello amatoriale). Imparare la programmazione ad oggetti tramite il C# è decisamente più facile che con Java, C++ o altro.
Perchè C# è + facile di Java?
Sono praticamente equivalenti questi due linguaggi.
Inoltre, è più facile, sempre grazie alla pulizia del linguaggio, anche trattare argomenti complicati che raramente ci sono nei libri didattici, come la creazione di un'interfaccia grafica per un programma.
La creazione di un interfaccia grafica dovrebbe essere demandata al GUI Builder.
Non ha senso sprecare tempo per creare un interfaccia grafica se questa viene altrettanto bene con un editor visuale e con qualche piccola ottimizzazione a mano.
C e C# però ti servono più che altro per capire la natura dei problemi; non che non siano utili anzi, completamente il contrario. Sono estremamente potenti e flessibili, per questo te li ho consigliati. Solamente che non dovrebbero essere gli unici linguaggi che un programmatore debba conoscere.
Veramente col C ti devi concentrare a trattare problemi che a te non servono x nulla.
E' troppo a basso livello a meno di esigenze particolari.
Nella programmazione seria, un programmatore conosce sempre abbastanza bene più di un linguaggio, ed utilizza di volta in volta quello che serve di più per un particolare problema (C++ e Fortran dove serve velocità, Python dove serve rapidità di programmazione, Javascript e PHP per siti dinamici, E per il calcolo distribuito e così via).
Si sono d'accordo...
ma vedi che cmq oggi come oggi la velocità di Java è paragonabile a quella del C++ :p
Era un film di Woody Allen, la maledizione di (qualcosa) di giada. Lui interpreta un regista al tramonto della sua carriera, gli offrono la regia di una grande produzione, viene colpito da cecità psicosomatica e fa un film bruttissimo. Alla preproiezione viene chiesto agli spettatori di rispondere ad alcune domande, tra cui "Consiglierebbe questo film ad un amico" e la risposta è "Sì, se fossi amico di Hitler". Ah ah ah, che ridere (adesso ridi per farmi contento, sù).
A mio sommesso avviso non è possibile usare un sottoinsieme di un linguaggio. Per due ragioni.
La prima è che ogni sfumatura ha un suo campo di applicazione: nel contesto del linguaggio di programmazione Java 5, ad esempio, i generici sono una soluzione tecnicamente migliore rispetto ai "tipi nudi e crudi" perchè garantiscono la consistenza dei tipi in un idioma che è essenzialmente polimorfico (un'espressione può avere più tipi).
La seconda è che il singolo essere umano digitante non è un atomo nel mondo della programmazione. Vive accanto ad altri digitanti. Vuoi per collaborazione, vuoi per manutenzione, è inevitabile che gli passi sotto agli occhi il codice scritto da altri. La grammatica ci dice che per comunicare occorre conoscere la lingua usata. Tutta quanta. Non un pezzo. Se io eliminassi dal mio panorama Java le classi, i generici, le chiusure, i tipi primitivi, le eccezioni non controllate e un paio d'altre cose che adesso non mi vengono in mente, non starei più comunicando in Java. Chiunque conosca il linguaggio non potrebbe che dire "ma questo deve essere espresso in quest'altro modo". Perchè io starei usando Java ma non in un modo adeguato ad esprimere un certo significato.
E' come se io, in questo forum e se ne fossi capace, scrivessi sempre usando termini italiani desueti. Facendolo commetterei un errore perchè la grammatica ci dice che la scelta della parole deve essere adeguata al contesto della comunicazione. Parlando ad un consesso di "adoratori dei bei tempi andati" sarei nel giusto, nella sezione "programmazione" del forum di hardware upgrade, no.
Non penso che siano rilievi poi così irragionevoli, vi pare?
cdimauro
19-07-2007, 11:27
Era un film di Woody Allen, la maledizione di (qualcosa) di giada. Lui interpreta un regista al tramonto della sua carriera, gli offrono la regia di una grande produzione, viene colpito da cecità psicosomatica e fa un film bruttissimo. Alla preproiezione viene chiesto agli spettatori di rispondere ad alcune domande, tra cui "Consiglierebbe questo film ad un amico" e la risposta è "Sì, se fossi amico di Hitler". Ah ah ah, che ridere (adesso ridi per farmi contento, sù).
Ma LOL. No no: me la rido di gusto. Bellissima battuta (era "La maledizione dello scorpione di giada" se non erro, che però non ha ancora visto). :D
A mio sommesso avviso non è possibile usare un sottoinsieme di un linguaggio. Per due ragioni.
La prima è che ogni sfumatura ha un suo campo di applicazione: nel contesto del linguaggio di programmazione Java 5, ad esempio, i generici sono una soluzione tecnicamente migliore rispetto ai "tipi nudi e crudi" perchè garantiscono la consistenza dei tipi in un idioma che è essenzialmente polimorfico (un'espressione può avere più tipi).
La seconda è che il singolo essere umano digitante non è un atomo nel mondo della programmazione. Vive accanto ad altri digitanti. Vuoi per collaborazione, vuoi per manutenzione, è inevitabile che gli passi sotto agli occhi il codice scritto da altri. La grammatica ci dice che per comunicare occorre conoscere la lingua usata. Tutta quanta. Non un pezzo. Se io eliminassi dal mio panorama Java le classi, i generici, le chiusure, i tipi primitivi, le eccezioni non controllate e un paio d'altre cose che adesso non mi vengono in mente, non starei più comunicando in Java. Chiunque conosca il linguaggio non potrebbe che dire "ma questo deve essere espresso in quest'altro modo". Perchè io starei usando Java ma non in un modo adeguato ad esprimere un certo significato.
E' come se io, in questo forum e se ne fossi capace, scrivessi sempre usando termini italiani desueti. Facendolo commetterei un errore perchè la grammatica ci dice che la scelta della parole deve essere adeguata al contesto della comunicazione. Parlando ad un consesso di "adoratori dei bei tempi andati" sarei nel giusto, nella sezione "programmazione" del forum di hardware upgrade, no.
Non penso che siano rilievi poi così irragionevoli, vi pare?
OK, adesso è chiara la tua visione e devo dire che è condivisibile.
L'unica cosa è che se uno mi dicesse "questo dev'essere espresso in quest'altro modo" quando in realtà si tratta di una mia scelta (ognuno ha un suo stile di programmazione), lo prenderei a randellate sulle gengive.
Ad esempio, quando ho lavorato in C/C++ ho cercato di fare quasi sempre a meno del famigerato operatore terziario (il "?"): non lo sopporto proprio. Purtroppo nelle macro (altra cosa che odio e che cerco di evitare come la pesta) era quasi inevitabile usarlo (anche perché il compilatore che usavo all'epoca riconosceva soltanto espressioni che usavano il "?" per generare l'istruzione MIN o MAX del processore LX, mentre usando l'if metteva la classica sequenza di confronto, salto / copia registro).
P.S. Quando arriverà la prossima versione di Java passerai a Squeeke, o hai in mente altro?
Devo essere sincero, mi aspettavo risposte più semplici, ma vedo che siamo arrivati ad un certo OT :D
La mia domanda era semplice, e sinceramente di Hitler e di film poco mi importa :p
Tralasciando linguaggi ad oggetti quali C++, Java ed altri, volevo imputarmi su C o Python, e ho chiesto a voi quale era il più appropriato per uno che non ne sa un H di programmazione!Aspetto sane risposte :D
cdimauro
19-07-2007, 11:46
La risposta è a dir poco banale: Python. Assolutamente Python. Sempre Python. :D
Tralasciando i linguaggi orientati agli oggetti, tra C e Python logica vuole che uno risponda C, essendo Python orientato agli oggetti.
Tra C e Python tout-court, Python.
Per una questione pratica. I programmi Python sono indipendenti dalla piattaforma (cioè dipendono dalla piattaforma Python ma non dal sistema operativo). Vale la pena ricordare che "sistema operativo" include versioni diverse dello "stesso" sistema operativo.
Dirò un'inezia. Se passi da Windows 98 a Windows 2000, a XP o a vista, a 32, 64 e chi più ne ha più ne metta bit, il programma che hai scritto quello è e quello rimane.
C'è il lavoro di qualcuno dietro a questa portabilità. Ma è qualc-UNO, una volta sola e per tutti.
cdimauro
19-07-2007, 12:55
Però Python funziona benissimo (e anche meglio :D ) pure per la programmazione strutturata, eh! :p
P.S. La tua firma mi fa sbellicare dalle risate. :asd:
Finge. Sempre oggetti sono. Per quanto mi è dato di capire, e come in altre lingue che mischiano la prospettiva orientata agli oggetti con altre cose, la dichiarazione di una funzione è una sintassi alternativa per l'invocazione di un metodo dell'istanza di una classe. E qui sta il problema. Ma ho il divieto di OT :D:
cdimauro
19-07-2007, 13:35
Mumble mumble. Classi e funzioni vengono invocate (generando un'istanza la prima ed eseguendo il suo codice la seconda) utilizzando la stessa sintassi, ma per il resto non noto analogie.
Con la bieca scusa che Leddolo ha scelto Python, mi collego a:
http://docs.python.org/ref/function.html#function
E' la guida di riferimento al linguaggio di programmazione Python e...be', gli serve. Non sono OT. Un'auto-assoluzione :D.
Là dice che la definizione di una funzione è la definizione di un oggetto di tipo funzione. Non è una stranezza, anzi. Il fatto è che ci sono due modi di fare una cosa e uno dei due vale solo in alcuni casi. Il problema che io vedo è questo. Le funzioni (e le chiusure di Gafter) sono un'eccezione sintattica e le eccezioni in generale sono, in quanto deduzioni contraddittorie, veri e propi macigni per il cervello. E' il classico caso del:
<<non non alzarti dal letto>>
Devo alzarmi o no? Ci vogliono dei secondi perchè il cervello trovi una risposta corretta ad una doppia negazione.
Cmq si alla fine ho optato per Python :D
Quando ci ho preso un pò la mano sicuramente cambiero linguaggio, tipo C o Java, dopo si vedrà :D
cdimauro
19-07-2007, 20:22
Con la bieca scusa che Leddolo ha scelto Python, mi collego a:
http://docs.python.org/ref/function.html#function
E' la guida di riferimento al linguaggio di programmazione Python e...be', gli serve. Non sono OT. Un'auto-assoluzione :D.
Ma figurati, dai! Le tue osservazioni sono molto interessanti e quindi gradite. :)
Là dice che la definizione di una funzione è la definizione di un oggetto di tipo funzione.
Come per le classi: http://docs.python.org/ref/class.html
La definizione di una classe è la definizione di un oggetto di tipo classe.
Vabbé che per Python qualunque cosa è un oggetto (anche i tipi di dati :p).
Non è una stranezza, anzi. Il fatto è che ci sono due modi di fare una cosa e uno dei due vale solo in alcuni casi. Il problema che io vedo è questo. Le funzioni (e le chiusure di Gafter) sono un'eccezione sintattica e le eccezioni in generale sono, in quanto deduzioni contraddittorie, veri e propi macigni per il cervello. E' il classico caso del:
<<non non alzarti dal letto>>
Devo alzarmi o no? Ci vogliono dei secondi perchè il cervello trovi una risposta corretta ad una doppia negazione.
Onestamente non conosco le chiusure di Gafter, ma vorrei capire meglio (si capisce che non ho capito? :D) come mai definisci "eccezione sintattica" le funzioni.
cdimauro
19-07-2007, 20:25
Cmq si alla fine ho optato per Python :D
Quando ci ho preso un pò la mano sicuramente cambiero linguaggio, tipo C o Java, dopo si vedrà :D
Bravo, ma prima che tu riesca a imparare tutti gli aspetti del linguaggio, e soprattutto a padroneggiarli (entrando nell'ottica di chi sviluppa con in Python) passerà un bel po' di tempo.
Nel frattempo andrai maturando l'idea che Python è un linguaggio completo e che ti permette di fare praticamente tutto e in poco tempo, per cui il tuo interesse per linguaggi come il C, che sono decisamente più astrusi e che per realizzare la benché minima cosa ti fanno sudare le canoniche 70 (!) camiche, verrà decisamente meno. :D
Neal Gafter è un ingegnere ex Sun passato a Google ma che comunque spacca le nocciole a Sun perchè vuole che Java 7 abbia le chiusure. In questo senso intendevo "di Gafter" :D.
La faccio molto breve.
La programmazione orientata agli oggetti consiste nel definire degli oggetti e metterli in relazione. Siccome le relazioni sono a loro volta oggetti, la faccenda si risolve nel creare oggetti.
Tutti i linguaggi orientati agli oggetti danno la possibilità all'utente programmatore di creare degli oggetti. Chi con le classi e col new, chi senza classi e senza new, chi con le classi e senza new... un modo c'è.
Tutto quello che non corrisponde a quel modo è un'eccezione. E quante più regole sono eccezioni tanto più complicato è apprendere il linguaggio.
cdimauro
20-07-2007, 07:54
Grazie per il chiarimento (adesso so pure chi è che vorresti strozzare :D).
L'unica cosa che mi lascia perplesso è la complessità legata alle eccezioni per generare oggetti.
Mi spiego meglio. Con Python qualunque definizione (possiamo intendere con ciò anche la banale assegnazione: a = 'Pippo' che genera un oggetto stringa con valore 'Pippo') genera un oggetto. Con oggetto inteso nell'accezione classica: istanza di una qualche classe.
A mio avviso non c'è però un aumento della complessità per l'apprendimento del linguaggio: si tratta semplicemente di una questione sintattica.
Qual è la differenza fra:
var
s: string = 'Pippo';
in Pascal/Delphi e
s = 'Pippo'
in Python?
Nel primo caso il compilatore infila nella locazione di s il puntatore all'area di memoria che contiene la stringa (compresa la lunghezza e il reference count).
Nel secondo caso il compilatore infila in s (che non è una locazione, ma per il momento lasciamo perdere questo dettaglio :D) il "puntatore" all'area di memoria dell'oggetto stringa creato e che contiene 'Pippo'.
Ma al di là di ciò, cos'è cambiato? Nulla, perché entrambe sono... stringhe, e le userò come tali appunto. Ha qualche importanza il fatto che la seconda sia in realtà un oggetto? Non credo.
Al programmatore interessa che esista una certa sintassi che gli permetta di creare delle stringhe, che poi andrà a utilizzare in maniera appropriata.
Non penso esista un'oggettiva difficoltà / complessità, se non quella di imparare una certa sintassi per utilizzare un qualche strumento. Ma questo per un programmatore è una cosa "naturale".
EDIT: ma in Java le stringhe non sono istanze di una classe? Però non si creano con l'operatore new. ;)
Per creazione di oggetto intendo la dichiarazione e definizione di un oggetto. Tutte le lingue OO a me note hanno una forma usuale per farlo. Mi pare che l'abbia anche Python (class Persona: eccetera e poi x = Persona()).
Considero eccezionale la deviazione da questo schema perchè la dichiarazione di oggetti "propri" è prevalente nei programmi orientati agli oggetti. E' necessario che lo sia, si tratta di modellare un fenomeno per come è stato visto da chi scrive il programma, non è possibile risolvere il problema esclusivamente con gli oggetti built-in. Se si tentasse allora il programma sarebbe non ciò che ho osservato io ma quello che io osservo per come lo vedrebbe qualcun'altro (qualcuno che possedesse esclusivamente i concetti di stringa, numero eccetera).
Le funzioni di Python sono come le chiusure di Smalltalk. Istanze la cui creazione non segue lo schema prevalente (= Classe() per Python o = Classe new. per Smalltalk). Per il primo abbiamo:
def fun(x, y): return x + y
"fun" è l'istanza.
Per il secondo:
[:x :y | x + y].
Questa roba è l'istanza.
{ int x, int y => x + y }
Questa sarà l'istanza di Java.
Il problema non è la sintassi, nè il fatto che siano funzioni. Che le funzioni siano oggetti è "naturale". Il problema è che questa sintassi corrisponde a qualcosa che normalmente si fa in un altro modo e quel "normalmente" è il 100% dell'orientamento agli oggetti.
Se mi dici "in Java le Stringhe sono oggetti e non si creano con il new" io ti rispondo: "Bravo e non una volta sola, ma due!".
Perchè? Perchè in quel rilievo c'è la regola e c'è la sua eccezione espressa con la negazione che è propria delle eccezioni.
Java dice proprio quello. Se vuoi creare un oggetto devi usare il new a meno che quell'oggetto non sia una stringa allora puoi usare anche un'altra forma (il cui risultato eccepisce alla norma dell'identità tra riferimenti :eek:). lo fa anche, e in modo ben peggiore, con gli involucri numerici.
Integer x = 10;
Spiegare questa linea richiede almeno un'ora. Cita una regola... la eccepisce!
Sono questioni sintattiche? Certamente sì, sono regole sintattiche. Bisogna impararle. Bisogna sapere che ci sono alcune regole che valgono sempre ed altre che valgono "a meno che". Maggiore è la quantità di "a meno che" più difficile è apprendere il linguaggio, perchè il ragionamento negativo è più oneroso di quello positivo (esitono montagne di studi in psicologia che lo confermano).
E' quello che il buon Ken Arnold (progettista di Java, fiero oppositore dei generici, San Giuseppe lo benedica) chiama "Fattore C++".
Perchè C++ è un linguaggio così maledettamente complicato da tenere a bada? Non certo perchè consente di giostrarsi coi puntatori. Lo permette anche C ed è una delle lingue più semplici del pianeta. Se uno guarda le specifiche di C++ scopre che accanto ad un numero non poi eccessivo di regole esiste una quantità soverchiante di eccezioni.
Noto il problema, lo si dovrebbe evitare. Infatti se l'attività principale è definire oggetti noi ci mettiamo due o tre sintassi diverse perchè quache volpone ha la strana idea che scrivere meno significa scrivere meglio.
Ecco, con quel volpone ci verrebbe bene un pellicciotto per signora.
cdimauro
20-07-2007, 13:37
Premesso che condivido l'aspetto teorico, ma fra:
String s = new String("Pippo");
e
String s = "Pippo";
preferisco nettamente l'eccezione alla regola. :D
Sull'onerosità dell'apprendimento delle diverse "sintassi" / "eccezioni" hai ragione: lo sforzo è maggiore (da qualche mese in azienda sto partecipando a un corso d'inglese upper/intermediate, e c'è da spararsi: ci sono centinaia di regole ed eccezioni con questa lingua. La prossima volta che qualcuno mi dice che l'inglese è una lingua semplice da imparare gli faccio un attentato).
Però per quanto evidenziato con l'esempio di cui sopra, non sono del tutto d'accordo con l'ultima parte del tuo messaggio. E' chiaro che l'affermazione "scrivere meno significa scrivere meglio" è oggettivamente falsa, ma è anche vero che non è del tutto falsa.
Posto che abbiamo abbastanza memoria per ricordare tutte le sintassi / eccezioni (o almeno una buona parte), se queste sono fatte con certi criteri, il codice che ne può venire fuori potrebbe essere più semplice e/o comprensibile.
Tu utilizzi la prima o la seconda forma, fra le due che ho riportato? ;)
Naturalmente uso la seconda. L'alternativa "regolare" sarebbe eccessivamente scomoda. E non sarebbe:
String x = new String("hello");
ma una cosa tipo:
H h = new H();
E e = new E();
L el = new L();
O o = new O();
String x = new String(h, e, el, el, o);
Assolutamente masochistica. Diciamo che per essere "usabile" una cosa del genere richiederebbe una sintassi diversa da quella a cui siamo abituati. Sarebbe ad esempio praticabile se la lingua permettesse di dire:
Caratteri c = new Caratteri();
String x = new String(c: hello);
dove una cosa tipo "c:" starebbe a significare che dopo "c:" appaiono i nomi di metodi invocati sull'istanza "c".
Sempre per rispettare la regolarità, questo richiederebbe che tutte le invocazioni di metodo avessero la forma:
istanza: uno o più nomi di metodo tutti attaccati.
h, e, l, l, o, sarebbero metodi di Caratteri i quali restituirebbero un'istanza di Carattere.
Che mi sa di stron... ma è per dire che un linguaggio dovrebbe privilegiare la regolarità anche qualora questa abbia un costo in termini di sintesi, qualora questo sia sopportabile, considerando che un programmatore non particolarmente rapido è pur sempre un digitante a 100 battute per minuto.
Con la faccenda della sintesi e della memoria mi alzi una palla che sarei tentato di schiacciare ma mi trattengo. Basti dire che la capacità di memoria stimata del cervello umano è più o meno quella di un CD-Rom.
cdimauro
21-07-2007, 05:36
No, no: non trattenerti. Se ti va, parlane pure. :) Comunque lo spazio di un CD-Rom mi sembra pochino... :|
Sul resto, che dire... :eek: :eek: :eek:
La regolarità ha, appunto, un prezzo da pagare e a volte è decisamente eccessivo (al volo mi viene in mente anche l'inizializzione degli array, ad esempio).
Diciamo che personalmente preferisco le eccezioni (ma questo s'era capito già da un pezzo :p), perché generalmente mi fanno procedere col lavoro più velocemente, e il codice che ne viene fuori risulta comunque leggibile.
Non si tratta di "syntactic sugar", come soleva ripeteva il mio professore di linguaggi di programmazione (all'epoca adorava Scheme, e non perdeva occasione di fare battutine su linguaggi come il C :D), ma di strumenti che permettono, se usati sapientemente, di rendere la vita più facile a chi scrive codice.
Comunque ti ringrazio ancora per le informazioni sull'argomento, che sono veramente interessanti e mi hanno fornito un nuovo punto di vista con cui vedere il codice (e la programmazione). :)
Premetto che siamo latamente In Topic. Lo siamo perchè approfitterò dell'alzata di cidimauro per dire un perchè raramente citato.
Parlo del motivo per cui se una variabile denota un Bancomat chiamarla "bancomat" è meglio che chiamarla "x" ma se la variabile denota l'incognita di una funzione allora "x" è meglio di "bancomat". Dirò che una denominazione "mirata" è valida solo se è coerente con il contesto. Cioè se il programma tratta di manipolazioni di immagini e ad un certo punto io vedo una variabile che si chiama "bancomat" possono capitare cose bizzarre.
Ai tempi dei tempi, Von Neumann stimò la dimensione della memoria in 10^20 bit. Un conto basato sugli impulsi neurali gestite dal cervello in una vita o roba del genere.
Più o meno una ventina d'anni fa si passò dal conto astratto a quello empirico. Il succo di tutto sta nel lavoro di tal Thomas K. Landauer il quale trasse due conclusioni. 10^20 un corno e 2 bit al secondo.
La dimensione stimata da Landauer aveva un massimo di un gigabit. In più, cosa molto interessante, la velocità del trasferimento delle informazioni dalla memoria a lungo termine alla memoria di lavoro risultava essere di 2 bit al secondo.
Insomma, un CD-Rom con il lettore più schifoso che si sia mai visto.
Come diceva un mio professore, lo sdudende addendo bodrebbe ghiedere: ma com'è che io ricordo una valanga di cose?
L'evoluzione non toglie niente per niente. A fronte di poca memoria, per giunta di scarsa qualità, sembra aver dato tanta capacità di calcolo: tra 10^8 e 10^10 MIPS.
Il cervello ha un'enorme "forza bruta" ed è circondato da una rete sensoriale pienamente in grado di alimentarlo (solo il "bus" di ciascun occhio trasferisce costantemente un miliardo di punti immagine al secondo).
E qui arriva la teoria della memoria esterna.
Il cervello "inventa" i suoi ricordi sulla base delle informazioni che può reperire dal contesto in cui si trova. Detto altrimenti è molto più probabile che quello che dico sia non il frutto di ciò che ricordo ma di ciò che ricostruisco mischiando un poco delle mie passate esperienze con un tanto dell'esperienza che sto vivendo.
Il cervello lavora usando un buffer volatile noto come memoria di lavoro. E' piccolo, associativo e ha un tempo di accesso insignificante. Qui si trovano le informazioni usate per il pensiero cosciente.
I dati travasati dalla memoria centrale sono quelli che hanno un qualche genere di attinenza con il contesto attualmente vissuto.
Poichè costa caro, il cervello tende a non rimpiazzare questi dati con altri provenienti dalla memoria centrale. Semmai li trasforma sul posto reinterprentadoli alla luce di quanto osserva. Pessima memoria, grande capacità di calcolo.
La teoria della memoria esterna, cioè il fatto che il cervello preferisca creare informazioni derivandole da ciò che è percepito piuttosto che riesumarle da ciò che ricorda, ci dice che per essere più facilmente leggibile un nome di variabile deve essere coerente con l'argomento del codice sorgente e deve essere suggestivo nell'ambito di tale argomento.
Non è cioè sufficiente, come taluni dicono, che il nome sia significativo in quanto corrispondente ad un'esperienza comune perchè se l'esperienza comune non è anche l'esperienza attuale allora rischio due cose:
che il significato sia reinterpretato nel contesto attuale (cioè che bancomat significhi un tipo di immagine o persino un arbitrario nome di variabile nel contesto di una funzione matematica astratta)
oppure
che si verifichi un accesso alla memoria principale con svuotamento di quella volatile e conseguente reinterpretazione non solo della variabile, ma di ogni altra informazione suggerita dal contesto.
Quindi se aderiamo alla teoria della memoria esterna e se riteniamo plausibile che il cervello abbia più capacità di calcolo che memoria permanente, allora X è un nome di variabile migliore di Y se X esprime un significato appartenente all'esperienza desumibile dal contesto in cui appare.
Insisto perchè, secondo me, è fondamentale per capire cosa significhi "leggibile" o "semplice".
Non è che "a001" sia un pessimo nome di variabile e "indice" ottimo per grazia ricevuta. Nè sono pessimo e ottimo perchè uno è insensato e l'altro sensato. Non siamo alla bocciofila, che tra un bicchiere di vino e l'altro ognuno tira la sua palla: la programmazione è informatica, l'informatica è scienza e la scienza richiede spiegazioni criticabili in quanto fondate su una teoria.
"indice" è un miracolo di leggibilità SE quel nome abbia un significato SE quel significato sia coerente con un contesto SE quel contesto sia anche quello valido nel momento in "indice" appare e soprattutto SE un essere umano funzioni nel modo prima riassunto.
Chiudo con un paio di collegamenti in cui si possono trovare pubblicazioni che trattano (anche) di queste cose.
http://www.jetpress.org/index.html
http://www.foresight.org/Updates/Publications.html
http://www.cognitivesciencesociety.org/
e il libro che ogni sviluppatore di software per esseri umani, codice incluso, dovrebbe avere: The Psychology of Everyday Things, di D. A. Norman.
mindwings
21-07-2007, 19:28
Premetto che siamo latamente In Topic. cut cut cut ...
molto interessante :D
mi pare sentir parlare il mio prof quando ci spiegava
cosa è l'A.I.
>Perl< (http://www.perl.it//documenti/corsoperl.html)
cdimauro
22-07-2007, 06:23
Premetto che siamo latamente In Topic. Lo siamo perchè approfitterò dell'alzata di cidimauro per dire un perchè raramente citato.
[...]
e il libro che ogni sviluppatore di software per esseri umani, codice incluso, dovrebbe avere: The Psychology of Everyday Things, di D. A. Norman.
Se tutti i messaggi OT fossero di questo spessore, beh... spero che l'OT diventi la regola e non l'eccezione (giusto per rimanere "in tema" :D).
Grazie per l'n-esimo post da incorniciare, che oltre a essere interessante condivido (in particolare sull'ultima parte quando sei passato in ambito più prettamente informatico, con cui sono assolutamente d'accordo e che, nel mio piccolo, cerco di applicare).
Quanto al libro che suggerivi, si trova in Italia e/o in italiano?
cdimauro
22-07-2007, 06:31
>Perl< (http://www.perl.it//documenti/corsoperl.html)
:eek: Dopo questi bellissimi post di PGI su regole ed eccezioni, modellazione e conoscenza, te ne esci con uno dei linguaggi più brutti che siano mai stati progettati, in cui esistono diverse regole per fare le stesse cose (o dovremmo chiamarle eccezioni? :D) e in cui gli oggetti sono stati aggiunti in maniera a dir poco raccapricciante. :cry:
Casualmente venerdì discutevamo di PERL con un mio collega che lavora prevalentemente con questo linguaggio; sebbene l'avessi studiato un paio d'anni fa, giusto ieri sono andato sul sito ufficiale per dargli una ripassata e le mie pessime impressioni di allora sono state ampiamente riconfermate e consolidate... :p
Giusto per far cominciare male la giornata a PGI :D posto il link alla pagina della sintassi http://perldoc.perl.org/perlsyn.html (che è già tutto un programma :p) e la ciliegina sulla torta: http://perldoc.perl.org/perlboot.html l'introduzione alla programmazione orientata agli oggetti in PERL. :asd:
The Psychology of Everyday Things si trova un po' dappertutto, è un libro abbastanza famoso, pare che Norman sia un capoccione.
La seconda edizione inglese si chiama The Design of Everyday Objects. Io l'ho preso qui (http://www.bol.it/inglesi/scheda/ea978046506710.html)
Costa poco, è corto ed è anche divertente.
Di PERL conosco l'esistenza e null'altro.
Ormai le cose le hai lette, ma metterti a scrivere codice senza uno scopo è come scrivere un libro senza avere una storia da raccontare. Difficile e noioso dopo poco. Per imparare a programmare veramente, ti serve un problema da risolvere.
Non mi trovi d'accordo :
Scrivere codice senza uno scopo puo essere noioso, ma scrivere codice per apprendere un nuovo framework, una nuova libreria, puo essere interessante.
Io e' anni che ho sviluppato un applicazione web java che chiamo benchmark, nella quale ho organizzato alcune semplici voci come amministrazione (sotto cui vanno gestione utenti, gruppi, permessi), parte gestione dati (sotto cui finiscono tutte le possibili query per testare i casi piu disparati, etc. la quale cresce ogni volta che mi avvicino ad un nuovo argomento java.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.