Newsgroup: it.comp.programmare
Titolo: Cercasi collaboratori per nuovo linguaggio open source.

Salve a tutti, scrivo questa discussione per segnalarvi quanto segue.
Da circa un anno (o poco più), sto lavorando su un nuovo linguaggio di
scripting, chiamato Hybris, implementato in C/C++, completamente open
source.
Quello che inizialmente era un passatempo è diventato qualcosa di
grosso e complicato, pertanto mi trovo nella necessità estrema di
validi collaboratori che mi aiutino con lo sviluppo.
I requisiti sono ovviamente una buona conoscenza del C/C++, di GNU/
Linux e soprattutto passione, considerando che il progetto è free e
non retribuito.
Il linguaggio code delle seguenti caratteristiche principali :
    * Virtual machine ad altissime prestazioni.
    * Garbage collector asincrono per diminuire il consumo di risorse.
    * Tipizzazione dinamica con dati strutturati a contenuti misti.
    * Interazione a basso livello con il sistema tramite loading di
librerie dinamiche e funzioni implementate in C.
    * Supporto sia per la programmazione procedurale, che per la
programmazione ad oggetti, ereditarietà e overloading degli operatori.
    * Gestione delle eccezioni.
    * Due librerie standard, una per la programmazione procedurale ed
un altra per la programmazione OO, che possono coesistere nello stesso
sorgente.
Vi linko il sito ufficiale 
http://www.hybris-lang.org/
 ed il
repository su github 
http://github.com/evilsocket/hybris
 .

 Linux 
Perché anche GNU?

 Perché anche GNU?
Perché Linux è il kernel, ma GNU è tutto il resto... GCC, libc ecc.
per cui GNU/Linux.

 sorgente.
perch� devono essere due librerie diverse? Non si pu� farne una sola?

 per cui GNU/Linux.
La domanda è come mai una buona conoscenza sia un requisito, non cosa 
sia GNU.
Poi scusa chi usa *BSD è fregato?

Innanzitutto grazie a tutti del vostro intervento, mi accingo a
rispondere alle varie domande .
- Perché anche GNU?
Perchè come ha detto Massimo Soricetti "Perché Linux è il kernel, ma
GNU è tutto il resto... GCC, libc ecc. per cui GNU/Linux."
- Sarebbe?
Per tipizzazione dinamica si intende che una variabile non viene
dichiarata con un tipo (come in C ad esempio), bensì la sua
dichiarazione coincide con l'assegnazione di un valore, ad esempio :
variabile = 10.234;
In seguito, la stessa variabile può assumere valori di tipo diverso,
la vm si occuperà di gestire questo "cambio" di tipo ed il garbage
collector di deallocare precedenti valori se non sono più
deferenziati, sempre seguendo l'esempio:
variabile = "ciao mondo";
- hmmmmm... un linguaggio di scripting che interagisce a basso livello
con la macchina? hmmmmmm...
Come il Python supporta la libreria ctype (o qualunque sia il nome
della versione attuale XD), Hybris supporta il linking dinamico di
librerie di sistema ed il caricamento dei simboli ivi definiti, ad
esempio :
import std.*;
dll  = dllopen( "libc.so.6" );
if( dll == 0 ){
	print( "error loading library\n" );
	exit();
}
printf = dlllink( dll, "printf" );
if( printf == 0 ){
	print( "error linking symbol\n" );
	exit();
}
for( i = 0; i < 10; i++ ){
	printf( "%d %s\n", i, "ciao" );
}
pointer = printf;
pointer( "hello da pointer\n" );
pointer( "0x%X\n", pointer );
dllclose(dll);
- perchè devono essere due librerie diverse? Non si pu farne una
sola?
Perchè la prima, quella "funzionale", è stata realizzata direttamente
in C per offrire prestazioni elevate, mentre la seconda, quella
orientata ad oggetti, è stata realizzata in Hybris partendo da queste
funzioni, "wrappandole" in classi che consentono di realizzare
software tramite il paradigma OO .
Questa dualità consente un buon compromesso tra prestazioni del
linguaggio e facilità di utilizzo delle librerie stesse.
Esempio, si poteva anche realizzare il tipo "Matrix" in Hybris usando
un vettore di vettori, ma le prestazioni sarebbero state ovviamente
più basse rispetto all'implementazione attuale in C delle primitive ed
alla classe che le wrappa.
- Poi scusa chi usa *BSD è fregato?
Guarda la roadmap della 1.0 stable prevede il porting sia per *BSD
(che cmq non dovrebbe essere un grande problema essendo il codice
POSIX compliant) che per ambienti Windows (attualmente la compilazione
sotto Cygwin va che è una meraviglia ^^), quindi ci stiamo
lavorando! :)

 sorgente.
A parte le "altissime prestazioni" :-) in quali punti chiave questa 
descrizione si differenzia da Python (e da diversi altri linguaggi meno 
diffusi)?

 
evilsoc...@gmail.com
 ha scritto:

Beh, sintatticamente parlando ovviamente son diversi, la gestione
delle classi, delle eccezioni, degli operatori ecc è diversa, la
gestione dei moduli e relativa gerarchia è diversa, molte delle
funzionalità che in python si trovano nei moduli a basse prestazioni
(poichè scritti direttamente in python, al massimo precompilati
in .pyc) sono integrate, ecc ecc ecc.
Potrei fare una lista lunghissima di differenze, ma non credo sia
questa la sede :)
Ovviamente, il Python è un linguaggio con un team di sviluppo molto +
vasto e soprattutto con tanti più anni di sviluppo alle spalle, ha una
libreria standard molto + vasta (sempre perchè ci lavorano molte +
persone), e così via ... per questo cerco dei collaboratori, per
portare Hybris al livello dei suoi "fratelloni" se non ad uno
superiore ... se Hybris fosse stato già maturo al 100% non avrei
scritto qui :)

 in .pyc) sono integrate, ecc ecc ecc.
Sintassi a parte, che sembra quella di un qualunque altro linguaggio con 
i punto e virgola (e non penso affatto che sia un difetto, ma non è 
certo un innovazione) e i dettagli come la gerarchia dei moduli, 
continuano a non essermi chiare le specificità.
Ad esempio, dici che la gestione delle eccezioni è diversa; ma è diversa 
in cosa e perché sarebbe migliore?
L'esempio dei moduli di Python è a doppio taglio: se ho del tempo da 
regalare ad un progetto, perché sviluppare un modulo per Hybris anziché 
migliorarne uno per Python? Cerca di convincermi...

Mettiamola così, Hybris più che offrire una particolarità unica (cosa
alquanto difficile considerando l'enorme gamma di linguaggi esistenti)
prende il meglio da ogni linguaggio e lo ripropone in uno solo.
Ad esempio, la sintassi e la gestione delle eccezioni è tra il
javascript ed il java (da quando supporta l'OO),
l'introspettività di ogni oggetto è simile al python (per quanto
l'overloading degli operatori è implementato in modo + chiaro a mio
avviso), alcuni costrutti son presi dal php così come alcuni tipi (in
particolare il tipo map).
Non ho voluto reinventare la ruota con questo, ma semplicemente
offrire un unico linguaggio che unisse gli aspetti più comodi (IMHO)
di quelli esistenti, con alcune caratteristiche di implementazione che
fan si che alcuni di questi aspetti siano anche superiori rispetto a
quelli del linguaggio dal quale ha tratto ispirazione.
Per rispondere alla tua domanda :
"L'esempio dei moduli di Python a doppio taglio: se ho del tempo da
regalare ad un progetto, perch sviluppare un modulo per Hybris anzich
migliorarne uno per Python?"
Innanzitutto, perchè se il modulo lo vuoi sviluppare direttamente in
C, il core di Python non astrae abbastanza questo aspetto e di
conseguenza implementare moduli/bindings/ecc scalari per Python non è
cosa facile, e anche riuscendoci va a discapito delle prestazioni,
mentre in Hybris il core è concettualmente separato sia dalla gestione
dei tipi (fondamentale per un modulo) che dal resto, quindi
implementare un modulo in C per Hybris è quasi come implementare le
funzioni in C senza preoccuparsi di "cosa c'è a monte".
Se invece intendi sviluppare un modulo Python IN Python, sarai sempre
limitato per due ragioni.
Innanzitutto, il Python per gestire l'introspezione degli oggetti
(anche un modulo è un oggetto) limita notevolmente le possibilità
dell'utente, secondo poi, il Python non offre una gamma di primitive
implementate direttamente in C che consenta prestazioni elevate.
Ho studiato MOLTO il codice del Python e posso dire che è eccelso per
quanto riguarda il core, ma per quanto riguarda la modularizzazione e
la scalabilità si sono un po persi per strada.
Lo trovo un linguaggio eccezionale ma che, se fosse stato implementato
meglio, sarebbe stato non solo eccezionale ma anche definitivo.
Uno potrebbe dirmi "Allora, invece di scrivere un linguaggio ex-novo,
xkè non contribuisci al core del Python migliorando quello che credi
che non vada?" ... semplicemente xkè per certi versi è stato
progettato male fin dall'inizio, andrebbe riscritto praticamente da
zero, di conseguenza preferisco implementare un mio linguaggio con una
mia grammatica.

 in .pyc) sono integrate, ecc ecc ecc.
Non vorrei dire, ma tutta sta cosa delle "basse prestazioni" andrebbe un
po' mostrata. In primo luogo cpython *ha* moduli critici scritti in C,
proprio dove si e' ritenuto che il beneficio fosse grande.
In secondo luogo perche' dici che la macchina virtuale di Hybris e'
cosi' veloce? 
Tra l'altro mi sembra che questa cosa della velocita' pura delle
macchine virtuali sia sostanzialmente storia vecchia. Come e' un po'
l'architettura della VM di Hybris? Perche' non hai scelto di appoggiarti
ad una qualche macchina virtuale gia' collaudata e provatamente veloce?
-- 
-riko

 mia grammatica.
Ohibo'... parlare di "progettato male" riguardo a Python e'
un'affermazione che dire... un po' forte. Come in tutte le cose, ci sono
ovviamente errori evolutivi (buona parte dei quali corretti in Python
3), ma sinceramente non conosco molti linguaggi progettati altrettanto
bene. 
-- 
-riko

 -riko
Allur, prima di tutto, io non parlo di Cython ma del Python puro, e
con questo credo di aver
risposto a circa l'80% delle sue considerazioni, il primo lo conosco
molto
poco e di conseguenza non mi esprimo in merito per non dire
castronerie su ciò che non conosco.
I bench ci sono, non sono stati documentati ne pubblicati poichè
aspetto di fixare alcuni bugs
(è inutile pubblicare un benchmark di qualcosa di comunque instabile)
e da questi emergono in alcuni
ambiti prestazioni decisamente migliori nella VM di Hybris.
Per quanto riguarda il GC, durante lo sviluppo ho provato diversi
approcci e tra tutti quanti il
reference counting è risultato il miglior compromesso, particolari
problemi in proposito non ne ho
trovati, ma detto in tutta sincerità è la prima volta che mi trovo a
scrivere un gc per qualcosa di
così complesso, quindi potrei aver sottovalutato/non visto alcuni
aspetti ed in tal proposito la invito
ad illuminarmi (non è sarcasmo, dico seriamente).
Per il "progettato male", intendevo dire che --> IMHO <-- trattare
TUTTO come un oggetto, per quanto sintatticamente
e logicamente parlando possa essere un pregio, a livello prestazionale
non lo è.
Sempre a mio avviso, tipi base come stringhe, interi, float, booleani,
ecc andrebbero trattati come tipologie primitive
ed eventualmente wrappati in classi, così facendo si ha lo stesso
risultato ma con prestazioni più elevate.
Tutto questo, lo ripeto, lo dico dal basso della mia esperienza in
merito.
Più che affermazioni certe sono semplicemente mie personali
osservazioni ... è la prima volta che scrivo un linguaggio
e le relative strutture, ho imparato più cose in questo anno che in
tutti gli anni che programmo, quindi chiedo ai partecipanti
del thread di perdonare mie eventuali imprecisioni o affermazioni che
possono sembrare "forti" ma che sono poco
più che "pensieri ad alta voce" .

 con questo credo di aver risposto a circa l'80% delle sue considerazioni,
Enrico si riferisce a CPython, quello che tu definisci "python puro".
CPython != Cython

 un'affermazione che dire... un po' forte.
Se c'è una cosa fatta male, o almeno che a me non piace, è come gestisce 
lo stato di esecuzione.
Basta prendere Lua come contro esempio.
In CPython usare sotto interpreti ha diversi problemi.
Se finalizzi l'interprete e poi lo reinizializzi, hai dei memory leak.
Ciao  Manlio


Ops chiedo venia, avevo semplicemente letto male (conosco la
differenza tra CPython e Cython XD).

On 29 Apr, 16:33, Manlio Perillo <manlio_perill...@SPAMlibero.it>
wrote:

Manlio a cosa ti riferisci esattamente con "stato di esecuzione" ?

 Manlio a cosa ti riferisci esattamente con "stato di esecuzione" ?
http://docs.python.org/c-api/init.html#thread-state-and-the-global-
interpreter-lock
Ciao  Manlio

 pi� che "pensieri ad alta voce" .
Ma sono assolutamente convinto che tu abbia imparato tantissimo. Quello
che vorrei suggerirti e':
1.  non concentrarsi sulle perfomance, in realta' non interessano a 
    nessuno[0]
2.  prima di fare scelte con un fortissimo impatto a lungo termine, 
    studia bene pro e contro. Non stai toccando, nel campo dei 
    linguaggi, argomenti di frontiera. Ovvero trovi tutta la 
    documentazione possibile ed immaginabile. 
-----
[0] ci sono fortissime evidenze che passare per bytecode porti a grossi
    vantaggi di efficienza (e da quanto capito, tu non lo fai). inoltre,
    avere un JIT (o analogo) *straccia* qualunque confronto (e tu non lo
    hai).
Insomma, se uno ha bisogno del tipo di performance per cui hybris puo'
(eventualmente) essere 0.x volte piu' veloce di $Lang vorra' piuttosto
passare ad altre categorie di linguaggi che sono y volte piu' veloci di
hybris, con y facilmente > 10.
Traducendo: Java e' imbarazzantemente piu' veloce di tutto il cioppo dei
linguaggi dinamici. Idem C#. Se tu vai il 30% piu' veloce, e'
completamente irrilevante, specie in quanto ormai il gioco e' quasi
tutto sulla scalabilita' orizzontale e concorrenza.
-- 
-riko

 lo stato di esecuzione.
Non piace nemmeno a me, ma a naso e' un problema di cpython, non del
linguaggio.
-- 
-riko

 garbage collector alla quale ti rimanderei.
Verissimo, ma già devo essere "responsabile" quando sono a lavoro,
quando scrivo software per divertimento (perchè è di questo che in
fondo si tratta, non dimentichiamolo) tendo un po a fregarmene delle
regole che di solito seguo nella progettazione e a "buttarmi" un po,
così tanto per imparare sulla mia pelle i vari pro e contro di
approcci differenti invece di leggerli semplicemente da qualche parte.
Per il resto mi trovo d'accordo con lei e la ringrazio vivamente dei
consigli ... purtroppo sviluppando Hybris da solo, non ho avuto molti
scambi di opinioni ne un gran riscontro, quindi sono andato avanti
senza sapere effettivamente se quello che stavo facendo era giusto o
meno ... per questo ho bisogno di collaboratori :)

 meno ... per questo ho bisogno di collaboratori :)
Erano *anni* che non vedevo dare del lei da un tecnico ad un altro
tecnico su usenet. Anzi, non ne ho proprio memoria. La prassi comune e'
di dare a tutti del tu, a prescindere da eta', anzianita' e skill. 
A parte questo (per cui ti invito *assolutamente* a dare del tu a me a
tutti quelli che partecipano a questa discussione) contribuire ad un
progetto e' una cosa impegnativa. Io personalmente ho un sacco di
progetti e impegni, per cui ti mentirei dicendo di poterti aiutare
"fattivamente". A discutere e parlare sono invece piu' che disponibile.
Anche se, non sempre, riesco a farlo con prontezza.
-- 
-riko

 Anche se, non sempre, riesco a farlo con prontezza.
Ahah non sapevo funzionasse così, allora darò del tu a tutti :)

 Ahah non sapevo funzionasse cos�, allora dar� del tu a tutti :)
Beh, ci diamo *tutti* del tu. ;)
-- 
-riko

 Quale hai scelto? Bohem?
Intendi quello già pronto e confezionato che si trova in giro? In tal
caso no, ho implementato da zero il gc ... ho trovato l'algoritmo mark
and sweep talmente semplice (concettualmente parlando) che mi son
voluto divertire a scriverlo, considerando che, per puro caso (vorrei
poter dire per mia lungimiranza, ma sono onesto dai :D), la gestione
della memoria di Hybris è praticamente perfetta per il mark and sweep,
sembra fatta apposta :D.

 sembra fatta apposta :D.
Voglio dire, per forza che funziona mark&sweep. ;)
Io poi sinceramente non capisco il tuo interesse nell'efficienza se ti
reimplementi a mano i vari algoritmi di base. Tipicamente le
implementazioni testate hanno una serie di truccacci che migliorano
molto le performance. Questo mi sembra piu' tipico di un progetto
didattico.
-- 
-riko

 didattico.
Invece proprio perchè le implementazioni "testate" che ho trovato non
davano
le prestazioni che volevo le ho riscritte.
Ad esempio (tanto per dirne una), std::map, boost::unordered_map (o
una cosa del genere, nn ricordo come si chiamasse), ecc ecc
sono molto + lente nel lookup delle funzioncine stupide stupide che mi
son scritto io.

 son scritto io.
std::map e' O(log n), unordered_map e' avg O(1). Una lavora su enti
ordinati, l'altra su hashabili. Non e' esattamente che siano la stessa
cosa. Il problema che hai misurato in che situazioni si presenta? Che
benchmarks hai usato? Su che hardware? Chi ha scritto le funzioni di
hashing e di confronto? Profilando il codice, quanta della differenza di
performance era relativa alle funzioni di hashing/confronto e quanta al
codice di gestione della struttura dati? Quanta all'allocazione
deallocazione? Sono reperibili/riproducibili in qualche modo questi
dati?
-- 
-riko

 [...]
Ciao  Manlio

 dati?
La situazione era la più banale in assoluto, chiavi come char * e
valori come
void * per generalizzarne l'uso.
In tutta onestà, non ho eseguito benchmark e profiling tanto
approfonditi da capire
PERCHE' le prestazioni non mi soddisfavano, ho solo contato i micro
secondi
su 100.000 insert e 100.000 find nell'implementazione std e nella mia
implementazione,
e nel secondo caso le prestazioni erano molto più elevate, di
conseguenza me ne son
fregato del perchè e del percome e ho optato per una mia
implementazione.
Se poi esiste un qualche tipo di classe nello std o in boost che fa al
caso mio e mantiene
prestazioni analoghe, se non superiori, a quanto ho implementato,
questo non lo so, ma
considerando che ne ho provate parecchie dubito.

 fare un esempio, che per� non credo usi Bohem).
Di quale implementazione di D parli? Quella ufficiale o quella del GCC?
Per inciso, non mi risulta che Bohem abbia piu' problemi di quelli che
ha un qualunque garbage collector. Ad ogni modo, sostiuire pure Bohem
con un qualunque GC funzionante contro "il mio piccolo GC fatto in
casa".
Comunque GHC non usa Bohem. Il GC che usano e' frutto di un progetto di
ricerca fatto a MS Research ed e' tutt'ora soggetto a continui studi ed
ottimizzazioni specifiche per Haskell (che e' un linguaggio pesantemente
diverso dai linguaggi "tradizionali" per cui e' stato creato Bohem).
-- 
-riko

 [...]
Ciao  Manlio

 Da circa un anno (o poco pi�), sto lavorando su un nuovo linguaggio di
....
Io non sono in grado di aiutarti ma mi limito a farti i complimenti per
l'iniziativa (che per una buona volta arriva dall'italia).
Ciao
-- 
Luca
http://www.codingace.it/userdetail.aspx?userid=2

Grazie mille Luca :)