Pour les fanatiques du C - Page 1

Lisez donc ceci :

http://valvassori.free.fr/dave_small/index.php3

Plus spécifiquement la partie nommé "Hérésie, 2nde partie"

C'est très instructif et ça remet les pendules à l'heure !


Cooper, qui aime Dave Small

Très intéressant cet article.

"
De même, structurer un article, tout auteur sain d'esprit le fait, mais pas forcément de manière conformiste. Le "flot de contrôle" de l'article ne doit pas être exagérément obscurci par des digressions, des écarts et des considérations hors- sujet. J'ai délibérément écrit cet article de manière non structurée, en y ajoutant force digressions, de manière à bien montrer l'analogie avec la programmation. Dans d'autres articles, je vais rigoureusement du début à la conclusion de manière linéaire, ce qui montre que je peux aussi écrire - ou coder - de manière structurée. Mais l'important, c'est le plaisir du lecteur. A votre avis, de l'agrément ou de la rigueur, qu'est-ce qui prime ?
"

Et il est vrai qu'on le lit avec bcp de plaisir

mouais...

hacker or not hacker that is the question...

Pendules à l'heure ? Hmmm, franchement, cet article date d'il y a 15 ans. Depuis non seulement les éditeurs ont évolués, les compilateurs mais aussi les débuggeurs. Débugger du code C sous Visual est même plus confortable que débugger de l'assembleur puisqu'il montre la valeur symbolique des variables locales en cours d'utilisation sur chaque instruction.

OK pour le patriotisme, mais il ne faut pas non plus être rétrograde. Les PC ont évolués, les bugs aussi, ainsi que les outils de programmation. Les temps changent, les références aussi... Reste que l'ont peu rendre le C aussi difficile à lire qu'un bon GFA Punch, alors pas de parallèles inconsidérés "le basic c'est mieux que le C, et gnagnagna", d'accord ?

Moi aussi dans ma jeunesse, j'ai eu plaisir à lire les articles de Dave Small, trop content d'avoir un professionnel qui traitait élogieusement nos machines. Mais il faut se rendre parfois à l'évidence, celles-ci sont tout de mêmes pourvus d'une multitudes de tares (voir le threaf 'Coup de gueule' sur les STf, ou les multiples défauts de conception du Falcon030). Les PC sont peut être des merdes (quoiqu'ils se sont bien améliorés depuis l'époque Small), mais ce sont des merdes qui tournent à 2 GHz ! Ca relativise...

Si vraiment vous n'aimez pas les PC ni le C, évitez alors de vouloir de l'USB, de l'EtherNet, du S-ATA, du PCI ou autre dans vos ATARI, et laissez donc ces technologie 'décadentes' à vos détracteurs...

Kochise

(les 2Ghz c'est hasbeen )

vince :
(les 2Ghz c'est hasbeen )

Sur Atari ou sur PC ?


Kochise

Les réflexions de Dave me semble "universelles" c'est-à-dire qu'on peut les transposer 15 ans après. On ne parle plus forcément du PC 386, du C et du Pascal, mais le raisonnement tiens bon.

Pour remarque, la phrase la plus belle :

"Le langage dans lequel vous codez n'a rien à voir avec vos capacités de bidouilleurs. Un langage de programmation est censé être une façon conventionnelle de donner des instructions à un ordinateur, et doit pouvoir être écrit et relu par des personnes différentes. ll n'est pas censé être obscur, bizarre et plein de pièges subtils (ça, ce sont les attributs de la magie). Ce qui importe en matière de créativité, ce sont vos rêves et votre volonté de repousser les limites, de faire ce que personne ne croyait possible."

@Kochise : à la semaine prochaine

Oui bien sûr il faut replacer dans le contexte. Ce que j'aime bien c'est sa façon d'écrire

edit

Rajah Lone
: Les réflexions de Dave me semble "universelles" c'est-à-dire qu'on peut les transposer 15 ans après. On ne parle plus forcément du PC 386, du C et du Pascal, mais le raisonnement tiens bon.

ze ferais mieux de réviser ma grammaire et mon orthographe.... :/

faire ce que personne ne pensait possible ? genre ?
(des exemples modernes svp)

Vous avez lu "Le test de Myers-Briggs" ? Amusant

J'aime bien ses articles que j'ai lu jusqu'ici car ils sont très empiriques (dans le sens "emprunt d'expérience", je ne sais plus si c'est bien le mot qui convient pour dire cela).

j'ai lu en entier souvenirs de hackers... ça permet vite de se faire une idée...

ça donne INTP pour ma pomme (I=100, N=44, T=1, P=11), peut être INFP si je refais ce test

Florian :
Vous avez lu "Le test de Myers-Briggs" ? Amusant

J'aime bien ses articles que j'ai lu jusqu'ici car ils sont très empiriques (dans le sens "emprunt d'expérience", je ne sais plus si c'est bien le mot qui convient pour dire cela).

j'ai lu aussi...

pipo

Je suis d'accord avec Dave, rien de tel qu'un bon code asm pour faire tourné les choses un peu plus vite, et Kochise pour info un compilateur tu auras prendre le plus efficace, aucun ne te generera un bon code de bourrin !!! Tu pourras faire ce que tu veux, l'asm reste le langage le plus rapide, le plus efficace, tu peux tout faire avec. Mais alors tout !!


Et perso, j'utilises aussi le Gfa pour faire deux trois essais et ensuite si ca marche et cela me plait, transcodage en asm.


Merci Cooper d'avoir reposé un tel article !

Asm Power !!


GT Contre le c, je comprendrais jamais rien a ce truc !!!

GT , qui aime Dave Small

GT : je savais que ça te plairais

GT Turbo :
Je suis d'accord avec Dave, rien de tel qu'un bon code asm pour faire tourné les choses un peu plus vite, et Kochise pour info un compilateur tu auras prendre le plus efficace, aucun ne te generera un bon code de bourrin !!! Tu pourras faire ce que tu veux, l'asm reste le langage le plus rapide, le plus efficace, tu peux tout faire avec. Mais alors tout !!


Et perso, j'utilises aussi le Gfa pour faire deux trois essais et ensuite si ca marche et cela me plait, transcodage en asm.


Merci Cooper d'avoir reposé un tel article !

Asm Power !!


GT Contre le c, je comprendrais jamais rien a ce truc !!!

GT , qui aime Dave Small

si tu avais bien lu tu aurais vu qu'il est devenu allergique au code en write only, exactement la définition du 'bon code de bourrin'

GT Turbo :
Kochise pour info un compilateur tu auras prendre le plus efficace, aucun ne te generera un bon code de bourrin !!! Tu pourras faire ce que tu veux, l'asm reste le langage le plus rapide, le plus efficace, tu peux tout faire avec. Mais alors tout !!

Et perso, j'utilises aussi le Gfa pour faire deux trois essais et ensuite si ca marche et cela me plait, transcodage en asm.

GT

Je suis d'acord avec toi sur certains points, l'ASM écrase tout. Moi aussi je teste d'abord mes algos en GFA, puis une fois débuggé, je les passes en ASM : http://yn1.free.fr/up/CSQR.ZIP

CSQR (Color SQuaRe) affiche les 65536 couleurs du Falcon sous forme de carré, le tout grace à une seule fonction. La version CSQR-0 est en GFA, les suivantes en ASM. La version CSQR-1 est la transpisition 'ligne-à-ligne' en ASM -> l'executable passe de 7147 octets à 621 octets, et est 10 fois plus rapide. Les versions CSQR-2 et CSQR-3 sont des optimisations de l'algorithme...

Là où je ne suis pas d'accords, c'est de cracher sur le C simplement parce que tu n'y arrive pas et que tu n'y connais rien. Avant de cracher sur tes ennemis, apprend à les connaitres mieux...

On m'a toujours vendu le C comme étant la panacé, c'est portable, c'est auto-commenté, etc... Comme à Small on me l'a fait avec moulte détails. Sauf que malgré mon 'jeune' âge, j'en ai déjà un peu vu Alors le gars, il me sort ça, j'lui sort de but en blanc "donc mon code C de mon PC, j'te le prend et j'le compile sur MAC ou sur VAX ?"

Silence gèné...

Le gars qu'il essaye de m'embobiner "non mais tu comprend, c'est pas pareil..." ! C'est quoi qu'est pas pareil ? Le C est AUSSI portable que l'ASM ! Tient que j'lui fait, tu prends mes routines ASM x86, elles s'assemblent bien sous Windows et Linux, coté portabilité, y'a rien à envier ! Y'm'regarde ce con, l'air de pas trop comprendre...

"Mais si abrutit, mes routines FFT en ASM x86, de bien belles routines qui ne font pas appel au système, elles servent autant à Windows qu'à Linux". Et là ça s'éclaire dans sa p'tite tête, d'un coup il comprend que tous les ordinateurs à base de x86 (et y'en à bonbon dans le monde) sont compatibles au niveau du processeur, c'est à dire au niveau ASM, avant d'être incompatible au niveau du système d'exploitation. Et là l'gars il dit plus rien, il baisse la tête et s'en va cogiter à la révélation qu'il vient d'avoir. Le gars...

Ca c'était pour la petite histoire. Maintenant si tu as bien lu celle de Small dans "Hérésie 2", il te cause de gars NT ou N, et d'autres d'un genre différent. Le problème déjà pour aborder l'ASM, c'est qu'il faut avoir une logique 'bit-à-bit'. Bref, savoir mettre les mains dans le cambouis (tu sais faire, donc l'ASM n'a rien de sorcier pour toi). Le C, c'est un truc conceptuellement fumeux pour donner plus d'abstraction à des concepts 'bit-à-bit'. Bref, ça sert surtout à embourgeoiser un langage et le rendre disponible à des personnes ne voulant pas ressembler à des 'geek poilus et poisseux', mais aussi à d'autres types de mentalité.

L'avantage du C sur l'ASM est le même, grosso-merdo, qu'à le GFA sur l'ASM : tu te concentre sur autre chose que les initialisation de contexte, les réservations mémoires ou les accès secteur-à-secteur pour lire un fichier. Le C (comme le GFA) offre une possibilité de démarrer un programme directement sans avoir à se préoccuper de préparer le terrain (ce que j'avais cherché à faire avec SSAVCALL pour l'ASM), des accès disque au niveau du fichier, une sortie console, des redirections de port, etc... en deux lignes. C'est possible en ASM sur Atari, grace au GEMDOS. Merci pour lui...

Mais tous les ordinateurs n'ont pas étés pourvus d'un BIOS aussi fournit que sur Atari, et donc les programmes C sur PC inclus la plupart des initialisation machine et consort qui font qu'ils prennent autant de place.

Mais le C (comme le GFA) offre une structuration du programme et quelques petites friandises dont on a du mal à se passer une fois que l'on y a gouter. Je dirais que l'ASM et le C sont complémentaires, pas opposés. Et il faudrait un jour enterrer la hache de guerre qui veut que ceux qui ne comprennent rien au C le fustige, tout comme ceux qui n'ont cure de l'ASM lui crache dessus.

Sus au crétinisme, ce n'est pas parce que la plateforme Atari est 'has-been' qu'il faut l'être dans la tête aussi. Je vais donc écrire un p'tit tutorial C dès que j'ai un peu de temps, histoire de te montrer que c'est vraiment pas la mer à boire, et que ça rend même bien service parfois.

Mais je reste comme toi sur l'idée que, définitivement, "Asm Powaaaaaaaaa" !

Kochise

du C compatible multiplateformes, ça existe, y'a des normes pour ça...

ton prog pour tous les x86 en asm se fait aussi en C...

les couches d'abstraction amenées par le C ne sont pas à ignorer certes, mais c'est un gain en productivité non négligeable... (suffit d'essayer de faire des fonctions réentrantes en asm par exemple)

pour la comparaison GFA <-> C, je me prononce pas, ne connaissant pas suffisament le GFA, mais j'émets de sérieux doutes...

maintenant ton prog qui fait des accès disque, il va pas marcher sur tous les sys utilisant le même proc... à l'inverse, un prog C peut aussi bien être compilé pour 286 que 386 486 ...x86 que i64 ou encore moto ou que sais-je d'autre... le prog qui fait des accès disque, si il utilise une lib standard, t'as fort à parier qu'elle existe selon les cibles (couple os+hard) et que recompiler ton prog suffira... en asm on en est loin...

la notion de place est devenu un argument limite à oublier, la majeure partie des programmes étant compilés d'abord pour leur vitesse et ensuite seulement pour leur taille....

Je dirais que l'ASM et le C sont complémentaires

pas d'accord... quand tu connais assez bien les deux, tu vois vite que tu peux faire EXACTEMENT la même chose aussi bien dans l'un que dans l'autre. sauf que je te rejoins dans l'idée de complémentarité, le choix de l'un ou de l'autre permettant de gagner du temps en fonction de ce qu'on a faire...


Kochise, enfin, si tu crées un tuto C, je te conseille de lire celui (ceux, la nouvelle version est en cours ) écrits par Squale92 et Verstand (deux anciens de yN) que tu peux trouver sur mon site TI ( www.ti-fr.com )

il est assez complet, tout en restant simple à comprendre...

vince :
du C compatible multiplateformes, ça existe, y'a des normes pour ça...

POSIX par exemple ?

vince :
ton prog pour tous les x86 en asm se fait aussi en C...

Nooooon ?

vince :
les couches d'abstraction amenées par le C ne sont pas à ignorer certes, mais c'est un gain en productivité non négligeable... (suffit d'essayer de faire des fonctions réentrantes en asm par exemple)

                 moveq.l    #3,D0
                 BSR          RecurseMe

                 move.w     #$4C,-(SP)
                 TRAP        #1

RecurseMe: tst.l          D0
                 BEQ          QuitMe

                 subq.l       #1,D0
                 BSR          RecurseMe     ; Ouuuuh la vilaine récursivité

QuitMe:      RTS

Quelque chose dans le genre ?

vince :
pour la comparaison GFA <-> C, je me prononce pas, ne connaissant pas suffisament le GFA, mais j'émets de sérieux doutes...

Tu ne prononce pas OU tu émets de sérieux doutes : rayer la mention inutile

vince :
maintenant ton prog qui fait des accès disque, il va pas marcher sur tous les sys utilisant le même proc... à l'inverse, un prog C peut aussi bien être compilé pour 286 que 386 486 ...x86 que i64 ou encore moto ou que sais-je d'autre... le prog qui fait des accès disque, si il utilise une lib standard, t'as fort à parier qu'elle existe selon les cibles (couple os+hard) et que recompiler ton prog suffira... en asm on en est loin...

Va pour recompiler un prog C sur Windows x86 ou Alpha. Il n'en sera pas pareil pour assembler un soft ASM sur Windows x86 ou Alpha. Ca implique déjà que le couple os+hard existe... Mais il ne me semblait pas avoir dit quelque chose à l'encontre de ce principe : "Mais si abrutit, mes routines FFT en ASM x86, de bien belles routines qui ne font pas appel au système, elles servent autant à Windows qu'à Linux" (c) Kochise ! Je met en gras : qui ne font pas appel au système !

vince :
la notion de place est devenu un argument limite à oublier, la majeure partie des programmes étant compilés d'abord pour leur vitesse et ensuite seulement pour leur taille....

C'est sur que pour gagner en vitesse, les compilo déroulent les boucle pour optimiser l'utilisation du cache. Futés les compilos... Ils font maintenant des bundles, pour un compilo acheté, un disque dur offert !

vince
:

Je dirais que l'ASM et le C sont complémentaires

pas d'accord... quand tu connais assez bien les deux, tu vois vite que tu peux faire EXACTEMENT la même chose aussi bien dans l'un que dans l'autre. sauf que je te rejoins dans l'idée de complémentarité, le choix de l'un ou de l'autre permettant de gagner du temps en fonction de ce qu'on a faire...

pas d'accord (ASM et C complémentaires) OU je te rejoins dans l'idée de complémentarité : rayer la mention inutile

vince :
Kochise, enfin, si tu crées un tuto C, je te conseille de lire celui (ceux, la nouvelle version est en cours ) écrits par Squale92 et Verstand (deux anciens de yN) que tu peux trouver sur mon site TI ( www.ti-fr.com )

il est assez complet, tout en restant simple à comprendre...

Si j'écris un tuto, en général je n'ai pas besoin d'avoir à en lire un. Ou alors pour le recopier. A moins que tu voulais donner l'adresse du tutorial à des personnes qui en avait besoin ? Dans ce cas, tu aurais pu écrire :

vince :
Dans l'attente du (super) tuto de Kochise, un tuto C écrit par Squale92 et Verstand (deux anciens de yN) est déjà disponible sur mon site TI ( www.ti-fr.com ). Je le trouve assez complet, tout en restant simple à comprendre...

Ca c'est top la classe, toi aussi tu peut le faire Au fait, quand c'est complet, c'esten général difficile à comprendre ?

Kochise

PS : Navré, ch'us un peu naze, donc ça tombe brut de décoffrage sans relecture...

Ce sera un tuto orienté Atari? genre affichage direct au Shifter/Videl ou GEM?

GEM essentiellement, puisque c'est un peu l'avantage du C. Sinon y'aura effectivement un peu de tuto graf pour comparer avec l'ASM

Kochise

Kochise >
pour la réentrance je pensais par exemple aux fonctions qui s'appellent elle même mais avec des args toujours différents (cf le prog des tours de hanoï, pour le pondre en asm 68k faut avoir un peu de temps devant soi... on avait eu ça a faire à l'iut, c'est pour cela que j'ai pris cet exemple)
pour la comparaison GFA et C, je ne connais pas assez pour entrer dans les détails, mais de ce que j'en ai vu (!=0) c'est loin (trèèèèèèès loin) d'être aussi structuré que du C... à la rigueur comparer le GFA et le BASIC me paraitrait plus approprié.
asm et c complémentaire OUI, mais en programmant full C ou full ASM on peut obtenir les mêmes résultats à ceci près que ça prends plus de temps.
le tuto c'était pas forcément pour les autres, c'était aussi pour toi... pour te donner une idée de l'aproche des choses qui y est présentée.... des tutos complets et imbouffables t'en a achier sur tous les langages, des tutos simples mais incomplets, t'en a aussi à chier, des tutos simples ET complets, c'est rare c'est pour ça que je le précise.

et pour le coup du déroulement de boucles c'est ce que font les programmeurs asm pour optimiser leur code en vitesse...

vince
:

Florian :
Vous avez lu "Le test de Myers-Briggs" ? Amusant

J'aime bien ses articles que j'ai lu jusqu'ici car ils sont très empiriques (dans le sens "emprunt d'expérience", je ne sais plus si c'est bien le mot qui convient pour dire cela).

j'ai lu aussi...

pipo

Comprenez "ce n'est pas complètement dément"

Après vérification, 'empirique' est bien le mot qui convient pour décrire ce que je voulais exprimer.

Essayer de calquer sa vie (et celle des autres) a certaines (pas toutes) idées d'une tierce (et une seule) personne, idées que vous avez acquises dans un bouquin de 300-400 pages, c'est assez réducteur... renier ses opinions juste pour un bouquin, trier ses amis en fonction d'un bouquin...
De toutes les religions (et sectes) du livre (peu m'importe le titre du livre), celles dont les "pratiquants" appliquent les règles pré-citées à la lettre sont connus sous le nom de "fanatiques"(les pratiquants hein pas les religions ^^).
Je doute que ce gars soit réellement un fanatique(il ne serait pas aussi ouvert et à l'écoute de la critique % à se écrits), donc ce qu'il raconte comporte un partie (l'intégralité ?) de pipo. (cela dit l'auteur du bouquin n'est pas n'importe qui, je le reconnais, me faites pas dire ce que j'ai pas dit)

C'est déjà plus nuancé. Bien sûr que c'est réducteur et il le dit lui-même ; je cite :

"
Mais attention, l'IPMB n'a jamais prétendu décrire exactement une personne. C' est impossible. On peut cependant esquisser une dominante globale, qui peut aider à comprendre certains individus. Voyons les différents types de plus près.
"

oui, mais le reste du texte fait artificiel tant il calque les personnes au nt nf et consorts

cooper :
Lisez donc ceci :

http://valvassori.free.fr/dave_small/index.php3

Plus spécifiquement la partie nommé "Hérésie, 2nde partie"

C'est très instructif et ça remet les pendules à l'heure !
Cooper, qui aime Dave Small

Y a t-il un site qui présente un article sur les fanatiques du GFA ?
Pas cool ce sujet

pour Cooper

---

sonja codait en GFA/C avec un peu d'Asm

Franchement j'ai gouté aux 3 : GFA, C et Asm.

J'aime le GFA pour sa simplicité d'utilisation, sa puissance (vive les inlines avec de l'asm inside )
A choisir entre le C et l'asm, je préfère encore l'asm, car cela restera toujours le langage le plus puissant SUR ATARI, gamme ST/Falcon de base. (Après vous faites ce que vous voulez avec vos PC, je m'en bat de savoir si c'est l'asm x86 est mieux que blabla... Après tout on est dans la partie développement atari...). Il est bon de rappeler qu'il n'y a pas visual studio et consort sur Atari.

On en dira ce que l'on voudra, mais le C reste un langage CHIANT.

Et puis oui, je suis un fanatique du GFA, et alors ?

Enfin je vois que ce sujet a encore créé une polémique... au lieu de polémiquer, sortez vos compilos préférés (Asm, GFA, C) et allez coder pour nos chères bécanes, bande de racailles !

y'a des articles sympas, vraiment bien et d'autres moyens, et un ou deux complètement nuls...