NSA - Non Solo Amiga
SOFTWARE => Linguaggi di programmazione e scripting => Topic aperto da: Allanon - 06 Giugno 2011, 22:00:17
-
Innanzi tutto una piccola introduzione:
Hollywood è un linguaggio multipiattaforma in grado di compilare per quasi tutto, da quest'ultima release il compilatore è in grado di produrre eseguibili anche per Linux perciò sono coperte tutte le principali piattaforme nonchè i nostri amati sistemi Amiga e Amiga-like, per chi vuole informazioni più dettagliate può visitare la pagina ufficiale di Hollywood:
http://www.airsoftsoftwair.com/ (http://www.airsoftsoftwair.com/)
L'autore di questo ambiente di sviluppo (Andreas Falkenhahn) definisce la propria creatura come:
Hollywood is a multimedia-oriented programming language that can be used to create graphical applications very easily
Tuttavia io ritengo che Hollywood sia adatto a programmi di tutti i tipi, logicamente multimedia, general purpose, giochi, ecc... il core di Hollywood si basa su Lua (http://http://www.lua.org), un linguaggio di scripting molto conosciuto ed estremamente flessibile e potente, disponibile per praticamente ogni sistema operativo.
Sviluppo regolarmente con Hollywood ormai da qualche anno, l'ho scoperto dopo aver provato a fare qualcosina con Lua, e l'ho trovato fenomenale.
Fenomenale per tre motivi principali:
1. Ha praticamente tutti i lati positivi di Lua
2. Supporta pienamente tutti i sistemi Amiga e Amiga-like
3. Crosscompila per moltissime piattaforme, e a meno che non vengano usate caratteristiche particolari di un sistema la ricompilazione non necessita di grosse modifiche del codice.
Questa tuttavia non vuole essere una recensione, ma vorrei proporre alcune librerie che ho scritto presentandole come tutorial per chi ha voglia di imparare questo linguaggio o semplicemente per chi già programma e vuole semplificarsi la vita con queste librerie.
Si presuppone una infarinatura di Basic generico :)
-----------------------------------------------------------------------------------------------------
Le librerie in Hollywood non sono altro che un insieme di definizioni e funzioni che possono essere utilizzate in qualsiasi progetto semplicemente "includendo" il codice della libreria nel proprio progetto.
In questo prima serie presento la più semplice delle mie librerie che ho chiamato Help Library, il nome del file in cui è definita si chiama Helpers.hws (.hws è l'estensione standard dei sorgenti di Hollywood che sta per Hollywood Script, ma è possibile chiamarli come si vuole in piena filosofia Amiga).
Per poter utilizzare queste librerie è necessario direal compilatore che deve includere questa libreria nel nostro progetto, per fare ciò dobbiamo utilizzare il comando @INCLUDE, nel nostro specifico caso, in testa al nostro sorgente dovremmo scrivere il seguente comando:
@INCLUDE "Helpers.hws"
In questo caso il compilatore cercherà la libreria nel cassetto corrente, è opportuno quindi fare attenzione al percorso dove la libreria sarà salvata.
Questa libreria contiene alcune utili funzioni di uso comune, che sono:
• HL.IsNil() Verifica se il valore passato è NIL
• HL.ParseArgs() Effettua il parsing degli argomenti della riga di comando
• HL.SafeNil() Resituisce la stringa "NIL" se il parametro passatto è NIL
• HL.Swap() Scambia fra loro due valori
Tutte le funzioni e le variabili utilizzate sono memorizzate nella tabella HL.
--------------------------------------------------------------------------
HL.IsNil(value)
--------------------------------------------------------------------------
Questa funzione verifica il parametro value e restituisce TRUE se è NIL, in caso contrario resituisce FALSE.
Ma cosa significa NIL?
NIL è un valore particolare assegnato alle variabili non inizializzate, può essere inteso anche come un non-valore, ossia come viariabili senza un valore.
Purtroppo in Hollywood non esiste un modo per verificare direttamente se una variabile è inizializzata o meno, perciò mi sono creato questa piccola funzione adatta allo scopo, ecco il codice:
Function HL.IsNil(value)
;———————————————————————————————————————————————————————————————————————————————
; Returns TRUE if <value> is NIL otherwise returns FALSE
;-------------------------------------------------------------------------------
; INPUT:
; • value value to check against NIL
;
; OUTPUT:
; • result TRUE if <value> is NIL, otherwise FALSE
;-------------------------------------------------------------------------------
If GetType(value) = #NIL Then Return(True) Else Return(False)
EndFunction
Se si tolgono i commenti rimarrà una sola riga di codice:
If GetType(value) = #NIL Then Return(True) Else Return(False)
Come si può intuire la chiave sta nel comando GetType() con il quale è possibile risalire al tipo di variabile che stiamo analizzando, per le variabili non inizializzate questo comando restituisce #NIL che è una costante particolare di Hollywood che ci da proprio l'indicazione che cerchiamo.
Gli altri tipi di variabile che GetType() può restituire sono:
#NUMBER per le variabili numeriche
#STRING per le variabili di testo
#TABLE per le tabelle
#FUNCTION per le funzioni
#NIL per le variabili non inizializzate
#USERDATA, #LIGHTUSERDATA e #THREAD in altri casi non ancora documentati nel manuale ufficiale
In attachment c'è la libreria completa, nei prossimi post spiegherò le altre funzioni. Se avete domande non fate i timidi :greetings-cya:
-
grande! grazie per il tuo prezioso contributo! :clap:
-
Dobbiamo diffondere il verbo :lol:
-
Che bello!, grazie!!! :D
Inizia ad avere una sua utilita' il sito :)
-
holliwood mi piace.
/me prende appunti.
-
Allora, eccomi qua per spiegare un'altra semplicissima funzione, ricordo che sto partendo proprio da cose estremamente semplici per permettere a tutti di capirle e prendere confidenza con questo linguaggio :D
--------------------------------------------------------------------------
HL.SafeNil(value)
--------------------------------------------------------------------------
Diciamo che anche questa funzione è abbastanza banale ma mi resta molto comoda quando devo concatenare delle variabili stringa tra loro, tuttavia se una di queste stringhe è NIL Hollywood si inalbera e da errore :D
Cosa sono le stringhe?
Le stringhe sono sequenze di caratteri alfanumerici, ad esempio 'pippo' è una stringa 'gianni ha 35 anni' è un'altra stringa e così via.
Una stringa vuota è semplicemente una sequenza di caratteri vuota, ossia senza caratteri. Per inizializzare una variabile stringa si può fare come segue:
Local stringa1 = "" ; questa è una stringa vuota
Local stringa2 = "ciao!" ; questa è un'altra stringa
Concatenare le stringhe? :?
Certo! Concatenare due o più stringhe significa semplicemente mettere in sequenza i vari caratteri delle stringhe da unire in una singola variabile, esempio:
Local risultato = "Il mio nome è " .. "Fabio"
Come si vede per unire due o più stringhe si usa l'operatore ..
Altro esempio:
DebugPrint("Il mio nome è " .. nome)
In questo caso la variabile nome non è stata inizializzata, pertanto vale NIL e Hollywood non gradisce concatenare stringhe con variabili non inizializzate: risultato il programma si interrompe ed esce inaspettatamente.
Prima regola del programmatore:
MAI, e dico MAI permettere al proprio programma di uscire in maniera inaspettata, e soprattutto incomprensibile per l'utente finale.
La funzione che ho fatto mi aiuta moltissimo proprio in questo ultimo caso, ossia quando devo concatenare delle stringhe per le quali non ho idea di cosa conterranno e devo fare in modo che se una di queste variabili sia a NIL il programma non si interrompa.
Ecco il codice semplicissimo di questa funzione:
Function HL.SafeNil(value)
;———————————————————————————————————————————————————————————————————————————————
; Returns the string 'NIL' if <value> is Nil, otherwise returns <value> without
; modifications.
;———————————————————————————————————————————————————————————————————————————————
; INPUT
; • value value to check against NIL
;———————————————————————————————————————————————————————————————————————————————
; OUTPUT
; • Result 'NIL' if <value> is Nil, otherwise <value>
;———————————————————————————————————————————————————————————————————————————————
; NOTES
; This func is useful for string concatenations where there is a risk that
; the value to concatenate can be Nil, in this case the concatenation will raise
; an error breaking the code execution.
;
; Example:
; DebugPrint("Hello " .. b) ; In this case if <b> is Nil an error is raised
; DebugPrint("Hello " .. HL.SafeNil(b)) ; No errors will be raised in case <b>
; ; is Nil, at least you will get the
; ; output: Hello NIL
;-------------------------------------------------------------------------------
If HL.IsNil(value)
Return("NIL")
Else
Return(value)
EndIf
EndFunction
Questa funzione fa una semplicissima cosa:
Se <value> è NIL restituisce una stringa contenente la parola "NIL" altrimenti restituisce <value> senza alcuna modifica.
Un'ora di spiegazione per questa cavolata di funzione? Che ci faccio adesso?
Esempio pratico
Ho una funzione che mi stampa sulla console dei messaggi per monitorare lo svolgimento del programma:
Function stampa_messaggio(messaggio)
DebugPrint("Messaggio ricevuto:" .. messaggio)
EndFunction
Se <messaggio> è NIL il programma si interrompe con un errore, mentre se uso:
Function stampa_messaggio(messaggio)
DebugPrint("Messaggio ricevuto:" .. HL.SafeNil(messaggio))
EndFunction
...tutto scorre come dovrebbe senza errori imprevisti 8-)
Per concludere una piccola nota sulla concatenazione: è possibile concatenare stringhe e numeri indistintamente, al momento della concatenazione Hollywood convertirà automaticamente i numeri in stringhe, provare per credere:
Local numero = 12
DebugPrint("Concatenare stringhe con numeri -->" .. numero)
La prossima volta facciamo qualcosina di leggermente più complesso :obscene-smokingsombrero:
A presto :whistle:
-
cool!!
NIL è l'equivalente di NULL del C.
Interessanti le GetType per la determinazione del tipo di dato, nonchè la Hl.SafeNil (un vero salvagente da quel che leggo) e la concatenazione di stringhe eseguite con la coppia di punti.
Aspetto la prossima lezione :clap:
-
Oggi vediamo un'altra funzione, un po' più complessa, della mia Help Library
--------------------------------------------------------------------------
HL.ParseArgs(CaseSensitive)
--------------------------------------------------------------------------
Premetto che esiste già una funzione di Hollywood che mette a disposizione in una tabella tutti gli argomenti passati nella riga di comando, tuttavia io sono un tipo pignolo, e come mi presenta i dati non mi soddisfa: per questo ho deciso di manipolare il risultato ottenuto per avere questi valori in una tabella molto più flessibile.
Procediamo con calma.
GetCommandLine() è il comando di Hollywood che restituisce, all'interno di una tabella, tutti i parametri specificati nella riga di comando. Supponiamo che il nostro programma si chiami "test", se io da shell digito:
>test -parametro1 ciao -parametro2 mondo
e che nello script vi sia un qualcosa di simile:
Local argomenti, conteggio = GetCommandLine()
Avrò come risultato la tabella <argomenti> così composta:
posizione 0 -> { arg = "-parametro1", param = "ciao" }
posizione 1 -> { arg = "-parametro2", param = "mondo" }
mentre <conteggio> riporterà il numero di parametri specificati, in questo caso 2
Esempio di come accedere a questi dati:
DebugPrint(argomenti[0].arg, argomenti[0].param)
DebugPrint(argomenti[1].arg, argomenti[1].param)
A questo punto io ho già un problema: se nel mio codice voglio sapere se l'utente ha specificato il -parametro2 come faccio?
Semplice, scorro la tabella con un ciclo For .. Next e se incontro ciò che cerco significa che l'utente l'ha specificato!
Si ok, ma se devo verificare tutti i parametri? E se il mio programma supporta tantissimi argomenti? Questa soluzione non è efficiente, non posso effettuare dei cicli For .. Next a raffica per ogni argomento da controllare!!
HL.ParseArgs() si occupa quindi di manipolare il risultato di GetCommandLine() e mi restituisce una tabella accessibile direttamente con il nome del parametro stesso.
Questo è possibile perchè in Hollywood (ed anche in LUA) è possibile indicizzare le tabelle con qualsiasi cosa, comprese le stringhe. Per chi è abituato al basic classico conoscerà sicuramente le tabelle, vettori o array come dir si voglia: le tabelle di Hollywood sono molto più dinamiche ma soprattutto possono contenere qualsiasi cosa ed essere indicizzate con qualsiasi cosa, nel caso specifico la tabella restituita da HL.ParseArgs() sarà indicizzata così:
posizione "parametro1" -> "ciao"
posizione "parametro2" -> "mondo"
Micro-Tour sulle tabelle:
; Tabella classica
Local classica1 = { "rosso", "verde", "giallo" }
; equivale a
Local classica2 = {}
classica2[0] = "rosso"
classica2[1] = "verde"
classica2[2] = "giallo"
; Tabella indicizzata con stringhe
Local computer1 = { cpu = "i5", clock = "2.26GHz", ram = "8Gb" }
; che equivale a scrivere
Local computer2 = {}
computer2["cpu"] = "i5"
computer2["clock"] = "2.26GHz"
computer2["ram"] = "8Gb"
; che, ancora, equivale a scrivere
computer3 = {}
computer3.cpu = "i5"
computer3.clock = "2.26GHz"
computer3.ram = "8Gb"
La potenza delle tabelle indicizzate con stringhe sta nel fatto che gli elementi possono essere recuperati direttamente, proprio come strutture dati, o record:
DebugPrint(computer1.cpu)
; Stamperà su console esattamente <i5>
E' chiaro che se avrò tutti gli argomenti in una tabella del genere non dovrò più effettuare i cicli For .. Next sprecando inutile tempo macchina, ma dovrò semplicemente tentare di accedere all'elemento che mi interessa, se questo esiste significa che l'utente lo ha specificato, altrimenti ciccia :D
Per adesso mi fermo, consiglio a chi possiede Hollywood di dare un'occhiatella veloce alla sezione dove vengono spiegate le tabelle (sezione 5.3), sono fondamentali per utilizzare delle tecniche di programmazione decisamente carine e rapide.
La prossima volta spiego come ho implementato la funzione e le istruzioni coinvolte.
:teasing-blah:
-
@Allanon
molto molto molto interessante :) grazie
-
prego! :D
-
...dunque, dicevamo? :D
Ecco il codice che ho utilizzato per la funzione HL.ParseArgs():
Function HL.ParseArgs(CaseSensitive)
;———————————————————————————————————————————————————————————————————————————————
; Parse command line arguments and return a table indexed by the argument and
; with the value equal to the parameter.
; Case sensitive is switched by default to TRUE, set to FALSE to parse arguments
; and parameters without case distinctions.
;———————————————————————————————————————————————————————————————————————————————
; INPUT
; • CaseSensitive Optional switch to activate (True) case sensitive argument
; recognition, defaults to True.
;———————————————————————————————————————————————————————————————————————————————
; OUTPUT
; • Result A table indexed with the argument and with the value equal
; to the argument value.
;———————————————————————————————————————————————————————————————————————————————
; NOTES
; Example:
; shell>MyHWTest -test1 10 -test2 hello
;
; HL.ParseArgs() will return the following table:
; result = { test1 = '10',
; test2 = 'hello' }
;-------------------------------------------------------------------------------
If HL.IsNil(CaseSensitive) Then CaseSensitive = False
Local Result = {}
Local Args, ArgsCount = GetCommandLine()
Local index, value = NextItem(Args)
While GetType(index) <> #NIL
If Not(CaseSensitive)
Result[value.arg] = value.param
Else
Result[LowerStr(value.arg)] = LowerStr(value.param)
EndIf
index, value = NextItem(Args, index)
Wend
Return(Result)
EndFunction
Qua si comincia a vedere un po' di roba consistente :D
Innanzitutto gestisco il valore di default del'argomento CaseSensitive questo perchè prevedo che questa funzione possa essere chiamata anche senza argomento e in questo caso CaseSensitive sarà assegnato a False come valore predefinito.
If HL.IsNil(CaseSensitive) Then CaseSensitive = FalseCome si vede utilizzo la funzione descritta qualche post indietro per verificare velocemente se CaseSensitive è stata specificata o meno.
Successivamente mi inizializzo una tabella che conterrà il risultato dell'elaborazione degli argomenti rilevati dalla riga di comando
Local Result = {}
E poi utilizzo il comando predefinito di Hollywood per leggere i parametri della riga di comando
Local Args, ArgsCount = GetCommandLine()
Adesso c'è il ciclo vero e proprio per convertire la tabella restituita da GetCommandLine() in una tabella indicizzata con il nome dell'argomento stesso.
Il ciclo di analisi viene eseguito con un loop particolare che utilizza il comando NextItem() per scorrere tutti gli elementi di una tabella, nel nostro caso la tabella restituita da GetCommandLine(): in pratica non è altro che un modo per scorrere una lista di elementi memorizzati in una tabella.
Vediamo pezzo per pezzo il codice:
Local index, value = NextItem(Args)
While GetType(index) <> #NILInizializzo <index> e <value> con il primo elemento e il primo valore della tabella <Args>
Dopodichè inizializzo un ciclo While ... Wend e come condizione pongo che <index> sia diverso da #NIL, questo perchè quando NextItem() raggiunge la fine della tabella restituisce NIL come indice, <value> invece prende il valore dell'elemento corrente su cui ci siamo posizionati con NextItem().
Quindi il ciclo prosegue fino a che non abbiamo raggiunto la fine della tabella.
If Not(CaseSensitive)
Result[value.arg] = value.param
Else
Result[LowerStr(value.arg)] = LowerStr(value.param)
EndIf
Qua avviene la conversione, ossia memorizzo nella tabella <Result> alla posizione <value.arg> il valore <value.param>, ossia Result[argomento_riga_di_comando] = valore_argomento_riga_di_comando
L' If ... Then ... EndIf serve solo a rendere tutto minuscolo (utilizzando LowerStr()) nel caso in cui si sia chiamata la funzione con CaseSensitive = False.
Per finire recupero il prossimo elemento della tabella da elaborare:
index, value = NextItem(Args, index)
E chiudo il ciclo While
Wend
Al termine dell'elaborazione restituisco la tabella dei risultati:
Return(Result)
Esempio pratico dell'utilità di questa funzione
Voglio creare un visualizzatore di immagini da riga di comando che possa interpretare le seguenti coppie di argomenti:
-image <nome_file_da_aprire>
-fullscreen <0=off, 1=on>
-quitkey <tasto_da_premere_per_uscire>
...
Local arguments = HL.ParseArgs()
If GetType(RawGet(arguments, "image")) <> #NIL Then load_image
If GetType(RawGet(arguments, "fullscreen")) <> #NIL Then set_fullscreen
If GetType(RawGet(arguments, "quitkey")) <> #NIL Then set_quitkey
...
Function load_image()
LoadBrush(1, arguments.image)
...
EndFunction
Vedete quanto è semplice testare se un argomento è stato passato o meno? Neppure un For ... Next per scorrere gli argomenti, il controllo è immediato e rapidissimo, inoltre è facile anche accedere ai valori abbinati agli argomenti come si vede nella funzione dell'esempio <load_image>: il valore del parametro viene letto come se fosse il membro di una struttura 8-)
Spero di non avervi confuso le idee e me ne resto qua in stand-by 2/3 giorni in attesa di domande, se ce ne saranno :whistle:
-
Io leggo...passivamente ma leggo :D Non ho domande da farti perche' non sto programmando :P pero'...insomma...volevo dirti che la guida e' molto interessante e magari ci sono altri come me che sono "passivi" ma apprezzano, quindi grazie del tempo che dedichi alla guida per impararci qualcosa :)
-
Anche se Lua non mi piace proprio (io sono un pythonista sfegato :D), ci sono anch'io che leggo. ;)
P.S. Sarebbe interessante aggiungere la syntax highlight al codice. Apro un thread nell'apposita sezione.
-
Ottimo!
Almeno sarò ancora più motivato a proseguire... grazie dell'interesse dimostrato :D
@cdimauro
Devo essere sincero: non ho mai provato Python anche se so che si tratta di qualcosa di enormemente diffuso e con svariati moduli per praticamente ogni cosa, nel mio percorso di ricerca del linguaggio perfetto (che ancora non ho trovato :D ) ho incontrato LUA e mi sono subito innamorato del suo modo di gestire i dati, nonche' della semplicità di programmazione e della possibilità di creare codice dinamico con infinite possibilità per sviluppare anche le applicazioni più complesse... poi ho riscoperto Amiga nella sua incarnazione moderna, e successivamente Hollywood che nonostante allo stato attuale abbia molti difetti (come ad esempio la mancata accelerazione HW di tutte le chiamate grafiche) ha anche moltissimi pregi, primo fra tutti il crosscompiling per quasi tutte le piattaforme esistenti senza eccessivi sforzi da parte del programmatore 8-)
-
E' un vero peccato che Hollywood abbia deciso di impiegare LUA e non Python. Dalla sua LUA ha una ENORME facilità di embedding, per cui da questo punto di vista è giustificato. E' anche un linguaggio molto semplice e dinamico, e per questo ha attecchito.
Per contro, Python ha una sintassi decisamente più semplice, ma anche... ben più ricca. Ti permette di esprimere molte cose con meno codice, e in maniera più elegante. Poi è dinamico fino all'osso, per cui cose "strane" ne puoi fare a bizzeffe ("monkey patching" e metaprogrammazione in generale).
Non ti nascondo che man mano che mostri il tuo codice e lo analizzo, penso subito "con Python farei così; questo verrebbe più semplice; non c'è da controllare ogni volta il Nil; ecc. ecc." :D
D'altra parte "se siamo nerd, ci sarà un perché..." :lol:
-
: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 :D
Ad ogni modo, si, nerd fino all'osso :lol:
Casomai ti venisse voglia di dare qualche base di Python contraccambierò di sicuro l'interesse ;)
-
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.
-
Sembra proprio un linguaggio interessante, mi sottoscrivo!
-
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:
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:
Local a, b = [b]HL.Swap(a, b)[/b]
Il codice che costituisce la funzione appena utilizzata è il seguente, ed è semplicissimo:
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:
Local Nome, Cognome, Età = "Fabio", "Falcucci", 40
2. E' possibile far restituire alle funzioni valori multipli, esempio:
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 :D
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.
-
Nemmeno Python ha una routine/istruzione di swap, perché... non serve. :D
In Python si utilizza un'istruzione di assegnazione che serve a "spacchettare" valori multipli:
a,b = b,aVisto che anche Lua sembra essere dotato di questa funzionalità, si potrebbe fare così anziché chiamare appositamente Swap. :P
-
Appena provato, e funziona! :D
Vedi che "parlare" di 'sta roba aiuta?
:dance:
-
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. ;)
-
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:
typeof = GetType
dopodichè:
If typeof(obj)=#NUMBER Then DebugPrint("Number!")
...Sono piccole cose che per me contano parecchio :-) ...
Ognuno ha le sue piccole manie :D
Io per esempio sono così ossessionato la riusabilità del codice che creo librerie su librerie come un forsennato :lol:
-
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. :P
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.
-
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:
-
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. :)
-
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.
-
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" :D, 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. :D
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! :P
-
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. (http://http://www.nonsoloamiga.com/forum/viewtopic.php?f=12&t=329)
/MOD