si tu veux t'endurcir il faut programmer en assembleur :-)
il y a longtemps que j'ai arrété, mais mes débuts en progr ammation
c'était du microcode de HP-41C (une calculatrice). Pour le tester
il fallait le bruler sur deux éproms (c'était du dix bits, avec
calculs en BCD, rien que ca) et en cas d'erreur effacer aux
ultra-violets et recommencer
très formateur. Une journée pour dix lignes, mai qu'est-ce que ca
allait vite :-)
après je suis passé au forth : mafonction moncode ;, RPN, pile de
data, code réentrant et pas de module de plus d'un écran 85x24
http://home.hccnet.nl/a.w.m.van.der.horst/figforth.html
pour debian
http://packages.debian.org/search?keywords=gforth
c'est à peu près le contraire d'ADA... léger, interprà ©té pour la
version d'essai, compilé ensuite avec un code impossible à retr o
engénier, si le source est bon facile à maintenir, très co mpact
(bien plus que le C), pratiquement aussi rapide que l'assembleur.
seul défaut, mais de taille, c'est tellement configurable qu'une
fois que tu as commencé personne ne peut reprendre ton code.
on en bave pendant deux ou trois mois, ensuite on programme tous
les micro controleurs et le reste
un monde de geeks :-) - il y avait même un forth pour HP-41 :-) -
j'en ai un sur mon smartpĥone :-)
http://sourceforge.net/projects/androidforth/
dommage, j'ai bifurqué vers tout autre chose..
si tu veux t'endurcir il faut programmer en assembleur :-)
il y a longtemps que j'ai arrété, mais mes débuts en progr ammation
c'était du microcode de HP-41C (une calculatrice). Pour le tester
il fallait le bruler sur deux éproms (c'était du dix bits, avec
calculs en BCD, rien que ca) et en cas d'erreur effacer aux
ultra-violets et recommencer
très formateur. Une journée pour dix lignes, mai qu'est-ce que ca
allait vite :-)
après je suis passé au forth : mafonction moncode ;, RPN, pile de
data, code réentrant et pas de module de plus d'un écran 85x24
http://home.hccnet.nl/a.w.m.van.der.horst/figforth.html
pour debian
http://packages.debian.org/search?keywords=gforth
c'est à peu près le contraire d'ADA... léger, interprà ©té pour la
version d'essai, compilé ensuite avec un code impossible à retr o
engénier, si le source est bon facile à maintenir, très co mpact
(bien plus que le C), pratiquement aussi rapide que l'assembleur.
seul défaut, mais de taille, c'est tellement configurable qu'une
fois que tu as commencé personne ne peut reprendre ton code.
on en bave pendant deux ou trois mois, ensuite on programme tous
les micro controleurs et le reste
un monde de geeks :-) - il y avait même un forth pour HP-41 :-) -
j'en ai un sur mon smartpĥone :-)
http://sourceforge.net/projects/androidforth/
dommage, j'ai bifurqué vers tout autre chose..
si tu veux t'endurcir il faut programmer en assembleur :-)
il y a longtemps que j'ai arrété, mais mes débuts en progr ammation
c'était du microcode de HP-41C (une calculatrice). Pour le tester
il fallait le bruler sur deux éproms (c'était du dix bits, avec
calculs en BCD, rien que ca) et en cas d'erreur effacer aux
ultra-violets et recommencer
très formateur. Une journée pour dix lignes, mai qu'est-ce que ca
allait vite :-)
après je suis passé au forth : mafonction moncode ;, RPN, pile de
data, code réentrant et pas de module de plus d'un écran 85x24
http://home.hccnet.nl/a.w.m.van.der.horst/figforth.html
pour debian
http://packages.debian.org/search?keywords=gforth
c'est à peu près le contraire d'ADA... léger, interprà ©té pour la
version d'essai, compilé ensuite avec un code impossible à retr o
engénier, si le source est bon facile à maintenir, très co mpact
(bien plus que le C), pratiquement aussi rapide que l'assembleur.
seul défaut, mais de taille, c'est tellement configurable qu'une
fois que tu as commencé personne ne peut reprendre ton code.
on en bave pendant deux ou trois mois, ensuite on programme tous
les micro controleurs et le reste
un monde de geeks :-) - il y avait même un forth pour HP-41 :-) -
j'en ai un sur mon smartpĥone :-)
http://sourceforge.net/projects/androidforth/
dommage, j'ai bifurqué vers tout autre chose..
je suis utilisateur de ADA depuis le début,
je m'en tire Ã
l'expérience, mais si Bzzz n'aime pas la verbosité de java,
aimera-t-il la verbosité de ADA croissante de version en version?
je suis utilisateur de ADA depuis le début,
je m'en tire Ã
l'expérience, mais si Bzzz n'aime pas la verbosité de java,
aimera-t-il la verbosité de ADA croissante de version en version?
je suis utilisateur de ADA depuis le début,
je m'en tire Ã
l'expérience, mais si Bzzz n'aime pas la verbosité de java,
aimera-t-il la verbosité de ADA croissante de version en version?
L'aboutissement de mon premier projet est une refonte dans un projet
équivalent mais bcp plus vaste; la finalité étant plus commerciale…
Hors, jusqu'à présent, je n'ai pas trouvé de langage qui permette de
(presque) tout faire, et de le faire bien (notamment de pouvoir
passer de mains en mains, sans PBs de relecture).
L'aboutissement de mon premier projet est une refonte dans un projet
équivalent mais bcp plus vaste; la finalité étant plus commerciale…
Hors, jusqu'à présent, je n'ai pas trouvé de langage qui permette de
(presque) tout faire, et de le faire bien (notamment de pouvoir
passer de mains en mains, sans PBs de relecture).
L'aboutissement de mon premier projet est une refonte dans un projet
équivalent mais bcp plus vaste; la finalité étant plus commerciale…
Hors, jusqu'à présent, je n'ai pas trouvé de langage qui permette de
(presque) tout faire, et de le faire bien (notamment de pouvoir
passer de mains en mains, sans PBs de relecture).
je sais aussi que la courbe d'apprentissage va me faire souffrir, ne
serait-ce que parce que d'habitude je bidouille et que ça finit tjrs
par fonctionner. Là, il va falloir abandonner tout ça (et, d'un côté
strictement personnel, c'est _aussi_ ce que je recherche), réfléchir
en amont, et _tout structurer. Disons que c'est un changement de vue,
autant qu'un changement de vie… Et puis il faut viser haut, si
aérospatiale et autres organisations du même acabit ont choisies
ADA+HOOD, c'est qu'il y a des chances que ça soit la combinaison
gagnante; même si ça n'est pas la plus facile.
je sais aussi que la courbe d'apprentissage va me faire souffrir, ne
serait-ce que parce que d'habitude je bidouille et que ça finit tjrs
par fonctionner. Là, il va falloir abandonner tout ça (et, d'un côté
strictement personnel, c'est _aussi_ ce que je recherche), réfléchir
en amont, et _tout structurer. Disons que c'est un changement de vue,
autant qu'un changement de vie… Et puis il faut viser haut, si
aérospatiale et autres organisations du même acabit ont choisies
ADA+HOOD, c'est qu'il y a des chances que ça soit la combinaison
gagnante; même si ça n'est pas la plus facile.
je sais aussi que la courbe d'apprentissage va me faire souffrir, ne
serait-ce que parce que d'habitude je bidouille et que ça finit tjrs
par fonctionner. Là, il va falloir abandonner tout ça (et, d'un côté
strictement personnel, c'est _aussi_ ce que je recherche), réfléchir
en amont, et _tout structurer. Disons que c'est un changement de vue,
autant qu'un changement de vie… Et puis il faut viser haut, si
aérospatiale et autres organisations du même acabit ont choisies
ADA+HOOD, c'est qu'il y a des chances que ça soit la combinaison
gagnante; même si ça n'est pas la plus facile.
On Fri, 29 Nov 2013 19:52:20 +0100
jdd wrote:
> j'arrive un peu tard, mais as-tu essayé le FORTH?
Si mes souvenirs sont bons, c'était le BIOS des sparks qui était
écrit en Forth.
> pour un bidouilleur, rien de mieux
Waimènan, les côtés qui me plaisent bien dans ADA, c'est déjà la
maturité du langage, le fait qu'il soit utilisé dans des projets
de grande envergure et très critiques (avionique, rail, systèmes
de surveillance aérienne, GPAO, etc); et que si tu fais bien
ton boulot en amont, tu ne reviens plus sur un projet.
Le plus intéressant, c'est que tu en chibaves pour la compilation,
mais qu'une fois que ça compile, si ça plante, c'est que l'analyse
était mauvaise.
On Fri, 29 Nov 2013 19:52:20 +0100
jdd <jdd@dodin.org> wrote:
> j'arrive un peu tard, mais as-tu essayé le FORTH?
Si mes souvenirs sont bons, c'était le BIOS des sparks qui était
écrit en Forth.
> pour un bidouilleur, rien de mieux
Waimènan, les côtés qui me plaisent bien dans ADA, c'est déjà la
maturité du langage, le fait qu'il soit utilisé dans des projets
de grande envergure et très critiques (avionique, rail, systèmes
de surveillance aérienne, GPAO, etc); et que si tu fais bien
ton boulot en amont, tu ne reviens plus sur un projet.
Le plus intéressant, c'est que tu en chibaves pour la compilation,
mais qu'une fois que ça compile, si ça plante, c'est que l'analyse
était mauvaise.
On Fri, 29 Nov 2013 19:52:20 +0100
jdd wrote:
> j'arrive un peu tard, mais as-tu essayé le FORTH?
Si mes souvenirs sont bons, c'était le BIOS des sparks qui était
écrit en Forth.
> pour un bidouilleur, rien de mieux
Waimènan, les côtés qui me plaisent bien dans ADA, c'est déjà la
maturité du langage, le fait qu'il soit utilisé dans des projets
de grande envergure et très critiques (avionique, rail, systèmes
de surveillance aérienne, GPAO, etc); et que si tu fais bien
ton boulot en amont, tu ne reviens plus sur un projet.
Le plus intéressant, c'est que tu en chibaves pour la compilation,
mais qu'une fois que ça compile, si ça plante, c'est que l'analyse
était mauvaise.
clairement, dans ce cas, il faut examiner ce que cette communauté
sait programmer et faire avec ca, le langage lui-même étant
secondaire.
la portabilité ca ne marche que si on cannait le langage. Tu serai
dans Linux, je dirais C et a la rigueur un peu de python, si tes
voisins sont sous ADA, y a pas à discuter :-)
clairement, dans ce cas, il faut examiner ce que cette communauté
sait programmer et faire avec ca, le langage lui-même étant
secondaire.
la portabilité ca ne marche que si on cannait le langage. Tu serai
dans Linux, je dirais C et a la rigueur un peu de python, si tes
voisins sont sous ADA, y a pas à discuter :-)
clairement, dans ce cas, il faut examiner ce que cette communauté
sait programmer et faire avec ca, le langage lui-même étant
secondaire.
la portabilité ca ne marche que si on cannait le langage. Tu serai
dans Linux, je dirais C et a la rigueur un peu de python, si tes
voisins sont sous ADA, y a pas à discuter :-)
Je ne connais même pas les primitives temps réel! Je pense
qu'elles restent inférieures à celles de langages vraiment
spécialisés.
Je ne connais même pas les primitives temps réel! Je pense
qu'elles restent inférieures à celles de langages vraiment
spécialisés.
Je ne connais même pas les primitives temps réel! Je pense
qu'elles restent inférieures à celles de langages vraiment
spécialisés.
Le 29/11/2013 20:12, Bzzz a écrit :Le plus intéressant, c'est que tu en chibaves pour la compilation,
mais qu'une fois que ça compile, si ça plante, c'est que l'analyse
était mauvaise.
ben ca c'est vrai partoutPar ailleurs, j'ai d'autres projets qui nécessitent bcp de
concurrentiel, et ADA me semble tout particulièrement bien loti
dans ce domaine (au moins aussi bien qu'Erlang).
si tu veux t'endurcir il faut programmer en assembleur :-)
il y a longtemps que j'ai arrété, mais mes débuts en programmation
c'était du microcode de HP-41C (une calculatrice). Pour le tester il
fallait le bruler sur deux éproms (c'était du dix bits, avec calculs en
BCD, rien que ca) et en cas d'erreur effacer aux ultra-violets et
recommencer
très formateur. Une journée pour dix lignes, mai qu'est-ce que ca allait
vite :-)
après je suis passé au forth : mafonction moncode ;, RPN, pile de data,
code réentrant et pas de module de plus d'un écran 85x24
http://home.hccnet.nl/a.w.m.van.der.horst/figforth.html
pour debian
http://packages.debian.org/search?keywords=gforth
c'est à peu près le contraire d'ADA... léger, interprété pour la version
d'essai, compilé ensuite avec un code impossible à retro engénier, si le
source est bon facile à maintenir, très compact (bien plus que le C),
pratiquement aussi rapide que l'assembleur.
seul défaut, mais de taille, c'est tellement configurable qu'une fois
que tu as commencé personne ne peut reprendre ton code.
Imagine que tu programme un tableur, dès ce moment tu peux intégrer ton
tableur dans n'importe quelle application sans aucune manoeuvre. Tes
modules sont simplement des ajouts au langage. A partir de ton programme
source, tu peux décompiler n'importe quel module si tu as oublié la
syntaxe :-)
la compilation finale n'en est pas une, c'est juste un nettoyage du code
pour supprimer tout ce qui est inutile
on en bave pendant deux ou trois mois, ensuite on programme tous les
micro controleurs et le reste
un monde de geeks :-) - il y avait même un forth pour HP-41 :-) - j'en
ai un sur mon smartpĥone :-)
http://sourceforge.net/projects/androidforth/
dommage, j'ai bifurqué vers tout autre chose..
Le 29/11/2013 20:12, Bzzz a écrit :
Le plus intéressant, c'est que tu en chibaves pour la compilation,
mais qu'une fois que ça compile, si ça plante, c'est que l'analyse
était mauvaise.
ben ca c'est vrai partout
Par ailleurs, j'ai d'autres projets qui nécessitent bcp de
concurrentiel, et ADA me semble tout particulièrement bien loti
dans ce domaine (au moins aussi bien qu'Erlang).
si tu veux t'endurcir il faut programmer en assembleur :-)
il y a longtemps que j'ai arrété, mais mes débuts en programmation
c'était du microcode de HP-41C (une calculatrice). Pour le tester il
fallait le bruler sur deux éproms (c'était du dix bits, avec calculs en
BCD, rien que ca) et en cas d'erreur effacer aux ultra-violets et
recommencer
très formateur. Une journée pour dix lignes, mai qu'est-ce que ca allait
vite :-)
après je suis passé au forth : mafonction moncode ;, RPN, pile de data,
code réentrant et pas de module de plus d'un écran 85x24
http://home.hccnet.nl/a.w.m.van.der.horst/figforth.html
pour debian
http://packages.debian.org/search?keywords=gforth
c'est à peu près le contraire d'ADA... léger, interprété pour la version
d'essai, compilé ensuite avec un code impossible à retro engénier, si le
source est bon facile à maintenir, très compact (bien plus que le C),
pratiquement aussi rapide que l'assembleur.
seul défaut, mais de taille, c'est tellement configurable qu'une fois
que tu as commencé personne ne peut reprendre ton code.
Imagine que tu programme un tableur, dès ce moment tu peux intégrer ton
tableur dans n'importe quelle application sans aucune manoeuvre. Tes
modules sont simplement des ajouts au langage. A partir de ton programme
source, tu peux décompiler n'importe quel module si tu as oublié la
syntaxe :-)
la compilation finale n'en est pas une, c'est juste un nettoyage du code
pour supprimer tout ce qui est inutile
on en bave pendant deux ou trois mois, ensuite on programme tous les
micro controleurs et le reste
un monde de geeks :-) - il y avait même un forth pour HP-41 :-) - j'en
ai un sur mon smartpĥone :-)
http://sourceforge.net/projects/androidforth/
dommage, j'ai bifurqué vers tout autre chose..
Le 29/11/2013 20:12, Bzzz a écrit :Le plus intéressant, c'est que tu en chibaves pour la compilation,
mais qu'une fois que ça compile, si ça plante, c'est que l'analyse
était mauvaise.
ben ca c'est vrai partoutPar ailleurs, j'ai d'autres projets qui nécessitent bcp de
concurrentiel, et ADA me semble tout particulièrement bien loti
dans ce domaine (au moins aussi bien qu'Erlang).
si tu veux t'endurcir il faut programmer en assembleur :-)
il y a longtemps que j'ai arrété, mais mes débuts en programmation
c'était du microcode de HP-41C (une calculatrice). Pour le tester il
fallait le bruler sur deux éproms (c'était du dix bits, avec calculs en
BCD, rien que ca) et en cas d'erreur effacer aux ultra-violets et
recommencer
très formateur. Une journée pour dix lignes, mai qu'est-ce que ca allait
vite :-)
après je suis passé au forth : mafonction moncode ;, RPN, pile de data,
code réentrant et pas de module de plus d'un écran 85x24
http://home.hccnet.nl/a.w.m.van.der.horst/figforth.html
pour debian
http://packages.debian.org/search?keywords=gforth
c'est à peu près le contraire d'ADA... léger, interprété pour la version
d'essai, compilé ensuite avec un code impossible à retro engénier, si le
source est bon facile à maintenir, très compact (bien plus que le C),
pratiquement aussi rapide que l'assembleur.
seul défaut, mais de taille, c'est tellement configurable qu'une fois
que tu as commencé personne ne peut reprendre ton code.
Imagine que tu programme un tableur, dès ce moment tu peux intégrer ton
tableur dans n'importe quelle application sans aucune manoeuvre. Tes
modules sont simplement des ajouts au langage. A partir de ton programme
source, tu peux décompiler n'importe quel module si tu as oublié la
syntaxe :-)
la compilation finale n'en est pas une, c'est juste un nettoyage du code
pour supprimer tout ce qui est inutile
on en bave pendant deux ou trois mois, ensuite on programme tous les
micro controleurs et le reste
un monde de geeks :-) - il y avait même un forth pour HP-41 :-) - j'en
ai un sur mon smartpĥone :-)
http://sourceforge.net/projects/androidforth/
dommage, j'ai bifurqué vers tout autre chose..
* il FAUT que le prj soit "reprenable" par n'importe quel nerd,
* il FAUT que le prj soit "reprenable" par n'importe quel nerd,
* il FAUT que le prj soit "reprenable" par n'importe quel nerd,
Dans le même ordre d'idée, il y a aussi ceci : http://www.rpl2.fr.
Dans le même ordre d'idée, il y a aussi ceci : http://www.rpl2.fr.
Dans le même ordre d'idée, il y a aussi ceci : http://www.rpl2.fr.