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.

[lnessuno]

A tal proposito, di recente mi è stato chiesto il modo più creativo per stampare i numeri da 1 a 100 in C...

Adoro i linguaggi autoesplicativi

[ciro78]

Brainfuck, of course. Autoesplicativo, semplice e conciso. Questo per esempio

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

Stampa a schermo la lettera A...




Either way... http://learnxinyminutes.com/

ma chi è il pazzo che ha inventato una cosa del genere?

[Raffaele]

C'è sempre LOGO, per quelli davvero coraggiosi

Vero! Il logo insegna le basi delle basi, e se lo capiscono anche i bambini, da lì anche per un adulto parte tutto... Poi un po' di basic, e qualche linguaggio script, e infine leggersi il libro teach yourself C++ in 21 days. Funziona veramente...

[mydb]

Io ho iniziato col Pascal

Siamo in due

[hfish]

A tal proposito, di recente mi è stato chiesto il modo più creativo per stampare i numeri da 1 a 100 in C...

vabbè, se volete divertirvi con vari brainfuck, ecco qua un modo interessante per passare un sabato sera piovoso
http://www.ioccc.org/

[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.