¿La sintaxis realmente importa en un lenguaje de programación? [cerrado]


41

Uno de mis profesores dice que "la sintaxis es la interfaz de usuario de un lenguaje de programación", lenguajes como Ruby tienen una gran legibilidad y están creciendo, pero vemos que muchos programadores son productivos con C \ C ++, por lo que como programadores realmente importa que la sintaxis debería ser aceptable?

Me encantaría saber tu opinión al respecto.

Descargo de responsabilidad: no estoy tratando de comenzar una discusión. Pensé que este es un buen tema de discusión.

Actualización: este resulta ser un buen tema. Me alegra que todos estén participando en él.


16
¿Parece que esto supone que la sintaxis de C / C ++ es mala? Ciertamente, algunos elementos de las plantillas de C ++ son feos, pero en lo que respecta a los lenguajes (históricamente), C / C ++ sigue siendo muy, muy legible.
Macneil

2
bueno, conozco a muchos programadores que no estarán de acuerdo con eso, aunque la mayoría de la comunidad de rubíes es más legible de lo que puedo decir :)
Saif al Harthi

99
¿Fue un curso teórico? Recuerde: los profesores son a menudo algunos de los peores programadores. No tienen idea de cómo es estar ahí fuera en la naturaleza.
Trabajo

2
La legibilidad está en el ojo del espectador :).
MAK

8
Una buena sintaxis no puede mejorar un lenguaje miserable. Pero la sintaxis miserable puede empeorar un buen lenguaje;)
Dario

Respuestas:


65

Si lo hace Si tiene dudas, tome APL , o J , o Brainfuck , o incluso Lisp o Forth, e intente comprender cualquier programa no completamente trivial. Luego compare con, por ejemplo, Python.

Luego compare el mismo Python (o Ruby, o incluso C #) con cosas como Cobol o VB6.

No estoy tratando de decir que la sintaxis peluda es mala y la sintaxis similar al lenguaje natural es buena en todas las circunstancias. Pero obviamente la sintaxis hace una gran diferencia. Con todo, todo lo que puedes escribir en el lenguaje de programación más hermoso también puedes escribirlo como un programa de máquina de Turing, pero generalmente no quieres, ¿verdad?


26
Lisp es definitivamente comprensible.
cbrandolino

65
+1 por incluir Lisp en la lista de idiomas ilegibles.
asmeurer

65
-1 por incluir Lisp en la lista de idiomas ilegibles.
Paul Nathan

27
La programación en general es ilegible para los no iniciados. Al igual que la notación musical y los planos arquitectónicos. (= XY) es tan legible como X == Y, para alguien que sepa leer.
Paul Nathan

66
Me encantó APL, y a menos que el código se haya escrito intencionalmente para ofuscar (muy fácil de hacer), era bastante fácil de leer. El poder de la sintaxis era que podía programar algoritmos en 2 o 3 líneas de código APL que requerirían docenas o cientos de líneas de C, Fortran o COBOL. La concisión y el poder de un lenguaje como APL es importante para esta discusión porque tratar de leer cientos de líneas de código de otro idioma puede ser tan frustrante como descifrar elementos oscuros de APL.
oosterwal

11

En la práctica, creo que sí importa. La legibilidad ya se ha discutido anteriormente. Otro problema podría ser cuántas teclas se necesitan para expresar una idea / algoritmo? Sin embargo, otro problema es lo fácil que es para los errores tipográficos simples ser difíciles de captar por el ojo humano y la cantidad de travesuras que pueden causar.

También he encontrado útil en algunos contextos analizar y / o generar fragmentos de código a través de otro programa de computadora. La dificultad de analizar el idioma y / o generar el código correcto afecta directamente cuánto esfuerzo se requiere para crear / mantener tales herramientas.


Gran observación sobre errores tipográficos que son fáciles de distinguir.

77
Pero en teoría no hay diferencia entre teoría y práctica.
Trabajo

10

Creo que tu profesor se refiere al azúcar sintáctico .

El azúcar sintáctico es un término informático que se refiere a la sintaxis dentro de un lenguaje de programación que está diseñado para hacer que las cosas sean más fáciles de leer o expresar, mientras que existen formas alternativas de expresarlas .

Entonces, lo que su profesor insinúa es que cualquier código / sintaxis escrito en un lenguaje de programación puede expresarse en otros idiomas de la misma manera, o incluso en el mismo idioma.

Robert Martin, sacando del teorema de la programación estructurada , resumió lo que los programadores hacen fundamentalmente con los lenguajes de programación en su discurso de apertura en RailsConf 2010: Robert Martin (video de YouTube , ver después de 14 minutos, aunque recomiendo todo):

  • Secuencia (asignación)
  • Selección (si declaraciones)
  • Iteración (do-loops)

Eso es todo lo que hacen los programadores, de un lenguaje de programación a otro, solo en una sintaxis o interfaz de usuario (UI) diferente. Esto es a lo que supongo que se refería su profesor, si él / ella está hablando de manera abstracta sobre lenguajes de programación.

Entonces, en esencia , la sintaxis no importa . Pero si desea ser específico, entonces, obviamente, ciertos lenguajes y sintaxis son más adecuados para ciertas tareas que otras, por lo que podría argumentar que la sintaxis es importante.


¿Llamarías a C solo un azúcar sintáctico para ensamblador?
Goran Jovic

1
Me gustaría. Pero afirmo que la sintaxis es importante. ;)
Lennart Regebro

2
"... Robert Martin resumió lo que los programadores hacen fundamentalmente ..." ¿Robert Martin? Robert Martin ?? Es posible que desee considerar este documento: C. Böhm, G. Jacopini, "Diagramas de flujo, máquinas de Turing e idiomas con solo dos reglas de formación", Comm. de la ACM, 9 (5): 366-371,1966. que generalmente se acredita como la fuente del 'Teorema del programa estructurado'. en.wikipedia.org/wiki/Structured_program_theorem
leed25d

@ lee25d No quise acreditar al tío Bob como el creador de la abstracción, sino como la fuente donde la escuché recientemente (y vinculada). Pero gracias por el enlace, actualizaré mi respuesta para reflejar su enlace.
Spong

La pieza de Wikipedia vinculada anteriormente no comprende la historia del "teorema de programación estructurada". La idea fue anterior a Bohm & Jacopini. La contribución de Bohm & Jacopini demostró que era un teorema, no solo una conjetura, es decir, proporcionaban una prueba formal rigurosa.
John R. Strohm

7

Si y no.

Hay un par de aspectos diferentes para la sintaxis.

  • legibilidad
  • expresividad
  • parsability

La legibilidad ya ha sido mencionada.

La expresividad es un caso interesante. Voy a utilizar el paso de funciones como ejemplo, porque es una especie de punto de inflexión de dolor semántico / sintáctico.

Tomemos C ++ por ejemplo. Puedo crear una función de primer orden de esta manera:

class funcClass
{
  int operator()(int);
}
funcClass fun;

void run_func(funcClass fun)
{
   fun();
}

Este idioma particular se usa comúnmente en Elementos de programación de Stepanov .

Por otro lado, puedo imitarlo en Common Lisp con algo como esto :

(defun myfunc() )

(defun run_func(fun)
  (fun))

O, en Perl -

   sub myfunc
   {
   }

   sub run_func
   {
      my $func = shift;
      $func->();          #syntax may be a little off.
   }

O, en Python:

def myfunc():
    pass

def run_func(f):
    f()

Todos estos tienen, esencialmente, el mismo contenido semántico, aunque el ejemplo de C ++ lleva algún tipo de metadatos. ¿Qué lenguaje expresa mejor la idea de pasar una función de orden superior? Lisp común apenas hace una variación sintáctica. C ++ requiere que se cree una clase solo para 'llevar' la función. Perl es bastante directo sobre hacer algún nivel de diferenciación. Así es Python.

¿Qué enfoque se adapta mejor al dominio del problema? ¿Qué enfoque puede expresar mejor los pensamientos en su cabeza con el menor 'desajuste de impedancia'?

La capacidad de análisis es, en mi opinión, un gran problema. En particular, me refiero a la capacidad del IDE para analizar y cortar el idioma sin cometer errores. Reformatear es útil. Los lenguajes delimitados por tokens tienden a analizar bien: ruby ​​/ c / pascal, etc.

Sin embargo, considere: se han creado sistemas principales de todo tipo con cada lenguaje serio para resolver problemas del mundo real. Aunque la sintaxis es una barrera para expresar algunas cosas, es una barrera que puede solucionarse. Equivalencia de Turing y todo eso.


5

La sintaxis definitivamente importa, aunque tiendes a notarla más cuando no es intuitiva y alienta los errores. Por ejemplo, la broma infame del "último error del mundo":

if (AlertCode = RED)
   {LaunchNukes();}

2
+1: Interesante, nunca he visto (o reconocido) esta broma infame del "último error del mundo". Pero puedo ver cómo, dependiendo de la sintaxis de un lenguaje (o incluso de la semántica), el resultado de ese pseudocódigo podría ser cualquier cosa. Dado el ángulo semántico también, esto realmente puede atribuirse al clásico caso de falta de comunicación cultural.
Stephen Swensen

Esto es por qué debería utilizar los condicionales Yoda, es decir, if(RED = AlertCode)nunca se debe compilar porque el rojo es constante (o debería ser!)
Malfist

44
@Malfist: Y así vemos que una sintaxis incorrecta conduce a una sintaxis aún peor para compensar. Los condicionales de Yoda son feos y difíciles de leer porque no son la forma en que las personas piensan en el concepto asociado. Mi punto era más como "esta es (una de las muchas razones) por las que debes evitar a la familia C siempre que sea posible".
Mason Wheeler

1
Bueno, afortunadamente, ese código tiene dos errores. Claro, siempre ingresará el condicional, pero allí, solo obtiene una referencia al LaunchNukesprocedimiento y nunca lo invoca. ¡Crisis evitada!
munificente

3
Depende de lo que REDsea. Si es 0, LaunchNukes()nunca se llamaría.
dan04

5

La sintaxis es importante, y puedo darle dos ejemplos de apoyo: Dylan, que es un Lisp con una sintaxis más convencional, y Liskell, que es Haskell con una sintaxis similar a Lisp. En cada caso, se propuso una variante del lenguaje que tenía exactamente la misma semántica, pero una sintaxis radicalmente diferente.

En el caso de Dylan, se pensó que abandonar las expresiones s en favor de algo más convencional ayudaría a atraer a una gama más amplia de programadores. Resultó que la sintaxis no era lo único que impedía a los programadores usar Lisp.

En el caso de Liskell, se pensó que el uso de expresiones s permitiría un uso más fácil de las macros. Resultó que las macros realmente no son necesarias en Haskell, por lo que ese experimento tampoco funcionó.

Aquí está la cosa: si la sintaxis no le importara a nadie, ninguno de los experimentos habría sido probado.


1
Dylan era demasiado pequeño, demasiado tarde para otros idiomas. Lo que tenía a su favor no podía compensar eso. No podemos suponer más que es una falla de sintaxis de lo que fue una falla al nombrar.
Macneil

@Macneil: Tienes razón sobre lo poco y demasiado tarde. Dejar caer la sintaxis de Lisp fue solo el último clavo en el ataúd. No creo que haya sido la razón principal del fracaso de Dylan, pero no estoy seguro de cómo volver a redactar la respuesta para reflejarlo mejor.
Larry Coleman

Interesante, no sabía que tenían la sintaxis de Lisp en una versión anterior ... ¿Fue eso cuando se llamaba Ralph? El Newton Message Pad originalmente iba a tener a Dylan en su núcleo. 15 años después, tenemos iOS con Objective-C en el núcleo, el lenguaje menor de los dos, en mi humilde opinión.
Macneil

No recuerdo los detalles exactos sobre cuándo Dylan perdió expresiones-s. He estado al acecho en comp.lang.lisp durante mucho tiempo, y recuerdo el tema que aparece en una de sus peleas periódicas sobre paréntesis.
Larry Coleman

Dylan es anterior a Java, y no creo que hubiera muchos C ++ en ese entonces.
Tom Hawtin - tackline 01 de

3

La respuesta podría estar en separar lo que "importa" en factores informáticos y factores humanos . Hay muchos factores humanos en la sintaxis:

  • Legibilidad
  • Concisión
  • Mantenibilidad
  • Pedagogía
  • Prevención de errores
  • Idoneidad para el propósito: ¿es un lenguaje REPL, un lenguaje de script o un lenguaje de sistemas grandes?

En lo que respecta a la computadora, el único problema de la sintaxis es si hay ambigüedades que deben resolverse o no, y cuánto tiempo lleva tokenizar / analizar el código al compilarlo / interpretarlo, y es solo en el caso de este último donde la sobrecarga del análisis es un problema importante.

Esa podría ser la razón por la que siempre obtendrá una respuesta de "sí y no" a esta pregunta, porque tiene dos aspectos.


1

Sin sintaxis, no tendríamos una "plantilla" común desde la cual comunicar, a nivel humano, la intención de un bloque de código. La sintaxis proporciona un marco común desde el cual los compiladores pueden estandarizarse; los métodos pueden ser compartidos; El mantenimiento puede simplificarse.


¿Por qué mi respuesta fue rechazada?
Resumen de

1

Creo que lo que realmente importa es el acceso a la API y la disponibilidad de funcionalidad de bajo nivel (como el control y bloqueo de memoria) cuando sea necesario. La mayoría de los otros idiomas vienen con estas características incluidas. El problema es que cuando necesita funcionalidad adicional, a menudo tiene que usar un lenguaje como C para implementarlo. Y es engorroso interactuar C con el lenguaje que está utilizando.

Para todo, excepto el desarrollo web (y las matemáticas), he descubierto que C / C ++ sigue siendo EL lenguaje de un sistema operativo y una aplicación. Es lo que se admite la mayor parte del tiempo para el verdadero desarrollo de aplicaciones multiplataforma, preformado y multiplataforma. Y la sintaxis de C está bien. Simplemente muy simple y relativamente detallado. Amazing Syntax realmente no importa tanto. Disponibilidad de energía y API Todos necesitamos interactuar con el código de otras personas (que la mayoría de las veces está escrito en C o sus derivados).


No tengo reparos con C, pero la multitud de ML / Haskell probablemente tenga algo que decir con respecto al enhebrado.
Rei Miyasaka

+1 para "acceso a la API": creo que esto puede ser incluso más importante que las características del lenguaje.
Giorgio

1

La sintaxis definitivamente importa. Es extremadamente valioso si la sintaxis del idioma es lo suficientemente flexible como para permitirle crear un lenguaje específico de dominio conveniente y legible para su aplicación. Si dudas de esto, imagina hacer problemas de álgebra en latín prosaico, como se hizo antes del siglo XVIII, o imagina hacer cálculos sin la notación de Leibniz, ahora familiar. Claro, un texto de cálculo es ilegible para un novato, pero con la práctica podemos usar el cálculo y la notación de Leibniz para resolver rápidamente una clase de problemas que requieren páginas de matemáticas con métodos clásicos. La programación es solo otra parte de las matemáticas. Una notación conveniente, cercana al dominio del problema, puede marcar una enorme diferencia en la productividad.


Las DSL no tienen que ver con el azúcar de sintaxis. La semántica es una parte mucho más valiosa. Está bien diseñar eDSL que no agreguen nada a una sintaxis existente.
SK-logic

@SK: claro, pero la semántica está bajo el control completo del programador. La sintaxis está limitada por el idioma base. Podemos construir DSL convenientes dentro de Groovy y otros lenguajes, pero no tanto en Java.
Kevin Cline

1

Aquí hay un programa que calcula la facultad de 6:

S(K(S(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)KK))))))(S(K(S(S(K(SI))(SII)(S(K(SI))(SII))
(S(K(S(S(KS)(S(KK)(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))
(S(K(S(S(KS)(S(K(SI(KK)))(SI(K(KI)))))))(S(K(S(K(S(S(K(SI))(SII)(S(K(SI))
(SII))(S(K(S(S(KS)(SI(KK)))))(S(S(KS)(S(K(S(KS)))(S(K(S(KK)))(S(S(KS)K)
(K(SI(K(KI))))))))(K(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)))))))))))
(S(S(KS)K)(K(SI(K(KI)))))))))))(S(S(KS)K)(K(SI(K(KI))))))(S(S(KS)(S(KK)(S(KS)
(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)
(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)
(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))

La sintaxis es mínima:

expression: expression term | term
term: ‘(‘ expression ‘)‘ | combinator
combinator: 'S' | 'K' | 'I' 

Parece existir una creencia común de que la sintaxis es lo que dificulta el lenguaje. Como ocurre a menudo con las creencias comunes, exactamente lo contrario es cierto.

Tenga en cuenta que la sintaxis de LISP solo es legible (si es que lo tiene) porque tiene mucha más sintaxis que la anterior. Entonces, si los fanáticos de LISP te dicen que "la sintaxis no importa", pídeles que sean consecuentes y prueba el cálculo de SKI. Tendrán que admitir que una sintaxis un poco no es tan mala después de todo.


No puedo entender el voto negativo. Esta es una respuesta realmente perspicaz. +1
scravy

0

No creo que importe más allá de la preferencia personal. Todas las cosas (rendimiento, capacidades, etc.) son iguales, entonces puedo ver por qué uno pondría mayor peso en la sintaxis de un idioma, pero elegir pasar por alto el rendimiento de lenguajes como c / c ++ o cualquier otro idioma que mejor se adapte al trabajo simplemente por La sintaxis parecería una mala idea en general.


66
¿Qué tal "tiempo de comercialización", "costo de beneficio", etc.
Trabajo

0

Sí, la sintaxis es importante, aunque en realidad solo es legible. Comparar:

for i in range(10):
   print(i)

(Sí, eso es Python) con

FOR(i<-RNG-<10){PRN<-i}

(Sí, ese es un lenguaje que acabo de inventar) Ambos harían exactamente lo mismo, de la misma manera, pero la sintaxis es diferente y Python es más fácil de leer. Entonces sí, la sintaxis definitivamente importa. Incluso el "azúcar sintáctico" es importante.

 @property
 def year(self):
     return self._date.year

Es más fácil de leer que

 def year(self):
     return self._date.year
 year = property(year)

0

Si, claro.

Si quieres iniciar una gran llama, pregúntale a la gente dónde ponen el brazalete de apertura en lenguajes tipo C. quiero decir

void foo() {
  // blah
}

VS

void foo()
{
  // blah
}

o incluso VS

void foo() 
{ // blah
}

¡Y este es el mismo idioma! Además, pregúnteles acerca de los espacios, dónde los colocan (nombre y bracet de la función, operadores, etc.).

¡1000 respuestas están garantizadas!


no quiero iniciar una llama y hasta ahora tengo buenas respuestas y les agradezco a todos por participar y aumentar mi conocimiento y apuesto a que otras personas encontraron esto útil
Saif al Harthi

0

La sintaxis sí importa. Sin embargo, hoy en día diría que importa casi por completo debido a la legibilidad y no realmente en términos de la cantidad de pulsaciones de teclas necesarias. ¿Por qué?

  • A menos que realmente esté escribiendo algo así de simple, si la cantidad de teclas que presiona es el factor limitante para escribir un programa, entonces realmente es una mierda para escribir o piensa demasiado, demasiado rápido.
  • Todos los IDE decentes en estos días tienen una gran cantidad de accesos directos que significan que no es necesario que escriba todos los caracteres que usa la mayor parte del tiempo.

Dicho esto, si es demasiado detallado, puede llegar al punto donde afecta la legibilidad. Prefiero ver algo como:

foreach (Cadena en stringList)

A:

para cada cadena que está en la lista como se hace referencia en la variable stringlist

...¡cualquier día!


0

La sintaxis es importante para quienes la están aprendiendo, cuanto más baja sea la barrera de entrada, más popular será inicialmente el idioma. Pero si el lenguaje es difícil o imposible de expresarse de manera rica y sucinta, comenzará a debilitarse en popularidad.

Muy conciso y opaco (Perl) es tan malo como excesivamente detallado y prolijo (AppleScript).

Debe haber un equilibrio, una barrera de entrada más baja, alta productividad y fácil mantenimiento.


-2

Otra cosa a considerar es que los lenguajes de programación con una sintaxis más agradable son más fáciles de analizar, lo que hace que el compilador sea más fácil de escribir, más rápido y menos propenso a errores.


3
Umm ... 10000 SLOC de parse.yRuby en desacuerdo. Hay una razón por la cual cada una de las 7 implementaciones de Ruby actual o pronto listas para producción usa el mismo analizador, y cada implementación de Ruby que alguna vez ha intentado desarrollar su propio analizador ha fallado.
Jörg W Mittag

Y luego estaba el infame lenguaje ADA. Junto con la especificación del lenguaje, hubo 100 programas que tuvieron que ejecutarse correctamente para certificar el compilador. Había algunas cosas realmente sutiles sobre la sintaxis. Para resumir, CADA compilador ADA temprano construido suspendió un par de estos programas. Y no se trataba simplemente de corregir un error, sino que debían comenzar desde cero. A pesar de que contaba con el apoyo masivo del gobierno (todos los contratos del Departamento de Defensa exigían a la ADA), tuvo una muerte miserable.
Omega Centauri

-2

En pocas palabras: la sintaxis como tal no importa. La semántica que puedes expresar a través de ella es importante.


55
Como ejercicio, escriba un analizador complejo en C y luego un controlador de dispositivo en Haskell. ¿Te ayudó la sintaxis? Luego, haga lo contrario, preservando estrictamente la semántica de ambos programas. </irony>
9000

1
@ 9000: He visto un par de controladores de dispositivos en Haskell. No pude ver nada particularmente malo con ellos. ¿Cuidado para elaborar?
Jörg W Mittag

2
@ 9000, dado lo difícil que es obtener los controladores de dispositivo directamente en C, no estoy seguro de que haya elegido un buen ejemplo.

1
@ 9000: Ese fue exactamente mi punto. La naturaleza concreta de una construcción sintáctica no importa, es lo que expresas con ella. Un lenguaje de programación con la sintaxis exacta de Haskell, pero que utiliza una estrategia de evaluación diferente hará que muchos de Haskell se desempeñen terriblemente o incluso se atasquen en bucles infinitos. Cuando se trata de construcciones sintácticas (o más amplias: características del lenguaje), no es su sintaxis concreta lo que importa, sino su semántica, es decir, lo que puede expresar con ellas.
back2dos

@ 9000, no será un problema escribir un analizador sintáctico en un Haskell con una sintaxis similar a C (o un controlador, usando C con una sintaxis similar a Haskell).
SK-logic
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.