Polygen-PHP

Ai fini della continuità storica di questo thread, ritengo opportuno segnalare (sebbene in mostruoso ritardo) l'implementazione in PHP del Polygen (Polygen-PHP) realizzata da @RBastianini (Riccardo Bastianini, utente già presente e attivo sul gruppo FB) nel maggio del 2020 (ossia, in seguito a questa conversazione).

https://github.com/RBastianini/polygen-php

Ho provveduto ad aggiornare i due wiki del Polygen su GitHub (inglese ed italiano) aggiungendo il link a Polygen-PHP, con una succinta descrizione.

Sebbene non abbia ancora avuto modo di testarlo, mi pare di capire che questa nuova implementazione sia 100% compatibile con le grammatiche del Polygen originale. Si tratta quindi di un grosso passo avanti per quanto concerne l'integrazione del Polygen nei siti web, grazie alla facilità di integrazione del PHP con qualsiasi sito web.

Questo port del Polygen è un'ottima notizia perché conferma quanto l'interesse per il Polygen sia ancora vivo — e, ovviamente, porta una boccata d'aria fresca per i suoi utilizzatori storici, i quali finalmente potranno sciupare il proprio tempo libero implementando grammitiche per la generazione di testi casuali e privi di senso per adornare i loro siti web, dando così libero sfogo al lato oscuro dell'animo umano che è troppo spesso sublimato o represso.

La saga del Polygen è tutt'altro che finita, e la sua eredità è un fardello di cui non ci sbarazzeremo così facilmente. Simile al Golem di Praga, il Polygen è ormai un mostro animato da vita prorpia, totalmente fuori controllo e per il quale non vi è alcuna parola magica che possa essere incisa sulla sua fronte e provi un fine (a meno che @alvisespano non abbia inserito una backdoor per l'autodistruzione, in previsione di un simile scenario apocalittico).

Grazie Riccardo!

from polygen-docs.

from polygen-docs.

1. la PMP spec dovrebbe essere solo in inglese.

Mi trovi daccordissimo.

Punto 2

Quali sono gli svantaggi però? Che F# compila solo per .NET

Mhhhh, sul Mac non sarebbe un problema il .NET, ma su altre piattaforme sì.

siamo nel 2018 e ancora non esiste una soluzione al 100% al problema: o i linguaggi sono cross-platform ma sono linguaggi penosi, oppure i linguaggi belli hanno strumenti ed accessori al contorno penosi. E' incredibile ma non c'è un linguaggio eccellente che sia anche portabile ovunque e con un buon ambiente di sviluppo pulito e chiaro.

Mi verrebbe da dire che, tuttosommato, il buon vecchio Ansi C potrebbe essere una buona soluzione per crare una libreria di Polygen, con API, e poi lasciare che l'interfaccia CLI la si implementi in vari linguaggi. Questo garantirebbe una portabilità praticamente universale del cuore di Polygen (non solo Win, Mac e Linux, ma anche i vari processori ARM, e quindi telefonia, etc).

Io in questo periodo mi sto avvicinando al linguaggio Nim (attrazione dovuta a curiosità, quello che ho letto mi ha colpito, ma non è che lo conosca). Nim non ha ancora raggiunto la 1.0, quindi anche se è operativo non è ancora ufficialmente pronto all'uso — però l'ho installato più volte su Win (procedura semplice e non invasiva), e funziona:

https://nim-lang.org/

È un linguaggio versatile che supporta diversi compilatori (GCC, MSVS, e CLANG), si integra bene con librerie C e Cpp. Per molti versi è ispirato a Python, ma in versione compilabile. Nim compila i propri sorgenti da Nim a C, e poi compila il C con i vari compilatori (ma supporta anche la compilazione da Nim a Javascript, anche se è sperimentale per ora).

Di base è un procedurale, ma il suo paradigma è elastico e abbraccia anche quello funzionale e la programmazione ad oggetti (cerca di prendere da tutto un po'). Essendo fortemente orientato alla metaprogrammazione, è possibile adattare il linguaggio alle proprie esigenze (mi pare di capire, ma poi non ho ancora trovato il tempo di dedicarmici seriamente).

Iniziano a spuntare parecchie librerie per Nim, e per il resto basta scrivere un wrapper per libererie in C/C++. Per esampio, c'è già una libreria PEG parser in Nim, pronta all'uso.

Quanto alle IDE, funziona benissimo con VSCode (ma anche con Atom e Sublime Text).

Il fatto è che i nuovi linguaggi spuntano come funghi. Sulla carta promettono tutti bene, ma poi sarà solo il tempo (e le mode) a determinare se si evolveranno bene e se sopravviveranno.

Punto 3

Per la licenza volevo dire questo: la PML quali sintessi è uno standard aperto? Nel senso che uno volesse creare un programma tipo Polygen ma scrivendolo da zero (quindi non derivato dal codice GPL), facendo però in modo che rispetti al 100% la notazione PML, non sarebbe vincolato dalla GPL, giusto?

PML quale notazione è libera? allo stesso modo in cui HTML e CSS lo sono? Chiunque può creare software che la implementi? (a differenza di standard proprietari, come MP3 Pro, ad esempio, che è un marchio registrato e ci vuole la licenza)

from polygen-docs.