¿Cuáles son los pros y los contras de un lenguaje que utiliza espacios en blanco vs. {} para indicar el alcance? [cerrado]

Parece haber un conflicto sobre si es mejor usar espacios en blanco o tokens como paréntesis para indicar el alcance. He visto muchos elogiar la solución de Python al problema de sangría inconsistente, pero muchos no están de acuerdo:

Cualquier lenguaje que tenga espacios en blanco como tokens debe morir.

publicado más tarde en la misma respuesta:

Era una especie de anti-espacio en blanco como tokens, hasta que realmente lo intenté. Probablemente ayudó que mi diseño personal de espacios en blanco coincida con lo que usan todos en python-land. Quizás es que soy un poco minimalista, pero si vas a sangrar de todos modos, ¿por qué molestarte con los {} s?

Puedo ver algunos argumentos claros para cada lado:

usando espacios en blanco:

• ayuda a reducir la sangría inconsistente en el código
• borra la pantalla reemplazando los tokens visibles con espacios en blanco para cumplir el mismo propósito

usando tokens:

• Es mucho más fácil cortar y pegar código a diferentes niveles (no es necesario que corrija la sangría)
• mas consistente. Algunos editores de texto muestran espacios en blanco de manera diferente.
• más popular actualmente

¿Hay algún punto que me perdí? ¿Cual prefieres? ¿Alguna palabra de sabiduría después de haber trabajado con uno u otro durante mucho tiempo?

PD. Odio cuando los idiomas no usan el mismo token para cada estructura de control. VB es realmente molesto con sus declaraciones End Ify End While, la mayoría de los otros idiomas solo usan {} para todo. Pero tal vez ese es un tema para una pregunta diferente ...

Creo que muchos de nosotros los programadores (incluido yo mismo) tenemos una tendencia a "lógico" cada decisión. Eso está bien, pero no todas las preguntas tienen una respuesta lógica. Por ejemplo, dudo que los chefs publiquen preguntas sobre chefoverflow (si tal cosa existe) preguntando por los pros y los contras del pastel de manzana versus el pastel de cereza. Es una cuestión que te gusta más.

Con eso en mente, creo que la respuesta más simple es decir "A algunas personas les gustan los aparatos ortopédicos, a otras les gusta el espacio en blanco" y dejarlo así.

A riesgo de sonar como un fanboy absoluto, creo que todos los que afirman que los espacios en blanco "ayudan a reducir la sangría inconsistente en el código" nunca han usado Visual Studio. Con un solo comando (creo que el acceso directo predeterminado es Ctrl + K, D), toda la sangría es instantáneamente consistente¹. Además, al pegar el código, la sangría se corrige instantáneamente sin tener que hacer nada, y lo mismo ocurre cuando se escribe un código nuevo o cuando se envuelve algo en un ifbloque u otro (el formateo se realiza cuando }se escribe). Además, al presionar Intro después de una instrucción completada, el cursor se coloca en el nivel de sangría correcto para la siguiente instrucción, incluso si la instrucción anterior se sangra aún más debido a unifo similar, lo que hace que sea muy difícil pensar accidentalmente que una declaración todavía está bajo un ifcuando no lo está.

El punto que estoy tratando de aclarar no es que Visual Studio es genial. El punto que estoy tratando de hacer es que el IDE puede automatizar la fijación de sangría (y otros problemas de formato), pero solo si el significado del programa no depende de su formato. Esto le da al programador una mayor oportunidad para concentrarse en la tarea de programación real. Una sintaxis como la de Python es contraproducente: no es posible escribir un IDE que pueda "arreglar" la sangría del código de Python porque la sangría misma especifica algunas de las semánticas.

¹ _{(Sé que hay un caso especial en el que VS se niega a formatear, a saber, los literales de matriz que abarcan varias líneas, pero eso no viene al caso).}

Personalmente, creo que necesito la línea en blanco introducida al tener un token en su propia línea para que mi mente se dé cuenta de que el código está en otro ámbito.

Odio cuando en python la gente dice:

if something
    do something
    do somethingelse

    cleanup
else
    do the other thing

mientras que en tierra simbólica odio cuando la gente copia y pega y no limpia la sangría ,

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

o no use una línea separada para el token .

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

Puedo leer los tres, pero no son como esperaba y tengo que hacer un esfuerzo para analizarlos, y como dice Joel cuando las cosas no funcionan como esperabas, te frustra.

Pro: No hay guerras santas con sangría / colocación de llaves en el mundo de Python, que yo sepa. Tomar esta decisión en nombre de los desarrolladores probablemente haya ahorrado algo de dolor.

Con: las funciones anónimas están limitadas a una línea. Suena bien, pero con frecuencia me encuentro escribiendo líneas múltiples lambdaen Scheme (principalmente para alimentar mapo applyexactamente en un lugar, por lo que no tendría sentido declarar por separado).

{} agrega redundancia. Demasiada redundancia es mala, muy poca es mala. Y entrar manualmente es malo, especialmente. si es difícil de usar

Entonces, en tiempos de IDE malo / nulo, el estilo de espacio en blanco podría ser un poco mejor. Pero con el poderoso IDE, los frenos son mejores.

El problema que encontré con un lenguaje de espacios en blanco fue con expresiones condicionales de varias páginas. Agregar una línea en el medio de la página dos y bajar un espacio en medio de todo el desorden puede alterar drásticamente la lógica de su código. E incluso si el código de alguien es "correcto", intentar leerlo es un juego de adivinanzas terrible. ¿Para qué "si" es este 'otro'? Puedo contar llaves mucho más fácil de lo que puedo contar caracteres invisibles en blanco. Y la maquinaria de publicación en este sitio sigue aplastándolos en un solo espacio.

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

No creo que sea realmente un versus .
Los pitoneros a menudo critican a los programadores de aparatos ortopédicos como si pudieran violar fácilmente la sangría porque pueden hacerlo.
De hecho, siempre usé sangría 100% consistente incluso antes de conocer Python y su alcance de sangría.

El hecho es que los lenguajes de llaves también podrían imponer una sangría correcta en el compilador y tendríamos lo mejor de ambos mundos. ¿Ver? no versus en absoluto.

Los pitoneadores argumentarían que los frenos son inútiles cuando la sangría es parte de la sintaxis, pero no lo son, los frenos mejoran la legibilidad. Intenté programar Python y es un lenguaje muy interesante para mí, pero ¿has intentado tener if-elifcadenas de más de 2 o 3 niveles de sangría? ya no se ven tan bien.

PD: Escribí llaves pero de una manera más general, me refiero a tokens delimitadores. La llave de apertura puede verse como redundante, pero un idioma podría ser así (de hecho, estoy seguro de que hay idiomas exactamente como este, pero no los conozco bien):

if condition:
    statement
    other_statement()
end

PS2: 2019, 4 años después de esta respuesta. Aprendí Python y me acostumbré totalmente a su sangría semántica y no me resulta difícil leer en absoluto. Especialmente con la ayuda de IDEs modernos que dibujan barras verticales para ayudar a identificar bloques de sangría.