Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Renault Twingo E-Tech Electric: che prezzo!
Renault Twingo E-Tech Electric: che prezzo!
Renault annuncia la nuova vettura compatta del segmento A, che strizza l'occhio alla tradizione del modello abbinandovi una motorizzazione completamente elettrica e caratteristiche ideali per i tragitti urbani. Renault Twingo E-Tech Electric punta su abitabilità, per una lunghezza di meno di 3,8 metri, abbinata a un prezzo di lancio senza incentivi di 20.000€
Il cuore digitale di F1 a Biggin Hill: l'infrastruttura Lenovo dietro la produzione media
Il cuore digitale di F1 a Biggin Hill: l'infrastruttura Lenovo dietro la produzione media
Nel Formula 1 Technology and Media Centre di Biggin Hill, la velocità delle monoposto si trasforma in dati, immagini e decisioni in tempo reale grazie all’infrastruttura Lenovo che gestisce centinaia di terabyte ogni weekend di gara e collega 820 milioni di spettatori nel mondo
DJI Osmo Mobile 8: lo stabilizzatore per smartphone con tracking multiplo e asta telescopica
DJI Osmo Mobile 8: lo stabilizzatore per smartphone con tracking multiplo e asta telescopica
Il nuovo gimbal mobile DJI evolve il concetto di tracciamento automatico con tre modalità diverse, un modulo multifunzionale con illuminazione integrata e controlli gestuali avanzati. Nel gimbal è anche presente un'asta telescopica da 215 mm con treppiede integrato, per un prodotto completo per content creator di ogni livello
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 03-10-2007, 23:39   #41
k0nt3
Senior Member
 
Iscritto dal: Dec 2005
Messaggi: 7258
Quote:
Originariamente inviato da DioBrando Guarda i messaggi
no ha senso a prescindere dal linguaggio, sono teorie agnostiche rispetto agli strumenti utilizzati e che valgono sempre e cmq.

Altrimenti questo tipo di analisi come lo svolgi quando si tratta di software che utilizza + linguaggi di programmazione? (tanto per citare un caso)
allora dimostralo deve essere facile. prendi l'esempio di java.. scrivi una marea di codice, ma allo stesso tempo il compilatore ti da una grossa mano. secondo te è da trattare allo stesso modo di python dove per il compilatore puoi scrivere anche cose senza senso tipo dividere un intero per una stringa?
se usi linguaggi diversi in un progetto puoi fare queste analisi solo nelle parti che usano lo stesso linguaggio
Quote:
Originariamente inviato da DioBrando Guarda i messaggi
Hai dato l'esame di Ingegneria del Software 1 e 2?
ma risparmiatele certe domande, non sei certo te che mi insegni cos'è l'ingegneria del software

Quote:
Originariamente inviato da DioBrando Guarda i messaggi
e che ci vuole...pensa se fai questo ragionamento in un caso in cui dai per scontato che il garbage collector assolva il proprio ruolo mentre sei in una di quelle eccezione che devi controllare manualmente tu.
perchè il GC non dovrebbe assolvere il suo compito? e poi che problema c'è con il debug?
Quote:
Originariamente inviato da DioBrando Guarda i messaggi
Guarda uno sviluppatore che non si preoccupa della lunghezza del codice, nè per il numero di bug che (inevitabilmente) si verificano, non l'ho mai sentito.
mai detto questo. in java è inevitabile scrivere più righe di codice che in python, ma non è affatto vero che si commettono più errori

Quote:
Originariamente inviato da DioBrando Guarda i messaggi
perchè nei linguaggi che utilizzano un solo paradigma è possibile risolvere o implementare un algoritmo in un unico modo?

Mi sfugge la logica del tuo ragionamento per cui dovrebbero essere in contraddizione.
no uno può implementare gli algoritmi come gli pare, solo che nel caso di più paradigmi insieme il linguaggio perde inevitabilmente di omogeneità, e quindi aumenta la confusione. l'esempio più lampante che mi viene in mente è C++
k0nt3 è offline   Rispondi citando il messaggio o parte di esso
Old 03-10-2007, 23:48   #42
k0nt3
Senior Member
 
Iscritto dal: Dec 2005
Messaggi: 7258
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Prima quando? Riportalo, cortesemente, anche se sarà la classica eccezione che conferma la regola.
non ne ho voglia comunque in breve il fatto di poter evitare la dichiarazione delle variabili ti porta a scrivere meno codice, ma anche a commettere dei potenziali errori che altrimenti non potresti commettere. in ogni modo è difficile trovare un esempio in cui java è più "error prone" di python nonostante sia altamente banale trovare esempi in cui java richiede più codice di python
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Era un altro esempio che dimostrare che print è un'istruzione, al pari di if, ecc., per le quali NON c'è interazione fra oggetti.

Certo, è evidentissimo:
Codice:
int i = 1;
la variabile i "interagisce" con l'oggetto numero uno...
quello che avevo postato prima in python era un programma completo in cui non vi era alcuna interazione tra oggetti, mentre l'istruzione che hai postato te non è un programma completo.
la differenza è che un linguaggio che permette la creazione di programmi in cui non vi è nessuna interazione tra oggetti non si può definire puramente a oggetti
k0nt3 è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 09:16   #43
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
Quote:
Originariamente inviato da k0nt3 Guarda i messaggi
allora dimostralo deve essere facile. prendi l'esempio di java.. scrivi una marea di codice, ma allo stesso tempo il compilatore ti da una grossa mano. secondo te è da trattare allo stesso modo di python dove per il compilatore puoi scrivere anche cose senza senso tipo dividere un intero per una stringa?
E dove starebbe scritto che è una cosa senso? Quello che ancora non hai capito è che non devi trattare Python come gli altri linguaggi "tradizionali" con cui hai avuto a che fare adesso.

Python è un linguaggio puramente a oggetti, per i quali è previsto uno "scambio di messaggio" nelle loro interazioni. Questo significa che se un oggetto "risponde" al messaggio "dividi per", l'operazione è perfettamente legittima, altrimenti viene sollevata un'eccezione.

Infatti ci sono oggetti che "rispondono" correttamente: i numeri è il classico esempio, ma potrei anche prendere un insieme e definire l'operatore di divisione per generarmi una partizione, ad esempio.

Ovviamente, essendo un linguaggio dinamico, il tutto avviene a runtime e non in fase di compilazione.
Quote:
se usi linguaggi diversi in un progetto puoi fare queste analisi solo nelle parti che usano lo stesso linguaggio
Nessuno t'impedisce di calcolare il numero di bug per linee di codice di un intero progetto. Anzi, è una cosa perfettamente legittima.
Quote:
ma risparmiatele certe domande, non sei certo te che mi insegni cos'è l'ingegneria del software
Puoi sempre rispondere e dimostrare che ne hai conoscenza, no?
Quote:
perchè il GC non dovrebbe assolvere il suo compito?
Perché può anche capitare che finalizzi un oggetto in un certo momento dell'esecuzione e a causa di ciò sollevi un'eccezione (nel codice del distruttore dell'oggetto.)
Quote:
e poi che problema c'è con il debug?
Che, come ti ho già detto, per progetti non banali tante volte non è semplice farlo, nemmeno con l'aiuto di un debugger.
Quote:
mai detto questo. in java è inevitabile scrivere più righe di codice che in python, ma non è affatto vero che si commettono più errori
Se hai più linee di codice mi sembra a dir poco ovvio che hai più possibilità di avere dei bug. Ovviamente sto parlando in generale, non dei casi particolari, che esistono sempre e non dimostrano nulla.

E' il motivo per cui si è passati da linguaggi di basso/bassissimo livello, come linguaggio macchina & assembly ad altri di altissimo livello, come Python: c'è MOOOOOOLTA meno probabilità di commettere errori perché per implementare gli algoritmi nel primo caso devi scrivere tantissime linee di codice, mentre nel secondo caso ne scriverai molte meno perché hai tanti strumenti di alto livello (che ti semplificano la vita).
Quote:
no uno può implementare gli algoritmi come gli pare, solo che nel caso di più paradigmi insieme il linguaggio perde inevitabilmente di omogeneità, e quindi aumenta la confusione. l'esempio più lampante che mi viene in mente è C++
Ed è un esempio che non calza assolutamente con Python, di cui è ormai evidente non hai ancora capito niente.

Lo ripeto per l'n-esima volta: Python è un linguaggio puramente a oggetti che mette nativamente a disposizione diverse CLASSI E OGGETTI che hanno delle BEN PRECISE PROPRIETA'.

Tu come programmatore puoi usarli per risolvere i tuoi problemi: li "combinerai", li farai interagire, sfrutterai le loro caratteristiche peculiari per arrivare al tuo scopo. E' da tutto ciò che possiamo dire che lavorare con Python permette di sfruttare, o per meglio dire simulare, diversi paradigmi di programmazione.

Un esempio lampante di ciò è l'uso delle funzioni, che ci permette di parlare di programmazione funzionale (possiamo scrivere un programma come combinazioni di chiamate a funzioni).
Ebbene, le funzioni (anche quelle anonime / lambda / closure che dir si voglia) sono semplicementi degli oggetti che hanno la particolare proprietà di essere "invocati"; questo vuol dire che scrivendo Pippo e usando l'operatore di "esecuzione" (rappresentato dalle parentesi tonde, con eventuali parametri annessi) io sto spedendo un particolare messaggio al mio oggetto, che poi risponderà tornando un risultato.

Lo stesso "giochetto" lo possiamo fare con l'istanza di una classe: mi è sufficiente definire l'operatore __call__ nella classe da cui discende per renderlo "eseguibile". Questo vuol dire che se Pluto è un'istanza della classe di cui sopra, scrivendo Pluto('Ciao!') io farò uso dell'operatore () per spedire un messaggio a Pluto, con l'eventuale parametro passato.
Da ciò si vede che Pluto, che è un oggetto, si comporta come se fosse una funzione, ma qual è la differenza con la funzione Pippo prima definita? Nessuna: sono tutte e due degli oggetti, che offrono al programmatore la caratteristica di poter essere "eseguiti".

Tra l'altro questo comportamento sarebbe (parzialmente) fattibile anche in Java se permettesse di ridefinire gli operatori (che a te non piace, lo so).

E' chiaro adesso o devo aspettarmi di tornare un'altra volta sull'argomento?

Ripeto: se non conosci Python evita di lasciarti andare a dichiarazioni prive di senso. Non basta aver studiato la sintassi di un linguaggio, aver fatto qualche esercizietto e passato un esame per poter dichiarare di saperci programmare.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 09:39   #44
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
Quote:
Originariamente inviato da k0nt3 Guarda i messaggi
non ne ho voglia comunque in breve il fatto di poter evitare la dichiarazione delle variabili ti porta a scrivere meno codice, ma anche a commettere dei potenziali errori che altrimenti non potresti commettere.
Tutto qui? E' un caso particolare.
Quote:
in ogni modo è difficile trovare un esempio in cui java è più "error prone" di python nonostante sia altamente banale trovare esempi in cui java richiede più codice di python
Infatti, riallacciandomi anche al discorso di cui sopra, le considerazioni andrebbero fatte sempre sul solito numero di bug per righe di codice, che permette di astrarsi dai casi particolari che hai citato (che esisteranno sempre).

Faccio un esempio che confuta la tua citazione precedente. Il C è un linguaggio che obbliga a dichiarare le variabili da usare, e per cui quindi il caso di cui sopra non sarebbe applicabile perché il compilatore segnalebbe immediatamente il tentativo d'uso di variabili inesistenti.
Domanda: per te è più facile che i programmi Python abbiano più bug rispetto a quelli scritti in C? Io, avendo lavorato non poco con entrambi, una risposta me la so dare facilmente.

Questo a dimostrazione che bisogna analizzare globalmente il problema dei bug, e non fossilizzarsi ai singoli casi "da manuale", che di per sé non dicono proprio nulla.
Quote:
quello che avevo postato prima in python era un programma completo in cui non vi era alcuna interazione tra oggetti, mentre l'istruzione che hai postato te non è un programma completo.
Tutto qui? Ecco:
Codice:
public class SonoUnProgrammaCompletoMaSenzaOggetti {
     public static void main(String[] args) {
         int a = 1; // Non si direbbe, ma sono un oggetto. Non si direbbe, ma interagisco.
     }
 }
Adesso ci siamo, no?
Quote:
la differenza è che un linguaggio che permette la creazione di programmi in cui non vi è nessuna interazione tra oggetti non si può definire puramente a oggetti
Questa è una tua definizione suppongo, ampiamente NON condivisibile.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 10:02   #45
mad_hhatter
Senior Member
 
L'Avatar di mad_hhatter
 
Iscritto dal: Oct 2006
Messaggi: 1105
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
A parte questo, immagino che avrai usato spesso degli switch, catene di if-else, tabelle di costanti, tavole hash, ecc., che rappresentano l'universale concetto di SELEZIONE.
Concetto che in Python si traduce molto spesso nell'uso di dizionari, appunto.
il fatto che in python si usi una certa espressione non la rende automaticamente universale comunque switch e catene di if-else cerco di evitarli il più possibile visti i problemi di manutenibilità che comportano... se li uso, sono cortissimi, se diventano lunghi preferisco incapsulare la variazione e sfruttare il polimorfismo.

so che java presenta le enumeration, ma non mi sono mai trovato a doverle usare...
mad_hhatter è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 10:03   #46
k0nt3
Senior Member
 
Iscritto dal: Dec 2005
Messaggi: 7258
SonoUnProgrammaCompletoMaSenzaOggetti è una classe no?
Quote:
Originariamente inviato da cdimauro
Faccio un esempio che confuta la tua citazione precedente. Il C è un linguaggio che obbliga a dichiarare le variabili da usare, e per cui quindi il caso di cui sopra non sarebbe applicabile perché il compilatore segnalebbe immediatamente il tentativo d'uso di variabili inesistenti.
Domanda: per te è più facile che i programmi Python abbiano più bug rispetto a quelli scritti in C? Io, avendo lavorato non poco con entrambi, una risposta me la so dare facilmente.
più che confutare dimostra che ho ragione. perchè hai preso C e non java? java in media richiede un numero di righe di codice ancora maggiore del C.. dovrei concludere che è più facile trovare un bug in un programma in java piuttosto che in un programma C?
ripeto che questo confronto non ha senso tra linguaggi diversi


non è condivisibile che python non è un linguaggio a oggetti puro? ti sembra programmazione OO questa?
Codice:
print "hello"
k0nt3 è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 10:13   #47
mad_hhatter
Senior Member
 
L'Avatar di mad_hhatter
 
Iscritto dal: Oct 2006
Messaggi: 1105
Quote:
Originariamente inviato da DioBrando Guarda i messaggi
perchè non ci infiliamo anche l'ereditarietà singola, il multithreading e altre nozioni già che ci siamo?

No perchè se dobbiamo fare un minestrone di "cose da sapere" al primo Hello world che l'utente (che vuole imparare a programmare) si trova a fare, tanto vale farlo bene no? (Anzi studiamoci direttamente tutta la teoria e poi applichiamola...e con un linguaggio X perchè tanto in fin dei conti non conta molto questa scelta )

d'altra parte è logico che per te sia un approccio corretto, visto che è normale, sempre secondo te, studiare Fondamenti I come primo corso universitario...


Con Java scrivi:

Codice:
 class HelloWorld {
          public static void main (String[] args) {
             System.out.println("Hello World");
             }
          }
Legenda:
S = studente
P = professore

S: prof che cos'è class?
P: "è un argomento che tratteremo + avanti non ti preoccupare, intanto ricordati per un motivo di leggibilità e di non confusione che il nome della classe che sceglierai dovrà avere la prima lettera della parola in maiuscolo"
S: E public?
P: anche quello lo vedremo + avanti, intanto ricordati di copiare, dopo la linea in cui definisci la classe, tutta quella riga
S: quindi le parole "public static void main (String[] args)" ci verranno spiegati + avanti nel programma?
P: sì nella prossime lezioni vedremo i tipi di dato, poi le strutture di controllo...


Questo è quello che succede in un corso "normale" di programmazione 1 in cui si scelga Java come linguaggio.
Alla faccia della didattica: uso una decina di parole riservate e per ovvii motivi mi trovo a spiegarne una sola.
un corso che si chiama FONDAMENTI dove lo inseriresti?
comunque un corso di informatica per studenti di ingegneria informatica cosa dovrebbe insegnare? quante ore di lezione secondo te dovrebbero passare prima di iniziare a introdurre i concetti di un linguaggio OO? guarda che tra il non spiegare nulla e lo spiegare tutto dall'inizio alla fine esistono molti livelli intermedi di approfondimento che possono dare una visione d'insieme lasciando gli approfondimenti ad un momento successivo... non mi pare che accennare al concetto di classe, oggetto, package, metodo sia traumatico... non capisco questo tuo stupore.

io trovo che un approccio serio alla didattica sia: ti do' la definizione degli strumenti che usi e da qui andiamo avanti...

quando hai mostrato il

print "Hello"

che comprensione ne traggono gli studenti al di là del "ah... bello". quanto dura questa fase in cui vengono mostrate istruzioni specifiche invece di dare una visione generale e di alto livello che di sicuro è molto più utile ai fini dell'apprendimento (almeno quello serio)?
mad_hhatter è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 10:14   #48
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
Quote:
Originariamente inviato da mad_hhatter Guarda i messaggi
il fatto che in python si usi una certa espressione non la rende automaticamente universale
No, ma si presta a risolvere parecchi problemi (anche per questo tanti linguaggi moderni lo integrano nativamente, o almeno nella libreria standard), inoltre anziché aggiungere complessità al linguaggio introducendo nuove istruzioni (ad esempio lo switch, che manca del tutto in Python e di cui non si sente il bisogno perché esistono delle validissime alternative, appunto), s'è preferito introdurre un nuovo e molto utile tipo di dato.
Quote:
comunque switch e catene di if-else cerco di evitarli il più possibile visti i problemi di manutenibilità che comportano... se li uso, sono cortissimi, se diventano lunghi preferisco incapsulare la variazione e sfruttare il polimorfismo.
Anche in Java esistono le "mappe": servono proprio per questi problemi, e sono l'equivalente dei dizionari di Python.

Scomodare incapsulamento e polimorfismo ci può anche stare, ma dipende strettamente dal problema.
Quote:
so che java presenta le enumeration, ma non mi sono mai trovato a doverle usare...
Servono ad altro, però.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 10:36   #49
mad_hhatter
Senior Member
 
L'Avatar di mad_hhatter
 
Iscritto dal: Oct 2006
Messaggi: 1105
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
No, ma si presta a risolvere parecchi problemi (anche per questo tanti linguaggi moderni lo integrano nativamente, o almeno nella libreria standard), inoltre anziché aggiungere complessità al linguaggio introducendo nuove istruzioni (ad esempio lo switch, che manca del tutto in Python e di cui non si sente il bisogno perché esistono delle validissime alternative, appunto), s'è preferito introdurre un nuovo e molto utile tipo di dato.

Anche in Java esistono le "mappe": servono proprio per questi problemi, e sono l'equivalente dei dizionari di Python.
non ho detto che sono inutili, ho detto che in java sono nella libreria standard e che ci sono strutture per tutti i gusti... e che il fatto che il linguaggio offra strutture dati nativamente o tramite libreria standard mi pare del tutto indifferente... giuro, non vedo la differenza

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Scomodare incapsulamento e polimorfismo ci può anche stare, ma dipende strettamente dal problema.
appunto, dipende da cosa ti serve... è quello che ho detto nel mio post precedente.
mad_hhatter è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 10:41   #50
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
Quote:
Originariamente inviato da k0nt3 Guarda i messaggi
SonoUnProgrammaCompletoMaSenzaOggetti è una classe no?
Mi sfugge la presenza degli oggetti, che addirittura dovrebbero interagire, per RISOLVERE IL PROBLEMA (non basta, infatti, usare una classe, che in questo caso fa la parte del mero contenitore di istruzioni).
Quote:
più che confutare dimostra che ho ragione. perchè hai preso C e non java? java in media richiede un numero di righe di codice ancora maggiore del C.. dovrei concludere che è più facile trovare un bug in un programma in java piuttosto che in un programma C?
L'ho preso perché il C è un linguaggio che corrisponde al quadro che hai delineato, ma i cui programmi sono altamente soggetti a bug. Questo per dimostrare che prendere una precisa caratteristica di un linguaggio per valutare la predisposizione a commettere errori non ha senso.

Quanto alla quantità di righe di codice, per progetti non banali in Java se ne scrivono meno.
Quote:
ripeto che questo confronto non ha senso tra linguaggi diversi
Ha senso per un intero progetto, infatti, come avevo già scritto.
Quote:
non è condivisibile che python non è un linguaggio a oggetti puro? ti sembra programmazione OO questa?
Codice:
print "hello"
Ne avevamo già parlato: stai facendo uso di un'ISTRUZIONE. Per caso esistono dei linguaggi che non ne hanno?
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 10:49   #51
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
Quote:
Originariamente inviato da mad_hhatter Guarda i messaggi
non ho detto che sono inutili, ho detto che in java sono nella libreria standard e che ci sono strutture per tutti i gusti... e che il fatto che il linguaggio offra strutture dati nativamente o tramite libreria standard mi pare del tutto indifferente... giuro, non vedo la differenza
La differenza è che in Python basta scrivere roba così:

a = {'Qui' : 1, 'Quo' : 2, 'Qua' : 3}

e hai già tutto. Con una libreria è UN TANTINO più complicato e meno immediato, no (e devi conoscere anche il concetto di libreria)?

Se i dizionari/mappa/hash sono ormai presenti in tanti linguaggi "nativamente", è proprio perché si tratta di strutture molto utili e comunemente usate, che permettono di risolvere in maniera semplice ed elegante tanti problemi.

Tu non ci vedi differenza, ma anche didatticamente le due cose sono ben diverse (e con ciò mi riallaccio anche a quello che aveva scritto in precedenza DioBrando sull'argomento).
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 11:36   #52
mad_hhatter
Senior Member
 
L'Avatar di mad_hhatter
 
Iscritto dal: Oct 2006
Messaggi: 1105
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
La differenza è che in Python basta scrivere roba così:

a = {'Qui' : 1, 'Quo' : 2, 'Qua' : 3}

e hai già tutto. Con una libreria è UN TANTINO più complicato e meno immediato, no (e devi conoscere anche il concetto di libreria)?

Se i dizionari/mappa/hash sono ormai presenti in tanti linguaggi "nativamente", è proprio perché si tratta di strutture molto utili e comunemente usate, che permettono di risolvere in maniera semplice ed elegante tanti problemi.

Tu non ci vedi differenza, ma anche didatticamente le due cose sono ben diverse (e con ciò mi riallaccio anche a quello che aveva scritto in precedenza DioBrando sull'argomento).
guarda, sarà comodo, niente da dire, ma non mi sono mai trovato a rimpiangerlo in java...
mad_hhatter è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 14:58   #53
D3stroyer
Senior Member
 
L'Avatar di D3stroyer
 
Iscritto dal: Dec 2003
Messaggi: 3567
scusate, vorrei fare una semplice domanda che mi sta turbando..e creare un topic per una risposta alla "si o no" non mi pare utile.

La domdanda è:

"tutto ciò che creo con c++, posso crearlo identico anche con java? E viceversa?"
__________________
Intel Core 2 Duo E6300 @ 3.00GHz / Gigabyte P965 DS4 / 2xTEAM GROUP TVDD1024M800 / Gainward GTX460 GS 1GB
Barracuda 7200.11 SataII 500Gb + Maxtor ATA320Gb + Hitachi SataII 320Gb / Enermax Noisetaker 495W
Il miglior topic di sempre
D3stroyer è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 15:08   #54
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
Non sempre, ma per la stragrande maggioranza delle cose sì (e vale anche per Python e altri linguaggi dotati di virtual machine).

In sostanza viene esclusa la programmazione di sistema.

In realtà sono stati scritti anche dei sistemi operativi in Java, ma hanno bisogno di una virtual machine per girare.

A onor del vero anche i s.o. per eseguire lo startup hanno bisogno di un loader, anche minimale, ma scritto in assembly, che viene richiamato dal BIOS.
Quindi nemmeno linguaggi come C, C++, Pascal, Modula-2, ecc. (i più comunemente usati per scrivere s.o.) sono del tutto "indipendenti".

Accettando di allargare il concetto di loader, in teoria si potrebbe usare qualunque linguaggio di programmazione per scrivere un s.o., ma mi fermo qui perché rischiamo di impantanarci in discorsi troppo complicati.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 15:17   #55
variabilepippo
Senior Member
 
L'Avatar di variabilepippo
 
Iscritto dal: Mar 2007
Messaggi: 1792
Quote:
tutto ciò che creo con c++, posso crearlo identico anche con java? E viceversa?
Intendi in Java "puro"? In tal caso la risposta è negativa, tutta la programmazione "low-level" o non comunque non portabile Java deve delegarla a metodi scritti in codice nativo (vedi JNI).
variabilepippo è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 15:17   #56
D3stroyer
Senior Member
 
L'Avatar di D3stroyer
 
Iscritto dal: Dec 2003
Messaggi: 3567
oke mi basta, ti ringrazio.
__________________
Intel Core 2 Duo E6300 @ 3.00GHz / Gigabyte P965 DS4 / 2xTEAM GROUP TVDD1024M800 / Gainward GTX460 GS 1GB
Barracuda 7200.11 SataII 500Gb + Maxtor ATA320Gb + Hitachi SataII 320Gb / Enermax Noisetaker 495W
Il miglior topic di sempre
D3stroyer è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 15:52   #57
DioBrando
Senior Member
 
Iscritto dal: Jan 2003
Città: Milano - Udine
Messaggi: 9418
A me sembra che in queste discussioni stia un po' sfuggendo il quadro di insieme.
Ed il quadro di insieme ci dice che Java è diventato obsoleto e superato in diversi campi applicativi.

Negli anni 90, soprattutto la prima metà, è stato direi rivoluzionario con i suoi concetti, nella capacità di Sun di scorgere le potenzialità del World Wide Web prima degli altri e di approfittare del suo boom per veicolare la piattaforma Java nella quasi totalità dei computer (desktop) in giro per il mondo.
E forse è stato talmente tutto facile, senza reali competitor che potessero dare fastidio (la Microsoft ci ha provato con la celebre contesa della JVM non pienamente compatibile con gli standard Sun...ironia della sorte, la cessazione dello sviluppo della versione interna è stata la goccia che ha fatto traboccare il vaso e dato inizio al progetto .NET), che alla Sun si sono adagiati sugli allori, non vedendo come il Web del nuovo millennio ma soprattutto negli ultimi 3-4 anni stesse cambiando volto, con la definizione e proliferazione di nuovi standard o pseudo tali, con il cambiamento delle abitudini dei fruitori del Web (che sono diventati agenti attivi e non + solo passivi) e dei servizi che vi si appoggiano.

Si sono talmente seduti, che mentre nuovi linguaggi e metodologie di sviluppo prendevano piede (.NET, PHP, Python, Ruby...), il modello di Java e la sua architettura sono rimaste fondamentalmente sempre quelle, da quando Gosling e soci pubblicarono le prime specifiche.

E ora il ritardo tecnologico accumulato è evidente. Talmente evidente che negli ultimi mesi, dopo anni di silenzio, abbiamo assistito alla presentazione di
- la convergenza verso l'Open Source
- JAX-WS 2.0, JAXB 2.0, JAXP e STAX (tutte specifiche volte a colmare le "lacune" in ambito AJAX)
- JavaFX: linguaggio di scripting server-side
- Quaere, l'alter-ego di LinQ (progetto NET che ha ormai quasi 3 anni), che quindi dovrebbe permettere la modellazione OO di accesso ad una base di dati



Si è parlato anche di coerenza a proposito di Java.

Beh proviamo a vedere nel dettaglio alcuni casi in cui la coerenza è davvero lampante.

Cominciamo per esempio dalla (annosa) questione dell'ereditarietà multipla. All'inizio, sotto la spinta delle pompose dichiarazioni degli ingegneri Sun per cui la morale era "vi abbiamo dato un C++ privo dei suoi storici difetti", la scelta era stata +ttosto chiara: eliminarla alla radice, in modo tale da eliminare le situazioni in cui i benefici sono minori rispetto alle possibili situazioni di ambiguità (esempio tipico, il "diamond problem").
Chiaro, lineare, coerente con i principi di progettazione seguiti per edificare Java.
(non sto qui a discutere sul fatto che molti teorici affermano come un modello OO si possa definire compiuto solo se si utilizzi anche il concetto di ereditarietà multipla...le correnti sono diverse e spesso è difficile arrivare ad un'unica posizione di sintesi)
Poi però, si decide di farla rientra dal seminterrato, con l'uso delle interfacce; e questa scelta comporta due ordini di problemi, il primo, che l'ereditarietà multipla in questo modo, viene supportata solo parzialmente, il secondo, che vi è una frattura tra il modello concettuale fino a quel momento proposto e quello che in realtà è possibile realizzare con gli strumenti forniti dal linguaggio.

A questo punto la comunità si divide e chiede maggior chiarezza a proposito. La Sun continua a perseguire la stessa strada, se mi consentite il termine "ambigua". Questo fino all'avvento di Mustang (Java 6) in cui una delle novità sembrava potesse essere proprio questa: niente da fare.
Ora si parla di una prossima release e io sono curioso di vedere nono solo il quando ma soprattutto il COME verrà implementata, dato che stravolgerebbe il modello di gerarchie utilizzato fino ad adesso.
E quindi vi sarebbe la forzata necessità di ripensare dal profondo l'architettura del linguaggio, oltre a parte di una delle strutture semantiche utilizzate.


Un altro esempio di coerenza.
Quando ancora Sun era un ago della bilancia nel settore informatico sia HW che SW ed i suoi settori di R&D lavoravano a pieno regime, l'ipotesi che Sun potesse rilasciare con licenza Open Source, Java era impensabile.
Non solo era impensabile, ma Sun stessa era stata molto esplicita sulla necessità di mantenere le redini dello sviluppo del core e all'inizio anche dei progetti satellite correlati.
In meno di un anno, cambia tutto, Java diventa Open Source, con l'ambiguità di rilasciare le versioni Business attraverso le tradizionali licenze commerciale e di permettere però al tempo stesso fork di varia natura.

Il motivo di questo cambio repentino di vedute?
Opportunità.
L'hype spropositato che si è generato in questi anni e che ha dato vita a falsi miti ( del calibro de "Java è portabile", "Java è multipiattaforma", "Java ha rimosso i difetti di C++ e quindi è virtualmente immune da difetti", oppure "la decadenza prestazionale, seppur sia un linguaggio interpretato, è ininfluente, rispetto ai benefici"), è scemato e gli sviluppatori, sia freelance che in seno alle aziende, hanno fatto scelte oculate che tenessero conto del rapporto costi/benefici, nel caso di un utilizzo della piattaforma Java.
La Sun quindi ha visto nella transizione verso la GPL la possibilità di usufruire della comunità Open Source affinchè venisse dato nuovo lustro e una nuova spinta di interesse, in grado di contrastare le carenze tecnologiche di cui ho parlato poc'anzi.


Il problema, come sempre in questi casi, è che quando una transizione viene effettuata in fretta e furia, c'è il rischio che i cambiamenti radicali che questa comporta, non vengano assimilati e che il linguaggio non sia sviluppato + secondo una logica unitaria, ma a seconda di "come tira il vento". (come appunto l'estensione di funzionalità tramite la semplice aggiunta di nuove librerie, per esempio nel caso dei dizionari)

Ed è il motivo per cui grandi progetti Open Source, per quanto pubblicizzati, si dimostrino inferiori ad altri, magari di + basso profilo, ma con dinamiche di progettazione e evoluzione ormai consolidate nel tempo (chissà perchè mi viene sempre in mente l'esempio di MySQL VS PostGRES).
DioBrando è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 19:05   #58
mindwings
Senior Member
 
L'Avatar di mindwings
 
Iscritto dal: Dec 2005
Messaggi: 1278
Quote:
Originariamente inviato da PGI-Bis Guarda i messaggi
... cut
A quale elemento della prospettiva procedurale corrisponderebbe mai la classe?
... cut
Al record ( Pascal )
Classe == Astrazione Dati (oltre che all' astrazione funzionale)
che nel C è assente bisogna arrivare alla programmazione OOP per avere la benedetta astrazione dati .
Edit: Aggiungo che Wirth qualcosa l'aveva già intuita ma in tempi non maturi[congettura mia] (riguardante l'OOP).
il titolo di una suo opera famosa è "Algorithms + Data Structures = Programs" . L'astrazione funzionale permette di ampliare l'insieme dei modi di operare sui dati cioè gli operatori sui tipi di dati già disponibili ; mentre l'astrazione dei dati permette di ampliare i tipi di dati disponibili attraverso l'introduzione sia di nuovi tipi di dato che di nuovi operatori (metodi).[completa l'opera insomma ]

Imho per imparare a programmare è necessario partire dalla OOP dato che è un evoluzione naturale della procedural-way.
Io sono sempre per iniziare con Java e un buon manuale
__________________
Non esistono grandi uomini, solo grandi ambizioni , realizzate da qualcuno che si è alzato dalla sedia per realizzarle!

Ultima modifica di mindwings : 04-10-2007 alle 19:26.
mindwings è offline   Rispondi citando il messaggio o parte di esso
Old 04-10-2007, 20:08   #59
PGI-Bis
Senior Member
 
L'Avatar di PGI-Bis
 
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
Il record non è un elemento della prospettiva procedurale. Almeno non secondo la definizione di Nygaard.
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!
PGI-Bis è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2007, 15:38   #60
DioBrando
Senior Member
 
Iscritto dal: Jan 2003
Città: Milano - Udine
Messaggi: 9418
Quote:
Originariamente inviato da mad_hhatter Guarda i messaggi
un corso che si chiama FONDAMENTI dove lo inseriresti?
Partiamo dal presupposto che , per quanto tu lo scriva un maiuscolo, il nome del corso non è sempre un'indicazione precisa di quel che poi studierai nel dettaglio.
Se io dico per esempio Interazione Uomo-Macchina, si intuisce vagamente quale sarà il ramo trattato ma nello specifico non puoi sapere cosa ti spiegherà un professore...questo perchè la branca è talmente ampia e tocca così tanti ambiti scientifici per cui le ore di lezione non potranno mai esaurire l'argomento.
Le problematiche verranno affrontate secondo quale approccio? Psico-cognitivo, socio-culturale, tecnologico? Oppure tutti e 3? Se sì a quale dei 3 verrà dato + spazio?

Fatta questa precisazione, io non sono un docente e quindi non sono in grado di pianificare un intero corso di laurea (che poi dipende anche dalla scansione decisa a tavolino dall'Università: trimestrale, quadrimestrale o semestrale?).
Ma se c'è una cosa di cui sono sicuro è che non lo inserirei mai come primo esame di laurea; questo perchè in Fondamenti 1 vengono trattati argomenti come i modelli deterministici e non deterministici, le classi di complessità, il formalismo dei linguaggi.
Argomenti che non è possibile affrontare se prima non si dispone di una base solida di tipo logico-matematico.

E dato che l'Università si prefigge di insegnare e di formare persone indipendentemente dagli studi che queste hanno compiuto in precedenza, è giusto che si svolgano prima i corsi (e gli esami) che costruiscono la base di cui sopra.
Quindi, secondo me, prima di Fondamenti devono venire le matematiche fondamentali (analisi e matematica discreta), logica (se il corso di laurea la prevede), programmazione 1, architettura 1.
Prima o al massimo in contemporanea Algoritmi e Strutture Dati.

Quote:
comunque un corso di informatica per studenti di ingegneria informatica cosa dovrebbe insegnare?
quello che si insegna in qualsiasi corso di ingegneria informatica?

Quote:
quante ore di lezione secondo te dovrebbero passare prima di iniziare a introdurre i concetti di un linguaggio OO?
l'introduzione può avvenire fin da subito.
Ma un conto è la definizione e la presentazione, un altro conto è spiegare come questi concetti vengono utilizzati.

E a questo stadio non ci si arriva se prima non si studiano i mattoni fondamentali che ogni linguaggio utilizza e che sono le basi della programmazione, indipendentemente dal paradigma utilizzato.

Quote:
guarda che tra il non spiegare nulla e lo spiegare tutto dall'inizio alla fine esistono molti livelli intermedi di approfondimento che possono dare una visione d'insieme lasciando gli approfondimenti ad un momento successivo... non mi pare che accennare al concetto di classe, oggetto, package, metodo sia traumatico... non capisco questo tuo stupore.
io trovo che un approccio serio alla didattica sia: ti do' la definizione degli strumenti che usi e da qui andiamo avanti...
Francamente, da quando hai tirato fuori per primo l'argomento (annotazione che personalmente ho trovato superflua perchè nessuno si è mai sognato di dire o di pensare che la pratica possa sostituire la teoria, quando si tratta di imparare a programmare...ma vabbè), ovvero dall'inizio dell'altro thread, ancora non si è capito quale sia secondo te l'approccio corretto.

Hai cominciato col dire che prima và insegnata la teoria e poi l'applicazione, che insieme alla scelta del linguaggio, è una fase secondaria.
Quando ti è stato fatto notare che questo metodo non funziona perchè uno studente dopo che si trova imbottito di nozioni senza applicarle, poi semplicemente perde interesse nella programmazione, e che il metodo + sensato è quello di procedere passo passo con piccoli esempi e la spiegazione teorica, hai detto che "era quello che intendevi".
Al che, ti ho risposto che se era questo il tuo pensiero, era una contraddizione: non potevi infatti affermare che la scelta del linguaggio fosse secondaria, perchè non sarebbe possibile poi far vedere come le strutture sintattiche interagiscano tra loro, senza scrivere del codice (in un X linguaggio).

Da lì silenzio.

Onde evitare ulteriori voli pindarici e formule general generiche e passando invece al concreto, che intendi con "definizione degli strumenti?"
Quali sono le nozioni che prima solo accenneresti e poi approfondiresti? E che significa per te accennare?
In parole povere, come costruiresti un corso di programmazione 1?

Quote:
quando hai mostrato il

print "Hello"

che comprensione ne traggono gli studenti al di là del "ah... bello". quanto dura questa fase in cui vengono mostrate istruzioni specifiche invece di dare una visione generale e di alto livello che di sicuro è molto più utile ai fini dell'apprendimento (almeno quello serio)?
Non serve costruire un teorema e un percorso didattico (per altro io ho già espresso ampiamente quale sia la mia idea in proposito e come dovrebbe avvenire almeno all'inizio) su un semplicissimo stralcio di codice, il primo che di solito ogni studente di programmazione si trova a scrivere in vita sua.

Il confronto tra i due "Hello World" era mirato a far vedere come, mentre in Python, ci si può concentrare maggiormente sulla parte algoritmica perchè il linguaggio è sintetico ma ricco dal punto di vista espressivo, con Java invece, un principiante si trova a dover utilizzare PER FORZA costrutti di cui all'inizio non potrà capire lo scopo nè il come interagiscano tra loro.

Avrà un quadro generale di cosa sia la POO, conoscerà la definizione di classe, ma non sarà in grado di capire come si utilizza, come si istanzia, di cosa si compone, perchè gli mancano appunto le basi.

Quindi qual'è il senso di imbottire di concetti uno studente, se poi l'applicazione pratica seguirà una progressione differente?
Per me nessuno.


P.S.: non sapevo ci fosse anche un tipo di apprendimento poco serio a questo livello.
Dato che la spiegazione di cos'è un if non rientra necessariamente in un quadro di visione + ampio, ma può essere vista come la spiegazione di una semplice istruzione, anche questo secondo te è "apprendimento non serio"?
DioBrando è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Renault Twingo E-Tech Electric: che prezzo! Renault Twingo E-Tech Electric: che prezzo!
Il cuore digitale di F1 a Biggin Hill: l'infrastruttura Lenovo dietro la produzione media Il cuore digitale di F1 a Biggin Hill: l'infrast...
DJI Osmo Mobile 8: lo stabilizzatore per smartphone con tracking multiplo e asta telescopica DJI Osmo Mobile 8: lo stabilizzatore per smartph...
Recensione Pura 80 Pro: HUAWEI torna a stupire con foto spettacolari e ricarica superveloce Recensione Pura 80 Pro: HUAWEI torna a stupire c...
Opera Neon: il browser AI agentico di nuova generazione Opera Neon: il browser AI agentico di nuova gene...
Microlino, simbolo italiano della mobili...
Apple disattiverà la sincronizzaz...
Google lancia l'allarme: attenzione ai m...
Primo test drive con Leapmotor B10: le c...
'Non può essere un robot': l'uman...
Monopattino elettrico Segway Ninebot Max...
Syberia Remastered è disponibile:...
Sony scopre che tutti i modelli AI hanno...
Amazon nasconde un -15% su 'Seconda Mano...
Due occasioni Apple su Amazon: iPhone 16...
Verso la fine della TV tradizionale? I g...
Cassa JBL a 39€, portatili, smartphone, ...
Cometa interstellare 3I/ATLAS: la sonda ...
Jensen Huang e Bill Dally di NVIDIA prem...
Il futuro della birra è green: H...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 17:16.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Served by www3v