[Generico] Nimrod: The Return of Pascal

[nico159]

Ho notato questo articolo riguardante un nuovo linguaggio, Mimrod:
http://steved-imaginaryreal.blogspot...of-pascal.html

Ho trovato il linguaggio così interessante, che ho voluto condividerlo anche qua

http://nimrod-code.org/tut1.html
http://nimrod-code.org/tut2.html

Qualcuno ha dei pareri al riguardo?

Ovviamente è un linguaggio nuovo, quindi librerie e tools scarseggiano

[cdimauro]

Il fatto che sia ispirato al Pascal mi mette l'acquolina in bocca, ma al momento non ho tempo per dargli un'occhiata. Vediamo se posso questo fine settimana.

Anche se, come hai già detto tu, il problema dei nuovi linguaggi è quello che ci sono poche librerie e sono poco supportati. Questo, ormai, è un elemento molto importante, a prescindere dalla bontà stessa del linguaggio.

[cdimauro]

Ho letto circa metà del primo tutorial e un circa un quarto del post del blog.

Tutto sommato la commistione di Python (perché come base trovo che parta da questo, piuttosto che dal Pascal) mi piace, anche se alcune soluzioni che ha adottato non mi piacciono o mi fanno storcere decisamente il naso.

Penso all'operatore & per concatenare le stringhe, ma soprattutto al finally: piazzato all'inizio della procedura e allo stesso livello di indentazione delle altre istruzioni. Assolutamente non condivisibili.

Non mi piace, poi il fatto che non utilizzi la type inference anche per il valore restituito da una procedura. Un piccolo sforzo poteva essere fatto anche in questa direzione.

Altra cosa che non mi garba sono i commenti multilinea o che devono essere allineati al blocco attuale.

Infine funzioni come low e high applicate a un intervallo le avrei evitate, preferendo un paio di attributi tipo .low e .high o, al massimo (ma non mi piace molto), come metodi.

Per il momento è tutto. Non so se avrò tempo per leggere altro. Al momento il mio giudizio è più positivo che negativo: c'è tanta roba interessante, e meno cose che non mi aggradano.

[nico159]

Non mi piace, poi il fatto che non utilizzi la type inference anche per il valore restituito da una procedura. Un piccolo sforzo poteva essere fatto anche in questa direzione.

Sto testando un pò il linguaggio anche io
Puoi usare auto al posto di dichiarare il tipo di ritorno

[cdimauro]

Ho finito di leggere il blog, ma ho trovato sostanzialmente critiche per alcune scelte. Le riporto ugualmente, perché magari possono interessare. Eccole di seguito.

type
     TChars = range['A'..'C']

Sarebbe stato meglio:

type
     TChars = 'A'..'C'

perché 'A'..'C' identifica già un intervallo, e che si tratti di un nuovo tipo è evidenziato anche dalla keyword type.

Per i parametri passati per riferimento trovo che sia più comoda la sintassi del Pascal, che piazza la keyword var all'inizio di un elenco di parametri. In questo modo si sarebbero potuti marcare come var diversi parametri, anziché soltanto uno alla volta.

Non capisco per quale motivo il risultato di una funzione dev'essere scartato manualmente. Quale valore aggiunto porta questa decisione?

Le tuple, al contrario di quanto asserito, non sono come le tuple in Python. Sono, invece, come le struct in C, e sono anche mutabili. Mentre in Python sono anonime (ci sono le named tuple per assegnare dei nomi ai valori) e immutabili.

Peccato per l'uso di append anziché add come nome del metodo per appendere nuovi valori alle liste.

Non trovo corretto che con import vengano importati tutti i simboli di un modulo nel namespace. Sarebbe stato meglio dare visibilità al solo modulo, ed esplicitare i casi di importazione di tutto.

La definizione delle classi e dei metodi non mi spiace. E' verbosa e dispersiva. Avrei preferito qualcosa che incapsulasse tutto nella definizione, delegando magari fuori, a un'apposita sezione del codice, tutta o una parte dell'implementazione. E' una delle cose che digerisco di meno, come pure il dover creare manualmente l'istanza con new(result). Si poteva pensare a una soluzione stilistica di gran lunga migliore.
Devo vedere, invece, come funziona concretamente il concetto di dispatch-tree al posto della classica Virtual Method Table.

Mi piace l'idea dei generic "automatici", anche se trovo più leggibile la sintassi più esplicita (in cui si specifica un tipo opaco).

Stringhe mutabili... no. Non se ne sentiva il bisogno. Magari come tipo a parte sarebbe stato preferibile.

La sintassi per le procedure anonime è troppo verbosa e complessa. Decisamente poco pratica e poco intuitiva.

L'operatore $ per la convertire in stringa non mi piace. Sarebbe stato meglio mettere a disposizione un magic method, che avrebbe aumentato anche la leggibilità del codice.

Per adesso è tutto. Non so, però, se continuare coi tutorial, con questo spirito troppo critico. Ma forse dipende dal fatto che ho la mia idea di come dovrebbero andare le cose e come dovrebbe essere realizzato un linguaggio staticamente tipizzato, e non riesco proprio a farmi piacere le scelte fatte da altri. Limite mio, sia chiaro, ma voglio essere onesto ed esprimere esattamente ciò che penso.

[Shirov]

Anche io ci avevo speso un po' di tempo e tutto sommato mi trovo allineato con quanto detto di Cesare, forse reputo le pecche elencate un po' meno gravi dal punto di vista del gradimento ma lì è una questione di gusti. Onestamente tutti i linguaggi hanni limiti e carenze ma la più grave, per linguaggi come Nimrod, è quella dei tempi e dell continuità di sviluppo. Ormai di questi strumenti ce ne sono a centinaia e alcuni sarebbero anche davvero molto validi. Penso ad esempio a Cobra (forse quello messo meglio), ancor di più a Falcon (eccellente linguaggio creato da un italiano)... ma come fai a prendere i mano strumenti che ci mettono 4 o 5 anni per passare dalla fase alpha alla 1.0? Anche Clay era un linguaggio interessante, per fare un altro esempio... ma da luglio dello scorso anno non viene aggiornato... Wirbel, il "Python compilato" nato e morto in un paio d'anni. Per un Python o un Ruby ce ne sono altri 100 che passano inosservati anche si tratta di cose eccellenti. Altro problema è quello riguardante la documentazione.... come si fa a promuovere un linguaggio se la gente deve disperatamente cercare tra i sorgenti solo per far leggere una stringa di input dalla tastiera? La documentazione deve essere ampia, chiara ed aggiornata.... un controesempio, a mio avviso, è Fantom, linguaggio eccellente con molte caratteristiche interessanti ma l'organizzazione del materiale al suo riguardo è molto rigida e approssimativa..... Se si è interessati ai linguaggi "per diletto" va bene tutto... azzeccare "the next big thing" invece è un terno al lotto.... forse andrei con uno tra Rust, Go, Ceylon, Kotlin e Julia perchè hanno alle spalle team non dipendenti da un singolo sviluppatore... poi magari la gente adotterà in massa, che so, Ya, creato di recente da uno schizzato russo... ma chi può dirlo....

[cdimauro]

Infatti. Ormai abbiamo strumenti comodi per smanettare e tirare fuori nuovi linguaggi, per gioco o per qualcosa di più serio. Ma il loro futuro è una grande incognita per le motivazioni che hai ben esposto.

Per avere delle discrete possibilità di diffusione, credo che oggi un nuovo linguaggio debba avere un team alle spalle, che garantisca continuità.
Una cosa che potrebbe incoraggiare molto è se fosse basato su un altro linguaggio, di cui sarebbe quindi un'estensione o dal quale comunque prenderebbe molto, in modo da favorire un passaggio più morbido agli utenti. Ma questo rappresenta anche un grosso freno all'innovazione e alla creatività...

[epimerasi]

Originariamente inviato da cdimauro

Infatti. Ormai abbiamo strumenti comodi per smanettare e tirare fuori nuovi linguaggi, per gioco o per qualcosa di più serio. Ma il loro futuro è una grande incognita per le motivazioni che hai ben esposto.

Per avere delle discrete possibilità di diffusione, credo che oggi un nuovo linguaggio debba avere un team alle spalle, che garantisca continuità.
Una cosa che potrebbe incoraggiare molto è se fosse basato su un altro linguaggio, di cui sarebbe quindi un'estensione o dal quale comunque prenderebbe molto, in modo da favorire un passaggio più morbido agli utenti. Ma questo rappresenta anche un grosso freno all'innovazione e alla creatività...

A proposito (semi-OT), ma il tuo progetto wpython?

[cdimauro]

E' fermo causa assoluta mancanza di tempo.

Le idee ci sono per migliorare (penso pure di molto) le prestazioni, ma non trovo spazio per implementarle.