Pensez-vous que l'exposition à BASIC peut mutiler votre esprit? [fermé]

Il est pratiquement impossible d'enseigner une bonne programmation aux étudiants qui ont déjà été exposés au BASIC: en tant que programmeurs potentiels, ils sont mutilés mentalement au-delà de tout espoir de régénération.

- Edsger W. Dijkstra

J'ai un profond respect pour Dijkstra mais je ne suis pas d'accord avec tout ce qu'il a dit / écrit. Je suis en désaccord spécialement avec cette citation sur papier lié écrite il y a 35 ans à propos de la mise en œuvre de Dartmouth BASIC .

Beaucoup de mes collègues de travail ou amis programmeurs ont commencé avec BASIC, les questions ci-dessous ont des réponses qui indiquent que de nombreux programmeurs ont eu leur première expérience de programmation chez BASIC. AFAIK beaucoup de bons programmeurs ont commencé la programmation BASIC.

Je ne parle pas de Visual Basic ou d'autres dialectes "modernes" de BASIC fonctionnant sur des machines pleines de ressources. Je parle de l'ancien temps BASIC fonctionnant sur un ordinateur "jouet", que le programmeur devait s'inquiéter de la sauvegarde de petits nombres qui n'ont pas besoin d'être calculés comme une chaîne pour enregistrer un octet minable parce que l'ordinateur n'en avait que quelques centaines, ou doivent utiliser goto calculé faute d'une fonctionnalité plus puissante, et bien d'autres choses qui nécessitent que le programmeur réfléchisse beaucoup avant de faire quelque chose et de forcer le programmeur à être créatif.

Si vous aviez de l'expérience avec le BASIC ancien sur une machine aux ressources limitées (gardez à l'esprit qu'un micro-contrôleur simple a aujourd'hui beaucoup plus de ressources qu'un ordinateur en 1975, pensez-vous que le BASIC vous aide à trouver de meilleures solutions, à penser comme un ingénieur ou BASIC vous traîne du côté obscur de la programmation et vous mutile mentalement?

Est-il bon d'apprendre un langage de programmation fonctionnant sur un ordinateur plein de ressources où le programmeur novice peut faire tout mal et le programme s'exécute sans gros problèmes? Ou est-il préférable d'apprendre où le programmeur ne peut pas se tromper?

Que pouvez-vous dire sur le BASIC qui vous a aidé à être un meilleur / pire programmeur?

Souhaitez-vous enseigner un ancien BASIC fonctionnant sur une machine (virtuelle) de 2 Ko à un programmeur à venir?

Bien sûr, seule l'exposition à BASIC est mauvaise. Peut-être que vous partagez mon opinion que le BASIC moderne n'aide pas trop parce que le BASIC moderne, comme tant d'autres langages de programmation, offre des installations qui permettent au programmeur de ne pas réfléchir plus profondément.

Informations supplémentaires: Pourquoi BASIC?

Les principes de base populaires au moment de la citation étaient très différents de ceux que nous avions il y a même 20 ans. (Comptez-vous ceux parmi vos dialectes "modernes"?;)

Oubliez les boucles, les sous-programmes, les variables locales et tout ce que la programmation structurée (dont Dijkstra et Knuth étaient de grands partisans) a souligné. Vous aviez GOTO et vous avez aimé .

Dans ce contexte, les programmeurs qui ne connaissaient que les variables globales, ont inventé leurs propres sous-programmes (en utilisant plus de variables globales pour les paramètres et les valeurs de retour!) Et ont écrit des spaghettis GOTO étaient vraiment mutilés.

Si vous avez 30 ans ou moins aujourd'hui et que Basic était votre première langue, ce n'était pas la même langue que Dijkstra parlait. Même si vous êtes plus âgé et que votre premier Basic avait certaines de ces fonctionnalités, comme le commente Murph ci-dessous, il se peut que ce ne soit pas la même langue dont Dijkstra parlait.

Vous avez mis à jour la question avec un contexte que je ne connaissais pas auparavant:

• La citation de Dijkstra date de 1975.

• Ce n'est qu'à partir de la version 6 que vous avez obtenu des procédures compilables séparément - ce qui, je crois, montre le début du changement de focus loin de GOTO.

• "En 1976, Steve Garland a ajouté des fonctionnalités de programmation structurée pour créer Dartmouth SBASIC, un précompilateur qui a produit la sortie de la version 6 ..." ^{[ Wikipedia ]} Le contexte de la citation est clairement avant ce que nous connaissons maintenant sous le nom de structures de contrôle, et de nombreux utilisateurs de la le temps aurait pu être plus familier avec l'avant-dernière version - c'est-à-dire deux versions avant Garland, qui est la v5 et avant les procédures compilables séparément.

• GOSUB / RETURN ne gère toujours que les "sous-programmes simples".

• "Les noms de variables étaient limités à A à Z, A0 à A9, B0 à B9, ..., Z0 à Z9, donnant un maximum de 286 variables distinctes possibles." ... et ils sont tous mondiaux.

_{Un homme ne peut rien faire de mieux que manger et boire et trouver satisfaction dans son travail.}

J'ai appris le BASIC avant toute autre chose (enfin, sauf pour l'algèbre, je suppose). Si cela ne me déforme pas sérieusement, alors je ne sais pas comment expliquer les 18 années qui ont suivi ...

Cela dit, alors quoi? Dijkstra pourrait avoir du mal à m'apprendre quoi que ce soit à cause de mon exposition à long terme à BASIC, mais il aurait plus de mal à m'apprendre quoi que ce soit à cause de son exposition à long terme à une boîte de pin souterraine. Et même avec ces facteurs supprimés, je n'ai toujours jamais été un étudiant sérieux en CS, un étudiant sérieux en mathématiques ou un étudiant sérieux dans une autre discipline. L'abîme entre quelqu'un comme moi et le genre de programmeur que Dijkstra aurait aimé voir est si grand qu'il est presque insondable ...

Et pourtant, nous programmons. Nous qui avons mordu sur BASIC, joué avec FORTRAN, expérimenté avec COBOL et tout le reste, nous avons également trouvé une joie et une fascination pour ces petites machines qui, bien que peut-être totalement différentes de celle qui a attiré M. Edsger dans son domaine, n'est pas moins une vocation, le fondement d'un travail d'amour tout au long de la vie.

... ou peut-être que c'est ce que dirait un esprit mutilé ...

Ce n'est pas BASIQUE qui vous blesse, c'est l'échec de vous exposer à d' autres langues. Les "programmeurs" monoglots ne le sont pas.

BASIC, d'un point de vue structuré, n'était pas pire que l'assembleur ou le COBOL. À l'époque, il n'y avait pas la pléthore de langues d'origine algol que nous avons maintenant, Pascal étant la première introduction que la plupart des gens avaient à des structures de contrôle raisonnables (et je n'aime pas beaucoup les structures de contrôle Pascal).

Si BASIC était suffisant pour nuire de façon permanente aux gens, alors d'autres langues anciennes l'ont été aussi, et nous n'aurions donc pas eu suffisamment de personnes indemnes pour développer toutes les langues que nous utilisons aujourd'hui.

Il est possible que Dijkstra ait alors eu affaire à des gens qui n'étaient pas de bons programmeurs et qui ne le seraient jamais, qui ont appris à faire certaines choses en BASIC. C'est l'interprétation la plus charitable que je puisse donner à la déclaration.

J'ai appris avec BASIC sur un TRS-80 et Apple II c / e, et je me considère comme un bon programmeur. Les deux traits qui, selon moi, ont conduit à ne pas être détruits en apprenant le BASIC en premier sont:

1. J'ai continué à essayer de meilleures façons d'accomplir ce que je voulais avec moins d'effort, ce qui a conduit à l'apprentissage d'autres langues et aux fonctionnalités de ces langues qui les rendent puissantes, et
2. J'ai rencontré et reconnu des problèmes avec BASIC en tant que langue, en particulier le manque de sous-programmes (même si je n'avais pas l'expérience pour décrire de manière concise les problèmes que je fais maintenant).

Je dois admettre que l'apprentissage de la programmation orientée objet après la pure procédure de BASIC a été un combat pendant un certain temps, mais je ne sais pas si cela était vraiment lié à BASIC, car j'avais également appris une bonne quantité de C .

Je ne suis pas d'accord non plus avec Dijkstra. Je pense qu'il est plus difficile d'apprendre une deuxième langue à cause des paradigmes, pas parce que c'est BASIC.

BASIC était ma première langue sur un ordinateur personnel appelé TK (Sinclair like) en 1985. C'était une machine à ressources très limitées. Pendant ce temps, j'ai écrit un compilateur BASIC à partir d'un livre en utilisant un éditeur hexa-décimal pour le plaisir. J'ai acheté un livre Z80 et j'ai appris le langage machine 8 bits par la suite. BASIC m'a beaucoup aidé avec ça.

Après avoir appris C et Pascal et jouer avec Assembly pour 8080/6. MSX-BASIC, Quick Basic en temps MS-DOS ... VB, Delphi, certains Java en temps Windows ...

Aujourd'hui, un travail avec progrès (4gl), .net (C # / VB), php et je ne me sens pas comme un cyclope. : O)

J'ai commencé avec basic sur un clone de pomme quand j'avais huit ans.

Même les versions ultérieures de base qui comportaient des idées de POO (qbasic, visual basic, etc.) n'auraient pas eu de sens chez Eight.

Commencer la programmation aussi tôt est l'une des raisons pour lesquelles je peux réfléchir au problème du flux des programmes et c'est quelque chose de trop de gens ne peuvent pas bien faire dans cette industrie.

Je pense qu'un démarrage précoce est souvent bénéfique et un langage TRÈS SIMPLE est nécessaire pour les petits.

Votre kilométrage peut varier...

Je pense que l'exposition à la plupart des exemples BASIC dans le monde est ce qui mutile le cerveau des programmeurs, pas le langage lui-même. C'est comme le programmeur C # qui parcourt MSDN et ne pense pas que la gestion des exceptions soit nécessaire ou que les IDisposabletypes n'ont pas vraiment besoin d'être supprimés.

N'importe qui va avoir un problème s'il ne peut pas identifier les problèmes dans sa langue actuelle et non seulement être capable de les contourner, mais en trouver un autre conçu pour résoudre le problème.

Et GOTO n'est mauvais que si vous n'avez pas de numérotation des lignes;)

J'utilise actuellement BASIC pour apprendre à mon fils à écrire ses propres jeux simples. Je ne l'ai jamais utilisé, j'ai commencé mon support avec PowerBuilder et PowerScript et j'ai sauté sur C / C ++ puis Delphi. Aujourd'hui, j'utilise presque toutes les langues disponibles et je m'adapte très vite car les bases de toutes les langues sont les mêmes, des formules mathématiques avec des signes, opérateurs et symboles différents. C'est aussi ce que j'enseigne à mon fils et à cause de cela, il peut déjà lire et expliquer le code C ++. Mon fils a 12 ans.

BASIC GOTOest un excellent moyen d'enseigner la façon de penser en langage assembleur . Il ne mutile pas l'esprit, il éloigne seulement l'esprit des synapses à base de carbone et le rapproche des transistors à base de silicium.

Cependant, comparons BASIC et LOGO. BASIC peut détourner les jeunes enfants de la programmation, car pour écrire un programme simple et amusant, tout ce que vous pouvez faire est de continuer à copier un programme très, très long imprimé sur un magazine, alors qu'avec LOGO, une seule ligne peut dessiner des graphiques très impressionnants, ce qui est essentiel pour attirer les enfants.

Le basique est bon - c'est amusant et assez simple Il peut faire des graphismes 2D amusants et ce qui ne l'est pas ... J'ai appris (ou essayez d'apprendre) que quand j'avais environ 10 ou 12 ans, c'était un langage amusant qui m'a intéressé à en savoir plus sur les ordinateurs ...

Certains des meilleurs programmeurs que je connaisse ont été exposés très tôt à la programmation en Basic. C'est un peu plus "concret" et donne ainsi une meilleure idée de la façon dont la machine de bas niveau pourrait réellement fonctionner que de nombreuses langues plus récentes (par exemple, c'est une introduction HLL plus proche de l'assembleur).

La citation de Dijkstra est d'une période où les universitaires tentaient de pousser une tendance vers des programmes bien structurés et prouvablement corrects conçus à partir de spécifications. Mais ce n'est pas ainsi que s'est déroulée une grande partie de l'industrie. Au lieu de cela, de nombreux programmeurs de l'ère du Web 2.0 tentent de créer rapidement un prototype pour lequel la plupart des spécifications mathématiquement strictes pour prouver le code n'existent pas, car les choses évoluent trop rapidement pour que cette spécification reste compétitive.

Ainsi, les méthodes de programmation par essais et erreurs par hack-and-slash que la programmation en Basic encourage parfois, lorsqu'elles sont nettoyées un peu dans la méthodologie, sont une amorce utile pour la réflexion RAD.

Je terminerai en notant qu'il existe au moins 5 interprètes de base disponibles qui fonctionnent sur l'iPad, gardant ainsi la langue disponible même sur les appareils les plus récents.

Je pense que, étant donné que cette citation a 35 ans, cela a beaucoup à voir avec le manque d'abstraction qui était disponible dans les langages de programmation, et ce qui était nécessaire pour que vous sachiez bien évoluer, à l'époque où cela a été dit.

Le fait de recevoir un langage comme BASIC vous en apprend peu sur la programmation à bas niveau, quelque chose de beaucoup plus nécessaire dans le passé que maintenant, et vous donnerait l'impression erronée que la programmation était plus simple qu'elle ne l'est réellement.

Je me souviens avoir essayé de façon discrète d'apprendre le «code machine» à l'âge de 15 ans après plus de 3 ans de VZ200, C64 et Apple] [e BASIC, c'était un grossier réveil.

Ces jours-ci, cependant, bien que je sois un snob complet sur ces choses, et vous ne me trouverez pas heureux de travailler dans n'importe quelle langue avec BASIC dans le nom (j'ai tendance à commencer à crier sur les phrases du moniteur comme `` stupide Fisher Price Language '' car il , encore une fois, rejette mes accolades imprudentes), j'admets qu'il est plus facile de faire des choses productives avec des langages qui font abstraction de la mécanique du CPU qu'il y a 35 ans (ou il y a 25 ans, dans ma propre expérience personnelle et mon exemple)

pour ceux d'entre nous qui chargeaient un octet à la fois le code d'assemblage dans les ordinateurs Speer Micro-LINC via un ensemble de 8 commutateurs sur le panneau avant et les stockaient sur des bandes PDP en 1972, j'affirmerai sans équivoque que Dijkstra était un twit pompeux. Tout ce qu'il méprisait pour Basic était vrai dans la pique de l'assembleur avec lequel je travaillais et pourtant moi-même et des milliers d'autres personnes se sont remis de notre exposition à l'assembleur et plus tard à Basic et Fortran et Cobol et C etc.

J'ai commencé à programmer avec GW-BASIC au début des années 1990. Mon esprit ne s'est pas mutilé. Je suis passé à de meilleurs langages comme Pascal, C, C ++, Java, C # et Python.

Je ne pourrais pas écrire un programme BASIC aujourd'hui; J'ai oublié comment penser en termes de numéros de ligne. Ce n'est pas un problème.

Mais mon expérience BASIC m'a beaucoup aidé dans mon cours universitaire d'architecture informatique où j'ai dû apprendre le langage d'assemblage (MIPS). Assemblée flux de contrôle de la langue est un peu comme BASIC de: Sauts = GOTO, branches = IF... GOTO, jal(appel) ... jr(ret) = GOSUB... RETURN. C'est tout le flux de contrôle dont vous avez besoin!

Est-il bon d'apprendre un langage de programmation fonctionnant sur un ordinateur plein de ressources où le programmeur novice peut faire tout mal et le programme s'exécute sans gros problèmes? Ou est-il préférable d'apprendre où le programmeur ne peut pas se tromper?

Je dirais qu'il vaut mieux apprendre sur un ordinateur avec des ressources limitées. Non pas parce que "le programmeur ne peut pas se tromper" mais parce que le seuil de "fraîcheur" est beaucoup plus bas. Un programmeur débutant pourrait ne pas savoir comment faire un excellent jeu de tir à la première personne pour son PC. Mais ils pourraient écrire un grand jeu Pac Man pour leur TI-89 et utiliser le matériel à son plein potentiel. Et c'est un sentiment de puissance.