[Hollywood] Introduzione + Help Library

[Allanon]

• 

:lol:

Cmq alcune cose su Hollywood non sono state ancora implementate, come il già citato controllo con NIL che su LUA stand-alone non necessita di tutto quel putiferio. Inoltre non ho visto che Hollywood supporta come datatype i thread (si legge nel manuale) che ancora non sono disponibili, ma se Andreas (l'autore di Hollywood) l'ha inserito molto probabilmente avrà deciso di supportare questa fantastica feature  

Ad ogni modo, si, nerd fino all'osso  :lol:
Casomai ti venisse voglia di dare qualche base di Python contraccambierò di sicuro l'interesse  

[cdimauro]

• 

Qui non so perché il tempo manca e ho un sacco di cose da fare.

Qualcosa la scriverò in una serie di articoli per Appunti Digitali, ma riguarderà più che altro la virtual machine di Python e com'è implementata.

[Z80Fan]

• 

Sembra proprio un linguaggio interessante, mi sottoscrivo!

[Allanon]

• 

Sembrerà strano ma Hollywood non ha una funzione comune a tutti i BASIC: la funzione swap().
In pratica questa funzione inverte i valori di due variabili, spesso risulta utile effettuare un'operazione simile e anche se banale, può far sempre comodo una funzione del genere.

Supponiamo di avere due variabili <a> e <b>, e vogliamo scambiare il loro contenuto, il codice per effettuare questa operazione potrebbe essere:

Codice: [Seleziona]

Local dummy = a
Local a = b
Local b = dummy

Come si vede è necessaria una variabile "di appoggio" per eseguire questa operazione, ma basta una semplice funzione per rendere questa operazione istantanea in una sola riga:

Codice: [Seleziona]

Local a, b = [b]HL.Swap(a, b)[/b]

Il codice che costituisce la funzione appena utilizzata è il seguente, ed è semplicissimo:

Codice: [Seleziona]

Function HL.Swap(value1, value2)
;———————————————————————————————————————————————————————————————————————————————
; Returns the specified values swapped
;-------------------------------------------------------------------------------
   Return(value2, value1)
EndFunction

Qui non c'è molto da spiegare se non due caratteristiche di Hollywood (ma anche di LUA):
1. E' possibile assegnare dei valori a più variabili in una sola linea di codice, esempio:

Codice: [Seleziona]

Local Nome, Cognome, Età = "Fabio", "Falcucci", 40

2. E' possibile far restituire alle funzioni valori multipli, esempio:

Codice: [Seleziona]

Function AddSubMulDiv(a, b)
   Return(a+b, a-b, a*b, a/b)
EndFunction

Si conclude qui la spiegazione delle semplici funzioni contenute nella Help library  
Apro un' altro thread per dare un'infarinatura sulle funzioni e su come sia possibile utilizzarle in maniera non convenzionale per i BASIC più comuni.

[cdimauro]

• 

Nemmeno Python ha una routine/istruzione di swap, perché... non serve.

In Python si utilizza un'istruzione di assegnazione che serve a "spacchettare" valori multipli:

Codice: [Seleziona]

a,b = b,aVisto che anche Lua sembra essere dotato di questa funzionalità, si potrebbe fare così anziché chiamare appositamente Swap.

[Allanon]

• 

Appena provato, e funziona!  
Vedi che "parlare" di 'sta roba aiuta?
 :dance:

[cdimauro]

• 

Ottimo. Mi sono accorto che anche l'esperienza accumulata con altri linguaggi aiuta nello scrivere codice con quelli nuovi che s'imparano. Lo sto vedendo giorno per giorno con C#, dove trasferisco alcune "pratiche" che comunemente utilizzavo in Python.

Poi confrontarsi fra programmatori permette di arricchire i rispettivi bagagli culturali.

[Allanon]

• 

Ciao dsar, io non sono un esperto di linguaggi di programmazione in senzo letterale perciò prendo per buone le tue osservazioni
In effetti il problema della leggibilità è fondamentale in progetti grossi... ai voglia a rendere modulare il codice, se il linguaggio è poco leggibile impazzisci lo stesso.
Posso solo precisare che ".." per concatenare le stringhe è stato preso direttamente da LUA (ma non significa che sia la migliore implementazione possibile), anch'io avrei preferito il classico "+"

Per GetType() non so cosa dire, quello c'è e quello utilizzo ma posso sempre fare:

Codice: [Seleziona]

typeof = GetType

dopodichè:

Codice: [Seleziona]

If typeof(obj)=#NUMBER Then DebugPrint("Number!")


...Sono piccole cose che per me contano parecchio :-) ...

Ognuno ha le sue piccole manie  
Io per esempio sono così ossessionato la riusabilità del codice che creo librerie su librerie come un forsennato  :lol:

[cdimauro]

• 

Rispondo tardi, tuttavia sono qui da poco.

A me questo linguaggio non piace.
Quelli che voi chiamate due punti ".." in altri linguaggi vengono usati per i range type o value constructor per intendere un insieme di valori compresi tra due estremi. Nel design di un nuovo linguaggio, per evitare di creare confusione, andrebbero rispettate certe convenzioni.

Io non mi farei influenzare da quello che hanno fatto gli altri linguaggi nell'uso dei simboli.

Ad esempio, a me scoccia il dover usare == e != per uguaglianza e diseguaglianza, ma siccome si sono diffusi col C spesso vengono usati in linguaggi moderni che non hanno nulla a che vedere col C. Mentre io preferisco nettamente = e <> allo scopo.

Comunque anch'io trovo più "normale" l'uso del .. per specificare un range. Purtroppo in Python Guido ha deciso di usare il : allo scopo, ma considerato che è possibile specificare lo step (es: [1 : 10 : 2], da 1 a 10, escluso, a passi di 2) i .. avrebbero creato confusione.

Per la concatenazione di due stringhe in genere si usa il "+" o "&".

Si usa anche la | (in SQL, se non erro).

Comunque la scelta di operatori penso sia dovuta a questioni di velocità d'implementazione in Lua. In pratica sono stati riservati degli operatori per precisi tipi in modo da velocizzarne l'uso.

Il nome per la funzione del type introspection (GetType, anche se qui lo scopo è leggermente diverso) è brutto e inusuale. Io sono per un coding style leggibile e molto english-style.
La condizione "If GetType(value) = #NIL" non è per niente inglese. Mentre in C# si usa l'operatore "typeof" per il type introspection: "if typeof(obj) == Dog" o addirittura per i subtyping si può direttamente usare "if obj is dog". Il primo si può leggere come "if the type of obj is equal to dog". C# implementa pure un GetType(), ma come metodo di classe (e lì ha senso).

In Python si usa la funzione type che restituisce il tipo (classe) di un oggetto, mentre l'operatore is viene utilizzato per verificare l'identità (se un'espressione è esattamente la stessa istanza; cioè il puntatore è lo stesso), per cui verrebbe qualcosa di simile:

if type(obj) is dog:

Oppure si potrebbe utilizzare l'apposita funzione isinstance:

if isinstance(obj, dog):

o ancora:

if isinstance(obj, (square, rect)):

se serve effettuare controlli con più classi.

Nel caso specifico del test eseguito da Allanon per vedere se un oggetto è "null", in Python è sufficiente questo:

if obj is None:

Oppure, visto che None ha un valore logico "falso", mentre l'istanza di una classe (user defined) ha valore logico "vero":

if not obj:

Quest'ultimo test dev'essere eseguito facendo attenzione, perché le istanze di un oggetto "contenitore" (tupla, lista, stringa, dizionario, insieme, ecc.) hanno valore logico "falso" se il contenitore è vuoto, e "vero" se contiene almeno un (qualunque) elemento.

Esempi:

if s:
if not s:

Il primo controlla se una stringa ha almeno un carattere, e il secondo se è vuota.

Più precisamente, se s potesse anche essere None, e allora il primo caso risulterebbe vero se e solo se s NON è None e l'istanza è logicamente "vera" (se è una stringa, deve avere almeno un carattere). Tutti gli altri casi sarebbero "falsi".

Il secondo if invece sarebbe vero se s fosse None, oppure se fosse logicamente "falso" (contenitore vuoto).

Infine, e la finisco veramente qui che mi sono dilungato, tutti i tipi numerici vengono valutati come logicamente falsi se sono uguali a 0, e logicamente veri per qualunque altro valore.

Sono piccole cose che per me contano parecchio :-)

E che cominciano a pesare quando le applicazioni diventano sempre più grandi.

Non ricordo quale computer scientist di rilievo ha scritto una volta: Code should be written and read like a novel.

L'ho letta anch'io da qualche parte, ma adesso mi sfugge.

[cdimauro]

• 

Io non mi farei influenzare da quello che hanno fatto gli altri linguaggi nell'uso dei simboli.

Ad esempio, a me scoccia il dover usare == e != per uguaglianza e diseguaglianza, ma siccome si sono diffusi col C spesso vengono usati in linguaggi moderni che non hanno nulla a che vedere col C. Mentre io preferisco nettamente = e <> allo scopo.

Per quello c'è un motivo ben preciso per non ispirarsene :-)
Da un minimo di 40% ad un picco di 60% (inclusi programmatori esperti) nelle espressioni condizionali scrivono erroneamente = al posto ==. Fai conto che in C un'espressione è pure uno statement e che in compile time non ti ritorna un errore :-)
E sono bug che vengono scoperti mesi/anni dopo.

Verissimo, ma la cosa che mi dà più fastidio è che l'uso di = per l'assegnazione e di == per l'uguaglianza fu deciso su base puramente statistica, perché la prima operazione è più frequente della seconda, per cui si perde meno tempo a scrivere codice.

E' una ratio per me assurda e inaccettabile.

Riguardo la disuguaglianza darei l'ergastolo ai committee dell'ASCII per non aver incluso il fantastico ≠, che ovviamente è migliore di qualsiasi alternativa. Effettivamente != non ha senso. Da un punto di vista matematico <> ha molto più senso, oppure simbolicamente /= (Ada), # (Modula-2) gli si avvicinano parecchio.

In realtà il <> applicato ai numeri complessi, ad esempio, mi fa venire qualche mal di pancia. Il # l'ho visto meglio perché mi ricordava l'uguale "tagliato" (anche se in due parti).

L'optimum è rappresentato dal /= scelto da Ada, in mancanza di altri simboli nella tabella ASCII.

L'ho letta anch'io da qualche parte, ma adesso mi sfugge.

Ce n'era un'altra carina, ma non ricordo com'era in inglese. Se riesci a dettare un codice sorgente senza errori via telefono, allora è ben scritto :-)
Credo però che fosse mirato al coding style sul nome delle variabili

GLOM. E' carina, ma pensando a Python sarebbe difficilmente applicabile. :oops:

[Z80Fan]

• 

Effettivamente != non ha senso

Beh, io lo ho sempre visto come Not (!) Equal (=). Che poi sia != e non !== è un altro discorso.
Voglio poi far notare che non si poteva usare /= perchè questa simbologia è già usata per la divisione e assegnazione.
Infine # personalmente a prima vista non mi ispira un "diverso".

Si vede come la sintassi è soggettiva a chi programma più che al linguaggio.

[TheKaneB]

• 

Effettivamente != non ha senso

Beh, io lo ho sempre visto come Not (!) Equal (=). Che poi sia != e non !== è un altro discorso.
Voglio poi far notare che non si poteva usare /= perchè questa simbologia è già usata per la divisione e assegnazione.
Infine # personalmente a prima vista non mi ispira un "diverso".

Si vede come la sintassi è soggettiva a chi programma più che al linguaggio.

evidentemente ragioni con la sintassi C-like...

chi proviene dal pascal ragiona così:

if (isReady or isPending) and not isWaiting then fire; (praticamente è inglese)

dove isReady, isPending, ecc.. sono definite così
function isReady: boolean;
begin
..
..
..
  isReady := true;
end;

mentre fire, che non restituisce valori, è una procedura
procedure fire;
begin

....

end;

PS: ovviamente è un esempio buttato lì a casaccio, giusto per sottolineare le differenze abissali tra i linguaggi basati pesantemente su keywords, e linguaggi basati pesantemente su simboli.

[Z80Fan]

• 

Il compound assignment è la seconda caratteristica peggiore del C dopo l'equivalenza expression/statement.

Come sopra, non ci trovo nulla di male, idem per la seconda. Poi, se qualcuno le usa a sproposito rendendo il tutto una matassa illeggibile, non penso si possano dare tutte le colpe al linguaggio.
Visto che tu sei "quello delle citazioni" , te ne propongo una che avevo letto da qualche parte: "UNIX non impedisce all'utente di fare cose molto stupide, perchè gli impedirebbe di fare anche cose molto intelligenti".
Se poi era solo una scusa per nascondere i bug e farli sembrare features, questo non posso dirlo! :lol:

Invece di avere un taglio ne ha due ;-)  ≠ #

Mi ricorda cmq qualcosa tipo "numero" (gli anglosassoni usano #1, #2, o mi sto confondendo?).
Conoscendo il simbolo, il significato è ovvio, altrimenti non è così immediato capirlo (almeno io la penso così).

Anche io ero abituato a quella sintassi, ma dopo che sono passato ai linguaggi wirthiani la musica è cambiata, vuoi mettere un:
if not found then, con if (!found) { ?

Non voglio sembrare quello che si arrampica sugli specchi, ma il C++ permette di usare and, or, not, not_eq al posto dei simboli (a quanto pare per l'uso con tastiere che non hanno i seppur comuni simboli &, |, !; non tutti i compilatori però li abilitano automaticamente, bisogna attivarli.

ma per questo linguaggio ci voleva una tastiera particolare (la http://http://en.wikipedia.org/wiki/IBM_2741, prettamente matematica, a parte alcuni simboli tipo ≠, ≤ e ≥ la butterei volentieri in un cassonetto) .

In questo caso il C ha il vantaggio di usare solo simboli "di base" presenti sulle comuni telescriventi dell'epoca (che poi per culo è diventata la norma).
Se poi l'ascii non ha incluso ≠, è perchè non serviva per il suo scopo originale, e anche perchè era finito lo spazio.

E così C divenne un linguaggio che piace a tutti perché molto diffuso :-)

Può piacere o Deve piacere. Nella tua frase stà meglio la seconda versione.
Lo uso (insieme al C++) senza grossi problemi, non trovo tutta 'sta anarchia nella sintassi come molti urlano in giro.
Ho usato/userò ancora Python, vari Basic, vari linguaggi di Script; non sono stato tanto li a interrogarmi sui motivi filosofici della sintassi, la usavo e basta (ad esempio: perchè in Python devo terminare la riga di un if con i due punti ":"? il newline non bastava a delimitare?).

E non dite che è perchè arrivo dal C++ e quindi sono pronto a tutto!  

[AmigaCori]

• 

MOD
:text-offtopic:    ================================>    :angry-screaming:  
Visto che siete pigroni  :animals-chicken:  ad aprire nuovi topic ve lo apro io  :character-jason: ...ma non fateci l'abitudine perche' e' gia' la seconda volta che lo faccio!  :angry-tappingfoot:
Nuovo thread:------->  :auto-biker: Linguaggi a confronto.
/MOD