¿Por qué la introducción a la programación de cursos en línea no enseña pseudocódigo o diagramas de flujo antes de escribir la sintaxis del lenguaje?

Answer 1

Escribir diagramas de flujo solía ser el estándar para diseñar software. Lo que descubrieron los desarrolladores fue que pasaron demasiado tiempo creando esos diagramas de flujo, y terminaron siendo inexactos cuando realmente implementaron su código. Todavía tengo una plantilla para dibujarlos manualmente, y tengo un par de licencias para software costoso que no se pagó solo.

El seudocódigo es una especie de arte negro, y está muy infravalorado. No creo que la mayoría de los ingenieros o gerentes de software entiendan el valor de describir lo que quieres hacer en texto plano. También es posible que los cursos de programación sientan que no hay suficiente salto cognitivo entre escribir pseudocódigo y escribir código real.

La principal ventaja de escribir pseudocódigo es que no tiene que buscar ninguna de las funciones o cuál es su comportamiento específico. No tiene que recordar, por ejemplo, si la subcadena toma un principio y una longitud, y la subcadena toma un principio y un final, o si es al revés. Esto le permite escribir su intención y luego completar los detalles finos a medida que descubre lo que se está perdiendo. Por lo tanto, los detalles de implementación no interrumpen su línea de pensamiento.

Answer 2

Cuando estaba siendo entrenado, me enseñaron diagramas de flujo y una forma gráfica de diagrama de flujo mixto y pseudocódigo llamado diagrama de Nassi-Schneidermann. Puede ver los diagramas de Nassi-Schneidermann en Google Images si tiene curiosidad, o buscarlos en Wikipedia. Incluso he tenido ocasión en mi carrera para encontrarlos útiles.

Entonces, ¿por qué ya no se enseñan estas cosas en los cursos en línea? Te daré tres razones muy subjetivas.

Primero, eran artefactos de una época pasada incluso cuando los aprendí. Los gráficos de Nassi-Schneidermann, por ejemplo, se diseñaron en 1972. Cuando codifica en tarjetas perforadas o escribe su código en formularios de programación, y tiene un tiempo muy limitado en realidad frente a una computadora, o el tiempo de compilación se mide en horas, no había tanto espacio para ensayo y error y experimentación como lo hay hoy en día. Hoy en día tenemos lenguajes de secuencias de comandos que no son del todo pseudocódigo, pero son bastante parecidos, y puedes hacer prototipos que funcionen en el tiempo que solía llevar el diagrama. Muchos de estos tienen intérpretes donde puede probar el código de forma interactiva.

Mi segunda razón: ¿Alguna vez has oído hablar de una carta de Nassi-Schneidermann? Improbable. Estas cosas pasan de moda rápidamente, y casi existe una actitud de “no hablaremos de esto nuevamente” cuando lo hacen, porque es casi vergonzoso lo poco que estas ideas realmente ayudan con sus objetivos.

Mi tercera razón: el objetivo real de cualquiera de estos artefactos es que deberían ayudarlo a descubrir su diseño antes de la codificación. Al principio podrían ayudar con esto, algo así como las ruedas de entrenamiento en una bicicleta. Sin embargo, cuando comienzas a saber lo que estás haciendo con una bicicleta, te quitas las ruedas de entrenamiento porque, si bien fueron de gran ayuda al principio, ahora son un obstáculo. Podría decirse que una introducción al curso de programación probablemente debería darle las ruedas de entrenamiento. El problema es que muchas de las cosas que las personas aprenden en los cursos introductorios creen que es algo que deben seguir usando durante el resto de sus carreras, sin saber que en realidad se están obstaculizando.

El pseudocódigo en sí está en una clase mejor que los diagramas de flujo o los diagramas NS, y me resulta útil para trabajar en lenguajes de nivel medio. La última vez que hice un gran proyecto de C ++, primero escribiría pseudocódigo en comentarios, luego volvería a las funciones en la fase de codificación y escribiría C ++ para hacer lo que decía el pseudocódigo, dejando el pseudocódigo permanentemente en el código como comentarios. Los mantenedores que obtuvieron mi código adoraron este enfoque. Se recomendó en algún libro, ¿Código completo, tal vez? Y eso funciona muy bien.

Mis 2 centavos Mi respuesta favorita hasta ahora sobre este tema es la de Robert Rapplean porque describe muy bien la experiencia que he tenido con diagramas de flujo y pseudocódigo.

Gracias por el A2A. ¡Buena suerte con la programación!

Answer 3

Como otros han dicho, los diagramas de flujo son solo una forma diferente de expresar un algoritmo de programación, y si se toman de manera estricta son solo otro lenguaje de programación (y uno que tampoco está muy bien diseñado para programar computadoras). Educacionalmente, terminas pasar tiempo aprendiendo algo que no usará, luego aprenda una forma de traducirlo a otro idioma (práctico), así como aprender el idioma práctico.

Peor aún, hay formalismos en los diagramas de flujo (destinados a procesos industriales o químicos) que significa que se vuelve MUY fácil enseñar la “forma correcta” de producir un diagrama de flujo.

El pseudocódigo, por otro lado, puede ser MUY útil, pero solo si se enseña como una MANERA de pensar. He usado pseudocódigo para elaborar el diseño de algoritmos y estructuras de datos; me permite usar anotaciones idiosincráticas (personales) para algunos tipos de operaciones (como atravesar una lista) o entrar en detalles sobre cómo implementar una lista (dependiendo de qué parte del problema estoy considerando). Funciona especialmente bien cuando soy consciente de que ciertos tipos de cosas son posibles en un idioma, pero la sintaxis exacta no me es familiar, o no Seguro cómo voy a representar ciertas cosas.

En estos días, casi nunca recurro al pseudocódigo, ya que escribirlo como C o Perl es mucho más fácil. Al principio de mi carrera, antes de aprender C o Perl, mi pseudocódigo se parecía a FORTRAN-IV, que era el lenguaje de alto nivel que conocía entonces. Después de eso, se parecía a PL / 1, luego a Pascal, y luego a un lenguaje de scripting para el shell de comandos MTS, y luego a algunos otros lenguajes antes de aprender C y Perl.

También suelo pasar semanas pensando en un nuevo proyecto importante (pensando en estructuras de datos y operaciones en ellos) antes de escribir cualquier código. El título de un viejo libro de programación: “Estructuras de datos + Algoritmos = Programas” realmente describe mi proceso, y notarás que CODING no está involucrado en el título, más que los buenos libros sobre escritura mencionan la ortografía.

Answer 4

Es un poco de pollo y huevo. Es difícil enseñar a las personas a seudocódigo antes de que comprendan las construcciones básicas de la informática, como la selección y el bucle, por lo que realmente necesita entregar algoritmos listos para problemas que involucran este tipo de construcciones, luego debe codificarlos para que el estudiante pueda vea cómo funcionan y luego enséñeles a descomponer otros problemas similares, planifíquelos y codifíquelos. De hecho, la descomposición es a menudo la parte más difícil de enseñar, ya que a algunas personas les resulta difícil dividir una tarea en simples pasos discretos y codificables, y necesitan pasar por el proceso de verlo al revés en numerosas ocasiones antes de comenzar a hacerlo. Consíguelo.

Answer 5

Además de las razones dadas por las otras respuestas, creo que también hay una razón práctica: es más fácil automatizar la clasificación del código real, esencialmente pueden escribir un montón de pruebas unitarias, y si pasan, obtienes una A.