Ricominciare a programmare... da dove?

[cdimauro]

Originariamente inviato da Dott.Wisem

Perché, no bracket? Sono leggibilissimi e la vista può concentrarsi sul resto del codice (invece di disperdersi su potenziali 'begin' e 'end' che possono far confondere).

Il perché l'avevo scritto:

>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Comunque io trovo molto più facile seguire i begin/end piuttosto che {}.
Diciamo che ho una particolare avversione per le accozzaglie di simboli (che mi fanno confondere), e preferisco di gran lunga leggere parole (in inglese).

[Dott.Wisem]

Originariamente inviato da cdimauro

Il perché l'avevo scritto:

>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Comunque io trovo molto più facile seguire i begin/end piuttosto che {}.
Diciamo che ho una particolare avversione per le accozzaglie di simboli (che mi fanno confondere), e preferisco di gran lunga leggere parole (in inglese).

Mah, secondo me nella definizione sintattica di un linguaggio ideale, la delimitazione dei blocchi (che, semanticamente parlando, fa parte della punteggiatura di un codice), deve essere indicata da simboli, non da parole. E' come se io, per indicare un fine istruzione, scrivessi una parola, invece di un ';' o similare:

pi := 3.14 END
IF pi = 3.14 THEN Print("me lo ricordo ancora") END
...

[cdimauro]

Quindi questo:

pi = 3.14
if pi == 3.14:
  print "me lo ricordo ancora"

per te andrebbe bene.

[Dott.Wisem]

Originariamente inviato da cdimauro

Quindi questo:

pi = 3.14
if pi == 3.14:
  print "me lo ricordo ancora"

per te andrebbe bene.

Si, anche se quel ':' alla fine dell'if mi confonde un po'.

[Dott.Wisem]

Stavo dando un'occhiata a Python e, a parte la sintassi, mi sembra un linguaggio molto simile a Suneido da un punto di vista concettuale. Esempio:

in Python:

#An example of a class
class Shape:
    def __init__(self,x,y):
        self.x = x
        self.y = y
    description = "This shape has not been described yet"
    author = "Nobody has claimed to make this shape yet"
    def area(self):
        return self.x * self.y
    def perimeter(self):
        return 2 * self.x + 2 * self.y
    def describe(self,text):
        self.description = text
    def authorName(self,text):
        self.author = text
    def scaleSize(self,scale):
        self.x = self.x * scale
        self.y = self.y * scale

In Suneido:

//An example of a class
shape = class
	{
	Description: "This shape has not been described yet"
	Author: "Nobody has claimed to make this shape yet"
	New(x,y)
		{
		.x = x
		.y = y
		}
	Area() 
		{ 
		return .x * .y 
		}
	Perimeter() 
		{
		return 2 * .x + 2 * .y
		}
	Describe(text)
		{
		.Description = text
		}
	AuthorName(text)
		{
		.Author = text
		}
	ScaleSize(scale)
		{
		.x = .x * scale
		.y = .y * scale
		}
	}

Notare che in Suneido quando scrivo '.qualcosa', in realtà è come se scrivessi 'this.qualcosa'. Difatti Suneido consente (ma non obbliga) di omettere la keyword 'this', in modo da snellire la sintassi. Effettivamente, scrivere delle espressioni complesse riempite di this.XXX o self.XXX, alla fine risulta scomodo.

Python ha liste, tuple e dizionari. Le liste sono insiemi indicizzati di valori. Le tuple sono come le liste ma sono insiemi immutabili. Infine, i dizionari consentono di associare dei valori a delle parole. A differenza degli elementi nelle liste, gli elementi nei dizionari non vengono memorizzati nell'ordine in cui vengono aggiunti.

In Suneido, liste e dizionari sono combinati in un unico tipo di dato: il tipo Object (che è anche una classe, essendo Suneido un linguaggio OO puro). Quindi, in Suneido, io posso avere un'unica lista di valori contenente sia valori indicizzati che non indicizzati. Esempio:

myobj = Object(10, 20, 30, 40, autore: "Dott.Wisem", titolo: "Suneido è meglio di Python. Gnegnegne.")

myobj[2]
=> 30

myobj.autore
=> "Dott.Wisem"

Da quel poco che ho visto, in Python non si può fare la cosa di sopra, a meno che il programmatore non si definisca un nuovo tipo di dato che si comporti come sopra.

Così come Python ha le tuple, Suneido ha gli oggetti read-only, che si definiscono usando il cancelletto, invece del termine 'Object'. Ad esempio:

my_readonly_obj = #(1, 2, 3, 4, field1: 'hello')

[cdimauro]

Originariamente inviato da Dott.Wisem

Si, anche se quel ':' alla fine dell'if mi confonde un po'.

E' questione di abitudine. Vediamo se riusciamo a convincere Guido a farglielo togliere...

Originariamente inviato da Dott.Wisem

Stavo dando un'occhiata a Python e, a parte la sintassi, mi sembra un linguaggio molto simile a Suneido da un punto di vista concettuale. Esempio:

in Python:

#An example of a class
class Shape:
    def __init__(self,x,y):
        self.x = x
        self.y = y
    description = "This shape has not been described yet"
    author = "Nobody has claimed to make this shape yet"
    def area(self):
        return self.x * self.y
    def perimeter(self):
        return 2 * self.x + 2 * self.y
    def describe(self,text):
        self.description = text
    def authorName(self,text):
        self.author = text
    def scaleSize(self,scale):
        self.x = self.x * scale
        self.y = self.y * scale

In Suneido:

//An example of a class
shape = class
	{
	Description: "This shape has not been described yet"
	Author: "Nobody has claimed to make this shape yet"
	New(x,y)
		{
		.x = x
		.y = y
		}
	Area() 
		{ 
		return .x * .y 
		}
	Perimeter() 
		{
		return 2 * .x + 2 * .y
		}
	Describe(text)
		{
		.Description = text
		}
	AuthorName(text)
		{
		.Author = text
		}
	ScaleSize(scale)
		{
		.x = .x * scale
		.y = .y * scale
		}
	}

Notare che in Suneido quando scrivo '.qualcosa', in realtà è come se scrivessi 'this.qualcosa'. Difatti Suneido consente (ma non obbliga) di omettere la keyword 'this', in modo da snellire la sintassi. Effettivamente, scrivere delle espressioni complesse riempite di this.XXX o self.XXX, alla fine risulta scomodo.

Dipende da quello che ci devi fare. In Python comunque non si può rimuovere self (che comunque puoi chiamare come vuoi: anche s può andare benissimo, ad esempio ) perché:
- metodi e funzioni sono sostanzialmente la stessa cosa;
- in Python dev'essere esplicito ciò che stai facendo.

Da una parte hai lo svantaggio di dover scrivere di più, dall'altro quello di poter trattare i metodi esattamente come se fossero delle funzioni (che è molto comodo in tante situazioni).

Python ha liste, tuple e dizionari. Le liste sono insiemi indicizzati di valori. Le tuple sono come le liste ma sono insiemi immutabili. Infine, i dizionari consentono di associare dei valori a delle parole. A differenza degli elementi nelle liste, gli elementi nei dizionari non vengono memorizzati nell'ordine in cui vengono aggiunti.

Esatto.

In Suneido, liste e dizionari sono combinati in un unico tipo di dato: il tipo Object (che è anche una classe, essendo Suneido un linguaggio OO puro). Quindi, in Suneido, io posso avere un'unica lista di valori contenente sia valori indicizzati che non indicizzati. Esempio:

myobj = Object(10, 20, 30, 40, autore: "Dott.Wisem", titolo: "Suneido è meglio di Python. Gnegnegne.")

myobj[2]
=> 30

myobj.autore
=> "Dott.Wisem"

E' simile a PHP allora (linguaggio che notoriamente "amo" molto ).

Da quel poco che ho visto, in Python non si può fare la cosa di sopra, a meno che il programmatore non si definisca un nuovo tipo di dato che si comporti come sopra.

No, perché liste e dizionari sono dati concettualmente diversi.

Così come Python ha le tuple, Suneido ha gli oggetti read-only, che si definiscono usando il cancelletto, invece del termine 'Object'. Ad esempio:

my_readonly_obj = #(1, 2, 3, 4, field1: 'hello')

Utili perché semplificano la scrittura di applicazioni multithread.