Programmer en BASIC directement sur une Nintendo 3DS, c'est possible

Waow, on vis vraiment une époque formidable.

Saviez-vous qu'on peut également s'éclairer avec une demi noix de coco remplie de graisse animale ?

Waow, on vis vraiment une époque formidable.

Saviez-vous qu'on peut également s'éclairer avec une demi noix de coco remplie de graisse animale ?

+1

Bientôt ils comprendront que le futur des consoles, c'est le PC...

"Il est pratiquement impossible d'enseigner un bon style de programmation aux élèves qui ont eu une exposition antérieure à BASIC; en tant que programmeurs potentiels ils sont mentalement mutilés au-delà de tout espoir de régénération." E. W. Dijkstra, "The Threats to Computing Science".

Après, vous faites ce que vous voulez.

Au contraire je trouve l'idée originale. Le basic est un excellent moyen d'apprendre à programmer.
Et la programmation est une étape importante dans la compréhension approfondi du fonctionnement d'un ordinateur.
Évidement quelqu'un qui n'a pas connu les premiers ordinateurs risque de passer à coter de l'intérêt d'une telle chose.
Seul petit hic, programmer sur un clavier virtuel, c'est pas ce qu'il y a de plus top.

/dev/tty, le 23/07/2012 - 12:06

"Il est pratiquement impossible d'enseigner un bon style de programmation aux élèves qui ont eu une exposition antérieure à BASIC; en tant que programmeurs potentiels ils sont mentalement mutilés au-delà de tout espoir de régénération." E. W. Dijkstra, "The Threats to Computing Science".

Après, vous faites ce que vous voulez.

J'ai commencé à programmer en basic à 9 ans avec mon premier ordinateur (Oric 1). Cela ne m'a absolument pas géné dans l'apprentissage d'autres langages de programmations tels que le pascal, le C, le C++, ...
D'autant que le BASIC à largement évolué depuis ses premières moutures et on peut très bien faire de la programmation structurée (principal reproche que l'on faisait au basic à l'époque)

Ah oui, les propos de Dijkstra sont sans doute à remettre dans le contexte de l'époque. N'empêche qu'on peut trouver mieux pour débuter.

/dev/tty, le 23/07/2012 - 12:15

Ah oui, les propos de Dijkstra sont sans doute à remettre dans le contexte de l'époque. N'empêche qu'on peut trouver mieux pour débuter.

Oui, le brainf*ck

/dev/tty, le 23/07/2012 - 12:15

Ah oui, les propos de Dijkstra sont sans doute à remettre dans le contexte de l'époque. N'empêche qu'on peut trouver mieux pour débuter.

Le javascript ou le LISP ?
On ne parle pas forcément de faire de bon informaticien, mais surtout d'avoir une idée de ce qu'il y a derrière un programme.
Maintenant, on peut aussi s'installer un émulateur, et pourquoi pas de CPC , même si je préfère mon petit Spectrum.

Pour faire un bon informaticien, il faut commencer par une machine, sans mémoire, sans cpu et sans disque, après on peut voir pour faire de la programmation objet qui bouffe toutes les ressources en 2 lignes en parsant des fichiers XML de 2Go.
La contrainte est une chose qui n'est plus enseignée, c'est dommage, c'est la base de l'optimisation. Mais, on voit bien que ce n'est plus un objectif aujourd'hui, si ça tourne pas, c'est pas que c'est mal programmé, c'est que ta machine est pourrie.

"Il est pratiquement impossible d'enseigner un bon style de programmation aux élèves qui ont eu une exposition antérieure à BASIC; en tant que programmeurs potentiels ils sont mentalement mutilés au-delà de tout espoir de régénération." E. W. Dijkstra, "The Threats to Computing Science".

Après, vous faites ce que vous voulez.

Le BASIC, c'est bien le pire des langages pour commencer la programmation. Ou alors il faut être bien guidé par quelqu'un qui en a conscience.

Donc +1 si c'est ce que tu as voulu dire, mais je suis pas très sûr '

La contrainte est une chose qui n'est plus enseignée, c'est dommage

Sur nos machines d'aujourd'hui, un tel enseignement est souvent superflu. C'est très rare qu'une application logicielle standard aille taper dans les limites des machines actuelles. Ce qui est privilégié dans l'enseignement aujourd'hui, c'est le génie logiciel : il ne s'agit pas simplement de faire un programme qui tourne et qui soit le plus optimisé possible, il s'agit surtout de développer rapidement en divisant au mieux le travail, en développant des modules génériques hautement réutilisables, faciles à maintenir et à faire évoluer. Et s'il y a une optimisation à faire alors elle sera plus généralement d'ordre algorithmique (passage de O(n) à O(log(n)) par exemple) que bas-niveau.
Si on se place dans une optique de pure optimisation, alors on se contraint à ne coder qu'en ASM et à ne jamais développer ou utiliser de fonctionnalités génériques, de manière à pouvoir tout recréer chaque fois qu'on en a l'utilité mais en l'optimisant au mieux de nos besoins courants.

@Flaxe et /dv/tty
Le Basic n'est pas le meilleur langage de programmation, j'en conviens. Mais de là à dire que quelqu'un qui a travaillé en BASIC ne fera jamais un bon programmeur y a quand même un fossé que M.Dijkstra franchit allègrement.

@Centaurien :

La contrainte est une chose qui n'est plus enseignée, c'est dommage, c'est la base de l'optimisation. Mais, on voit bien que ce n'est plus un objectif aujourd'hui, si ça tourne pas, c'est pas que c'est mal programmé, c'est que ta machine est pourrie.

Je suis parfaitement d'accord avec ce point. Avant on avait une machine et on devait faire avec. Les programmeurs devait parfois se torturer les méninges pour faire tourner les programmes sur les ordis.
Aujourd'hui c'est l'inverse, un programme ne tourne pas, c'est pas grave on rajoute de la mémoire ou on change la carte graphique, le processeur, ...

Aldebran, le 23/07/2012 - 13:23

Sur nos machines d'aujourd'hui, un tel enseignement est souvent superflu. C'est très rare qu'une application logicielle standard aille taper dans les limites des machines actuelles.

Installe Photoshop !

Ce qui est privilégié dans l'enseignement aujourd'hui, c'est le génie logiciel : il ne s'agit pas simplement de faire un programme qui tourne et qui soit le plus optimisé possible, il s'agit surtout de développer rapidement en divisant au mieux le travail, en développant des modules génériques hautement réutilisables, faciles à maintenir et à faire évoluer.

Oui, je sais, ce qui compte, c'est que ton développeur fasse son programme en 1 mois, pas que celui puisse tourner sur une machine de moins de 1 pétaflops. Parce que ça coûte un développeur et que la machine, c'est pas toi qui l'achète. Néanmoins, on vit sur la même planète, il faut aussi penser que les ressources dégringolent et si moyennant un usage parcimonieux des librairies couteuses en mémoire et CPU, tu peux faire la même chose, autant le faire. On est pas obligé de tout stocker en XML par exemple.

Et s'il y a une optimisation à faire alors elle sera plus généralement d'ordre algorithmique (passage de O(n) à O(log(n)) par exemple) que bas-niveau.

Le problème c'est surtout d'utiliser les bonnes librairies pour faire les bonnes choses. Si ton les développeurs utilisent la même librairie, et que celle-ci a été développée avec les pieds, c'est tous les programmes qui en pâtissent. Les objets, c'est super pratique en temps qu'informaticien, mais c'est quasiment impossible de gérer correctement les ressources d'une machine dans ce concept (à part la gestion du No more memory available).

Si on se place dans une optique de pure optimisation, alors on se contraint à ne coder qu'en ASM et à ne jamais développer ou utiliser de fonctionnalités génériques, de manière à pouvoir tout recréer chaque fois qu'on en a l'utilité mais en l'optimisant au mieux de nos besoins courants.

Non, mais toute librairie n'est pas une fin en soi. Si tu utilises une librairie qui fait des cercles pour faire des carrés, tu pourras bidouiller ton truc pour que ça rentre dedans, mais si derrière tu utilises cette librairie dans 50000 programmes, c'est juste naze, tu aurais dû créer ta propre librairie de carré.

"Les programmeurs devait parfois se torturer les méninges pour faire tourner les programmes sur les ordis" : programmes non maintenables car pas de doc, pas de commentaires dans le code et pas de capacité à développer suffisemment vite pour répondre aux besoins du business. si les grosses boites gardent leurs applis backoffices aujourd'hui ça n'est pas par plaisir mais pas le temps de revoir tout ça, voir peur de toucher à une boite noire qui marche : on préfère broder broder et encore broder autour, complexifier le SI, le soit disant simplifier avec des workarounds que certains appeleront EAI, ESB, pourquoi pas ETL ... bla bla. Aujourd'hui c'est vrai, c'est très différent : on fait des programmes non maintenables car pour une enormes partie fait d'un assemblage de briques, les frameworks à gogo dont le développeur néo-architecte ne comprends qu'une maigre partie, frameworks qui changent de version tous les 15 du mois si ils ne disparaissent pas tout simplement. Des solutions techniques qui forment les fondations des applis et dont les cycles de vie sont courts tels qu'on ne l'avait jamais vu avant, assez court pour que le niveau d'adoption dans la communauté ne soit pas suffisant pour qu'on risque de maintenir en vie l'appli. Oui mais tu cnnais bidule qui est un guru là dessus ? On connait tous un bidule guru d'un truc mais ça ne suffira pas aux boites pour embaucher quelques bidules, ca ne leur garantira pas que le savoir est perenisé ni fournira une GTI, GTR ... La TMA en rêve alors que la TMA, c'est lemonde demain pour l'informatique (je ne suis pas pro-TMA, je constate). Donc l'appli ira, plus raisonnablement, à la poubelle. Finalement on fait aujourd'hui des applis très dans l'esprit de la société de consommation. Pas cher, jetables. Chaque brique qui la compose que t'assemble peut te faire le café le linge et la vaisselle mais t'as juste besoin d'une petite cuillère, là passe la conso de ressource. Par le passé et aujourd'hui, dans les 2 cas des programmes peu ou pas maintenables (et des machines pas saturées - woua, on a sauvé un truc ... sauf la conso d'électricité et clim bien sur ... va savoir pourquoi on parle de plus en plus de green IT et datacenter qui doivent respecter des normes eco). L'informatique, un éternelle recommencement. Dans une autre veine on pourrait aussi s'amuser en parlant du SaaS (encore mieux, marketisé : le clouuuud) ou comment louer un malheureux prologicel hébergé dans un datacenter. J'ai aussi le VDI pour la virtualisation de station travail ... trop moderne, ça me fait penser aux terminaux X... etc

Rêvons

Faire découvrir le "Fun" des syntax error à ceux qui n'ont pas connu , c'est bon ça.

Me souviens encore de l'angoisse naissante quand je tapais "run" le doigt sur la touche enter ...

ah le coup de vieux là bon je file relire mes tilt

speed, le 23/07/2012 - 14:16

Faire découvrir le "Fun" des syntax error à ceux qui n'ont pas connu , c'est bon ça.

Me souviens encore de l'angoisse naissante quand je tapais "run" le doigt sur la touche enter ...

ah le coup de vieux là bon je file relire mes tilt

C'est toujours mieux que les java exceptions pendant que ça tourne ...

@Nebuleusem44 :
Pas tout a fait d'accord quand tu dis que les vieux programmes n'étaient pas maintenable.
Les commentaires ça à toujours existé même en assembleur.
Et si ton code était propre il n'était pas difficile de le comprendre.

Justement beaucoup moins que maintenant ou il y a des librairies à gogo.

Comme tu le souligne justement, alors qu'ils suffit parfois de prendre 10 minutes pour programmer son propre truc. Certains, préfèreront charger une librairie de 10000 lignes de codes là ou il pourrait faire le truc en 5 lignes.

Maintenant des gens qui programment avec les pieds, y en a toujours eu. Et il y en aura toujours.

@Astragor

Ce que j'ai pu constater mais chaque expérience est unique : pour mon cas sur des programmes C entre 10 et 20 ans d'âge chez différents clients pour plusieurs 10aines de milliers de lignes sur des systèmes critiques, c'est certes des commentaires, mais pas tant que ça de commentaires qui soient utiles ; rarement du code propre (les cours d'algorithmie pour les très nombreux profils bac+2 sur le marché laissent certainement à désirer en contenu et/ou n'ont pas le poids qu'ils devraient avoir ce qui n'a pas aidé les entreprises, sans parler des multiples profils reformés d'autres métiers vers l'IT mono-sujet mono-technique en 1 voir 2 mois grand maximum - je parle d'informatique de gestion bien sur) ; si le code était propre à l'origine, l'urgence des besoins business depuis 10 ans a fait que la dite appli est criblée de patchs (pour ne pas parler de verrues) et que personne n'a voulu prendre le temps et surtout l'argent pour s'offrir du refactoring. Pour à la fin arriver souvent, statistiquement, à "bon, ça prend donc 15 jours de changer cette petite fonction ? mmm ... brodons plutôt autour, on est grave pressés"

Bien sur il y a des exceptions.

Quant aux gens qui programment avec leurs pieds, tu auras compris mon avis : je crains qu'il y en ai beaucoup, beaucoup plus que ce qu'on imagine. Et quand ce sont des personnes capables de bien faire, encore faut-il qu'ils soient dans une entreprise capable de comprendre le temps nécessaire à un travail de qualité, avec un chargé de projet capable de vendre cette qualité et les economies long terme inherentes aux utilisateurs non IT qui sont souvent les decideurs et ceux qui affectent le pognon. Les mêmes utilisateurs qui sont approchés de + en + en direct par des avant-ventes de solutions SaaS dites "clef en main" (ahah), qui eux se vendent comme réactifs, comprennent le métier (of course), travaillent en agile (la class , bref qui court-circuitent l'IT pour bourrer le moue de personnes qui n'y comprennent rien, ne s'intéressent pas à la sécurité des données, au SLA, et encore moins aux possibilité d'interfacage avec les systèmes existants. Voilà l'IT interne qui rame pour faire de beaux spaghettis

Bref,
Pour notre sujet je crois donc qu'il y a un problème de formation plus que de technique (puisqu'on pourrait effectivement et aujourd'hui, se passer de ces librairies de 10000 lignes de code), et un problème de relation en entreprise entre IT/non-IT qui va croissant (avec la multiplication des offres SaaS hyper-markétisées + la consumérisation de l'IT)


A moins que ça ne soit un problème du capitalisme qui pousse à toujours plus de profit sans vision long terme ? )) Qui ici se trouve dans une DSI qui a un schéma directeur sur 5 ans

Centaurien, le 23/07/2012 - 14:32

speed, le 23/07/2012 - 14:16

Faire découvrir le "Fun" des syntax error à ceux qui n'ont pas connu , c'est bon ça.

Me souviens encore de l'angoisse naissante quand je tapais "run" le doigt sur la touche enter ...

ah le coup de vieux là bon je file relire mes tilt

C'est toujours mieux que les java exceptions pendant que ça tourne ...

Euh ? Non.

8$ pour un putain d'intepreteur basic la vache ils manquent pas d'air

Je n'y connais pas grand chose en programmation. J'ai seulement quelques petites notions.
J'ai commencé il y a peu à m'y intéresser, en commençant par le langage Python, car j'ai lu que c'était un bon langage pour débuter. (et aussi parce que c'est un langage libre et multiplateforme)
J'ai également vu que le BASIC et dérivés étaient déconseillés mais je n'ai jamais su pourquoi.
Si quelqu'un peut m'expliquer avec des mots simples pour une personne qui débute à peine ce serait sympa ;-)

Il faut savoir que nombreux reproche que l'on faisait au BASIC à l'époque n'ont plus lieu d'être.

- Le principal reproche était que le Basic n'était pas un langage structuré. Où faiblement structuré :
Peu de structure de boucle (juste la boucle for, et pour les plus évolués parfois la boucle repeat ou la boucle while).
Pas de fonctions mais des sous programmes (le fameux gosub) ou la fameuse instruction goto qui avait pour action de détourner le cheminement du programme vers un autre endroit.
Pas de passage de variable
Pas de bloc d'instructions pour les Test. Le If...then else ne pouvait contenir qu'une seule instruction.
Pas d'utilisation de label mais des numéros de lignes
Pas d'obligation de déclarer une variable avant son utilisation
Pas de notion de portée des variable (uniquement des variables globales).
- Le deuxième reproche était que le basic était un langage interprété donc un code plus lent à exécuter qu'un langage compilé.

Mais bon tout ces défauts ont été gommés dans les basic nouvelle génération, il est donc devenu un langage aussi intéressant à apprendre que d'autres.

Pou ma part, je suis convaincu que le meilleur langage d'apprentissage reste le pascal qui oblige le programmeur à adopter une structure irréprochable sous peine de se faire jeter par le compilateur. Ce n'est d'ailleurs pas pour rien que c'est le premier langage à être enseigné dans les écoles informatiques. (Avant le C)

Après bon c'est un peu chacun qui voit en fonction de ses besoins / ses envies.

Pou ma part, je suis convaincu que le meilleur langage d'apprentissage reste le pascal qui oblige le programmeur à adopter une structure irréprochable sous peine de se faire jeter par le compilateur. Ce n'est d'ailleurs pas pour rien que c'est le premier langage à être enseigné dans les écoles informatiques. (Avant le C)

Tout à fait d'accord pour du procédural.

Mais pour de la programmation évenementielle, Visual Basic a été un véritable électrochoc : on a enfin pu écrire facilement des programmes pour Windows.

Sinon chaque langage correspond à la fois à un usage et à une époque. Et tu pouvais écrire des trucs bien et de la merde avec chacun d'entre eux.

J'ai vu du code en assembleur qui s'automodifiait pour optimiser la taille du code : en fonction de certaines conditions, le programme allait modifier le sens d'un test supérieur ou inférieur.

J'ai vu du code en C avec des multiplications de pointeur : ne me demandez pas à quoi ça sert, je n'ai jamais compris.

J'ai aussi vu du code C planter un ordinateur alors que le programme ne faisait rien : Juste une boucle qui réservait x octets de mémoire, puis libérait ces x octets. Sauf que quand il réservait, le compilateur arrondissait le nombre d'octets à la puissance de 2 supérieure, mais que quand on libérait il utilisait la valeur exacte indiquée. Saturation mémoire assurée.

J'ai vu du code Pascal (pour des systèmes de contrôles de radars) avec des procédures de 30 pages de long et 40 à 50 niveaux de if imbriqués. Impossible à maintenir.

A mon humble avis pour apprendre à programmer aujourd'hui c'est clairement Python (version 3) qui est le meilleur choix. Il a été créé pour être le plus simple possible, ça se lit comme du pseudo-code tellement c'est simple. Et c'est hyper puissant, la gestions des objet est super bien foutue, surtout quand on compare à d'autres langages (java par exemple).
Moi aussi j'ai commencé avec le BASIC sur mon CPC6128 mais jamais je ne recommanderais ça à un novice maintenant. Python est là.

Coder avec un stylet sur un écran tactile tout petit ? oO Mais ils veulent dégouter les jeunes de la programmation.

FroLeMageBlanc, le 24/07/2012 - 09:40

A mon humble avis pour apprendre à programmer aujourd'hui c'est clairement Python (version 3) qui est le meilleur choix. Il a été créé pour être le plus simple possible, ça se lit comme du pseudo-code tellement c'est simple. Et c'est hyper puissant, la gestions des objet est super bien foutue, surtout quand on compare à d'autres langages (java par exemple).
Moi aussi j'ai commencé avec le BASIC sur mon CPC6128 mais jamais je ne recommanderais ça à un novice maintenant. Python est là.

C'est sur que le langage objet et tout ce qui en découle est bien pour débuter en programmation !
Déja il faut que la personne puisse débuter sur un langage qui soit simple sans fioriture.
Si tu commences dès le début par un langage tel que le python ou le C++, c'est pas la peine.

+1, python est un bon langage mais loin d'être le meilleur pour apprendre.

Mais pour de la programmation évenementielle, Visual Basic a été un véritable électrochoc : on a enfin pu écrire facilement des programmes pour Windows.

Delphi était quand même et reste plus performant que VB pour la prog windows. A peu de chose pret il est sorti en même temps que VB !
Beaucoup de défaut aussi dans les premières versions de VB (langage pseudo compilé, impossible de créer ses propres composants, ...). Défaut qui ont été gommé par la suite lorsq'un chef de projet delphi à été débauché par MS et à intégré l'équipe de dev VB.

Delphi était quand même et reste plus performant que VB pour la prog windows. A peu de chose pret il est sorti en même temps que VB !

Je suis d'accord que Delphi était plus performant.
Mais il est sorti 2 ou 3 ans après Visual Basic.

A l'époque (vers 1992/1993), on avait deux développeurs en C (MS-DOS) à qui on avait demandé de faire une maquette d'un logiciel (formulaire) sous Windows. En 3 semaines, ils avaient à peine réussi à faire un écran tout moche et qui ne marchait pas très bien.

Et peu de temps après, on a eu à faire une autre maquette (idem, un formulaire assez chargé). En deux jours avec Visual Basic, on avait un truc nickel.

C'est vrai que VB avait plein de défauts : mais on a quand même mené 3 ou 4 projets assez importants avec lui. Quand on avait besoin de composants spécifiques, on les faisait réaliser en C.

Et ensuite, on a laissé tomber VB et on est passé sous PowerBuilder plutôt que Delphi.

zig, le 25/07/2012 - 10:10

Et ensuite, on a laissé tomber VB et on est passé sous PowerBuilder plutôt que Delphi.

Aïe !