¿Por qué los libros de texto usan pseudocódigo en lugar de idiomas reales?

8

En las universidades y en los libros de texto de algoritmos, es bastante común que el maestro y el autor expliquen el flujo de control en pseudocódigo. Con el advenimiento de lenguajes más expresivos como Python y Haskell entre otros, ¿es razonable que las universidades cambien para explicar algoritmos a través de uno de estos lenguajes?

La única ventaja del pseudocódigo que se me ocurre es que supuestamente no tiene en cuenta el lenguaje. Pero no lo es. Algunos pseudocódigos usan un enfoque imperativo, otros pseudocódigos parecen funcionales. Los autores simplemente toman prestada la semántica de cualquier lenguaje de programación con el que se sientan cómodos, o peor aún, simplemente describen la semántica en lenguaje natural. Entonces, si el pseudocódigo no es realmente independiente del lenguaje, ¿cuál es la ventaja de usarlo? ¿No sería mejor usar un idioma existente?

Asterisco
fuente
55
"Podría haber elegido el lenguaje de una máquina X en particular, pero las personas que no poseen la máquina X pensarían que este libro es solo para personas X. Además, la máquina X probablemente tiene muchas idiosincrasias que son completamente irrelevantes para el material en este libro que aún debe explicarse; y en dos años el fabricante de la máquina X sacará la máquina X + 1 o la máquina 10X, y la máquina X ya no será de interés para nadie ". (Donald Knuth, TAOCP)
Kilian Foth
@KilianFoth Nice. Creo que Knuth también dijo que preveía un futuro en el que los programas se escribirían en inglés y se separarían por espacios en blanco (aunque no puedo encontrar la fuente), lo que es casi como decir que el pseudocódigo sería ejecutable :) Aunque las idiosincrasias realmente distraen, un subconjunto formal de características sería aceptable.
Asterisco
1
@Asterisk estás pensando en programación alfabetizada . Me aseguraría de que también se lea EWD667: Sobre la necedad de la "programación en lenguaje natural". por Dijkstra. También señalaría la dificultad que tienen las personas para formular preguntas aquí que siguen reglas consistentes de puntuación, mayúsculas y ortografía en inglés. Me estremezco al pensar en estas personas que escriben códigos que siguen estilos similares cuando escriben programación en prosa.
1
"adviento"? Ambos idiomas tienen más de 20 años. Y Haskell al menos fue precedido por Miranda, que tenía una sintaxis casi idéntica, y creo que ahora tiene 30 años.
Jules
@Jules Bueno, los nombré porque tienen la sintaxis más limpia y sucinta que parece adecuada para el pseudocódigo. Ambos han ganado una mayor tracción en los últimos 10 años (o más como los últimos 5 años). Python descifrando los 10 primeros en PyPl y Haskell por debajo de 50. Hay otros lenguajes que están creciendo (por cualquier razón), pero tienen una sintaxis más pesada y características extrañas. La industria todavía es 50% C ++ y Java y luego está JavaScript (que parece un lenguaje diseñado en reversa, primero agrega características y luego define reglas y restricciones).
Asterisco

Respuestas:

18

No. El punto del pseudocódigo es que no tiene que compilarse. Puedo pasar por alto rápidamente detalles irrelevantes. Por el contrario, incluso los lenguajes que parecen pseudocódigo a primera vista pueden tener detalles muy no intuitivos que simplemente restarían valor al algoritmo. Tomemos por ejemplo Quicksort en Haskell:

qs :: Ord a => [a] -> [a]
qs [] = []
qs (pivot:xs) = (qs smaller) ++ pivot:(qs larger)
  where smaller = [x | x <- xs, x <= pivot]
        larger  = [x | x <- xs, x > pivot]

o lo mismo en Python:

def qs(array):
  if not array:
    return []
  pivot = array[0]
  xs = array[1:]
  smaller = [x for x in xs if x <= pivot]
  larger  = [x for x in xs if x > pivot]
  return qs(smaller) + [pivot] + qs(larger)

La ventaja en ambos casos es que este es un código ejecutable y, como tal, los estudiantes pueden probarlo, verificarlo y jugarlo. Sin embargo, ambos incluyen detalles sintácticos que distraen. Por lo general, los estudiantes recibirían un mejor servicio con un pseudocódigo que ilustra la intención del algoritmo, no los detalles de implementación:

algorithm QUICKSORT(array)
  return [] if array is empty
  pivot  array[0]
  xs  array[1, ...] -- the rest of the array without the pivot
  smaller  [x | x  xs, x <= pivot] -- all smaller or equal elements
  larger  [x | x  xs, x  > pivot] -- all larger elements
  return [QUICKSORT(smaller)..., pivot, QUICKSORT(larger)...]

Diferencias notables:

  • Solo puedo hacer una sintaxis de comprensión de listas que parezca matemática en lugar de tener que explicar por qué Python tiene un fory ifaquí.

  • No tengo que explicar la sintaxis de ese lenguaje para la concatenación de listas. ¿Por qué Python usa la +suma? ¿Qué hay :en Haskell? Solo puedo elegir una sintaxis que haga que el punto sea más claro.

  • la firma de tipo Ord a => [a] -> [a]es solo un detalle de implementación. Aunque posiblemente sea útil en este caso, las firmas de tipo que a veces requiere Haskell pueden ser absurdas.

  • No tengo que explicar por qué Python considera que las colecciones vacías son falsas, y qué array[1:]se supone que significa.

  • Evito que los estudiantes inteligentes señalen que realmente debería usarlo yielden el ejemplo de Python.

  • Haskell apesta por explicar estructuras de datos mutables como tablas de hash, árboles RB, ...

  • Las cosas comienzan a ser muy específicas del idioma una vez que necesitamos registros complejos para expresar nuestros algoritmos. Por ejemplo, el sistema de objetos de Python tiene algunas sorpresas que solo distraen.

Dicho esto, puede ser muy valioso usar uno de estos lenguajes además del pseudocódigo, simplemente etiquete cuidadosamente qué es qué.

amon
fuente
99
Estoy de acuerdo con usted en general, pero su ejemplo contradice algunos de sus argumentos: su pseudocódigo y el ejemplo de Python se ven extremadamente similares. Eso es en mi humilde opinión una consecuencia del lenguaje Python que contiene mucho "sentido común".
Doc Brown
2
Si solo se utiliza un subconjunto de funciones de lenguaje / API, estaría sincronizado con la esencia del pseudocódigo. Sin embargo, si comenzamos a profundizar en cuál sería la mejor forma o la forma más esotérica de lograrlo en un idioma en particular, sería una distracción. Los científicos que describieron el algoritmo idearon su propia notación que se parecía mucho a la teoría de conjuntos. Después de que se estableció la idea de la máquina de Turing y C, Fortran, Lisp apareció, el pseudocódigo comenzó a tomar prestadas ideas de ellos
Asterisk
2
Yo agregaría que si el código se puede compilar "tal cual", entonces existe un riesgo muy real de que "el estudiante use cortar y pegar y no haya aprendido nada".
Brendan
3
Discutiste I don't have to explain ... what array[1:] is supposed to mean., pero realmente terminaste teniendo que explicar array[1, ...] -- the rest of the array without the pivoten los comentarios porque nadie podría haber descubierto qué array[1, ...]significa (es tu matriz de pseudocódigo basada en 0 o 1, qué diablos significan esos puntos suspensivos, etc.). Creo que realmente está a favor de usar el lenguaje real como base para el pseudocódigo, ya que simplemente puede dirigir a las personas a la documentación / tutorial de un idioma real en lugar de tener que aprender sus sintaxis de pseudocódigo.
Mentira Ryan
1
@amon Para bien o para mal, las anotaciones matemáticas no están tan bien definidas como los lenguajes de programación. Además, el uso de puntos suspensivos en secuencias no tiene un significado específico. A veces significa que es una secuencia aritmética, a veces significa geométrica, a veces significa el siguiente elemento en una secuencia arbitraria de la que habla el autor y hay que leer cinco párrafos del código para entenderlo. La notación de corte tiene un significado bien definido, no es ambiguo. Además, aunque los puntos suspensivos pueden haber sido comunes en la secuencia, aún no había especificado cómo interactúa la secuencia entre corchetes.
Mentira Ryan
10

No.

El propósito completo del pseudocódigo es abstraer los detalles y las complejidades de los idiomas individuales para que pueda centrarse en lo que se supone que debe hacer el programa, en lugar de cómo lo hace. Con el pseudocódigo, puede inventar reglas arbitrarias que no necesitan ajustarse a los requisitos de implementación reales como lo hacen los lenguajes del mundo real, sino solo a los requisitos del tema actual en cuestión.

Además, si la lógica se presenta de una manera que usted (como estudiante) no puede simplemente copiar / pegar en un archivo, compilarlo y listo, entonces se ve obligado a implementar la solución usted mismo, incluso cuando se describe la solución en sí misma para ti. Esto fomenta el pensamiento individual sobre copiar / pegar trampas.

Carreras de ligereza en órbita
fuente
0

¿Qué es real?

Porque Real es solo en definición para un intérprete .

¿El mandarín es más o menos real que el inglés?

  • Ciertamente, el mandarín no es particularmente útil para un hablante de inglés
  • Del mismo modo, el inglés no tiene sentido para un hablante de mandarín
  • a menos que hablen ambos.

Entonces, Real ni siquiera es la pregunta. Vamos a reformularlo:

¿Por qué se utiliza el pseudocódigo en lugar de un lenguaje formal?

Un simple diagrama de VENN puede resaltar el problema fácilmente. El conjunto de todos los humanos que hablan inglés y mandarín es el subconjunto de hablantes de inglés o mandarín. Debido a que se requiere esfuerzo para obtener competencia en cualquier idioma, la intersección es generalmente mucho más pequeña que la unión.

El libro de texto sobre programación puede presumir que comprende al menos un lenguaje natural, el idioma en el que está escrito el libro de texto. En general, es seguro presumir esto, ya que de lo contrario se hubiera seleccionado un libro de texto diferente y más legible. Después de todo, aprender un idioma es bastante difícil, dos es más difícil.

Esto da la primera razón para usar un pseudocódigo. Maximiza la audiencia que podría leer fácilmente el libro. Esto se hace siguiendo las convenciones de lenguaje establecidas que ya se encuentran en el lenguaje natural. Digamos recetas de cocina, fórmulas matemáticas, etc. Cualquier brecha se puede cerrar con una explicación rápida del lenguaje natural o, si no, un recurso final a nuestro sistema visual con imágenes.

En cuanto a por qué el lenguaje común no podría ser el lenguaje de programación. Le dejo que considere cuánto mandarín (o cualquier idioma que aún no hable) haya aprendido al leer un libro sobre programación escrito con ejemplos dados en un lenguaje de programación familiar.

Lo que logra un libro de texto

En cuanto a la segunda razón, considere lo que debe lograr un libro de texto:

  • explique por qué se molestarían en aprender un idioma extraño en lugar de simplemente usar su lenguaje natural.
  • Explicar al lector un idioma extraño para que pueda hablarlo por sí mismo.

Por qué programa

La mayor parte del libro tiene que convencerte de por qué querrías aprender y usar este idioma extraño o cualquier otro idioma similar. Esto significa discutir la esencia de la programación misma.

  • ¿Cómo identificas un problema?
  • ¿Cómo se separa un problema?
  • ¿Cómo se crean los datos?
  • ¿Cómo se diseñan los procesos?
  • ¿Cómo gestionas las dependencias?
  • ¿Cómo identificas las fallas?
  • y más

La mayor parte de esto no tiene nada que ver con las máquinas en sí, es principalmente una discusión sobre cómo debe funcionar la carne para llevar a cabo un programa. Eso es bastante complejo porque tiene que mostrar por qué vincularíamos nuestros objetivos espaciales humanos, para programar problemas espaciales y tratar de resolverlos.

Describiendo un programa

El segundo logro del libro de texto es describir un idioma. Ahora la mayoría de los lenguajes de programación se pueden describir con una gramática y algunas reglas semánticas. En el extremo poco profundo están los lenguajes como JSON, que se pueden definir de manera bastante completa en aproximadamente tres páginas. Los lenguajes más complejos necesitan una especificación más grande, pero en su mayor parte no necesitan una comprensión total para ser útiles. Sin embargo, estas descripciones son Pseudocódigo. Especifican el lenguaje formal en términos de un lenguaje natural. La diferencia es que estos pseudocódigos se especifican de antemano.

Ahora que incluso los lenguajes formales son pseudocódigos (ejecutables), la pregunta es ¿qué es lo más importante al describir un algoritmo? El siguiente contexto más grande.

  1. El algoritmo tiene un objetivo que es razonable en ese contexto,
  2. ese contexto tiene algunas restricciones,
  3. y el algoritmo es una descripción de cómo se pueden manejar esas restricciones mientras se logra el objetivo.

En ningún momento es importante el lenguaje en el que está escrito el algoritmo. En todo caso, solo unas pocas operaciones clave son críticas para el éxito de los algoritmos. Entonces la pregunta se convierte en:

  • ¿Es mejor describir un programa de hardware capaz de interpretar la especificación completa de un lenguaje formal como C ++ / C # / Python / etc ... para comprender el algoritmo
  • o simplemente defina las 4 primitivas necesarias para comprender el algoritmo.

Dado que aprender un idioma es difícil, y el lector debe haber aprendido / aprender un idioma para comprender el algoritmo, como escritor de un libro de texto, ¿qué debe preguntarle al lector?

Kain0_0
fuente
0

Iría contra la corriente aquí y argumentaría que sí, los libros y tutoriales deberían usar pseudocódigo basado en lenguajes reales de alto nivel en lugar de inventar una sintaxis de pseudocódigo completamente nueva.

Sin embargo, también advertiría a los autores y lectores que cuando se usan en este contexto, esto debería ser una pseudo versión del lenguaje real, y los autores deberían tener en cuenta que no deben ser demasiado estrictos acerca de seguir la sintaxis y las limitaciones del lenguaje. En cambio, los autores deberían pensar cuidadosamente sobre qué es lo que están tratando de comunicar con el fragmento, y ocultar detalles irrelevantes detrás de las llamadas a funciones y / o comentarios en lugar de luchar por una implementación completa o código compilable que sea idiomático para el idioma base elegido. .

Los autores deben tomarse un poco de libertad creativa en el idioma para expresar su punto de vista, de modo que incluso alguien que conozca solo los conceptos básicos del idioma pueda comprender la esencia del fragmento, mientras que aquellos que buscan una semántica más exacta pueden consultar la documentación del idioma o recurrir a su conocimiento previo sobre el idioma para completar los detalles.

Lie Ryan
fuente