La sintassi di Clojure è davvero più semplice di quella di Scala? [chiuso]

So from a neutral point of view, which syntax is simpler and readable?

Queste sono due molto domande diverse.

Più semplice significa "composto da meno parti". La sintassi di Clojure ha meno regole, quindi è oggettivamente più semplice di Scala.

Readability , tuttavia, è soggettiva. Si tratta principalmente di familiarità . Per esempio, trovo che ECMAScript, C #, Java, D, Go, C ++ e C siano quasi incomprensibili, ma per qualcuno che è abituato a leggere quel tipo di sintassi, sono abbastanza leggibili. Questa parte della domanda non può essere risolta obiettivamente o "da un punto di vista neutrale".

Quando lavoro in Scala, c'è spesso una fase del mio sviluppo (specialmente con for comprehensions) in cui devo fare in modo che tutti i tipi funzionino correttamente, il che è un grande vantaggio per i grandi progetti, ma è decisamente negativo per i piccoli. Mi aspettavo di dimenticare i tipi e di concentrarmi sul "portare a termine il lavoro" in Clojure nel modo in cui mi ricordo vagamente di aver fatto in Perl o Awk, ma finora non ha funzionato in quel modo per me. La mia esperienza è che invece di "far funzionare i tipi" nella fase di codice / compilazione, sto ricevendo delle eccezioni quando provo a eseguire il mio codice. Questa non è una semplificazione; il problema non è scomparso, è appena passato a una parte più pericolosa / costosa del ciclo di sviluppo.

Lì è una deliziosa semplicità della sintassi Lisp-ish. Uno dei principali punti di forza di Emacs è la possibilità di eseguire codice lisp arbitrario premendo una sequenza di tasti speciale sul paren di chiusura di un blocco di codice in qualsiasi momento in qualsiasi buffer. La semplice parentesi delimitata dalla natura della sintassi lisp rende questo elegante in un modo che sarebbe imbarazzante (dovendo introdurre parentesi graffe?) Nella maggior parte degli altri linguaggi. Inoltre, la regolarità di (function arg, arg...) e (operator arg, arg...) rende molto naturale pensare a funzioni e operatori come cittadini di prima classe e pensare a funzioni anonime, in un modo che gli operatori infissi di altri linguaggi come Scala non lo fanno.

La mia esperienza limitata con Scala mi impedisce di dire che la sintassi è più semplice o più leggibile. Certo, ci sono alcune sintassi non-libere in Clojure usando le macro, ma la mia percezione è che queste macro aprono solo una piccola finestra sul pensiero imperativo in una sintassi che è altrimenti molto funzionale. Imporre una preferenza per la sintassi funzionale o imperativa nella lingua può semplificare le cose. Dovrei dare un punto a Clojure, Java e Haskell per questo.

La mia preoccupazione per Scala è la stessa preoccupazione che ho avuto con C ++ o Perl (anche se in misura minore); la sintassi del linguaggio comprende diversi stili di pensiero (Haskell e Java). Questo rende divertente scrivere, ma potrebbe essere problematico per la leggibilità. Mentre scrivo questo, ricordo che Clojure supporta le lingue specifiche del dominio e mi chiedo fino a che punto mina il mio punto.

La tua domanda è molto interessante. In definitiva, il confronto è complesso. Ma sulla base delle mie conoscenze attuali, dovrei essere d'accordo sul fatto che la sintassi di Clojure sia più semplice di Scala, ma forse non è un intero ordine di grandezza più semplice.

Even though we write them with the same parenthesis syntax

E questa è fondamentalmente la risposta alla tua domanda.

we need to learn how each works.

Mentre è possibile introdurre DSL con una sintassi non così lispy come Common Lisps loop usando macro regolari (lascerò fuori da questo i macro dei lettori), sono principalmente usati per controllare la valutazione, e continueranno a essere usati regolarmente sintassi di espressione s. Una caratteristica importante è che anche i macro più complessi di loop possono essere letti usando lo stesso vecchio lettore sexpr.

Anche se è vero che dovrai conoscere le diverse macro e la forma di input che prendono, diciamo cond di Common Lisp con il cond più nidificato rispetto a Clojure riducendo uno strato di nidificazione, che non fa t tenere solo per macro, ma anche per funzioni regolari. Immagina una funzione usuale prendendo come argomento un elenco quotato di una particolare struttura: dovrai comunque conformarti alla struttura di input prevista, se la funzione trasforma il codice, si aspetta una sorta di alist, plist, un albero o qualcosa di completamente diverso.

Ogni volta che incontri nuove funzionalità, ci saranno alcune API che dovrai imparare. Ciò vale anche per un linguaggio che ammette solo la sintassi function(arg1, arg2, …, argN) rigorosa - dovresti ancora imparare quali sono gli argomenti previsti, quali effetti collaterali si verificano e quale è l'output di una determinata funzione.

Ciò che è più semplice della sintassi Lisp rispetto a un linguaggio come Scale, è che tutto è rappresentato più o meno lo stesso, e anche che il codice stesso usava queste rappresentazioni e strutture dati (che sarebbe il omosessualità di cui tutti parlano). Questa differenza nella complessità sintattica diventerebbe piuttosto chiara se si provasse a scrivere un parser Lisp o Clojure e quindi un parser Scala. Dovrai affrontare una grammatica molto più complicata - regole più complesse in materia di precedenza, spazio bianco, ambiguità, più eccezioni e così via.

Dalla wikipedia definizione :

In computer science, the syntax of a programming language is the set of rules that defines the combinations of symbols that are considered to be correctly structured programs in that language

Poiché clojure è una lisc, hai le espressioni s + l'elenco di macro dei lettori e questo è tutto.

In scala, hai classi, case classes, lambda implicita con _, parola chiave implicita, tratti, annotazioni generiche, annotazioni di varianza, ecc.

Clojure ha una sintassi più semplice perché le funzionalità possono essere implementate come macro o moduli speciali. Questo è impossibile con scala, nel suo devi aggiungere la sintassi per supportare alcune funzionalità.

Le macro non sono sintassi.

Argomentare l'ecosistema o la complessità della libreria di base è una discussione completamente diversa.