Design del linguaggio: lingue come Python e CoffeeScript sono davvero più comprensibili?

Penso che l'articolo abbia un punto per quanto riguarda JavaScript e CoffeScript.

Personalmente trovo JavaScript abbastanza leggibile e non vedo il punto di attaccare un altro livello di sintassi in cima.

Ho esperienze simili con Java / Groovy, Groovy è semplicemente fantastico: altamente espressivo, taglia fuori un sacco di inutile noioso digitazione rispetto a Java, gli "extra" come il supporto SQL nativo sono davvero degni di essere visti. MA l'ultima volta che ho usato il debugging è stato doloroso, finisci per passare attraverso infinite oscure classi Groovy interne prima di tornare al tuo codice.

Python d'altra parte è un ambiente completo autosufficiente, è un linguaggio proprio e non è attaccato a un altro linguaggio (sebbene Python sia scritto in C e abbia un'eccellente integrazione con qualsiasi cosa scritta in C o C ++). Ha il suo debugger quindi per la maggior parte stai eseguendo il debug del codice python che hai scritto.

I designer di Python sono ossessionati dall'espressività del linguaggio e dalla coerenza della sintassi. Una volta capito, è molto leggibile. In Python stai scrivendo molto meno codice rispetto all'uso di altri linguaggi per risolvere lo stesso problema, e il codice Python ben scritto è chiaro e non ambiguo.

Gli unici svantaggi sono che, in comune con la maggior parte dei linguaggi dinamici, non funziona bene con gli IDE, e che tutta quella adorabile espressività di alto livello non è interpretata come un'espressione magra.

Trovo che l'argomento sui simboli e la struttura che comunicano più (e più rapidamente) delle parole naturali sia piuttosto convincente, ma la mia lingua preferita di sempre è Scheme, quindi lo farei.

Risponderei "un po '".

Per essere onesti, penso che dobbiamo prima valutare il nostro pregiudizio personale (cioè familiarità con parole chiave, sintassi e costrutti) e giudicare solo le lingue che non abbiamo mai visto prima. (Per giudicare le lingue più popolari possiamo accettare solo le risposte dei nuovi programmatori quando vengono introdotte per la prima volta in una lingua.) Quindi, data un'implementazione identica in diverse lingue, la domanda posta dovrebbe essere "quale di questi è più facile? capire "?

Direi che più c'è un ostacolo di sintassi, meno è probabile che una lingua segnerà bene in questo scenario e ciò favorirà le lingue con una sintassi più pulita e più ovvia.

Molto più probabilità di comunicare l'intento del programmatore sarà la scelta di nomi di variabili e, naturalmente, i commenti che sono stati inclusi e che trascendono quasi tutte le lingue.

Non leggo il codice; Vedo i modelli.

Alla fine questo vale per tutte le lingue che imparo.

La finestra in cui è "leggibile" è molto breve, pochi giorni al massimo, anche per i linguaggi idiomatici.

People naturally think in images

L'autore di quell'articolo non dovrebbe parlare per tutti. Alcune persone pensano naturalmente nelle immagini, altre sono più verbali / simboliche. Inoltre, i suoi esempi sono di tipo verbale o simbolico. Né && né and è un'immagine; entrambi sono simbolici piuttosto che pittorici ed entrambi sono elaborati dallo stesso lato del cervello. Il ragionamento simbolico è molto più vicino al ragionamento verbale che al ragionamento spaziale.

Io per primo non sono un grande fan della programmazione pittorica. Non mi comunica. Non mi sono mai piaciuti i diagrammi di flusso. Detesto assolutamente i diagrammi UML come inevitabilmente fanno uscire il peggio in entrambi i mondi. Le immagini sono belle vignette, ideali per presentare idee alla direzione. Non sono così bravi a fare lavori significativi in programmazione, matematica o fisica (che sono in gran parte simbolici).

A volte le foto semplicemente non lo tagliano. I simboli sono più potenti delle immagini. Prova a disegnare un'immagine di uno spazio di Hilbert infinito dimensionale.