Parzialmente correlato, articolo vecchio ma interessante.
http://www.red-lang.org/2016/07/nati...7-loc.html?m=0
Red e in generale i linguaggi REBOL like mi stupiscono sempre
Parzialmente correlato, articolo vecchio ma interessante.
http://www.red-lang.org/2016/07/nati...7-loc.html?m=0
Red e in generale i linguaggi REBOL like mi stupiscono sempre
"Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares
Sì, intendevo implementazione in senso lato... se vuoi nel senso di "istanziazione concreta" della più generale classe dei linguaggi di derivazione Lisp.
È uno standard, c'è tanta roba (librerie) già scritta, ci sono implementazioni robuste e relativo tooling e che non spariranno dall'oggi al domani, c'è tanta documentazione in proposito, se cerco qualcuno che lavori ad un progetto in CL è probabile che lo trovi (al netto del fatto che già trovare un lisper rispetto ad un programmatore Java è cosa complicata).Per i principi sono d'accordo anch'io, la mia domanda è perché uno dovrebbe scegliere razionalmente CL e non altre alternative?
Ha buone capacità di metaprogrammazione e in questo siamo d'accordo tutti, ma la sintassi è quella che è e soprattutto CL (nello specifico) è secondo me molto prolisso. E le parentesi non aiutano quando devi scrivere tanto.
Tutti questi "corollari" ad un linguaggio quando poi ti trovi nel "mondo vero" e devi scriverci progetti veri (con magari un orizzonte temporale di una decina d'anni) sono importanti; ti faccio qualche esempio sparso di cose dove la "sexyness" del progetto non c'entra niente con la viabilità effettiva di utilizzo "nel mondo vero":
- nim; linguaggio di sicuro interesse e con un sacco di idee interessanti; un mio collega ha provato a scriverci qualcosa per divertimento, ha passato i successivi tre giorni a discutere e a riportare bug all'autore del compilatore; in ogni caso, è un one-man project; magari diventa il prossimo Lua (progetto con una community ricca), magari diventa Haxe (prodotto solido ma ancora oggi one-man-project, se l'autore viene investito da un tram domani chi lo sostituisce?), magari lui si stufa e nim sparisce nel nulla;
- GTK+; la documentazione è oscena e la gestione del progetto (specie da GTK3 in poi) è pessima: il ramo GTK2 è abbandonato, per passare a GTK3 di fatto è necessario un rewrite; ha convinto addirittura Linus Torvalds a scappare da C + GTK a C++ + Qt; se avessi un progetto scritto in GTK2, oltre ad aver bestemmiato fino a ieri per farlo andare, ora sarei nella cacca (vedi GIMP, che parla di passare a GTK3 da anni ma non ha le risorse per farlo);
- winelib, sulla carta l'idea era interessante per migrare in maniera graduale una nostra applicazione Win32 a roba multipiattaforma, e intanto eseguirla nativamente su Linux; la cosa è fallita miseramente nel momento in cui si è visto che era sufficientemente poco usata/mantenuta da avere cose come le wstring che non funzionavano - e per non funzionavano intendo segfault (la causa era: il lato C++ compilato con winegcc ha impostazioni "alla Windows" con wchar_t di 2 byte, ma invoca il runtime C Linux già compilato con wchar_t da 4 byte, con risultati catastrofici); in generale, nel momento in cui l'unica documentazione disponibile è greppare i sorgenti la situazione non è rosea;
- non mi ricordo quale framework figo del giorno con cui è stata sviluppata una web application interna, ora è morto e sepolto (o si è evoluto a tal punto da essere un prodotto completamente diverso e incompatibile); l'applicazione è bloccata con il framework nello stato in cui era quando è stata scritta, lo sviluppatore che l'aveva scritta è altrove, la cui documentazione del framework è ovviamente perduta come lacrime nella pioggia; ogni volta che ci si mette mano è grep nei sorgenti del toolkit;
- SilverLight? WPF? Visual FoxPro? Visual J++? Quanti milioni di ore-uomo sono stati investiti in toolkit e linguaggi "sexy" sul momento ma che sono stati abbandonati dopo pochi anni perché non tiravano abbastanza? La cosa purtroppo vale anche per i progetti open - anche se almeno riesci a recuperare i sorgenti e a metterci le pezze;
- addirittura MinGW - progetto ultrafamoso, per cui si immaginerebbe che la "quality of implementation" sia alta - se vai a guardarci dentro ci sono cose molto discutibili - winpthreads è un colabrodo di bug, abbiamo perso 12 giorni-uomo (i miei in particolari immerso nel disassembly) a capire che un nostro problema derivava da una race condition nel loro codice (con cose assurde per cui lanciando tre thread con tre argomenti diversi magari ne lanciava due con lo stesso argomento, e uno con NULL).
Questo per dire: uscire dal mainstream è interessante e valido per un sacco di motivi, ma l'implementazione rodata, documentata, con un ampio supporto di mercato e con un ecosistema solido alle spalle spesso ha il suo "fascino noioso".
Ultima modifica di MItaly; 03-10-2017 a 22:50
Amaro C++, il gusto pieno dell'undefined behavior.
Java viene insegnato in qualsiasi scuola/corso/università in cui si tratti di programmazione e viene presentato come la manna dal cielo per ogni problema che (se consideriamo il parco di librerie disponibili) non è neanche falsissimo, ma non lo definirei tale.
Questo per dire che oltre a essere il linguaggio di fatto più diffuso è anche ben sostenuto dall'istruzione.
Da un punto di vista lavorativo sono completamente d'accordo sul restare nel mainstream, di fatto che possano permettersi di sperimentare con grandi cambiamenti e tecnologie innovative sono solo "i big". Sono d'accordo anche per quando riguarda il ricco ecosistema CL e le ottime (e testate) implementazioni sia commerciali che gratuite. Però è come dire un suo mondo, isolato e in un certo senso marginale. Con parecchi pregi ma parecchi difetti. Per questo mi stavo chiedendo cosa potrebbe effettivamente portare a scegliere CL oggi...
nim ho provato a scriverci un progettino per tipo 1 settimana, dopo l'n bug sul type system ho rinunciato...
(REBOL era un linguaggio commerciale fino a n anni fa)
"Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares
Assolutamente, difatti bisogna trovare una via di mezzo, e ogni tanto magari correre rischi anche in produzione.
Non saprei, forse non è un caso se non conosco nessuno che usi CL "per davvero". Viceversa, ho sentito diversi "evangelisti" di Clojure (tra cui l'ottimo Eli Benderesky) - complice anche il fatto di avere a disposizione l'interop con l'ecosistema Java può essere una buona idea per progetti seri...Da un punto di vista lavorativo sono completamente d'accordo sul restare nel mainstream, di fatto che possano permettersi di sperimentare con grandi cambiamenti e tecnologie innovative sono solo "i big". Sono d'accordo anche per quando riguarda il ricco ecosistema CL e le ottime (e testate) implementazioni sia commerciali che gratuite. Però è come dire un suo mondo, isolato e in un certo senso marginale. Con parecchi pregi ma parecchi difetti. Per questo mi stavo chiedendo cosa potrebbe effettivamente portare a scegliere CL oggi...
A me ha iniziato a mettere paura quando ho visto la storia dei parametri che diceva essere passati "come se fossero copie" ma che per ragioni di efficienza di fatto passava "per const reference" nel caso delle stringhe, con risultati disastrosi in caso di aliasing tra un parametro var e uno let. Cercando nel manuale non trovo più la frase precisa, qualcuno deve avergli fatto notare la cosa.nim ho provato a scriverci un progettino per tipo 1 settimana, dopo l'n bug sul type system ho rinunciato...
Sul resto, ricordo che continuava a rompersi soprattutto il compilatore verso JavaScript - o meglio, generava codice semanticamente rotto rispetto alle specifiche del linguaggio.
Indagherò(REBOL era un linguaggio commerciale fino a n anni fa)
---
Invece: partendo dall'assunto che per qualche motivo tutti i build system fanno schifo, per un progettino "esplorativo" al lavoro ho deciso di provare qbs e... funziona sorprendentemente bene, sono colpito! Ci sono dietro delle idee interessanti, e soprattutto mi sta facendo conoscere il mondo QML che finora avevo ingiustamente snobbato. Ha un po' di regole strane molto "praticone", e lo scripting è JavaScript (pro: potente, semantica nota; contro: per quanto nota, la semantica spesso è orrenda), ma devo dire che l'hanno pensata piuttosto bene - alla fine è un modo compatto e dichiarativo per dichiarare alberi di oggetti (che è quello che si fa di continuo in GUI e sistemi di build) e prototipi di alberi di oggetti, il tutto arricchito appunto dallo scripting imperativo. Vale la pena di provare a farci qualcosa.
Amaro C++, il gusto pieno dell'undefined behavior.
Mm diciamo che non gode di salute eccelsa; se guardi la history dei rilasci dal 2015 non ci sono rilasci nuovi (l'articolo è del 2015, ma non ho trovato nulla di più recente neanche nella documentazione Microsoft), e in ogni caso è dal 2013 che non ci sono feature significative. Viceversa, Microsoft stava in prima battuta puntando tanto sulle applicazioni "modern" (o "metro" o come si chiamano), e in ogni caso il mondo - per il bene e per il male - si sta spostando sul web (inteso come HTML5 e affini) - e non a caso Microsoft sta investendo in Azure. Non sembrano quindi intenzionati ad investire più energie su un framework per applicazioni rich client sciccoso ma tradizionale come impostazione.
Amaro C++, il gusto pieno dell'undefined behavior.
ottimo, grazie per la risposta.
ma invece qualcuno ha testato haxe??
dal sito sembra interessante.
Unrelated: nuova macchina di build.
(l'IP è ovviamente il .11 )
Amaro C++, il gusto pieno dell'undefined behavior.