continuazione da "imparare a programmare"

[mad_hhatter]

Originariamente inviato da k0nt3

continuo a pensare che quello che state facendo sia inutile.. non esistono criteri oggettivi e questo vale per python come per java come per C
uno può consigliare in base alle proprie esperienze personali, ma non in base a considerazioni oggettive.
anche se fate una tabella con il confronto delle caratteristiche a quel punto dovreste stabilire se una data caratteristica è bene o male. in pratica non ci si salva più

visto anche il penultimo post di cdimauro io lascio... qui si continua a voler far passare per considerazioni oggettive opinioni ed esperienze personali...

esempio : "Non adesso, ma il concetto di lista e dizionario si affrontano dopo aver trattato i tipi numerici, in virgola mobile e le stringhe."

uno ha seguito questo percorso, quindi questo è l'unico percorso seguibile

non c'è spazio per una discussione oggettiva, è inutile

[cdimauro]

Originariamente inviato da mad_hhatter

iio francamente sono sfinito da queste discussioni: finiamo sempre per tirar dentro di tutto credo che anche cdimauro sia d'accordo

Io sono disponibile a continuare.

[cdimauro]

Originariamente inviato da mad_hhatter

visto anche il penultimo post di cdimauro io lascio... qui si continua a voler far passare per considerazioni oggettive opinioni ed esperienze personali...

esempio : "Non adesso, ma il concetto di lista e dizionario si affrontano dopo aver trattato i tipi numerici, in virgola mobile e le stringhe."

uno ha seguito questo percorso, quindi questo è l'unico percorso seguibile

non c'è spazio per una discussione oggettiva, è inutile

Cosa ci vedi di poco oggettivo? Hai mai avuto l'esigenza di memorizzare una sequenza di dati, anziché soltanto uno? Secondo te un concetto del genere viene prima o dopo quello di libreria.

In Java si chiamano array, mentre in Python liste.

Eppure per te non è oggettivo il fatto che io affermi che dovrebbero essere trattati prima delle librerie.

[mad_hhatter]

gli array si, le liste no... in java sono due cose leggermente diverse.

stando a quello di cui parlavi tu il dizionario è una struttura non necessariamente primaria... l'array si, sono d'accordo

ma già parlando di array si introduce il concetto di reference e di oggetto, e da qui il passo alla libreria è brevissimo

[cdimauro]

Originariamente inviato da mad_hhatter

gli array si, le liste no... in java sono due cose leggermente diverse.

In Python sono la stessa cosa, per cui quando avrai l'esigenza di memorizzare più dati nello stesso contenitore, le dovrai studiare.

stando a quello di cui parlavi tu il dizionario è una struttura non necessariamente primaria...

A giudicare dall'intenso uso che se ne fa da tempo nei vari linguaggi di programmazione, direi proprio di sì.

Sono tanti i linguaggi che lo mettono a disposizione nativamente, infatti.

l'array si, sono d'accordo

Per la mia esperienza anche i dizionari sono ugualmente importanti.

ma già parlando di array si introduce il concetto di reference e di oggetto, e da qui il passo alla libreria è brevissimo

Non vedo cosa c'entrino le reference con le librerie.

Per gli oggetti, beh, in Python sono tutti oggetti...

[mad_hhatter]

Originariamente inviato da cdimauro

Per la mia esperienza anche i dizionari sono ugualmente importanti.

Non vedo cosa c'entrino le reference con le librerie.

i dizionari hanno la stessa importanze di molte altre strutture di dati. la tua esperienza non è un parametro di valutazione: io i dizionari mi trovo a usarli di rado per esempio, ma questo non significa niente.

reference e libreria non c'entrano niente... quello che ho scritto è che una volta che si è appreso cos'è un oggetto si inizia a spulciare la libreria alla ricerca delle strutture dati che ci servono invece che reimplementarle da zero...

[mad_hhatter]

Originariamente inviato da cdimauro

Hai mai avuto l'esigenza di memorizzare una sequenza di dati, anziché soltanto uno? Secondo te un concetto del genere viene prima o dopo quello di libreria.

io quando ho iniziato con java prima ancora di sapere cos'era un tipo primitivo ho scritto l'hello word... per stampare ho scritto system.out.println

così i primi concetti appresi sono stati:
classe e oggetto
package
import
membro statico
metodo

solo dopo sono venuti i numeri e gli array...
per un linguaggio OO non mi pare un percorso assurdo

[PGI-Bis]

Mi tolgo solo la curiosità di chiedere a chi ha definito baggianata il fatto che Java supporti una ed una sola prospettiva (quella orientata agli oggetti) di scrivere un programma strutturato in Java.

E faccio in anticipo la domanda che segue all'esempio che sarà scritto: a quale elemento della programmazione strutturata corrisponderebbe la classe?

Volendo si può anche scegliere di scriverne uno funzionale o imperativo. Resta comunque la domanda: a quale elemento della prospettiva funzionale corrisponderebbe mai la classe? A quale elemento della prospettiva procedurale corrisponderebbe mai la classe?

[cdimauro]

Originariamente inviato da mad_hhatter

i dizionari hanno la stessa importanze di molte altre strutture di dati.

Sono oggetti molto conosciuti e usati nel campo dell'informatica. Nella letteratura li trovi chiamati "array sparsi", ma il concetto è molto più generale (ne parlo meglio dopo).

la tua esperienza non è un parametro di valutazione: io i dizionari mi trovo a usarli di rado per esempio, ma questo non significa niente.

Ho realizzato tante applicazioni in Python e nella stragrande maggioranza almeno un dizionario l'ho usato.

E io non amo usare cose delle cose soltanto perché ci sono: le uso in base al problema che devo risolvere.

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.

Quindi come vedi non puoi dire che li hai usati poche volte: semplicemente hai reso l'operazione di selezione in modo diverso.

reference e libreria non c'entrano niente... quello che ho scritto è che una volta che si è appreso cos'è un oggetto si inizia a spulciare la libreria alla ricerca delle strutture dati che ci servono invece che reimplementarle da zero...

Questo lo farai dopo che avrai imparato i mattoncini di base.

Originariamente inviato da mad_hhatter

io quando ho iniziato con java prima ancora di sapere cos'era un tipo primitivo ho scritto l'hello word... per stampare ho scritto system.out.println

così i primi concetti appresi sono stati:
classe e oggetto
package
import
membro statico
metodo

solo dopo sono venuti i numeri e gli array...
per un linguaggio OO non mi pare un percorso assurdo

A me è bastato questo:

print 'Hello, world!'

e ho raggiunto immediatamente l'obiettivo col minimo sforzo e, ma tu guarda un po', col massimo della leggibilità.

Quanto a ciò di cui stavamo parlando, resta ancora in piedi il concetto che ho espresso: avere a che fare con sequenze di dati e strumenti di selezione è cosa comunissima nella programmazione, e Python e te li offre in maniera estremamente flessibile. Il tutto senza andare, appunto, a scomodare alcuna libreria (a proposito, sempre per il discorso dell'omogeneità di cui si parlava prima, in Python anche queste sono... oggetti ).

[cdimauro]

Originariamente inviato da k0nt3

sarebbe stato interessante discutere sulla leggibilità dei blocchi..

Basta prendere un algoritmo scritto in pseudocodice e guardare com'è fatto.

o sulla disomogeneità della sintassi python..

Questa me la dovresti spiegare.

comunque io ho usato python e quindi so di cosa parlo. lo "sporcarsi le mani" era più riferito al fatto che sembra che più è alto il livello del linguaggio e più è meglio per iniziare. nessuno sa qual'è la strada corretta, per cui escludere delle strade a priori è senz'altro sbagliato.

Basta confrontare il sorgente di un'applicazione Python e la fila di opcode di un eseguibile in linguaggio macchina per rispondere alla tua domanda.

senti è inutile continuare a parlare di aria.. io ti ho fornito un esempio, sei in grado di fare altrettanto te?
al massimo si potrebbe teorizzare che un programma scritto in un certo linguaggio lungo 6 righe di codice ha meno probabilità di contenere bug di un altro programma scritto nello stesso linguaggio con più righe di codice. ma confrontare due programmi scritti in due linguaggi diversi ci dice molto poco... se non nulla.

Non devi convincere noi: vaglielo a dire a chi ha tirato fuori la metrica dei bug per numero di codice. La letteratura informatica è piena di riferimenti a questa metrica, che è fra le più usate.

forse perchè non era una risposta all'osservazione di cesare
lasciamo perdere sta faccenda delle eccezioni, per me a uno che inizia non danno nessun aiuto. nel senso che imparare a usare un debugger è buona cosa comunque.

E partiamo anche col linguaggio macchina allora.

Comunque su questo ti ha risposto in maniera impeccabile marco.r, con cui mi ritrovo pienamente.

se poi parliamo di SEMPLICITA' mi dispiace ma con python non ci siamo.. troppi modi per fare la stessa cosa..

Ma che stai a dire?!? Guarda che ti stai confondendo con PERL e Ruby.

Se c'è una cosa che a cui si tiene particolarmente in Python è proprio quella di offrire (possibilmente) un solo modo per fare la stessa cosa: è proprio nel DNA del linguaggio e il pensiero di fisso di chi l'ha creato e di chi lo sostiene.

Guarda qui cosa succede se scrivi "import this" (senza virgolette) e premi invio nell'interprete Python:

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

E ancora, qui http://www.python.org/dev/peps/pep-3100/ si parla del futuro Python 3.0 che sarà un consistente rimaneggiamento del linguaggio. Da notare l'obiettivo fondamentale:

General goals

A general goal is to reduce feature duplication by removing old ways of doing things. A general principle of the design will be that one obvious way of doing something is enough.

Che poi è l'esatto opposto di PERL e di Ruby.

Quindi fammi il favore: se di Python sai poco e niente, evita di lanciarti in affermazioni suicide che cozzano violentamente con la FILOSOFIA di base di questo linguaggio.

I pythonisti sono talmente fissati che non si fanno nemmeno problemi a rinunciare alla compatibilità col passato pur di avere un linguaggio "omogeneo" e con una solida filosofia, ed è quello che avverrà appunto con Python 3.0.
In particolare, http://www.python.org/dev/peps/pep-3...and-transition :

"Python 3.0 will break backwards compatibility with Python 2.x."

Una cosa che non vedrai con gli altri linguaggi, che pur di mantenere la compatibilità col passato diventano dai pachidermi che inglobano tutto.

troppi paradigmi insieme.

E' un bene: c'è maggior espressività. E tra l'altro pure Java ha imboccato un processo di "inglobamento" di funzionalità prese in prestito da altri linguaggi che offrono paradigmi diversi da quelli offerti da Java (ad esempio le closure che tanto piacciano a PGI-Bis sono prese da LISP).

banalmente se vuoi iniziare dalla programmazione strutturata non inizi da java. pessima scelta quella far finta che un linguaggio a oggetti sia un linguaggio procedurale.

Mica è soltanto a oggetti...

ma quali titoli nobiliari.. non mi interessa dirti quale esame era o cosa faccio nella mia vita. sta di fatto che in un esame ho affrontato l'argomento python e visto che è andato bene posso dire che lo conosco.

Certo, lo conosci così da bene da confonderlo con linguaggi completamente diversi.

parlando del framework penso che ci sia poco da dire.. quello di java non teme rivali. come anche la documentazione, la javadoc è un punto di riferimento

Dai un'occhiata PyDoc, che non ha nulla da invidiargli.

[DioBrando]

Faccio una premessa.
trovo che il titolo sia stato poco azzeccato. Sarebbe stato meglio scrivere "confronto tra Java e Python", oppure "imparare a programmare: scelgo Python o Java?" et similia.
Così non si capisce come il cuore della discussione sia il confronto tra i due linguaggi (ed anche di là, alla fine 9 pagine su 11 si parlava proprio di questo).

Cmq vabbè ormai è stato scelto così, pazienza.

Originariamente inviato da mad_hhatter

io quando ho iniziato con java prima ancora di sapere cos'era un tipo primitivo ho scritto l'hello word... per stampare ho scritto system.out.println

così i primi concetti appresi sono stati:
classe e oggetto
package
import
membro statico
metodo

solo dopo sono venuti i numeri e gli array...
per un linguaggio OO non mi pare un percorso assurdo

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:

 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.


Con Python invece scrivi:

print "Hello World"

Basta. Fine. Non ci si perde nelle definizioni e nel "beh per ora scrivi così, poi dopo imparerai cosa significa e perchè si usa"
Si impara cosa sia print (che è +ttosto intuitivo da solo no?).
Poi dopo ci sarà il tempo per complicarsi la vita e per imparare le altre strutture del linguaggio.


Se invece lo scopo è quello di imparare a programmare direttamente con un approccio OO allora prendiamo Smalltalk o Eiffel che sono OO puri.

[cdimauro]

Anche Python è OO "puro", eh!

Tutti gli elementi con cui interagiamo sono oggetti che si "scambiano dei messaggi".

[k0nt3]

Originariamente inviato da cdimauro

Non devi convincere noi: vaglielo a dire a chi ha tirato fuori la metrica dei bug per numero di codice. La letteratura informatica è piena di riferimenti a questa metrica, che è fra le più usate.

si vede che non leggi nemmeno cosa scrivo la metrica ha senso solo a parità di linguaggio

Originariamente inviato da cdimauro

Comunque su questo ti ha risposto in maniera impeccabile marco.r, con cui mi ritrovo pienamente.

non ho mai sentito dolore per un bug nel codice. se non si nota a occhio si fa un pò di debug e via.

Originariamente inviato da cdimauro

Ma che stai a dire?!? Guarda che ti stai confondendo con PERL e Ruby.

Se c'è una cosa che a cui si tiene particolarmente in Python è proprio quella di offrire (possibilmente) un solo modo per fare la stessa cosa: è proprio nel DNA del linguaggio e il pensiero di fisso di chi l'ha creato e di chi lo sostiene.

allora dovrebbe supportare un solo paradigma.. mi sa che si contraddicono da soli

poi non ho mai capito perchè print "hello" e non print("hello")

[DioBrando]

sì io per "puro" intendevo per quanto riguarda sia il paradigma di programmazione usato sia per quanto riguarda le strutture usate

[k0nt3]

Originariamente inviato da cdimauro

Anche Python è OO "puro", eh!

Tutti gli elementi con cui interagiamo sono oggetti che si "scambiano dei messaggi".

quando scrivo:

print "hello"

non vedo nessuna interazione tra oggetti

[cdimauro]

Originariamente inviato da k0nt3

si vede che non leggi nemmeno cosa scrivo la metrica ha senso solo a parità di linguaggio

L'ho letto e non sono affatto d'accordo.

non ho mai sentito dolore per un bug nel codice. se non si nota a occhio si fa un pò di debug e via.

Si vede che non hai mai realizzato programmi di una certa consistenza in C, dove per tracciare un segmentation fault dovevi fare i salti mortali.

allora dovrebbe supportare un solo paradigma.. mi sa che si contraddicono da soli

Non confondere un paradigma di programmazione con gli strumenti che vengono messi a disposizione dei programmatori.

poi non ho mai capito perchè print "hello" e non print("hello")

Perché è un'istruzione, come if, while, for, ecc., o anche questi dovrebbero essere degli oggetti secondo te?

Comunque, a dimostrazione che di Python non t'interessi e che ne sai poco e niente, direttamente dal primo link che ho riportato sopra (e che non hai nemmeno letto a questo punto):

"Replace print by a function[done]"

Contento? Come vedi chi sviluppa il linguaggio è talmente ossessionato dal fatto che debba essere "omogeneo" che non gliene frega nulla di compere la compatibilità col passato andando a cambiare addirittura un'istruzione usatissima come print. E scusa se è poco.

Originariamente inviato da k0nt3

quando scrivo:

print "hello"

non vedo nessuna interazione tra oggetti

Nemmeno qui:

if True:
  pass

C'è interazione fra oggetti. Si chiamano istruzioni.

[cdimauro]

Originariamente inviato da DioBrando

sì io per "puro" intendevo per quanto riguarda sia il paradigma di programmazione usato sia per quanto riguarda le strutture usate

OK

[DioBrando]

Originariamente inviato da k0nt3

si vede che non leggi nemmeno cosa scrivo la metrica ha senso solo a parità di linguaggio

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)


Hai dato l'esame di Ingegneria del Software 1 e 2?

non ho mai sentito dolore per un bug nel codice. se non si nota a occhio si fa un pò di debug e via.

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.


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.

allora dovrebbe supportare un solo paradigma.. mi sa che si contraddicono da soli

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.

[k0nt3]

Originariamente inviato da cdimauro

L'ho letto e non sono affatto d'accordo.

prima ho portato un esempio in cui scrivere più codice serviva a evitare gli errori.. guardacaso calzava a pennello confrontando python con java. potresti portare un controesempio?

Originariamente inviato da cdimauro

Si vede che non hai mai realizzato programmi di una certa consistenza in C, dove per tracciare un segmentation fault dovevi fare i salti mortali.

in realtà l'ho realizzato eccome.. per questo ora uso java
ma stavamo parlando di imparare a programmare no? cosa c'entrano i programmi di una certa consistenza?

Originariamente inviato da cdimauro

Non confondere un paradigma di programmazione con gli strumenti che vengono messi a disposizione dei programmatori.

due paradigmi sono 2 modi di vedere le cose, quindi due modi di fare la stessa cosa

Originariamente inviato da cdimauro

Perché è un'istruzione, come if, while, for, ecc., o qualche questi dovrebbero essere degli oggetti secondo te?

pensavo che if while for ecc.. fossero parole chiave e non funzioni

Originariamente inviato da cdimauro

Comunque, a dimostrazione che di Python non t'interessi e che ne sai poco e niente, direttamente dal primo link che ho riportato sopra (e che non hai nemmeno letto a questo punto):

"Replace print by a function[done]"

Contento? Come vedi chi sviluppa il linguaggio è talmente ossessionato che sia "omogeneo" che non gliene frega nulla di compere la compatibilità col passato andando a cambiare addirittura un'istruzione usatissima come print. E scusa se è poco.

Nemmeno qui:

if True:
  pass

C'è interazione fra oggetti. Si chiamano istruzioni.

se l'hanno corretto tanto meglio, sta di fatto che print "hello" era rotto
non capisco il tuo secondo esempio :|
se prendi java ad esempio le interazioni tra gli oggetti si vedono sempre

[cdimauro]

Originariamente inviato da k0nt3

prima ho portato un esempio in cui scrivere più codice serviva a evitare gli errori.. guardacaso calzava a pennello confrontando python con java. potresti portare un controesempio?

Prima quando? Riportalo, cortesemente, anche se sarà la classica eccezione che conferma la regola.

Comunque mi ritrovo con quello che ha scritto DioBrando poco fa.

in realtà l'ho realizzato eccome.. per questo ora uso java
ma stavamo parlando di imparare a programmare no? cosa c'entrano i programmi di una certa consistenza?

Perché hai scritto questo:

"non ho mai sentito dolore per un bug nel codice. se non si nota a occhio si fa un pò di debug e via."

e i dolori dovuti a bug per codice non banale si fanno sentire, eccome.

due paradigmi sono 2 modi di vedere le cose, quindi due modi di fare la stessa cosa

Questo succede a livello macroscopico. A livello di linguaggio Python mette a disposizione oggetti che interagiscono. Infatti persino le funzioni, in Python, sono oggetti con le loro proprietà.

Poi come programmatore puoi sfruttare le loro caratteristiche per implementare un algoritmo come vuoi, anche sfruttando una mistura di ciò che a più alto livello sono due paradigmi diversi.

pensavo che if while for ecc.. fossero parole chiave e non funzioni

Infatti sono istruzioni per cui Python come linguaggio riserva delle parole chiave.

Da notare che esistono altri linguaggi, come il PL/1, che non riservano parole chiave per nessuna istruzione.

se l'hanno corretto tanto meglio, sta di fatto che print "hello" era rotto

Non direi, visto che si trattava di un'istruzione come altre.

Guido comunque ha fornito delle valide motivazioni per farla diventare una funzione built-in, esattamente come tante altre che Python mette a disposizione.

non capisco il tuo secondo esempio :|

Era un altro esempio che dimostrare che print è un'istruzione, al pari di if, ecc., per le quali NON c'è interazione fra oggetti.

se prendi java ad esempio le interazioni tra gli oggetti si vedono sempre

Certo, è evidentissimo:

int i = 1;

la variabile i "interagisce" con l'oggetto numero uno...