alvisespano
commented
6 years ago Ti dico in breve cosa penso degli interessanti spunti che hai proposto:
1) la PMP spec dovrebbe essere solo in inglese. Anche all'epoca lo pensavo, ed oggi lo penso ancora di più. Il motivo per cui avevo scritto la guida in italiano era solamente perché il polygen era rivolto ad un pubblico italiano che tipicamente non sa l'inglese; non aveva presa all'estero perché le grammatiche facevano ridere solamente persone italiane, quindi la community italiana era l'unica da coltivare. E così è stato. Gli anglosassoni non si sono mai avvicinati perché non c'erano grammatiche buone in inglese, non perché macava il manuale. Il manuale inglese c'è sempre stato ed il fatto che non fosse allineato con le ultimissime feature è del tutto irrilevante, secondo me: il grosso di ciò che serviva c'era e c'è sempre stato. Il sito stesso aveva la modalità inglese, con tutte le parti tradotte - l'abbiamo tolto nel 2007, tipo, perché non avevamo visite. La community internazionale va conquistata con cose diverse dalla community italiana a cui basta farsi due risate. Oppure vedila così: se fossimo stati in grado di replicare in inglese lo stesso humour delle grammatiche italiane, e con la stessa qualità e quantità, allora avremmo avuto una chance.
2) Sto pensando di fare il colpaccio e portare Polygen in F#, che è il linguaggio più vicino ad OCaml avente un buon IDE (VS). Portarlo in F# è un lavoro che durerebbe poco, ed aprirebbe la strada ad un comfort senza precedenti per quanto riguarda lo sviluppo: visual studio è uno dei migliori IDE del mondo ed il supporto ad F# è grandioso. Inoltre io lavoro moltissimo con F# e VS in generale, qunidi ho una familiarità totale. Quali sono gli svantaggi però? Che F# compila solo per .NET e bisognerebbe usare mono ed altre cagate del genere per farlo funzionare dappertutto. Insomma, Tristano, 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.
3) spiegami meglio l'impatto delle questioni delle licenze, perché non ho capito bene.
Il giorno 20 gennaio 2018 11:30, Tristano Ajmone notifications@github.com ha scritto:
Alcune considerazioni sulla Polygen Meta Language Spec.
Alla luce degli innumerevoli problemi nella compilazione con OCaml (ulteriori ricerche mi hanno confermato che installare OCaml su Windows 10 è problematico), credo che la ristampa di questi documenti acquisti ulteriore importanza.
Una definizione formale della specifica PML, soprattutto in inglese, faciliterà il compito a chiunque volesse implementare Polygen in altri linguaggi — e credo che questa possibilità sia realistica visto che ho già individuato un simile tentativo in Haskell, ed esisteva anche un port per telefonini in passato.
Fosse anche che qualcuno dovesse implementarlo in qualche linguaggio di scripting (es: Python, Ruby, Javascript) per semplificarsi il lavoro sfruttando l'esistenza di librerie di lexing and parsing, sarebbe comunque ottimo.
Quanto ai binari Windows, credo che questi seguiteranno a funzionare per parecchi anni dato che Windows ha comunque sempre offerto la possibilità di eseguire applicazioni in modalità compatibilità, e per quanto riguarda la DLL di Cygwin, questa verrà sempre aggiornata dato l'elevato numeri di applicazioni che dipendono da essa. E comunque, non è detto che prima poi OCaml per Windows non venga rimesso a nuovo (anzi, direi che Andreas Hauptmann https://fdopen.github.io/opam-repository-mingw/installation/ sta lavorando attivamente in quella direzione).
Alla fine dei conti, dato che ad oggi ci ritroviamo con dei binari Polygen funzionanti, vale la pena investire energie più nella direzione della documentazione che non dello sviluppo (o riscrittura) del Polygen stesso (soprattutto visti i molteplici problemi con OCaml).
Credo che se la documentazione inglese non fosse stata incompleta (nonché poco visibile e pubblicizzata) in tutti questi anni (oltre 10!) il Polygen si sarebbe diffuso molto di più nel mondo, e avremmo assistito a svariati tentativi di porting ad altri linguaggi. Il fatto che la documentazione inglese delle grammatiche fosse incompleta deve averne ostacolato l'uso (e quindi anche la diffusione) nel mondo anglofono.
Spero quindi che la ristampa di questi documenti, e la nuova edizione inglesa completa sulla PML possano dare una spinta di rinnovamento al Polygen.
Credo sarebbe utile in tal senso una chiarifica riguardo la licenza GPLv2. Essa, mi par di capire, concerne solo il programma e la documentazione, e non lo standard del metalinguaggio PML, giusto? Ossia, la spec di PML è libera, e chiunque può implementarla in altri linguaggi senza i vincoli della GPLv2?
Varrebbe la pena specificare questo punto in entrambi i documenti.
Altresì, andrebbe considerata l'idea di ufficializzare la spec in qualche modo, chiarendo quale sia il suo riferimento originale, di modo che eventuali varianti da essa possono essere chiaramente percepite come tali. Magari, alla fine del lavoro di ristampa, potresti clonare il progetto sotto il tuo account così da ufficializzarlo e auto-linkarlo nei documenti stessi. GitHub offre anche la possibilità di associare un sito a ciascun progetto, e si potrebbe pensare di pubblicare il documento di specifica inglese come sito pubblico.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tajmone/polygen-docs/issues/4, or mute the thread https://github.com/notifications/unsubscribe-auth/ACcZxjfwVYzGwKAcUjE1bbgxIHEsK9QMks5tMcA4gaJpZM4RlY4R .
tajmone
Alcune considerazioni sulla Polygen Meta Language Spec.
Alla luce degli innumerevoli problemi nella compilazione con OCaml (ulteriori ricerche mi hanno confermato che installare OCaml su Windows 10 è problematico), credo che la ristampa di questi documenti acquisti ulteriore importanza.
Una definizione formale della specifica PML, soprattutto in inglese, faciliterà il compito a chiunque volesse implementare Polygen in altri linguaggi — e credo che questa possibilità sia realistica visto che ho già individuato un simile tentativo in Haskell, ed esisteva anche un port per telefonini in passato.
Fosse anche che qualcuno dovesse implementarlo in qualche linguaggio di scripting (es: Python, Ruby, Javascript) per semplificarsi il lavoro sfruttando l'esistenza di librerie di lexing and parsing, sarebbe comunque ottimo.
Quanto ai binari Windows, credo che questi seguiteranno a funzionare per parecchi anni dato che Windows ha comunque sempre offerto la possibilità di eseguire applicazioni in modalità compatibilità, e per quanto riguarda la DLL di Cygwin, questa verrà sempre aggiornata dato l'elevato numeri di applicazioni che dipendono da essa. E comunque, non è detto che prima poi OCaml per Windows non venga rimesso a nuovo (anzi, direi che Andreas Hauptmann sta lavorando attivamente in quella direzione).
Alla fine dei conti, dato che ad oggi ci ritroviamo con dei binari Polygen funzionanti, vale la pena investire energie più nella direzione della documentazione che non dello sviluppo (o riscrittura) del Polygen stesso (soprattutto visti i molteplici problemi con OCaml).
Credo che se la documentazione inglese non fosse stata incompleta (nonché poco visibile e pubblicizzata) in tutti questi anni (oltre 10!) il Polygen si sarebbe diffuso molto di più nel mondo, e avremmo assistito a svariati tentativi di porting ad altri linguaggi. Il fatto che la documentazione inglese delle grammatiche fosse incompleta deve averne ostacolato l'uso (e quindi anche la diffusione) nel mondo anglofono.
Spero quindi che la ristampa di questi documenti, e la nuova edizione inglesa completa sulla PML possano dare una spinta di rinnovamento al Polygen.
Credo sarebbe utile in tal senso una chiarifica riguardo la licenza GPLv2. Essa, mi par di capire, concerne solo il programma e la documentazione, e non lo standard del metalinguaggio PML, giusto? Ossia, la spec di PML è libera, e chiunque può implementarla in altri linguaggi senza i vincoli della GPLv2?
Varrebbe la pena specificare questo punto in entrambi i documenti.
Altresì, andrebbe considerata l'idea di ufficializzare la spec in qualche modo, chiarendo quale sia il suo riferimento originale, di modo che eventuali varianti da essa possono essere chiaramente percepite come tali. Magari, alla fine del lavoro di ristampa, potresti clonare il progetto sotto il tuo account così da ufficializzarlo e auto-linkarlo nei documenti stessi. GitHub offre anche la possibilità di associare un sito a ciascun progetto, e si potrebbe pensare di pubblicare il documento di specifica inglese come sito pubblico.