Paul Graham rilascia Arc

Che ci crediate o meno, Paul Graham ha rilasciato Arc, il dialetto di LISP di cui si è parlato per anni. Nel suo annuncio Paul mette subito le mani avanti chiarendo che si tratta di una versione incompleta e ancora da rifinire. Ma quello che sembrava destinato ad essere vaporware si è rivelato invece un progetto concreto che può finalmente essere scaricato e installato. Non solo, ma il linguaggio è già impiegato da tempo per Hacker News, un clone di Reddit orientato al mondo delle startup e della programmazione.

Oggi Graham e Morris, autori del linguaggio, hanno lanciato il sito ArcLanguage.org con un forum, un tutorial e istruzioni per l’installazione. Da una prima lettura al tutorial, il linguaggio non sembra particolarmente distante da Scheme o Common Lisp, anche se ha una sintassi più concisa che può decisamente piacere ad alcuni programmatori. Si tratta di una alpha release, per cui non me la sento di criticarlo in alcun modo, ma tra gli applausi e l’entusiasmo degli early adopter si sono sentite anche molte critiche da parte di chi si aspettava qualcosa di più.

In fondo, ora come ora Arc può essere visto più come una skin per MzScheme che un linguaggio a se stante. Staremo a vedere come evolverà, ora che avrà l’attenzione di moltissimi sviluppatori e possibili contributor. Faccio i complimenti a Paul Graham per la scelta di rilasciare Arc e mi riprometto di iniziare a giocarci nel mio (poco) tempo libero. E voi, farete lo stesso? Quali sono le vostre prime impressioni?

About Antonio Cangiano

Antonio lavora come Software Engineer & Technical Evangelist presso la IBM in Canada. È inoltre il direttore di Stacktrace.it, un internet marketing strategist, imprenditore del web, serial blogger, e autore di un paio di libri in inglese (recentemente Technical Blogging.) Puoi dare un'occhiata ai suoi progetti sulla sua homepage e seguendolo su Twitter.

Comments

  1. Non supporta unicode ne` UTF-8. Le librerie per HTML usano tabelle ovunque. No macro igieniche. Niente package o modulo e via dicendo nelle mancanze.

    Dopo 6 anni di lavoro ci si aspetterebbe di piu` da un linguaggio che sostanzialmente e` un piccolo layer tra l’eval loop e il reader di mzscheme. Non vedo nulla di rivoluzionario o anche solo un briciolo di cio` che aveva promesso a suo tempo.

    Grandissima delusione.

  2. Michele Simionato says:

    Acc, avevo appena scritto in un articolo per Stacktrace che Arc era solo vaporware! Per fortuna faccio ancora in tempo a cambiare la frase 😉 Comunque si’, sono d’accordo con Valentino, per scrivere un sottolinguaggio di MzScheme ci poteva mettere anche meno di sei anni. Non credo che Arc attirera’ i Lispers e Schemers con esperienza, per gli altri programmatori vedremo. La cosa che mi
    infastidisce di piu’ e’ la mancanza di moduli (oltre al non-supporto per unicode, che in un linguaggio per il Web e’ impensabile). Su questo comunque penso che tornera’ indietro, MzScheme supporta gia’ unicode quindi dev’essere facile da aggiungere ad Arc.

  3. Credo che la parola chiave sia “exploratory programming”, nelle parole di Graham:

    – “I don’t want to spend even one day dealing with character sets”

    – “Tables are the lists of html.”

    Personalmente credo che continuero’ a preferire Scheme (in particolare err5rs), ma e’ comunque interessante avere un Lisp piu’ pragmatico di Scheme e piu’ pulito di CL.

  4. Unica pecca: e’ ridicolo.
    Non e’ un common lisp piu’ pulito. Non e’ un common lisp piu’ sporco. Non e’ al pari di uno scheme. Potrebbe essere considerato come un set di piccole comode utilities. Purtroppo implementato come linguaggio a se stante, queste utilities non sono nemmeno utili.
    Odia le vocali (qui una mia parodia: http://reddit.com/r/programming/info/6710p/comments/c0318ty ).
    Le uniche “idee” sono fun:fun2 per la composizione di funzioni, ~fun per (complement fun), function call per l’indexing all’interno di sequenze, i.e. (“ciao” 1) => #\i.
    La sintassi per (fn (_) (* 2 _)) –> [* 2 _] e’ orrenda, e comunque implementabile con una banale reader-macro.
    Dove sono i packages? Clos con method combinations? Il Mop? loop? keyword arguments? Gli array? Le struct? Handlers & restarts? Dynamic variables? Multiple values? reader macros? […]
    Ah gia’. In common lisp. Seriamente, se lo scopo era cambiare alcuni nomi per scrivere programmi piu’ corti (perdendo in leggibilita’), una libreria per common lisp non solo sarebbe stata sufficiente, ma sicuramente migliore.

  5. (Ehy, dove sono finiti i miei newline! Argh! un blob di testo illeggibile! Scusate.)

  6. Sono con gli altri. Alcune cose non mi dispiacciono, ma è spaventosamente al di sotto delle mie aspettative.

    E siamo realisti, nel terzo millenni progettare un linguaggio senza prevedere unicode non è una semplificazione, è un’idiozia.

    E no, non sono uno di quelli che si incazza quando la gente scrive Rome invece che Roma, sono uno di quelli che si incazza quando scrive De André in un campo e gli dicono che deve inserire solo caratteri alfanumerici.

  7. Quel che più si avvicina ad essere il prossimo passo del Lisp IMHO: http://clojure.sf.net

  8. Massimiliano, dopo aver scritto la notizia ne parlavo con Valentino in chat, e gli ho proprio citato Clojure. 🙂

  9. A me in realta` non piace neanche clojure perche` trovo abbia preso la strada piu` sbagliata possibile per gestire la concorrenza. Ormai tutti hanno capito che i thread non sono la scelta giusta e puntare, ancora una volta, ai thread per gestirla e` semplicemente miope.

  10. “tutti hanno capito che i thread non sono la scelta giusta”

    Permettimi di rifinire la frase. Tutti hanno capito che i thread usati come in Java (stato condiviso e mutabile) non sono la scelta giusta.

    Non mi sembra che in Clojure si usino come in Java.

  11. a proposito di unicode, paul ritratta.. ma no non è che non lo voglio, è che lo aggiungerò quando ho tempo. Eh si, facile, vedrai che figata quando devi riscrivere tutte le operazioni di basso livello perché improvvisamente neanche l’apertura di un file funziona più.

    PS
    come lisp a me piaceva tanto Goo ma è morto 🙁

  12. In realta` neanche STM sistema il problema dei thread. Semplicemente l’approcio giusto e` quello di erlang oppure un multiprocesso normale. Sono piu` veloci e piu` sicuri.

  13. “In realta` neanche STM sistema il problema dei thread. Semplicemente l’approcio giusto e` quello di erlang ”

    Erlang usa i thread.

    “oppure un multiprocesso normale.”

    fork(2)? Oh, I see…

  14. Nop. Erlang usa green thread (che erlang chiama processi) a user level e, solo dalle ultime versioni e sfruttando il fatto che e` funzionale puro, fa dispatch dei suoi green thread, sotto la scocca del linguaggio, sui vari core. Questo e` parecchio diverso dal dire ‘usa i thread’, che sono una primitiva di bassissimo livello che andrebbe usata solo a livello di kernel.

    Il multiprocesso normale, che non e` fork(2) perche` su windows e` CreateProcessEx(), sa essere estremamente utile se usato nel modo giusto ed e` piuttosto facile usarlo nel modo giusto (molto piu` semplice che scrivere un corretto programma multi-thread).

  15. “Nop. Erlang usa green thread (che erlang chiama processi)”

    Un green thread è un thread.

    “a user level e, solo dalle ultime versioni e sfruttando il fatto che e` funzionale puro, fa dispatch dei suoi green thread, sotto la scocca del linguaggio, sui vari core. Questo e` parecchio diverso dal dire ‘usa i thread’, che sono una primitiva di bassissimo livello che andrebbe usata solo a livello di kernel.”

    Un thread è un flusso di esecuzione. Può essere implementato in vari modi, per cui lo si qualifica con altri termini (“kernel” thread, “green” thread) e, ortogonalmente, può condividere stato o meno con gli altri thread e comunicare con essi (shared state, share nothing, actor model, message passing, …).

    “Il multiprocesso normale, che non e` fork(2) perche` su windows e` CreateProcessEx(), sa essere estremamente utile se usato nel modo giusto ed e` piuttosto facile usarlo nel modo giusto”

    Quindi li useresti, se ho capito bene, per fare quello che in Erlang o Java si fa con le rispettive forme di thread.

    “(molto piu` semplice che scrivere un corretto programma multi-thread).”

    Scrivere un programma multi-thread in Erlang è molto più semplice che scrivere un programma multiprocesso in Erlang.

  16. La definizione dei thread non serve, so benissimo cosa sono e come funzionano. Il problema non e` certo rappresentato dal nome ma dal fatto che parlando di thread, senza specificazione ulteriore, si intendono gli OS-level thread. Ovvero quelli che vengono gestiti dall’OS e vengono quindi sospesi e ripristinati quando vuole il sistema operativo.

    Nonostante la tua lezioncina, utile ma fino a un certo punto ai fini di questa faccenda, questo tipo di threading, sia esso gestito via STM, locking o quello che preferisci, continua e resta un enorme problema sotto talmente tanti punti di vista (primo fra tutti la velocita`) da risultare ovvio.

    Il multiprocesso non lo userei per fare quello che si fa in erlang e in java con le rispettive forme di thread. Si cambia proprio modo di lavorare sfruttando di piu` la programmazione asincrona, che incidentalmente e` anche quello che fa thin, ultimo nato in casa rails, prendendo molto spunto da Twisted Matrix.

    L’uso dei thread serve a ridurre la latenza di risposta di un processo, ma si porta dietro svariati problemi, ad esempio le ottimizzazioni dei compilatori che spesso portano dentro e fuori dai lock istruzioni che non dovrebbero spostare (maggiori informazioni riguardo a questo talk di Hans Bohem http://video.google.com/videoplay?docid=-7297026930630041154 ).

    Certamente cambiando modo di agire, ad esempio usando shared nothing come politica, riesci a ridurre fortemente il numero di problemi che si possono incontrare (pur sempre restando piu` lento) ma resta una soluzione poco scalabile, manca, per esempio, la possibilita` di spostare, trasparentemente, un thread da un server a un altro senza dover riscrivere il software.

    Il fatto che Erlang si usino dei green thread e` a ulteriore testimonianza di quanto dico: non potendosi affidare al sistema operativo per decidere quando sospendere o eseguire ancora un thread, e non potendosi permettere neanche l’overhead di creazione e distruzione di ciascun thread, se ne prende carico l’ambiente di esecuzione che ha piu` informazioni a disposizione per farlo rispetto al sistema operativo, ed eliminando la gestione dei thread allo userlevel riesce anche a garantire la correttezza di esecuzione. In Erlang, ma anche in stackless python per dire, si riescono ad evitare molti dei problemi legati al multiprocesso, come l’alta latenza di creazione (anche se questa e` un vero problema solo per windows), o anche il fatto che questo tipo di cose non e` immediatamente implementato nel linguaggio.

    Usando una soluzione multiprocesso, non a-la-erlang, non andresti a usare la stessa tecnica del multi-thread ma avresti una serie di processi dedicati a un compito definito che comunicano tra loro senza continuamente morire, ognuno di questi andrebbe a ridurre la latenza del server frontend, d’altronde non si inventa nulla a riguardo, le architetture n-tier sono parecchio diffuse e conosciute e un approcio simile, anche se meno gerarchico, e` quello che si applicherebbe in questo caso. Erlang infatti e` un’astrazione su questo tipo di comunicazione e non un’astrazione dello sviluppo via thread, ecco perche` non si chiamano thread ma processi.

  17. “Il problema non e` certo rappresentato dal nome ma dal fatto che parlando di thread, senza specificazione ulteriore, si intendono gli OS-level thread.”

    Interessante, questo m’è nuovo.

    “Il multiprocesso non lo userei per fare quello che si fa in erlang e in java con le rispettive forme di thread.”

    Devo aver frainteso “semplicemente l’approcio giusto e` quello di erlang oppure un multiprocesso normale”.

    [Snip discussione su kernel thread vs. green thread]

    Vedo vagamente l’attinenza se finora ti sei basato sul presupposto “thread” == “kernel thread”, ma temo sia una diversa discussione da quella a cui ho partecipato io.

  18. Vedo vagamente l’attinenza se finora ti sei basato sul presupposto “thread” == “kernel thread”, ma temo sia una diversa discussione da quella a cui ho partecipato io.

    E` un buon modo di svicolare dalla discussione. La mia risposta e` piuttosto lunga e abbastanza dettagliata, con i dovuti rimandi. Il resto delle cose che hai creduto, pensando che non sapessi di cosa sto parlando, l’hai fatto tutto da solo. Magari, se non ti costa troppa fatica, cerca di capire di cosa si parla prima di entrare in discussione. Tra l’altro il numero assurdo di diverse tecniche per gestire i thread e` gia` testimone sufficiente della loro complessita`.

  19. “Magari, se non ti costa troppa fatica, cerca di capire di cosa si parla prima di entrare in discussione.”

    Non temere. In questo caso, anche se non concordiamo sul presupposto, concordiamo sulle conclusioni. 🙂

  20. Frase sopra spogliata dei–malefici, come l’intera discussione dimostra–margini di interpretazione: non temere che entri in altre discussioni (anche se probabilmente non per i motivi che suggerisci). 🙂

Policy per i commenti: Apprezzo moltissimo i vostri commenti, critiche incluse. Per evitare spam e troll, e far rimanere il discorso civile, i commenti sono moderati e prontamente approvati poco dopo il loro invio.