¿Crees que la exposición a BASIC puede mutilar tu mente? [cerrado]

Es prácticamente imposible enseñar una buena programación a los estudiantes que han tenido una exposición previa a BASIC: como programadores potenciales, son mutilados mentalmente más allá de la esperanza de regeneración.

- Edsger W. Dijkstra

Tengo un profundo respeto por Dijkstra pero no estoy de acuerdo con todo lo que dijo / escribió. No estoy de acuerdo especialmente con esta cita en un documento vinculado escrito hace 35 años sobre la implementación de Dartmouth BASIC .

Muchos de mis programadores de compañeros de trabajo o amigos comenzaron con BASIC, las preguntas a continuación tienen respuestas que indican que muchos programadores tuvieron su primera experiencia en programación en BASIC. AFAIK muchos buenos programadores comenzaron en la programación BÁSICA.

No estoy hablando de Visual Basic u otros dialectos "modernos" de BASIC que se ejecutan en máquinas llenas de recursos. Estoy hablando de los viejos tiempos BASIC que se ejecutan en la computadora "juguete", que el programador tuvo que preocuparse por guardar números pequeños que no necesitan calcularse como una cadena para guardar un byte miserable porque la computadora solo tenía unos pocos cientos de ellos, o tiene que usar goto computarizado por falta de una característica más poderosa, y muchas otras cosas que requieren que el programador piense mucho antes de hacer algo y obligar al programador a ser creativo.

Si tenía experiencia con el BASIC de antaño en una máquina con recursos limitados (tenga en cuenta que un microcontrolador simple hoy tiene muchos más recursos que una computadora en 1975, ¿cree que BASIC le ayuda a su mente a encontrar mejores soluciones, a pensar como un ingeniero o BASIC te arrastra al lado oscuro de la programación y te mutila mentalmente?

¿Es bueno aprender un lenguaje de programación que se ejecuta en una computadora llena de recursos donde el programador novato puede hacer todo mal y el programa se ejecuta sin grandes problemas? ¿O es mejor aprender dónde el programador no puede salir mal?

¿Qué puedes decir sobre BASIC que te haya ayudado a ser un mejor / peor programador?

¿Le enseñarías el BASIC antiguo que se ejecuta en una máquina de 2 KB (virtual) a un programador que viene?

Claro, solo la exposición a BASIC es mala. Tal vez comparta mi opinión de que el BASIC moderno no ayuda demasiado porque el BASIC moderno, al igual que otros lenguajes de programación, brinda facilidades que permiten al programador no pensar más profundamente.

Información adicional: ¿Por qué BASIC?

Los conceptos básicos populares en el momento de la cita eran muy diferentes de los que teníamos incluso hace 20 años. (¿Está contando esos entre sus dialectos "modernos"?)

Olvídese de los bucles, subrutinas, variables locales y todo lo que enfatizó la Programación Estructurada (de la cual Dijkstra y Knuth fueron grandes defensores). Tenías GOTO y te gustó .

En este contexto, los programadores que solo conocían variables globales, inventaron sus propias subrutinas (¡usando más variables globales para parámetros y valores de retorno!), Y escribieron espaguetis GOTOs realmente fueron mutilados.

Si tienes 30 años o menos hoy y Basic era tu primer idioma, no era el mismo idioma del que hablaba Dijkstra. Incluso si eres mayor y tu primer Basic tenía algunas de estas características, como comenta Murph a continuación, puede que no haya sido el mismo idioma del que hablaba Dijkstra.

Has actualizado la pregunta con un contexto que nunca antes había conocido:

• La cita de Dijkstra es de 1975.

• No fue sino hasta la versión 6 que obtuviste procedimientos compilables por separado, lo que, creo, muestra el comienzo del cambio de enfoque lejos de GOTO.

• "En 1976, Steve Garland agregó características de programación estructurada para crear Dartmouth SBASIC, un precompilador que produjo la versión 6 ..." ^{[ Wikipedia ]} El contexto de la cita es claramente anterior a lo que ahora conocemos como estructuras de control, y muchos usuarios de Time podría haber estado más familiarizado con la segunda versión más reciente, es decir, dos versiones anteriores a la de Garland, que es la v5 y antes de los procedimientos compilables por separado.

• GOSUB / RETURN solo maneja "subrutinas simples".

• "Los nombres de las variables se limitaron a A a Z, A0 a A9, B0 a B9, ..., Z0 a Z9, dando un máximo de 286 posibles variables distintas". ... y todos son globales.

_{Un hombre no puede hacer nada mejor que comer y beber y encontrar satisfacción en su trabajo.}

Aprendí BASIC antes que nada (bueno, excepto álgebra, supongo). Si no me hizo pensar seriamente, entonces no estoy seguro de cómo explicar los 18 años que siguieron ...

Dicho eso, ¿y qué? Dijkstra podría tener dificultades para enseñarme algo debido a mi exposición a largo plazo a BASIC, pero tendría más dificultades para enseñarme algo debido a su exposición a largo plazo a una caja de pino subterránea. E incluso con esos factores eliminados, nunca he sido un estudiante serio de CS, un estudiante serio de matemáticas o un estudiante serio en ninguna otra disciplina. El abismo entre alguien como yo y el tipo de programador que a Dijkstra le hubiera gustado ver es tan grande que es casi insondable ...

Y sin embargo, programamos. Nosotros, que tentimos en BASIC, jugamos con FORTRAN, experimentamos con COBOL y todo lo demás, también encontramos alegría y fascinación con estas pequeñas máquinas que, aunque tal vez completamente diferentes de lo que primero atrajo al Sr. Edsger a su campo, no es menos un llamado, la base para una labor de amor de por vida.

... o tal vez eso es sólo lo que una mente mutilada sería decir ...

No es BÁSICO lo que te lastima, es la incapacidad de exponerte a otros idiomas. Los "programadores" de Monoglot no lo son.

BASIC, desde un punto de vista estructurado, no fue peor que ensamblador o COBOL. En aquel entonces, no había la gran cantidad de idiomas descendientes de Algol que tenemos ahora, siendo Pascal la primera introducción que la mayoría de la gente tuvo a las estructuras de control razonables (y no soy tan aficionado a las estructuras de control de Pascal).

Si BASIC fuera suficiente para dañar permanentemente a las personas, también lo fueron otros idiomas tempranos, por lo que no habríamos tenido personas lo suficientemente intactas para desarrollar todos los idiomas que usamos hoy en día.

Es posible que Dijkstra estuviera tratando con personas que no eran buenos programadores y que nunca lo serían, que aprendieron a hacer algunas cosas en BASIC. Esa es la interpretación más caritativa que puedo poner en la declaración.

Aprendí con BASIC en un TRS-80 y Apple II c / e, y me considero un buen programador. Los dos rasgos que personalmente creo que llevaron a no ser destruidos al aprender BASIC primero son

1. Seguí tratando de aprender mejores formas de lograr lo que quería con menos esfuerzo, lo que me llevó a aprender otros idiomas y las características en esos idiomas que los hacen poderosos, y
2. Me encontré y reconocí problemas con BASIC como lenguaje, especialmente la falta de subrutinas (aunque no tenía la experiencia para describir de manera concisa los problemas que hago ahora).

Admitiré que aprender programación orientada a objetos después del procedimiento puro de BASIC fue una lucha por un tiempo, pero no sé si eso estaba realmente relacionado con BASIC, ya que también había aprendido una buena cantidad de C para entonces. .

No estoy de acuerdo con Dijkstra también. Creo que es más difícil aprender un segundo idioma porque los paradigmas, no porque es BÁSICO.

BASIC fue mi primer idioma en una computadora personal llamada TK (como Sinclair) en 1985. Era una máquina de recursos muy limitada. En ese tiempo, escribí un compilador BÁSICO de un libro usando un editor hexadecimal por diversión. Compré un libro Z80 y aprendí el lenguaje de máquina de 8 bits después de eso. BASIC me ayudó mucho con esto.

Después aprendo C y Pascal y juego con Assembly para 8080/6. MSX-BASIC, Quick Basic en tiempos de MS-DOS ... VB, Delphi, algunos Java en tiempos de Windows ...

Hoy un trabajo con progreso (4gl), .net (C # / VB), php y no me siento como un cíclope. : O)

Comencé con basic en un clon de manzana cuando tenía ocho años.

Incluso las versiones posteriores de basic que tenían algunas ideas de OOP incorporadas (qbasic, visual basic, etc.) no tendrían sentido en Eight.

Comenzar a programar tan temprano es una de las razones por las que puedo pensar en el problema en el flujo del programa y es algo que mucha gente no puede hacer bien en esta industria.

Creo que un comienzo temprano a menudo es beneficioso y se requiere un lenguaje MUY SENCILLO cuando se trata de pequeños.

Su experiencia puede ser diferente...

Creo que la exposición a la mayoría de los ejemplos BÁSICOS del mundo son los que mutilan los cerebros de los programadores, no el lenguaje en sí. Es como el programador de C # que navega por MSDN y no cree que sea necesario el manejo de excepciones o que los IDisposabletipos realmente no necesitan ser eliminados.

Cualquiera tendrá un problema si no puede identificar los problemas en su idioma actual y no solo podrá solucionarlos, sino que encontrará otro creado para resolver el problema.

Y GOTO solo es malo si no tiene numeración de línea;)

Actualmente estoy usando BASIC para enseñarle a mi hijo a escribir sus propios juegos simples. Nunca lo usé, comencé mi portadora con PowerBuilder y PowerScript y salté a C / C ++ y luego a Delphi. Hoy, uso casi todos los idiomas disponibles y me adapto muy rápido porque la base de todos los idiomas son las mismas fórmulas matemáticas, con diferentes signos, operadores y símbolos. Eso también es lo que le estoy enseñando a mi hijo y por eso ya puede leer y explicar el código C ++. Mi hijo tiene 12 por cierto.

BASIC GOTOes una excelente manera de enseñar la forma de pensar en lenguaje ensamblador . No mutila la mente, solo aleja la mente de las sinapsis basadas en carbono y más cerca de los transistores basados ​​en silicio.

Sin embargo, comparemos BASIC con LOGO. BASIC puede alejar a los niños de la programación, porque para escribir un programa simple y divertido, todo lo que puedes hacer es seguir escribiendo un programa muy, muy largo impreso en una revista, mientras que con LOGO una línea puede dibujar gráficos muy impresionantes, lo cual es esencial para atraer niños.

Basic es bueno, es divertido y bastante simple. Puede hacer gráficos 2D divertidos y lo que no ... Aprendí (o intenté aprender) que cuando tenía alrededor de 10 o 12 años, era un lenguaje divertido que me interesó en aprender más sobre computadoras ...

Algunos de los mejores programadores que conozco estuvieron expuestos desde el principio a la programación en Basic. Es un poco más "concreto" y, por lo tanto, proporciona una mejor idea de cómo podría funcionar realmente la máquina de bajo nivel que muchos lenguajes más nuevos (por ejemplo, es una introducción más cercana de HLL al ensamblador).

La cita de Dijkstra es de un período de tiempo en que los académicos estaban tratando de impulsar una tendencia hacia programas bien estructurados y probadamente correctos diseñados a partir de especificaciones. Pero esa no es la forma en que fue la gran parte de la industria. En cambio, muchos programadores de la era de la web 2.0 están tratando de crear prototipos rápidamente de algo para lo que la mayoría de las especificaciones matemáticamente estrictas para probar el código no existe, porque las cosas están evolucionando demasiado rápido para que esa especificación sea competitiva.

Por lo tanto, los métodos de programación de prueba y error de hack-and-slash que la programación en Basic a veces fomenta, cuando se limpia un poco en la metodología, es una introducción útil para el pensamiento RAD.

Terminaré señalando que hay al menos 5 intérpretes básicos disponibles que se ejecutan en el iPad, manteniendo así el idioma disponible incluso en los dispositivos más nuevos.

Creo que, dado que esta cita tiene 35 años, tiene mucho que ver con la falta de abstracción que estaba disponible en los lenguajes de programación y lo que se requería para que usted se desarrolle bien, cuando se dijo.

Recibir un lenguaje como BASIC le enseña poco sobre cómo programar en un nivel bajo, algo mucho más necesario en el pasado que ahora, y le daría la impresión errónea de que la programación era más simple de lo que realmente es.

Recuerdo que intenté aprender 'código de máquina' a la edad de 15 años después de más de 3 años de VZ200, C64 y Apple] [e BASIC, fue una llamada de atención grosera.

Sin embargo, en estos días, aunque soy un completo snob acerca de estas cosas, y no me encontrarás trabajando felizmente en ningún idioma con BASIC en el nombre (tiendo a empezar a gritarle a las frases del monitor como "estúpido lenguaje Fisher Price". , una vez más, rechaza mis llaves descuidadas), admito que es más fácil hacer cosas productivas con lenguajes que abstraen la mecánica de la CPU que hace 35 años (o hace 25 años, en mi propia experiencia y ejemplo personal)

Para aquellos de nosotros que estábamos cargando el código de ensamblaje en las computadoras Speer Micro-LINC un byte a la vez a través de un conjunto de 8 interruptores en el panel frontal y almacenándolos en cintas PDP en 1972, afirmaré inequívocamente que Dijkstra fue un imbécil pomposo. Todo lo que despreciaba de Basic era cierto en espadas sobre el ensamblador con el que estaba trabajando y, sin embargo, yo y miles de otras personas nos recuperamos de nuestra exposición al ensamblador y luego Basic y Fortran y Cobol y C, etc.

Comencé a programar con GW-BASIC a principios de la década de 1990. Mi mente no fue mutilada. Pasé a mejores lenguajes como Pascal, C, C ++, Java, C # y Python.

No podría escribir un programa BASIC hoy; He olvidado cómo pensar en términos de números de línea. No es que eso sea un problema.

Pero mi experiencia BASIC me ayudó mucho en el curso de Arquitectura de Computadores de mi universidad, donde tuve que aprender lenguaje ensamblador (MIPS). Asamblea flujo de control lenguaje es muy parecido a BASIC: Salta = GOTO, = ramas IF... GOTO, jal(llamada) ... jr(r) = GOSUB... RETURN. ¡Eso es todo el flujo de control que necesitas!

¿Es bueno aprender un lenguaje de programación que se ejecuta en una computadora llena de recursos donde el programador novato puede hacer todo mal y el programa se ejecuta sin grandes problemas? ¿O es mejor aprender dónde el programador no puede salir mal?

Yo diría que es mejor aprender en una computadora con recursos limitados. No porque "el programador no pueda salir mal" sino porque el umbral de "frialdad" es mucho más bajo. Un programador novato podría no saber cómo hacer un gran juego de disparos en primera persona para su PC. Pero podrían escribir un gran juego de Pac Man para su TI-89 y usar el hardware en todo su potencial. Y eso es un sentimiento de poder.