MySilicium

Bon, ben ça nous fait 364 jours pour corriger le bogue. T'as fait un organigramme ?

Pour ma part : 7 et 8, sauf le « rarement » qui pourrait se transmuter en « jamais »...

Les phases de conception, de codage et de production (utilisation du programme et obtention du résultat) sont presque totalement confondues chez moi. Je commence un programme en partant d'une structure connue (typiquement en C : un « source » unique avec la lecture ligne à ligne d'un fichier-texte), puis j'ajoute la sortie sur un autre fichier, puis des traitements intermédiaires, de plus en plus complexes. Et quand je ne m'y retrouve plus dans mon programme (mes sources atteignent rarement 1000 lignes), je reprends de zéro, pour effectuer d'autres traitements... Je documente peu ou pas du tout, et quand je commence à le faire sur un projet, c'est que c'est le début de la fin pour lui !

Sur poquettes, rares sont les machines qui font des fichiers. Il s'agit davantage d'essayer des algorithmes, la notion de résultat est quasiment absente, en dehors du fonctionnement « bien huilé » de l'algorithme même. J'ai mis au point une méthode de numérotation des lignes par bloc qui soutient ma mémoire efficacement dans les branchements par GOTO. Voir mon fil sur les listes chaînées... Depuis son invention, je fais des algorithmes plus complexes et plus rapidement.

En fait, je n'ai pas l'habitude d'écrire ou de me documenter avant d'agir, et on ne m'a jamais entraîné à cette gymnastique ; je fonctionne systématiquement sur ma seule mémoire, même si celle-ci se révèle quelquefois défaillante. En fait, mon fonctionnement est par étape ; sur ordinateur, c'est ce que j'ai écrit et validé par la compilation qui me sert à la fois de base et de pierre d'appel pour le développement d'un module supplémentaire. J'ai besoin de commencer de la « page blanche » car tout ce qui est ajouté se nourrit de tout ce que j'ai échafaudé ; si je ne connais pas intimement tout ce qui a été fait avant, je ne peux pas avancer.

_________________
Programmeur abscons.

"Programmation d'amateurs"... n'ayant jamais eu d'emploi nécessitant de programmer (regrets...), je n'ai jamais programmé pour des activités professionnelles, et donc je me sens pleinement qualifié pour répondre en qualité d'"amateur"

Et en pratique, c'est une des raisons qui me font aimer les pockets Basic : c'est simple, immédiat et rapide. Autrement dit, pourquoi s'embarrasser d'un organigramme quand l'idée se traduit (quasi-) immédiatement en Basic ?

Dernièrement encore, j'ai eu à calculer la quantité de revêtement mural pour aménager deux pièces, et il m'a fallu dix minutes (au plus) pour faire le programme correspondant, puisque les dimensions du revêtement en question (lambris plastique) sont changeantes d'un fournisseur à l'autre, sans parler des dimensions des pièces en question. Ce qui m'a permis en prime de comparer facilement des prix, qui sont parfois exprimés en m², et d'autre fois en paquet (qui peut faire entre 1,98 et 2,66 m²). Un peu de logique, et en Basic cela devient tout de suite naturel. Pas besoin d'organigramme ni de théorie compliquée...

D'ailleurs, j'ai comme l'impression que le Basic a été conçu pour ce genre d'usage : après tout, il a été l'un des premiers -sinon le premier- langage interprété, autrement dit permettant immédiatement d'obtenir un résultat, sans passer par des compilations, éditions de liens, bibliothèques ou autres conceptions exotiques, fort pratiques pour les constructeurs mais imbuvables pour les utilisateurs (je pense en particulier au langage C, très pratique pour écrire un compilateur performant -c'est presque du langage-machine- mais difficilement compréhensible à la première lecture...).

Moralité : pour moi, si l'on a besoin de faire un organigramme, c'est que le langage de programmation utilisé n'est pas assez proche des besoins de son utilisateur pour être efficace. Ce qui est le cas de la quasi-totalité des langages de programmation actuels d'ailleurs, plus conçus pour exploiter les possibilités du matériel que pour être à portée de l'utilisateur.

Au déut des années 80, comme il y avait plus de machines que de logiciels disponibles, on était bien obligé de programmer. D'où le succès du Basic, rustique mais accessible. Ensuite sont venus les programmeurs professionnels, qui ont préféré des langages permettant plus proches du matériel, pour en tirer le maximum... et les programmeurs amateurs ont disparu.

Ne restent que quelques nostalgiques ...dont je suis. Nostalgique d'une époque où l'on pouvait réellement comprendre ce que faisait la machine que l'on utilisait, nostalgie d'une époque où l'on pouvait concevoir soi-même ce dont on avait besoin. Avec les ordinateurs actuels, nous ne sommes plus que des consommateurs : soit l'on trouve le logiciel qui fait ce que l'on désire, soit l'on reprend le papier et le crayon. Et grâce à Internet et au "cloud computing", nos beaux ordinateurs ne seront bientôt plus que de simples terminaux, comme à l'époque des "centres de calcul" des années 60 ou du Minitel... Quel progrès !

Bref, "programmer", c'est dépassé

_________________
I'm the operator
Of my pocket calculator
I am adding
And substracting...
(Kraftwerk, Computer World, 1981)

Donc il y a programme et programme.

Effectivement, pour un petit programme Forth (maxi 1000 lignes), pour moi c'est pratiquement du langage naturel

Mais quand ça devient plus sérieux, comme le programme de ma table à découper qui a dépassé les 10000 lignes à ce jour
(sans compter les définitions des données, je parles uniquement de programmation), si je ne mets pas par écrit les bouts de code,
ça devient très vite le souk

J'ai pris comme habitude de bien documenter mes sources, enfin, suffisamment pour moi
Par exemple, si je dois créer le mot "DISP5.1" qui affichera un nombre entier 16 bits sous la forme
5 chiffres + 1 chiffre après la virgule, je fais un truc comme ça :



les choses écrites entre parenthèses sont des commentaire, et toute la ligne située derrière l'antislash est aussi du commentaire
J'aime bien souligner les noms des mots, ça permet de mieux les voir dans le flot de code.

Dans mon programme de table à découper, je découpe aussi mon code en plusieurs fichiers (gestion mémoire, gestion claviers, gestion fichiers ...etc...)
Et pour le coup, dans le fichier principal, après un "INCLUDE" je liste les mots chargés avec une courte définition sur une seule ligne.
Ca me permet de ne pas à avoir à me balader dans les fichiers pour retrouver qui fait quoi...
(surtout que la programmation s'étale sur plusieurs mois)

Je trouve que le fait que le Forth fonctionne avec des mots facilite la programmation.
Comme les mots ne peuvent être définis qu'avec des mots existants, on peut donc les tester immédiatement,
ce qui permet d'éviter pas mal de temps de débogage

a+ François

L'organigramme permet parfois de rendre évident un raisonnement qui, autrement, pourrait ne pas l'être ; il permet parfois aussi de rationaliser les branchements conditionnels. Je me souviens de l'éclair de compréhension quand je m'étais servi d'un organigramme pour expliquer la méthode de calcul d'une année bissextile à une collègue de fac.
Elle avait presque compris.

_________________
Les génies composent, les pros exécutent.

5 & 6 pour moi.

En ce qui me concerne, je ne fais presque jamais d'organigramme lorsque je connais très bien la machine et que le problème est éventuellement posé au préalable sur une feuille. Cela est valable pour le Sharp PC-1403 dont le BASIC est, il est vrai, limpide. Néanmoins, il peut m'arriver de revenir sur un détail bogué avec un sous-organigramme. Mais c'est un cas assez rare.

Pour mes autres machines (HP évidemment, mais aussi PSION S3 que je connais moins bien), ça dépend beaucoup de ce que je veux faire : un programme d'astronomie sur 41 nécessitera un organigramme, et un autre programme cherchant à pousser l'engin dans ses derniers retranchements aussi (290 décimales de fractions à stocker dans les 29 mémoires de mes HP-19c ou 29c en est un exemple actuel).

Parfois, je m'embrouille et je me rends compte que les choses sont plus claires avec l'organigramme. J'utilise alors Draw d'OpenOffice : c'est beau, très intuitif, et on peut ranger le diagramme avec fierté dans le dossier des programmes.

@+ (pour le UP )

9 ... meme pire car quant je devais faire du "langage d'analyse" a l'ecole, je commençais a faire le truc en C en ensuite je convertissais

Pour les organigrammes en tant que tell, ca m'est arrive de griffonner des crobars pour comprendre ce que d'autres avait fait, mais soit pour des langages pas tres lisible tels que l'assembleur ou des langages que je ne maitrise pas trop.

_________________
Amiga, UNIX
Sharp, NetBSD http://destroyedlolo.info/
Apache, PHP 100 % dictionnary free
Vacances, Voyages 1 mispelling by word

Quand je donne du boulot à mes AP (analystes programmeurs) et en fonction de leur niveau et de la complexité j'explique mon besoin soit en français soit par des algorithmes plus ou moins détaillés. Quand je programme moi même 95% du boulot est fait de tête pour le reste je fais soit un algo soit je liste les cas. De manière générale je programme en partant du général et en allant vers le particulier et en prenant soin de ne pas écrire de procédures qui dépasseraient une feuille A4 à l'impression (mais ce n'est pas toujours faisable).

_________________
Tout est bon dans le pocket.
Moi j'aime tout.... Casio, HP, Sharp, TI et les autres sauf que les TI semblent ne pas m'aimer
http://www.emmella.fr
Mes Casio - HP - Sharp - TI
Homme invisible.

Je fais pas d'ordinogramme. Parfois, je gribouille quelques lignes de code lorsque le module devient complexe mais ça reste sur une section particulière : mouvement d'un sprite, recherche dicho si j'ai plus les idées claires, récursivité,etc...Sinon pour le code de base : jamais

L'ordinogramme n'est pas obligatoire, mais la présentation si.
Allez, un branchement direct : viewforum.php?f=49
Pierre

_________________
Le frottage de silex, c'est tout sauf une innovation : avant, on attendait simplement que la foudre tombe sur un arbre et qu'elle enflamme une branche, et ça fonctionnait très bien... ©SbM