alerighi
commented
6 years ago Aggiungo questioni più tecniche riguardanti questo progetto.
L'aggiunta di un linguaggio lato soluzione consiste nello scrivere principalmente:
- un generatore di codice, ossia una sorta di compilatore che traduce degli statement generici in codice nella sintassi particolare linguaggio
- il codice necessario a dare i comandi per compilare e mandare in esecuzione il programma
- una piccola sandbox, ossia un sistema che restringa le operazioni che il programma può fare. Non serve un isolamento completo (in quanto di per se TuringArena gira già in container Docker), ma è necessario un isolamento per evitare che lo studente possa barare (esempio, leggere file temporanei creati dal valutatore)
- dei test e delle soluzioni ai problemi di esempio, per verificare che tutto funzioni correttamente
L'implementazione di un linguaggio lato problema invece consiste nello scrivere una piccola libreria che contenga delle classi che consentono di comunicare con TuringArena. Questa libreria andrà a comunicare a TuringArena mediante delle pipe su cui scriverà e leggerà secondo un protocollo che è già implementato.
Naturalmente, per fare tutto questo si può prendere spunto e copiare/incollare molto codice dai linguaggi che sono già implementati in TuringArena. Per molti linguaggio quindi l'implementazione è quasi meccanica, c'è solo da mettersi a farla, soprattutto per i linguaggi imperativi.
Attualmente, i linguaggi completamente implementati lato problema sono:
- C
- C++
- Python3
- Java
I linguaggi parzialmente implementati sono:
- Go, manca la sandbox
- Bash, manca il supporto a callback e array, e ci sono alcuni bug che lo fanno piantare
- JavaScript, ci sono diversi bug da risolvere
Alcune idee di nuovi linguaggi da implementare invece:
- Rust
- OCaml
- Haskell
- Lisp
In particolare, credo sia utile supportare almeno un linguaggio di programmazione funzionale.
I linguaggi implementati lato problema sono invece solamente C++ e Python3. Si potrebbe pensare di aggiungere a questi Java, ma anche qualsiasi altro linguaggio venga in mente.
La nostra grande scommessa attuale è il sistema e progetto open-source TuringArena (vedi documentazione)
Una delle caratteristiche di questo sistema, caratteristica unica nel caso di problemi dove la valutazione richieda un'interazione tra codice sottomesso e codice valutatore, è l'indipendenza dal linguaggio di programmazione. Tale indipendenza si ottiene facendo confrontare i codici da valutare (collaborativi od antagonisti, più tipicamente e tradizionalmente uno solo: la soluzione ad un problema algoritmico), ed il codice di valutazione, entro una sandbox. I codici sviluppati dagli attori (il valutatore del problem-poser ed il solutore o bot del problem-solver o dei players) vengono embeddati in codici di libreria che consentono a detti codici di comunicare tra loro (ad ogni ogni passaggio, quale ad esempio la chiamata di una funzione) per serializzazione dei dati tramite file (standard POSIX). Questi wrapper d'uso compilati insieme ai codici di pura soluzione e valutazione prodotti dai problem-solver sono a loro volta generati automaticamente a partire dal file interfaces.txt dove il problem-poser ripone (utilizzando un linguaggio ad-hoc, semplice e povero) una descrizione dei protocolli di comunicazione coinvolti nell'estricazione del suo gioco didattico a due o più giocatori.
Attualmente in TuringArena abbiamo il supporto per C/C++ e per Python sia sul lato problem-solver (ossia la generazione dei wrapper che si legano alla soluzione prodotta dal problem-solver od ai bot/gladiators prodotti dai players) che sul lato problem-maker.
E' così confermato che virtualmente TuringArena supporta ogni linguaggio, un problema scritto oggi in Pascal da un'anziano docente di scuola superiore che nel suo contesto non ha alcuna valida ragione di apprendere un nuovo linguaggio, può valutare soluzioni scritte in qualsiasi altro linguaggio di programmazione, anche del futuro. Ovviamente, questa importante potenzialità trova attuazione quando qualcuno sviluppa il supporto per un particolare linguaggio. Il supporto ad un liguaggio può essere curato, in modo del tutto indipendente, sul lato problem-solver o sul lato problem-poser. Il primo tipo di supporto è più facile da sviluppare, e siamo pronti a delegare, sul secondo si possono affacciare, a seconda del linguaggio, delle questioni più delicate e/o che richiedono il lavoro venga fatto con la dovuta sensibilità. Questo giustifica la differenza sui punti messi in palio.
In particolare, saremmo molto interessati ora allo sviluppo dei supporti per sperimentare un primo linguaggio funzionale. Pensavamo in particolare ad OCaml, sia in quanto linguaggio mutiparadigma che essendomi stato richiesto in particolare da dei colleghi francesi.
Ad ogni modo, ogni linguaggio che vogliate aggiungere vi assicura quantomeno i punti indicati nel preambolo della scheda.