Hace poco comencé a enseñarle a una amiga a programar (estamos usando Python), y cuando comenzamos a hablar sobre la creación de variables y el operador de asignación, ella preguntó por qué el valor de la derecha está asignado al nombre de la izquierda, y no al revés .
No lo había pensado demasiado antes, porque me parecía natural, pero ella dijo que de izquierda a derecha le parecía más natural, ya que así es como la mayoría de nosotros leemos idiomas naturales.
Lo pensé y concluí que hace que el código sea mucho más fácil de leer, ya que los nombres asignados (que el programador deberá reutilizar) son fácilmente visibles, alineados a la izquierda.
aligned = 2
on = 'foo' + 'bar' + 'foobar'
the = 5.0 / 2
left = 2 + 5
Opuesto a:
2 = aligned
'foo' + 'bar' + 'foobar' = on
5.0 / 2 = the
2 + 5 = right
# What were the names again...?
Ahora me pregunto si hay otras razones también para este estándar. ¿Hay una historia detrás de esto? ¿O hay alguna razón técnica por la que esta es una buena opción (no sé mucho sobre compiladores)? ¿Y hay algún lenguaje de programación que se asigne al lado derecho?
fuente
value -> variable
).Respuestas:
Lo mismo @paxdiablo. Los primeros lenguajes de programación fueron escritos por matemáticos, en realidad todos lo fueron. En matemáticas, por su propio principio, leer de izquierda a derecha, tiene sentido en la forma en que funciona.
x = 2y - 4.
En matemáticas, diría esto: Sea x igual a 2y -4.
Además, incluso en álgebra, haces esto. Cuando resuelve una ecuación para una variable, aísla la variable que está resolviendo para el lado izquierdo. es decir, y = mx + b;
Además, una vez que toda una familia de lenguajes, como la familia C, tiene una cierta sintaxis, es más costoso cambiarla.
fuente
let a be...
cuando no hay tiempo, ambos lados de la tarea también son iguales, por lo que la tarea es de hecho una igualdad, no es de extrañar por qué ambos usan el mismo signo:=
x = 1
en el capítulo uno, pero afirmox = 2
en el capítulo dos, eso no es una contradicción terrible: cada afirmación se aplica solo dentro de un determinado contexto. La diferencia en la programación imperativa es, en parte, la eliminación de una barrera (no necesitamos un cambio de contexto) y, en parte, la implementación y la utilidad.BASIC
, uno de los primeros lenguajes de computadora tenía la forma "adecuada" de:que coincide con la mentalidad matemática de especificar una variable, como "Sea H la altura del objeto".
COBOL
También fue similar con suCOMPUTE
declaración. Al igual que con muchas formas de hacer las cosas, puede haber sido simplemente una decisión arbitraria que se llevó a cabo en muchos idiomas.fuente
I declare that X must equal THIS
lugar del más linealEvaluate THIS and store it in X
MULTIPLY HEIGHT BY WIDTH GIVING AREA
, por lo que la variable que obtiene el resultado está en el lado derecho de la declaración.En realidad, hay un lenguaje de programación que se asigna al lado derecho: TI-BASIC ! No solo eso, sino que tampoco usa '=' como operador de asignación, sino que usa una flecha conocida como el operador "STO".
ejemplos:
En el ejemplo anterior, se declaran tres variables y se les dan valores. A sería 5, B sería 8 y C sería -3. La primera declaración / asignación se puede leer 'almacenar 5 como A'.
En cuanto a por qué TI-BASIC usa dicho sistema para la asignación, lo atribuyo a ser porque es un lenguaje de programación para una calculadora. El operador "STO" en las calculadoras TI se usaba con mayor frecuencia en las operaciones normales de la calculadora después de calcular un número. Si era un número que el usuario quería recordar, presionarían el botón "STO" y el caclulador les pediría un nombre (activando automáticamente el bloqueo alfa para que las pulsaciones de teclas produjeran letras en lugar de números):
y el usuario podría nombrar la variable lo que elijan. Tener que activar el bloqueo alfabético, escribir el nombre, luego presionar "STO", y presionar la tecla "Ans" habría sido demasiado engorroso para las operaciones normales. Dado que todas las funciones de la calculadora están disponibles en TI-BASIC, no se agregaron otros operadores de asignación ya que "STO" realizó la misma tarea, aunque al revés en comparación con la mayoría de los otros idiomas.
(Anécdota: TI-BASIC fue uno de los primeros idiomas que aprendí, así que cuando aprendí Java por primera vez en la universidad, ¡sentí que asignar a la IZQUIERDA era inusual y 'al revés'!)
fuente
Heurística 1: cuando se enfrente con más de una forma posible de hacer algo mientras diseña un idioma, elija el más común, el más intuitivo, o de lo contrario terminará con Perl +.
Ahora, ¿cómo es más natural (al menos para un hablante de inglés)? Veamos cómo escribimos / decimos cosas en inglés:
Steven ahora tiene 10 años (a diferencia de los 10 años, Steven ahora tiene). Yo peso más de 190 libras (a diferencia de más de 190 libras que peso).
En codigo:
Lo siguiente también suena más natural:
"Si Mary tiene 18 años, entonces puede tener un dulce". "Si soy menor de 21 años, entonces le pediré a mi hermano que tome tequila".
que:
"Si 18 años Mary es ..." "Si 21 es mayor que mi edad ..."
Ahora el código:
Tenga en cuenta que esto no es natural ni para los programadores ni para los angloparlantes. Las oraciones suenan como yoda-speak, y el código se llama yoda-condition. Esto podría ser útil en C ++, pero estoy seguro de que la mayoría de la gente estaría de acuerdo: si un compilador pudiera hacer el trabajo pesado y aliviar la necesidad de las condiciones de yoda, la vida sería un poco más fácil.
Por supuesto, uno podría acostumbrarse a cualquier cosa. Por ejemplo, el número 81 se escribe como:
Ochenta y uno (inglés) Ochenta y uno (español) Uno y ochenta (alemán).
Finalmente, hay 4! = 24 formas válidas de decir "la manzana verde yace en la mesa" en ruso: el orden (casi) no importa, excepto que 'on' debe venir junto con 'table'. Entonces, si usted es un hablante nativo de ruso (por ejemplo), entonces no le importará si uno escribe
a = 10
o10 = a
porque ambos parecen igualmente naturales.Si bien la lingüística es una asignatura fascinante, nunca la estudié formalmente y no conozco tantos idiomas. Sin embargo, espero haber proporcionado suficientes contraejemplos.
fuente
(four times twenty) one
Comenzó con FORTRAN en la década de 1950. Donde FORTRAN era una abreviatura de FORmula TRANslation, las fórmulas en cuestión son ecuaciones algebraicas simples que por convención siempre se asignan a la izquierda.
Su COBOL casi contemporáneo, por otro lado, debía ser similar al inglés y asignado a la derecha (¡en su mayoría!).
fuente
Bueno, como señaló @ diceguyd30, hay dos anotaciones.
<Identifier> = <Value>
significa "dejar que el identificador sea valor ". O para expandir eso: defina (o redefina) la variable Identificador a valor .<Value> -> <Identifier>
significa "almacenar valor para el identificador ". O para ampliar eso: ponga valor en la ubicación designada por el identificador .Por supuesto, en general, el Identificador puede ser, de hecho, cualquier valor L.
El primer enfoque respeta el concepto abstracto de variables, el segundo enfoque trata más sobre el almacenamiento real.
Tenga en cuenta que el primer enfoque también es común en los idiomas, que no tienen asignaciones. También tenga en cuenta, que la definición de variables y asignación son relativamente cerca
<Type> <Identifier> = <Value>
vs<Identifier> = <Value>
.fuente
Como ya se mencionó, todos los primeros lenguajes de computadora funcionaron de esa manera. Por ejemplo, FORTRAN, que apareció muchos años antes que BASIC.
En realidad, tiene mucho sentido tener la variable asignada a la izquierda de la expresión de asignación. En algunos idiomas, es posible que tenga varias rutinas sobrecargadas diferentes con el MISMO NOMBRE, devolviendo diferentes tipos de resultados. Al permitir que el compilador vea primero el tipo de la variable asignada, sabe a qué rutina sobrecargada llamar, o qué conversión implícita generar al convertir (por ejemplo) de un entero a un flotante. Esa es una explicación un poco simplista, pero espero que entiendas la idea.
fuente
Podría ser un remanente de algoritmos de análisis tempranos. Recuerde que el análisis LR solo se inventó en 1965, y bien podría ser que los analizadores LL tuvieran problemas (dentro de las limitaciones de tiempo y espacio de las máquinas en ese momento) al revés. Considerar:
Los dos están claramente desambigados de la segunda ficha. Por otra parte,
No es divertido. Esto empeora cuando comienza a anidar expresiones de asignación.
Por supuesto, más fácil desambiguar para máquinas también significa más fácil desambiguar para humanos. Otro ejemplo fácil sería buscar la inicialización de cualquier identificador dado.
Fácil, solo mira el lado izquierdo. Lado derecho, por otro lado
Especialmente cuando no puedes
grep
perforar cartas, es mucho más difícil encontrar el identificador que deseas.fuente
Los idiomas de ensamblaje tienen el destino como parte del código de operación de la izquierda. Los idiomas de nivel superior tienden a seguir las convenciones de los idiomas anteriores.
Cuando veas
=
(o:=
para dialectos de Pascalish), podrías pronunciarlos comois assigned the value
, entonces la naturaleza de izquierda a derecha tendrá sentido (porque también leemos de izquierda a derecha en la mayoría de los idiomas). Dado que los lenguajes de programación fueron desarrollados principalmente por personas que leen de izquierda a derecha, las convenciones se mantuvieron.Es un tipo de dependencia del camino . Supongo que si las personas que hablaban hebreo o árabe (o algún otro idioma de derecha a izquierda) inventaron la programación de computadoras, sospecho que pondríamos el destino a la derecha.
fuente
mov.b #255, d0
, por ejemplo, dónded0
está el registro para asignar. Los ensambladores más antiguos solo tienen un único argumento por instrucción. En el 6502LDA #255
(Load Accumulator), podría argumentar queA
está a la izquierda, pero también está a la izquierda enSTA wherever
(Store Accumulator).Por si sirve de algo, la mayoría de las declaraciones de COBOL leen de izquierda a derecha, por lo que los dos operandos fueron nombrados en primer lugar, y el destino último, como:
multiply salary by rate giving tax
.Sin embargo, no sugeriré que su estudiante prefiera COBOL, ¡por temor a que me marquen (con razón) por hacer un comentario tan bajo, grosero e insípido! :-)
fuente
Creo que esto es un error. Por un lado, puede decir "asignar 10 a x" o "mover 10 a x". Por otro lado, puede decir "establecer x en 10" o "x se convierte en 10".
En otras palabras, dependiendo de su elección de verbo, la variable asignada a puede o no ser el sujeto, y puede o no estar a la izquierda. Entonces, "lo que es natural" depende completamente de su elección habitual de redacción para representar la asignación.
fuente
En pseudocódigo, el operador de asignación se escribe muy comúnmente a la derecha. Por ejemplo
En las calculadoras Casio, incluso las variantes no programables, la variable de asignación también se muestra a la derecha
En Forth la variable también está a la derecha
En x86, la sintaxis de Intel tiene el destino a la izquierda, pero la sintaxis de GAS invierte el orden, lo que confunde a muchas personas, especialmente en las instrucciones sobre el orden de los parámetros, como la resta o las comparaciones. Estas instrucciones son las mismas en 2 dialectos diferentes.
Ambos mueven el valor en rbx a rax. Ningún otro lenguaje ensamblador que conozco escribe el destino a la derecha como GAS.
https://en.wikipedia.org/wiki/Assignment_%28computer_science%29#Notation
La mayoría de los idiomas asignan el valor a la izquierda, una de las razones es que es fácil alinear los operadores, más fácil de leer y reconocer la variable, ya que los operadores de asignación y las posiciones de las variables no variarán enormemente en las líneas, y es más fácil de leer como "dejar que la variable sea un valor".
Sin embargo, algunas personas prefieren decir "mover el valor x a y" y escribir la variable a la derecha.
fuente
Creo que sigue una forma lógica de pensar.
Tiene que haber una caja (variable) primero, luego pones un objeto (valor) dentro de ella.
No pones el objeto en el aire y luego pones una caja a su alrededor.
fuente