Falcon p.l. su Slackware

[jonnymind]

Salve, sono Giancarlo Niccolai, autore del Falcon Programming Language:
http://www.falconpl.org

Il nostro pacchetto 0.8.10 è stato aggiunto a Fedora e Ubuntu, e la versione 0.8.8 è su gentoo e altre (che dovrebbero aggiornare a breve all'ultima versione).

Quando feci i primi pacchetti cercai un modo per mettermi in contatto anche con slackware per avere un pacchetto per questa distro, ma non trovai un semplice modo diretto di proporre un pacchetto, e la cosa passò in secondo piano.

Mi piacerebbe proporre un pacchetto Falcon per Slack, o trovare un packager che sia interessato a mantenerlo; dal punto di vista di slack dovrebbe essere semplice, dal momento che lo script build.sh incluso nel pacchetto sorgente fa tutto quello che dovrebbe essere necessario, e i binari di Falcon necessitano solo di essere copiati nelle directory di sistema.

A chi posso rivolgermi?

[neongen]

provo a farne un pacchetto...

[aschenaz]

L'avevo segnalato qui:
viewtopic.php?f=20&t=25009

[neongen]

L'avevo segnalato qui:
viewtopic.php?f=20&t=25009

non l'avevo letto

[neongen]

ok pacchetto pronto. hello world funziona quindi direi che è ok
stasera online.

[Vito]

per il pacchetto ufficiale dovresti contattare direttamente Pat però...

[Mario Vanoni]

L'avevo segnalato qui:
viewtopic.php?f=20&t=25009

Ed io avevo fatto una domanda precisa, senza risposta ...

Due Falcon?

[aschenaz]

L'avevo segnalato qui:
viewtopic.php?f=20&t=25009

Ed io avevo fatto una domanda precisa, senza risposta ...

Due Falcon?

E' solo omonimia. Quell'articolo si riferiva a questo storage-engine mysql:
http://dev.mysql.com/tech-resources/art ... depth.html

Questo è proprio un nuovo linguaggio di programmazione...

[Mario Vanoni]

Salve, sono Giancarlo Niccolai, autore del Falcon Programming Language:
http://www.falconpl.org

Uso dal 1985 le UNIX utilities (sh, awk, sed, tr ecc.),
mai usato perl/python/ruby, non mi servono.

Spiegheresti in parole concise (KISS rule)
in italiano i pregi in piu` di Falcon?

Grazie
Mario Vanoni

[jonnymind]

ok pacchetto pronto. hello world funziona quindi direi che è ok
stasera online.

Vi amo! Davvero!



E ora, rispondo alle domande del thread.

[jonnymind]

Spiegheresti in parole concise (KISS rule)
in italiano i pregi in piu` di Falcon?

Grazie
Mario Vanoni

Sissignore, con estremo piacere, anche perché è un esercizio utilissimo: LinuxJournal (USA) mi ha contattato per scrivere un articolo (in questo W.E.), e devo essere sempre KISS e diretto al punto (per commessa), e senza imparzialità e senzazionalismi. Quindi, se mi date una mano a capire se sono nella direzione giusta ve ne sarò infinitamente grato.

[NOTA: Rileggendo l'articolo mi accorgo che è davvero lungo; proverò a scrivere qualcosa di più compatto e dritto al punto, se avete pazienza...]

"Morfologicamente", Falcon è uno scripting language non tipizzato (o debolmente tipizzato), multiparadigma, basato su una grammatica relativamente semplice statement / end; usa EOL come separatore di statement (come python e ruby) e fornisce una serie piuttosto completa di statement "tradizionali", come gli if/else, switch, while, try/catch o leggermente "innovati" come "for/in" (con blocchi speciali per il primo, ultimo e "altri" elementi, la possibilità di rimuovere l'elemento corrente dalla struttura iterata o di modificarlo al volo), il select (switch automatico sul tipo o sulla classe) e cose simili.

Dividiamo i domini degli scripting language in 3
- Embedding in applicazioni
- Motore interno
- Linguaggio (espressività)
e rapportiamoli a scelte di flessibilità ed efficienza, e non ultimo, al problema emergente: il multithreading.

Prima, una premessa: perché l'ho scritto? -- nello specifico, volevo scriptare delle applicazioni che dovevano essere responsive per filtrare messaggi ad alta velocità in ambito MultiThreading. Ho provato un po' di cose (LUA, Python e Perl; il Ruby non l'ho provato in quel contesto perché già fallisce completamente il criterio di utilizzabilità in MT; il PHP all'epoca era lentissimo, ora è molto meglio, ma è ancora totalmente inadatto ad essere impiegato in mondi MT). Nessuno dei sistemi che avevo provato poteva stare dietro al flusso di dati da gestire; non perché le loro VM fossero lente, ma per la complessità del passaggio dei dati fra lo script e l'applicazione, nelle due direzioni. Potevo rinunciare e fare tutto hard-coded o scegliere una strada diversa.

Il punto è che non avevo bisogno della virtualità degli altri S.L. (in python puoi riflettere le classi e cambiarle runtime, in Lua puoi creare un oggetto classe, ecc.); quella virtualità richiedeva alle API un'overhead che era inaccettabile, e fra l'altro non mi dava assolutamente nulla in termini di valore aggiunto nella programmazione.

Il Falcon è pensato per essere minimamente ingombrante in applicazioni già esistenti, anche MT. Invece di avere un solo pool di memoria, ogni macchina virtuale ha il suo pool, e non condivide nulla con le altre istanze (nemmeno le allocazioni, né la struttura dei moduli). Tutti gli item di base linguaggio sono storati nello stack interno (o negli stack interni, in alcuni casi), o nello spazio delle variabili globali. Questo significa che l'allocazione di semplici item (i.e. numeri) costa zero. Si possono inviare stringhe e buffer di memoria trasparente dall'esterno dello script, e questo ha consapevolezza della disponibilità di questi item ad essere modificati o no. Stringhe "statiche" non entrano mai a far parte dell'insieme del garbage collecting. In pratica, un normale scripting di analisi dei dati, anche molto massivi, potrebbe facilmente girare per ore senza aver bisogno di ricorrere al GC né al reference counting.

Altra caratteristica dell'embedding del Falcon è la macchina virtuale totalmente preemptibile. Sebbene la macchina per conto suo non gestisca l'MT (ma vedi sotto), può essere sospesa e interrotta in qualsiasi momento con richieste "cortesi". E' dotata di una callback verso le applicazioni ospiti, che sono libere di usarela per fare cose come iniettare nuovi dati in code per lo script, far partire nuove coroutine per la gestione "quasi" parallela di altre richieste, o sospendere la macchina virtuale e riabilitarla in un secondo momento. Esiste anche un "protocollo di interruzione", per ora limitato (alle chiamate fondamentali) ma in fase di estensione, che permette di interrompere routine bloccanti a livello di sistema (i.e. read sincroni), consentendo ad applicazioni MT di ordinare alla VM di procedere comunque, o di terminare immediatamente. Infine, una richiesta di attesa (sleep esplicito, attesa su semafori delle coroutine ecc), può essere girata all'applicazione embedding. Ad esempio, nel nostro binding per XChat, possiamo usare le "sleep" e le attese di semafori su coroutine per sospendere gli script, mentre XChat continua a funzionare, e richiamerà il nostro script al momento della sveglia. Per fare la stessa cosa con altri binding che affossano la sleep in una chiamata di sistema è necessario gestire nello script direttamente i timer forniti dall'applicazione (se questi sono disponibili).

Veniamo quindi alle caratteristiche del motore interno. Il motore si basa su moduli che forniscono funzionalità alla VM attraverso una fase di "link". Il modulo può essere binario (scritto in c/c++), pre-compilato in bytecode (tipo .class/jar), o sorgente. Si possono rilasciare anche applicazioni fatte solo di moduli pre-compilati e binari. La struttura dei moduli è rigida; per essere precisi, è read-only per la macchina Virtuale (si possono però creare e distruggere moduli dentro la VM, e non entro nei dettagli dei nuovi FlexyModule che accettano di essere cambiati dinamicamente). Un modulo può essere caricato in memoria, o essere generato da una applicazione embedding, e assegnato a diverse macchine virtuali, anche in esecuzione concorrente.
A livello di dati di base, Falcon supporta l'accesso diretto a buffer controllati di memoria, o stringhe (sono due tipi diversi), anche a livello di singolo byte o carattere. Falcon ha molti costrutti che consentono il riutilizzo trasparente di queste strutture; ad esempio, è molto facile fare il parsing di un file usando una sola stringa a lunghezza non necessariamente fissa, e intervenendo sui singoli caratteri senza la necessità di creare nuovi oggetti stringa ad ogni carattere analizzato. Questo significa anche che non esistono meccanismi di riciclo veloce/forzato, perché non sono necessari; permettono sì il riutilizzo della memoria appena sfruttata in modo trasparente, ma impattano su tutte le operazione (in maniera non indifferente), anche quando si potrebbe semplicemente riutilizzare la stessa variabile in modo esplicito.

Falcon gestisce nativamente tipi interi a 64 bit, distinguendoli in modo automatico dai numeri in virgola mobile. La matematica in virgola mobile viene usata solo se si rende necessario; il linguaggio fornisce nativamente operatori bitfield e binari. Essendo hard-coded nella macchina virtuale e operanti direttamente su matematica intera, e potendo operare anche direttamente su singoli byte o parole di diversa lunghezza in aree di memoria co-gestita fra i moduli (o le applicazioni) e gli script, la gestione di dati binari (come ad esempio la manipolazione di immagini) è molto più efficiente.

In termini di tipi di dati, Falcon permette la creazione di vere e proprie classi dichiarate come "forma" da dare ad istanze. Gli altri scripting language permettono una elevatissima flessibilità grazie al fatto che ogni oggetto è un dizionario chiave-valore, che in qualche caso ha dei meta-dati di "classe" gestiti in modo speciale, in altri casi nemmeno. Questo significa che la creazione di nuove istanze richiede la creazione di alberi binari (o bilanciati), e la loro gestione (soprattutto il garbage collecting) risulta piuttosto onerosa. In Falcon l'istantazione dell'oggetto è una semplice copia (piatta) dell'immagine di classe; tutte le meta-informazioni sono nell'oggetto classe indisponibile agli script. La velocità di istantazione e di gestione dei singoli oggetti è quindi molto maggiore. Falcon usa un approccio "tradizionale" al linking, di modo che tutti i simboli globali ed esterni sono risolti in load time (recentemente ho introdotto la possibilità di un lazy loading). Questo significa che la chiamata di funzioni e simboli globali risulta molto più rapida che nei linguaggi dove le funzioni sono rappresentate da entry in un dizionario.

Altro elemento degno di nota per quanto riguarda l'engine è il modello di GC completo. Oltre a liberare sia il programmatore di moduli nativi che gli embedders dal problema del reference counting (cosa non banale soprattutto in MT), evita agli scripters la scomodità di essere costretti ad appoggiarsi su strutture opache, ineleganti e inefficienti come i "weakref", in caso di referenze incrociate o circolari. Ad esempio, il modulo XML, già disponibile, è perfettamente in grado di fornire ai nodi figlio un riferimento al padre senza che questo inneschi l'irrecuperabilità dell'albero. Se una parte dell'albero diventa tutta non raggiungibile, essa viene semplicemente rimossa, mentre nei sistemi basati su refcounting (anche parziali), il fatto che i figli abbiano una referenza al padre mantiene il conteggio delle referenze artificialmente elevato anche quando sia il padre che i figli sono irraggiungibili, e questo rende obbligatorio usare strategie avanzate di gestione delle referenze a livello di script. Falcon libera da questa problematica.

Sebbene ci sarebbero moltissimi altri dettagli di cui parlare, ma direi che ho reso l'idea dello sforzo in direzione dell'ottimizzazione delle strutture dati e dell'utilizzo dei tipi.

Veniamo infine al linguaggio. Un motore serve a poco se non ha dietro un'idea solida di modello di programmazione. Io ne offro ben quattro: procedurale, OOP, funzionale e message-oriented più la prgrammazione tabellare che stiamo inserendo nella prossima versione. Ok, questa è una frase a effetto; ma il modello di programmazione è realmente derivato da queste basi.

Nel dettaglio:

- Programmazione procedurale: le funzioni viste come procedure imperative supportano un protocollo di chiamata a parametri variabili e possono essere assegnate a proprietà di oggetti, divenendo dinamicamente dei metodi e possono essere usate per creare sequenze funzionali.
- Programmazione OOP: Abbiamo classi con proprietà e metodi, ereditarietà "multipla", ma con risoluzione in link time delle ambiguità possibili. Tuttavia, il modello OOP di Falcon è principalmente basato sulla "presentazione" dell'interfaccia verso gli utilizzatori; stiamo studiando il concetto di "contratto". Alle proprietà possono essere assegnate procedure o sequenze funzionali, facendoli diventare metodi ibridi. Gli oggetti possono iscriversi al marshalling automatico dei messaggi, e diventare parte della rete di comunicazione interna al programma. Abbiamo poi concetti "contaminatori" che estendono il modello, come gli oggetti "singleton", gli attributi interclasse (trasversali) e l'oggetto "sender" (chiamante).
- Programmazione Funzionale: oltre a poter incapsulare intere chiamate (funzione + parametri da applicare) in liste, sono disponibili dei veri e propri costrutti funzionali che elaborano liste di operazioni funzionali... è un po' come avere una (relativamente semplice, per ora) macchina lisp programmabile dall'esterno. Le "applicazioni" (leggi, funzioni) possono essere non solo dichiarate funzionalmente, ma possono anche essere metodi (che ricordano i loro oggetti) o normali procedure. Normali item di linguaggio (o istanze di oggetti, o strutture funzionali ecc.) possono essere dichiarati "fuori banda" per implementare una semplice forma di calcolo monadico.
- Programmazione Message Oriented: Statement di linguaggio e funzioni speciali permettono di instaurare un vero e proprio "dialogo multilaterale" fra oggetti arbitrari. Un punto del programma può lanciare un messaggio "nell'etere", con una semantica totalmente arbitraria, che contenga dati, funzioni, oggetti, metodi, interi sotto-programmi; i ricevitori possono sottoscriversi a vari tipi di messaggi e gestirli in proprio. Con i costrutti attuali è già ora facile creare (e li formalizzeremo/struttureremo meglio nella versione in produzione) costrutti di più alto livello, come "eventi", assert/retract (concetti Prolog; significa postare dati e/o funzioni e/o programmi funzionali e/o metodi da recuperare per chiave e riapplicare), funzioni variabili (che ricevono "pezzi di elaborazione" via messaggi da fornitori astratti) ecc.
- Programmazione tabellare (in fase di studio/realizzazione): Se la OOP categorizza concetti astratti, il mondo del business pensa per tabelle. Per la OOP una macchina è un veicolo con quattro ruote e un motore, a cui viene applicata l'interfaccia del freno, dell'accelleratore e dello sterzo, e i modelli derivano dalla classe base. Per un direttore di marketing, una macchina è una matrice di funzionalità (colore, potenza, sicurezza) e modelli che implementano in modo booleano o "percentuale" una certa caratteristica. Così, un auto di tipo XY è "molto potente", "piuttosto sicura" e "rossa". Le tabelle si possono leggere in molti modi; possono essere solo dati, o avere anche algoritmi; ad esempio, in una banca si associa alla riga "tipo cliente" e alla colonna "tipo di conto" un particolare ALGORITMO di calcolo. Ma gli algoritmi possono essere anche sulle righe, o sulle colonne, o sia su righe, che su colonne che su celle. Aggiungere un algoritmo di calcolo in una gerarchia di conti correnti può richiedere la riscrittura delle classi, ma se i conti sono organizzati in tabelle di prodotto/feature, ecco che diventa possibile combinare le categorie in modo molto più dinamico. E poi, le tabelle possono avere "pagine"; ad esempio tabelle con uno schema da applicare prima di certa data, da sostituire in automatico con nuove tabelle a partire da un altro anno (si pensi ai cambiamenti nella legislazione tributaria).

Perché tutto questo? Perché non un solo modello di programmazione? I puristi della OOP possono obiettare che si può risolvere il problema del conto corrente o della linea di prodotto anche con categorie sufficientemente flessibili. A parte il fatto che "sufficientemente flessibile" si rivela spesso (nella mia esperienza sempre) "appena meno flessibile del necessario", il vero motivo è un altro.

La categorizzazione più efficace è quella dicotomica, proposta da Aristotele. Se prendiamo tutte le cose, alcune sono morbide, e altre dure; di quelle morbide, alcune sono commestbili... ecc. Perché non si usa questo metodo in informatica per la categorizzazione dei tipi? --- del resto, lo si usa per l'ordinamento dei dizionari...

Perché pur essendo terribilmente efficace, non è efficiente. Può bastare la descrizione molto più grossolana, ma sintetica, delle classi di oggetto. Serve allo scopo e risparmia passaggi.

Lo stesso si può dire della programmazione funzionale. Sebbene sia di minor successo presso il grande pubblico, non esiste programma OOP che non possa essere riscritto funzionalmente. Solo che, alle volte diventa un po' difficile seguire quello che succede in un costrutto funzionale che cresce oltre la propria capacità di computarlo. Perché va più o meno computato tutto insieme per capirlo realmente.

Insomma, il fulcro della questione è l'adattabilità, o se vogliamo, la comodità di applicare certe concettualizzazioni a certi problemi reali. Se devo applicare una fuzione a una lista di numeri, il modello OOP puro in stile i.e. Java che vuole la creazione di un paio di classi (derivate da classi non sempre così elementari) per gestire la sequenza forse non è molto adatto, così come se devo gestire tabelle di algoritmi di calcolo o variabili fuzzy. Diventa molto, molto più adeguato degli altri per spiegare e mettere in moto modelli astratti, concettualmente chiusi e intercomunicanti secondo regole predefinite e poco mutevoli.

Il Falcon non impone l'uso di un modello piuttosto che di un altro, ma permette (e ripeto, permette senza richiedere) l'uso di tutti questi modelli, a mio giudizio complementari e reciprocamente supportanti, per raggiungere lo scopo con il minore sforzo possibile da parte dello sviluppatore.

---
Ok, lo so, lo so, sono andato lungo, soprattutto sull'ultima parte. Ma il fatto è che l'idea di commistionare diversi stili e interi paradigmi di programmazione, non per caso, sfizio o perché uno degli sviluppatori ci ha messo uno zampino (tagliato con veemenza, come nel caso dei costrutti funzionali e del Python 3000), ma come idea programmatica di base, è relativamente nuova. L'ultimo nato, il Ruby, è nato proprio con l'idea del radicalismo completo su un paradigma; radicalismo sul quale l'autore si è trovato a dover far marcia indietro, cercando di inserire almeno qualche ombra di costrutto funzionale. Anche se cercherò di essere più sintetico in articoli più tecnici, qui mi andava di chiacchierare un po' con voi e esporvi la mia idea.

In estrema sintesi:

- Maggiori prestazioni
- Più facile integrazione con applicazioni complesse
- MT ready (oh, non vi ho parlato del modulo MT, che attiva l'MT nativo a contenzione zero)
- Minore e più controllato impiego della memoria
- paradigmi più completi e potenti.

(ma queste cose vanno motivate, da qui la lunga lettera).

Una nota: per la velocità pura della VM, sebbene il ciclo a vuoto abbia le prestazioni del LUA, su alcuni algoritmi specifici siamo battuti da altri linguaggi che sfruttano caratteristiche "semantiche" per fare certi lavori (i.e. la costrizione di un albero di tuple a 12 livelli è più veloce del 25% in python). Ma tenete presente che il nostro codice ha ottimizzazione zero, al momento. L'inizio delle ottimizzazioni è programmato per la versione 0.9; includerà memory pooling, migliore gestione dei vettori e dei dizionari (abbiamo un margine di circa il 30% 50% di prestazioni in quell'area), ottimizzazioni a livello di albero sintattico e bytecode generato e altro ancora, che al momento, visto le risorse limitate (me e poi io), non abbiamo potuto inserire. Ciò nonostante, il lavoro per cui è nato, ossia, gestire migliaia di callback agli script per secondo in server MT, dovendo analizzare dati articolati e rimandando all'applicazione dati altrettanto articolati, o dovendo scrivere log estraendo informazioni da dati di passaggio, e il tutto ad un consumo non apprezzabile di CPU su macchine moderne, lo fa già adesso più che egregiamente. La test suite inclusa nella distro compila ed esegue circa 260 script, molti dei quali tutt'altro che banali (nell'ordine delle 300 righe), nell'ordine di circa 0,2 secondi su un normale pentium di ultima generazione. Il tempo di entrata/uscita/sospensione della macchina virtuale e il tempo di conversione/accesso dei dati dei moduli/applicazioni da e verso gli script sono stati fino ad ora il nostro primo obiettivo in termini di efficienza, e questo obiettivo pensiamo di averlo raggiunto, al di là delle possibilità di altri strumenti. In più, la VM non ottimizzata già non è affatto male, anzi...

E pensare che non ho detto nulla del supporto nativo all'internazionalizzazione (con switch del linguaggio a tempo 0), degli operatori di espansione stringa, dell'operatore indiretto, ho accennato poco alle coroutine e...

Beh, se ci fosse qualcuno più bravo di me nella sintesi...

Cordiali saluti,
Giancarlo Niccolai

[jonnymind]

L'avevo segnalato qui:
viewtopic.php?f=20&t=25009

Ed io avevo fatto una domanda precisa, senza risposta ...

Due Falcon?

Già; prima di tutto, va detto che il Falcon (linguaggio) ha un sito dal 2004 (anzi, dalla fine del 2003).

Tanto che in una sessione di ego-surfing trovai i lucidi di una lezione scritta da un professore di una università cinese (in inglese) che descriveva gli scripting language e indicava anche il Falcon, mostrando alcuni dei suoi costrutti. Pure Matz (l'autore di Ruby) scrisse del Falcon nel suo blog agli inizi del 2004, (un po' preoccupato, devo dire , notando (con sollievo come i target fossero completamente diversi: vaste e "pesanti" applicazioni per Ruby, piccole e snelle applicazioni e embedding puro per Falcon. Definì alcuni dei suoi costrutti letteralmente "kyoumibukai" (profondamente interessanti).

Non mancano quindi i record certi, e autorevoli, dell'esistenza di Falcon come scripting language nel 2004, e sicuramente prima dell'engine MySQL. Ad ogni modo, ero conscio quando scelsi il nome che si poteva trattare di un nome assai comune; una mini disambiguazione relativa al software, oggi, potrebbe indicare:

- FALCON - un framework matematico attivo fino al 1996 (con un linguaggio di scripting chiamato AMPLE) (precedente)
- Falcon - il famoso gioco di simulazione di volo (precedente)
- Falcon - un tool per la gestione dei pacchetti debian usato da alcuni packager di ubunutu (successivo)
- Falcon - l'engine mysql (successivo)
- Falcon - Il linguaggio di programmazione.
- Diverse software house americane e europee (una decina, alcune precedenti, alcune successive).
- chissà che altro...

Sapendo che c'erano altri "Falcon" quando diedi il nome al linguaggio, e che ne sarebbero venuti altri dopo, decisi di inserire "Programming Language" nel nome ufficiale. Insisto molto col dire che la cosa si chiama "The Falcon Programming Language", per esteso, tanto che il sito e alcuni pacchetti si chiamano "falconpl"; lo chiamiamo "falcon" solo quando è chiaro dal contesto che stiamo parlando del linguaggio. Insomma, è il nome per gli amici

(non mi preoccupai più di tanto quando quelli di MySQL decisero di dare il nome Falcon al loro engine alterantivo perché si trattava comunque di una libreria specifica per una applicazione particolare, e non di un qualcosa di "stand alone"; ad esempio, ben difficilmente si sarebbe potuto farne un pacchetto "falcon"; al più, "mysql-falcon").

[d4z_c0nf]

Grazie mille per questa spiegazione.
rock