linguaggio per far capire la programmazione

[MItaly]

Secondo me i casi sono troppi e troppo vari per imporre una regola così forte. Allunghi le linee di codice anche quando non è necessario. Per me deve rimanere una buona pratica e non una imposizione.

Non sono d'accordo. In qualunque altro linguaggio ho sempre scritto codice indentato, perché senza non si capisce una sega. Se il codice inizia ad essere troppo indentato, vuol dire che è arrivato il momento di un refactoring. Inoltre, Python non ti impone un numero di spazi fisso: volendo puoi indentare anche ad uno spazio, se esci dalle canoniche 80 colonne con indentazione di 'sto tipo vuol dire che stai facendo qualcosa di decisamente sbagliato.

Mah non lo so. Credo che dovrò farmele piacere perché l'hanno implementato in JS 1.7. Ma secondo me hanno una sintassi poco piacevole (certo se devi fare cose semplici sono comodissime. Ma se ne abusi... un po' come gli operatori ternari a? b: c? d : e? f? c: d : e)

Be', questo vale per qualunque caratteristica "avanzata" del linguaggio; ma fidati che in genere sono di una comodità estrema, a patto appunto di non abusarne.

Ok, se proprio devi allora non mi mettere True e False... mettimi true e false, o TRUE e FALSE. Ma va beh, forse mi ci sono scontrato a causa del fatto che in tutti i linguaggi ho sempre scritto "true" o "false".

Questo ogni tanto turba anche me quando vengo dal C++.

Poi dai.. mancano le costanti, e pure lo switch.

Le costanti in un linguaggio dinamico come Python non servono a niente. Lo switch ogni tanto manca anche a me, anche se in genere si rimpiazza o con una (brutta) catena di elif o con un dictionary (che poi è di fatto come spesso vengono implementati gli switch "sotto il cofano"). Sulla questione comunque si è discusso a lungo.

[chumkiu]

Non sono d'accordo. In qualunque altro linguaggio ho sempre scritto codice indentato, perché senza non si capisce una sega.

if(a) print("a");
if(b) print("b");
if(c) print("c");
if(d) print("d");
if(e) print("e");

lo reputo più chiaro e conciso di

if a :
	print "a"
if b :
	print "b"
if c :
	print "c"
if d :
	print "d"
if e :
	print "e"

oppure

print "a" if a else "a"
print "b" if b else "b"
print "c" if c else "c"
print "d" if d else "d"
print "e" if e else "e"

E' solo un esempio. E'il concetto di usare l'indentazione (rientrante nello stile visivo) come definizione di blocco è una cosa che mi fa storcere li naso. Ammetto che nella maggioranza dei casi è un vantaggio per la leggibilità, ma non mi piace essere costretto nell'estetica del sorgente.

Be', questo vale per qualunque caratteristica "avanzata" del linguaggio; ma fidati che in genere sono di una comodità estrema, a patto appunto di non abusarne.

Si, sono d'accordo che sono comode. Un po' ostiche a prima vista ma non tanto quanto le regular expressions.

Le costanti in un linguaggio dinamico come Python non servono a niente.

C'è stata una discussione anche sul PHP (che è il linguaggio su cui sto il 60% del tempo [e non vado in giro a dire che è bello, ma ci convivo ]). Ma la domanda madre è: perché devo usare una variabile per un valore che DEVE essere costante? In ogni caso non è vitale averne.

[MItaly]

if(a) print("a");
if(b) print("b");
if(c) print("c");
if(d) print("d");
if(e) print("e");

In Python è concesso:

if a: print "a"
if b: print "b"
if c: print "c"

Volendo strafare, è anche concesso

if a: print "a"; print "b"

ma non ho mai visto nessuno effettivamente usare la sintassi con il punto e virgola.

C'è stata una discussione anche sul PHP (che è il linguaggio su cui sto il 60% del tempo [e non vado in giro a dire che è bello, ma ci convivo ]).

Ci mancherebbe, PHP è innegabilmente orrido.

Ma la domanda madre è: perché devo usare una variabile per un valore che DEVE essere costante? In ogni caso non è vitale averne.

Anche qui, sono scelte progettuali... credo che dipenda da due fatti fondamentali:

• per l'interprete Python (in cui tutto è dinamico e alla fine tutti gli oggetti sono hashtable) una costante sarebbe un caso inutilmente speciale di variabile;
• l'idea di fondo di Python è "è più facile chiedere scusa che permesso", per cui il linguaggio tende al lassez-faire più completo; per esempio, le classi Python non hanno "veri" membri privati, ma c'è la convenzione per cui i membri "teoricamente da non toccare" hanno il nome che comincia per underscore (ad un certo punto sono stati implementati i nomi con doppio underscore, che funzionano tramite name mangling, ma di rado li ho visti usare).

Questo atteggiamento consente di evitare di dover fare refactoring allucinanti quando salta fuori un singolo caso in cui bisogna violare un'interfaccia, anche se allo stesso tempo bisogna evitare di partorire mostri (in Python 2 è tranquillamente possibile fare

matteo@teokubuntu:~$ python
Python 2.7.5+ (default, Sep 19 2013, 13:48:49) 
[GCC 4.8.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> True=False
>>> print True
False
>>>

- ma non significa che uno debba farlo )

[chumkiu]

• l'idea di fondo di Python è "è più facile chiedere scusa che permesso", per cui il linguaggio tende al lassez-faire più completo; per esempio, le classi Python non hanno "veri" membri privati, ma c'è la convenzione per cui i membri "teoricamente da non toccare" hanno il nome che comincia per underscore (ad un certo punto sono stati implementati i nomi con doppio underscore, che funzionano tramite name mangling, ma di rado li ho visti usare).

Beh dai... però...
mi metti l'indentazione come regola e poi si dichiarano metodi pubblici e privati tramite convenzioni??

[MItaly]

Beh dai... però...
mi metti l'indentazione come regola e poi si dichiarano metodi pubblici e privati tramite convenzioni??

Cosa c'è di così sacro in un membro private? È una convenzione esattamente come un underscore, nulla ti impedisce di piazzare tutto come public; private è un aiuto che ti viene dato per separare interfaccia ad implementazione, nulla di più. Se scrivi oggetto._membro sai che stai violando l'interfaccia, è l'unica cosa che conta.

Il problema è che siamo talmente abituati alla OOP "alla Java" (o C++, C# e di molti dei linguaggi mainstream attuali) da vedere solo l'implementazione "canonica" della OOP (o di altre caratteristiche del linguaggio), se ci si guarda in giro ci sono state (e ci sono tuttora) un mucchio di altre idee interessanti in ambito di linguaggi (e qui bisogna chiedere a Scara95, è lui che prova qualunque linguaggio si trovi in giro ).

Edit: per dire, basta vedere un diagramma come questo per vedere la varietà di idee che c'è in giro in ambito-linguaggi se appena si esce dai linguaggi super-mainstream.

[Scara95]

(e qui bisogna chiedere a Scara95, è lui che prova qualunque linguaggio si trovi in giro ).

Mi sento chiamato in causa

Il sistema migliore di (proto)oggetti a mio parere è quello di Lua in cui puoi fare tutto quello che vuoi basta che ti arrangi u.u

Il migliore sistema ad oggetti invece è quello di Eiffel. Vi invito fortemente ad informarvi: It's "OOP done Right"

Ah, molto interessante è anche la via adottata da tcl e che può essere adottata da qualsiasi linguaggio funzionale: questa consiste nel ritornare una closure che prende come primo argomento il nome funzione da applicare e poi un numero variabile di argomenti.

[ciro78]

Cosa c'è di così sacro in un membro private? È una convenzione esattamente come un underscore, nulla ti impedisce di piazzare tutto come public; private è un aiuto che ti viene dato per separare interfaccia ad implementazione, nulla di più. Se scrivi oggetto._membro sai che stai violando l'interfaccia, è l'unica cosa che conta.
.

Visto lo schema che hai postato mi pare di capire che tu sia un superguru della programmazione e quindi sai l fatto tuo. Detto questo avere metodi e proprietà private è si una convenzione ma impedisce anche di fare cavolate. In un progetto a più mani se mi collego ad una classe scritta da un altro avere i metodi e proprietà nascoste evita di fare casini. Certo potresti obiettare che un programmatore accorto eviterebbe certe cose ma, come saprai meglio di me, a volte i tempi di sviluppo non ci consentono di andare tanto per il sottile.

Una sintassi più snella aiuta parecchio. Però è anche vero che se sbagli una identazione puoi generare bug catastrofici.

[Scara95]

E' un niente quello che (volendo) ci metti a sostituire la parola "private" con "public", anche nel codice altrui. Non è un ostacolo poi così grande da superare...

E' vero che se sbagli la parentesi graffa e la metti un istruzione prima puoi generare bug catastrofici.