Quali sono i pro e i contro di una lingua che usa lo spazio rispetto a {} per indicare l'ambito? [chiuso]

Penso che molti di noi programmatori (me compreso) abbiano la tendenza a "logizzare" ogni decisione. Va bene, ma non tutte le domande hanno una risposta logica. Per esempio, dubito che gli chef inviino domande su chefoverflow (se esiste una cosa simile) che chieda i pro ei contro della torta di mele e della torta di ciliegie. È una questione che ti piace di più.

Con questo in mente, penso che la risposta più semplice sia quella di dire "ad alcune persone piacciono le parentesi graffe, ad alcune persone piace lo spazio bianco" e lasciarlo a quello.

A rischio di sembrare un fan fan completo, penso che chiunque affermi che lo spazio bianco "aiuta a ridurre il rientro incoerente nel codice" non ha mai usato Visual Studio. Con un singolo comando (penso che la scorciatoia predefinita sia Ctrl + K, D), tutte le indentazioni sono istantaneamente coerenti¹. Inoltre, quando si incolla il codice l'indentazione viene istantaneamente corretta senza dover fare nulla, e lo stesso è vero quando si scrive un nuovo codice o quando si avvolge qualcosa in un if o qualche altro blocco (il riformatt avviene mentre } viene digitato ). Inoltre, premendo Invio dopo un'istruzione completata posiziona sempre il cursore sul livello di indentazione corretto per l'istruzione successiva, anche se l'istruzione precedente è rientrata ulteriormente a causa di un if o simile, rendendo molto difficile pensare accidentalmente che un'istruzione sia ancora sotto un if quando non lo è.

Il punto che sto cercando di fare è non che Visual Studio sia ottimo. Il punto che sto cercando di fare è che l'IDE possa automatizzare il rientro dei fissaggi (e altri problemi di formattazione), ma solo se il significato del programma non dipende dalla sua formattazione. Ciò offre al programmatore una maggiore opportunità di concentrarsi sull'attività di programmazione effettiva. Una sintassi come quella di Python è controproducente: non è possibile scrivere un IDE che possa "aggiustare" il rientro del codice Python perché l'indentazione stessa specifica parte della semantica.

¹ _{(So che c'è un caso speciale che VS rifiuta di riformattare, vale a dire letterali di array che si estendono su più righe, ma questo è oltre il punto.)}

Personalmente trovo che ho bisogno della linea vuota introdotta avendo un token sulla propria linea per farmi capire che il codice è in un altro ambito.

Lo odio quando in Python le persone vanno:

if something
    do something
    do somethingelse

    cleanup
else
    do the other thing

mentre in terra dei token odio quando le persone copiano e incollano e non ripuliscono il rientro ,

if something
{
I have been too lazy
      {
            to clean up
            }
what I pasted
}

o non utilizzare una riga separata per il token .

if something {
    I find this confusing
}
else {
especially when combined with the previous 
do something
}

Posso leggerli tutti e tre, ma non sono come mi aspetto e devo spendere degli sforzi per analizzarli e come Joel dice quando le cose non funzionano come ti aspetti ti rende frustrato.

Pro: Per quanto ne so, non ci sono induzioni / ricusazioni di parentesi nel mondo di Python. Prendere questa decisione per conto degli sviluppatori ha probabilmente risparmiato un po 'di dolore.

Con: le funzioni anonime sono limitate a una riga. Sembra ok, ma mi trovo spesso a scrivere su più righe lambda s in Scheme (principalmente per alimentare map o apply esattamente in un punto, quindi non avrebbe senso dichiararlo separatamente).

Il problema che ho riscontrato con un linguaggio di spazi vuoti era con espressioni condizionali a più pagine. Aggiungendo una linea nel mezzo della seconda pagina e uscendo da uno spazio nel mezzo di tutti i pasticci, puoi modificare drasticamente la logica del tuo codice. E anche se il codice di qualcuno è "corretto", provare a leggerlo fa un terribile gioco di indovinelli. Per quale "se" è questo "altro"? Riesco a contare le parentesi graffe molto più facilmente di quanto io possa contare su caratteri in bianco invisibili. E i macchinari di postazione su questo sito continuano a distruggerli in un unico spazio.

IMHO "{{{{{" is more reliable than "     ".

{} aggiunge ridondanza. Troppe ridondanze sono cattive, troppo poche sono cattive. E inserirla manualmente è male, esp. se è difficile da usare.

Quindi in tempi di IDE male / no, lo stile degli spazi bianchi potrebbe essere leggermente migliore. Ma con IDE potente, le parentesi graffe sono migliori.

Non penso che sia davvero un contro .
Pythoneers spesso critica i programmatori di parentesi graffe come se volessero violare prontamente il rientro perché possono farlo In effetti ho sempre utilizzato un'indentazione coerente al 100% ancor prima di conoscere Python e il suo ambito di indentazione.

Il fatto è che le lingue dei bretelle potrebbero anche imporre indentazioni corrette nel compilatore e avremmo il meglio di entrambi i mondi. Vedere? no contro del tutto.

I pitonieri sostengono che le parentesi graffe sono inutili quando la rientranza è parte della sintassi, ma non lo sono, le parentesi graffiano migliorano la leggibilità. Ho provato a programmare Python ed è un linguaggio molto interessante per me, ma hai provato ad avere if-elif catene di più di 2 o 3 livelli di indentazione? non sembrano più così belli.

PS: ho scritto braces ma in un senso più generale, intendo i token delimitatore. Il tutore di apertura può essere visto come ridondante, ma una lingua potrebbe andare così (in effetti sono sicuro che ci sono lingue esattamente come questa ma non le conosco bene):

if condition:
    statement
    other_statement()
end