J'aimerais bien qu'on m'explique?

[invite2800a7c8]

Salut

Permettre à Ludwig de s'étaler ici au lieu de le faire en polluant toutes les autres discussions. cela s'appelle un abcès de fixation.

Oui on peut aussi voir ça comme ça. Mais peut ' être, même un abcès peut servir à quelque chose, va t'en savoir.


Cordialement

Ludwig
-----

[pm42]

Permettre à Ludwig de s'étaler ici au lieu de le faire en polluant toutes les autres discussions. cela s'appelle un abcès de fixation.

Je ne crois pas en grand chose mais là je prie pour que ça marche

[invite2800a7c8]

Re

Je ne crois pas en grand chose mais là je prie pour que ça marche

T'as tord, tu peux discuter ici tant que tu voudras, simplement essai de ne pas insulter. Tu as ta façon de voir les choses,
ce qui est ton droit.
Comme déjà dit l'informatique n'étant pas une science, tout au plus des modes opératoires, il me semble difficile de pouvoir dire lequel est le meilleur. On peut tout faire, POO pas POO compiler, pas compiler, interpréter, langage moderne ou pas,
bla bla et bla etc... à la fin il reste comme critère d'évaluation, l'aspect économique c.a.d time to market, ça c'est un paramètre mesurable.
Ici le cas est tranché depuis fort longtemps, les preuves ont été apportées, la méthode de développement la plus rapide est connue.

Cordialement
Ludwig

[pm42]

n-ième changement de sujet...

à la fin il reste comme critère d'évaluation, l'aspect économique c.a.d time to market, ça c'est un paramètre mesurable.

Comme d'hab, c'est faux.
L'aspect économique prend en compte de nombreuses choses, pas seulement le time to market. De plus, certains softs sont développés avec des critères qui n'ont rien à voir par exemple ceux des systèmes critiques où la qualité prime sur tout le reste.
Ou d'autres d'archivage où c'est la durée de vie du logiciel et sa maintenabilité sur des décennies qui est la plus importante (par ex pour la gestion de plans d'avion).

Ici le cas est tranché depuis fort longtemps, les preuves ont été apportées, la méthode de développement la plus rapide est connue.

Non plus. Cela dépend largement du contexte et certaines études ont au contraire montré que c'était la direction de projet le critère déterminant, pas la méthodologie.

D'autres affirmations fausses n'ayant rien à voir avec le sujet du fil comme ça ?
J'ai vraiment du mal à comprendre comment ton ignorance de l'informatique peut être abyssale à ce point.

[invite2800a7c8]

Re

n-ième changement de sujet...

Comme d'hab, c'est faux.
L'aspect économique prend en compte de nombreuses choses, pas seulement le time to market. De plus, certains softs sont développés avec des critères qui n'ont rien à voir par exemple ceux des systèmes critiques où la qualité prime sur tout le reste.
Ou d'autres d'archivage où c'est la durée de vie du logiciel et sa maintenabilité sur des décennies qui est la plus importante (par ex pour la gestion de plans d'avion).

Comme d'hab, croyant détenir une quelconque vérité tu affirmes.
C'est ta façon de voir, elle vaut ce qu'elle vaut. Pour ce qui est de la maintenabilité sur des décennies laisse moi te dire
que le code source d'une application écrite il y a 30 ans avec les instructions de la machine virtuelle tourne toujours, pour la bonne et simple raison qu'elle est écrite avec le jeu d'instruction d'une machine virtuelle.
Il se trouve que ce jeux d'instruction est normalisé ANSI et ISO.
Il y a 50 ans, l'instruction DUP dupliquais le sommet de la pile de données de la machine virtuelle, bizarrement, à l'instant ou j'écris, ça fait toujours la même chose.
Selon toi, il semblerai que les applications écrites sous DOS tournent évidement sous Windows 10. tu montres comment tu fais?

Non plus. Cela dépend largement du contexte et certaines études ont au contraire montré que c'était la direction de projet le critère déterminant, pas la méthodologie.
D'autres affirmations fausses n'ayant rien à voir avec le sujet du fil comme ça ?
J'ai vraiment du mal à comprendre comment ton ignorance de l'informatique peut être abyssale à ce point.

Je crois que je t'ai déjà dis à plusieurs reprise que l'informatique n'est pas une science, dès lors je ne vois pas ce qu'il faut
connaître ou ignorer.
Je ne comprends pas non plus, pour quelle raison tu veux faire croire que c'en est une en te posant comme détenteur d'une quelconque vérité.
Je suppose que tu veux dire que j'ignore certains modes opératoires que toi tu utilises, c'est certainement vrai.
Comme il est certainement tout aussi vrai que moi j'utilise des modes opératoires que toi tu ne connais pas. Ceci étant,
ce n'est pas une raison pour te traiter d'ignare.
Les logiciels que je développe fonctionnent, que ce soit ceux écris sous Windows 95 il y a bientôt 20 ans ou ceux écris la semaine passée sous Windows 10, c'est l'avantage d'utiliser un jeux d'instruction normalisé totalement indépendant d'un quelconque processeur ou système d'exploitation.

C'est marrant de discuter avec toi, tu verras je réussirais à te faire écrire du code avec les instructions de la machine virtuelle que j'utilise. Une fois que tu y auras pris gout, tu refuseras de travailler avec autre chose.

Cordialement

Ludwig

[Jack]

Je crois que je t'ai déjà dis à plusieurs reprise que l'informatique n'est pas une science

C'est une affirmation gratuite. Toute l'informatique ne se ramène pas qu'au codage.

[invite2800a7c8]

Resalut,

C'est une affirmation gratuite. Toute l'informatique ne se ramène pas qu'au codage.

Je n'ai pas connaissance que l'informatique en général a obtenu le Status de Science. Une des caractéristique principale de la science est la notion d'invariance, je n'ai pas connaissance que cette notion existe dans le domaine de l'informatique.
L'algorithmique peut' être, mais ici aussi il existe bien des façons d' aborder le sujet. A l'époque ou Wirth a fait Pascal pour ses
besoins propres liés à l'enseignement au Poly à Zürich, on pensait que cela deviendrai une science peut' être mais malgré que PASCAL était est absolument rigoureux, ce ne fut pas le cas. Je pense qu'il faudra encore longtemps se contenter du Status
de mode opératoire, c.a.d. celui d'une machine à traiter des informations de façon automatisé.
Ceci étant posé on peut tout de même commencer à réfléchir sur la notion d'invariance.

Par exemple le mode opératoire auquel doit obéir le traitement de l'information.
Un schéma possible parmi d'autres serai alors le suivant:

1) Préparation des données 2) Action de traitement sur les données.
pour satisfaire à la notion d'invariance, ce schéma devra être vrai à tous les niveaux.

Une autre difficulté est la syntaxe utilisée pour faire du codage, vu la quantité de langages qui existe ça ressemble plutôt à une foire d'empoigne.

En conclusion, personnellement je ne vois pas ou il y a trace de science. Note que je peux me tromper il faudra alors m'expliquer.

Cordialement

Ludwig

[Jack]

Encore une fois tu ramènes l'informatique au codage.

J'aurais bien du mal à en parler personnellement, mais mes enfants font des études en informatique et la programmation n'est pas une de leur principales activités.
Une approche ici peut-être.

[invite2800a7c8]

Encore une fois tu ramènes l'informatique au codage.

J'aurais bien du mal à en parler personnellement, mais mes enfants font des études en informatique et la programmation n'est pas une de leur principales activités.
Une approche ici peut-être.

Re,

Non je ne ramène pas tous au codage. Je suis le premier à dire que l'analyse par exemple est un point essentiel. ça fait longtemps que je me préoccupes de savoir comment faire pour générer du code à partir d'un algorithme, mais encore comment faire pour que cet algorithme se corrige par lui-même, quelques lueurs apparaissent à l'horizon mais c'est bien loin.
J'ai lu en diagonale l'article cité par le lien, ça résume bien la situation. Je pense que je reviendrai plus en détail sur le sujet.

Cordialement
Ludwig

[Dlzlogic]

Bonsoir,
Je suis cette discussion depuis le début et elle me plait bien.
Je ne connais pas Forth, mais apparemment, d'après ce que j'ai pu comprendre, son objectif est le même que celui des logiciels multiplateforme.
Je suis de la vieille école où les préoccupations était l'espace mémoire utilisé le plus petit possible et la rapidité d'exécution. Je constate que les logiciels sont de plus en plus gros et de plus en plus gourmands en mémoire. Ce sais que c'est un peu hors sujet, de même que ma question sur un autre fil : "expliquer ou savoir ce qu'on veut faire avant de chercher à savoir comment le faire". Je me pose une question idiote : qu'a écrit pm42 pour être aussi affirmatif ? Je suppose que 42 est directement lié à l'école que chacun connait, mais quoi de plus ?
Pardon pour ce hors-sujet.

[pm42]

Je ne connais pas Forth, mais apparemment, d'après ce que j'ai pu comprendre, son objectif est le même que celui des logiciels multiplateforme.

Non. Son objectif était d'avoir un langage d'un peu plus haut niveau que l'assembleur tout en restant compact, rapide et facile à implémenter.
Pour la simple raison que le hardware à l'époque était très, très peu puissant ou très, très cher.

Comme expliqué ici (et dans le lien donné), ce besoin étant moins fort aujourd'hui, les compilateurs ayant fait des progrès, etc, le langage devient très anecdotique et il est la plupart du temps plus logique d'utiliser le C ou autre.
On réserve plutôt la logique de pile/polonaise inversée à des langages cibles de compilateurs (JVM, Postscript) ou à des afficionados des calculatrices HP dont je suis (voir le projet WP-34s par ex fort sympathique).

Je suis de la vieille école où les préoccupations était l'espace mémoire utilisé le plus petit possible et la rapidité d'exécution.

Rien n'a changé. On est toujours préoccupé par cela tout comme on l'est de la maintenabilité du code, sa vitesse d'écriture, le nombre de bugs, etc.
On fait simplement des compromis différents en fonction du genre de programme qu'on écrit, des outils dont on dispose et du hardware qu'on va utiliser.

Je constate que les logiciels sont de plus en plus gros et de plus en plus gourmands en mémoire.

Ca dépend. Les gens qui écrivent de l'embarqué dans des petits "devices" ont toujours des contraintes fortes.
Les gens qui écrivent pour PC profitent de la mémoire énorme pour offrir plus en fonctionnalités, ergonomie...
Les gens qui font du Big Data profitent de la puissance en réseau pour faire des traitements inimaginables il y a 20 ans.

Je me pose une question idiote : qu'a écrit pm42 pour être aussi affirmatif ?

Bonne question mais je fais un principe de ne pas me justifier auprès des gens dont les contributions commencent par "je ne connais pas le sujet mais je vais challenger ce qui se dit sur le fil" (dans la discussion sur les booléens dans Python et ici même).

Je suppose que 42 est directement lié à l'école que chacun connait, mais quoi de plus ?

Non. Pour quelqu'un de la vieille école, il faudrait savoir d'où vient 42 qui a donné à la fois mon pseudo et le nom de l'école avec laquelle je n'ai rien à voir.


Au demeurant, le sujet ici n'est pas Forth ou pas. On peut apprécier ou non Forth, on peut en discuter ici.
Polluer presque tous les fils avec et finir par dériver sur des considérations générales avec des affirmations fausses ou obsolètes est le vrai sujet. Si un membre faisait pareil avec Haskell, cela provoquerait les mêmes réactions.

[invite2800a7c8]

Salut,

Non. Son objectif était d'avoir un langage d'un peu plus haut niveau que l'assembleur tout en restant compact, rapide et facile à implémenter.
Pour la simple raison que le hardware à l'époque était très, très peu puissant ou très, très cher.

L'objectif était essentiellement d'avoir un système complet, mais avant tout de disposer d'un processeur virtuel fonctionnant de façon indépendante par rapport au processeur hôte, ce qui est toujours le cas aujourd'hui. Chuck avait déjà à l'époque
introduit la gestion de la Mémoire Virtuelle, un système d'exploitation, un éditeur, un interpréteur, un compilateur, une structure permettant de faire de la POO orienté prototype. Par la suite s'est rajouté un cross assembleur permettant de construire des mots spécifique en code machine du processeur hôte. Dès l'apparition des premiers MU P, s'est rajouté le multitâche de type Round Robin.
Je viens de sortir de ma bibliothèque un tout vieux bouquin fait par Léo Brodie datant de 1984 pour la version traduite en Français. Je constate avec plaisir que que l'ensemble des mots que j'utilise aujourd'hui sont toujours tous dans le Kernel de la machine actuelle. Evidement entre temps s'est rajouté bien des mots nouveaux, mais les anciens eux sont toujours là. C'est un réel plaisir de constater que du code écris il y a 30 ans pour un IBM de l'époque tourne sur mon Laptop d'aujourd'hui.
Autre remarque et de taille, pour assurer la portabilité, le monde Forth fourni toujours les sources et les exécutables, ceci permet la cas échéant de porter une application sur n'importe quel type de processeur pour peux que le Kernel pour ce processeur existe.
Je répète, bien que cité comme langage par la communauté informatique classique, Forth est un système de développement basé sur un processeur virtuel invariant. Les méthodes de développement mise en Oeuvre, n'ont strictement rien à voir avec les méthodes classiques.
Une fois qu'on a pris le pli, on refuse de travailler autrement, car cette méthode de développement est au moins 10 fois plus rapide que les méthodes classiques. La raison en est la capitalisation des mots dans le dictionnaire ou les dictionnaires.
Comme la seule syntaxe est l'espace entre les mots il n'y a pas à se triturer les neurones pour se rappeler comment le compilateur va avaler l'affaire ou de savoir ce qu'il va réellement compiler.
Il n'y a pas de compilateur au sens strict du mot. Il y a juste un mot ( : ) qui dit à la machine de rajouter une nouvelle définition dans le dictionnaire et un autre mot ( ; ) qui dit fin de définition. En clair le développement consiste à mettre au point des mots nouveaux qu'on teste individuellement en dehors de toute application.
Tout de même, cette façon de travailler nécessite une analyse descendante et une structuration extrêmement rigoureuse selon
les préceptes du " Discours de la Méthode" selon Descartes et ça c'est le début d'une science.

Cordialement

Ludwig

[pm42]

C'est tellement faux et n'importe quoi à tous les niveaux, tellement une "silver bullet" sans avoir lu "the mythical man/month" que je ne vais même pas relever.

De toute manière, on se sortira jamais de "Forth est grand et Ludwig1 est son prophète".

[inviteb9f49292]

Bonsoir,
Je suis cette discussion depuis le début et elle me plait bien.

c'est rigolo tant que ça ne va pas polluer d'autres discussions... intéressante c'est un bien grand mot.

Je ne connais pas Forth, mais apparemment, d'après ce que j'ai pu comprendre, son objectif est le même que celui des logiciels multiplateforme.

Non, c'est un lanagage "historique" que PM42 a très bien présenté.

Je suis de la vieille école où les préoccupations était l'espace mémoire utilisé le plus petit possible et la rapidité d'exécution. Je constate que les logiciels sont de plus en plus gros et de plus en plus gourmands en mémoire.

Bossant dans l'embarqué, je suis "contraint" à la vieille école, et à lire la prose de PM42 (et d'autres sur ce forum) je pense qu'on est quelqu'uns dans ce cas.

Ce sais que c'est un peu hors sujet, de même que ma question sur un autre fil : "expliquer ou savoir ce qu'on veut faire avant de chercher à savoir comment le faire". Je me pose une question idiote : qu'a écrit pm42 pour être aussi affirmatif ? Je suppose que 42 est directement lié à l'école que chacun connait, mais quoi de plus ?
Pardon pour ce hors-sujet.

Et là je bondis... Tu as lu la prose de Ludwig qui passe des considérations philosophiques à l'architecure de Von-Neumann en passant par des considérations de time-to-market ? Et il faudrait qu'on te file notre portfolio github pour avoir le droit de critiquer les délires de Ludwig?
Je ne sais pas ce qu'a développé PM42, mais je sais que ce qu'il réponds à Ludwig est 100 fois plus censé, il me suffit d'utiliser mon cerveau.

[polo974]

Bonjour,

Allez, souvenirs, souvenirs...
J'ai acheté un forth pour ma super machine Oric1 (6052 64k) il y a houlala...
C'était sur cassette.
J'ai aussi encore le fameux bouquin de l'époque (si les termites ne l'ont pas bouffé).

C'était sympa et ça explosait le basic de la machine.

Sauf que...
Travailler sur la pile, est tout de même assez casse gueule: une fonction empile ou dépile un truc de trop et ça part en vrille.
Comment sépare-t-on le user-land du kernel-land dans ces conditions (si le concept existe dans une extension de forth) ? ? ?
Probablement par une pirouette en (berk) assembleur...


Il faut bien noter que forth n'est pas seulement un langage, c'est le système complet (ou en tout cas il peut l'être).
D'où l'usage du terme de machine virtuelle par-ci, par là (encore un terme vague dont le contexte détermine la signification sur plus de 90% de ses propriétés).
Donc on parle de quoi et dans quel contexte (je n'irais pas mettre un linux sur un micro 4 bits, tout comme je ne coderais pas en assembleur un os pour un système multi-tâches, idem pour le choix d'un langage).

Forth est un système/langage extensible. à l'époque, c'était pas rien, mais de nos jour, c'est d'une banalité...
C'est une force, mais aussi une faiblesse, car la même fonctionnalité basique (commutation de tâche avec séparation de droit par exemple) aura pu être développée de différentes façons par différents éditeurs de "macro système/langage". Il en découle alors les mêmes incompatibilité qu'entre les différents dialectes de basic (exemple pris presque au hasard).

La seule grande réussite de forth est cachée dans postscript qui ne se vante pas de cette filiation (serait-elle honteuse ? ? ?).

Depuis, les compilos "classiques" (C, C++, ...) ont fait d'énormes progrès en terme d'optimisation, le développeur peut écrire presque comme un cochon, et le code tourne presque aussi vite qu s'il avait été affûté à la main. Idem pour les os qui sont devenus très complexes et puissants.

Pour revenir à nos jours:
Les cross-tools permettent de développer dans un environnement confortable, le temps de la programmation aux clés sur la machine cible est révolu.

On essaie de séparer le spécifique à développer du générique qu'on peut retrouver dans un système (à choisir) qu'il "suffit" de paramétrer pour sa machine cible.

Si j'ai un dev à faire, je choisi un environnement tel que je saurai trouver des ressources humaines et si possible une communauté active importante pour aboutir. L'usage de technos un peu étranges peut mettre un projet en danger par la simple démission du magicien de 7ème niveau dans le langage sblurg qu'on aurait choisi pour une raison particulière.

Maintenant, pour revenir à :

NOTA: dans le monde Forth il est de tradition depuis toujours, de fournir tous les codes sources, pas seulement des exécutables, ceci comme le réclament les gens qui s'occupent de sécurité informatique.
Demandez donc les codes sources chez Microsoft.

Ah bon, il te donnent le source de leur système, là où t'as raqué 399$ ? ? ?
ça m'étonnerais.
et chez Boeing Military Aircraft & Missile Systems (dans la liste des utilisateurs), il te donnent leurs sources aussi (au fait, il n'y a pas la NASA dans la liste).


Sinon, si tu veux les sources d'un os ou 2, de divers compilos, de librairies diverses et variées, etc (très long, le etc)... tu peux regarder du coté de gnu, linux, bsd, apache, etc (même remarque)...
(il y a même un gforth gratuit, libre... ah oui, mais il y a une partie en assembleur, une partie en C, et sans doute le reste en forth...)

[pm42]

polo974, je suis bien sur d'accord avec tout ça et c'est une explication très précise.
Le problème, ce que cela a déjà été dit plusieurs fois au fil des nombreuses discussions polluées et ici (postscript, cross-compilation, progrès des compilos, faible utilisation du Forth...)

Comme tu t'en doutes, la réponse consiste en général à parler d'autre chose ou à poster de l'assembleur

[invite2800a7c8]

Salut

polo974, je suis bien sur d'accord avec tout ça et c'est une explication très précise.
Le problème, ce que cela a déjà été dit plusieurs fois au fil des nombreuses discussions polluées et ici (postscript, cross-compilation, progrès des compilos, faible utilisation du Forth...)

Comme tu t'en doutes, la réponse consiste en général à parler d'autre chose ou à poster de l'assembleur

Au moins polo974 ne m'insulte pas. La réponse, je suis en train de la préparer et ce point par point, sans polluer quoi que ce
soit. J'ai ouvert ce fil afin qu'on puisse débattre sur le vaste sujet que sont le

Traitement automatisé des informations

à l'aide de machines nommées ORDINATEURS en français.
Polo974 a émis des objections, ce qui est tout fait correct dans une telle discussion. Toi t'as juste répété à quel point j'étais nul
en informatique. Mis à part ça et déformer tous mes propos t'as jamais dis grand chose.

Cordialement

Ludwig

[pm42]

Toi t'as juste répété à quel point j'étais nul
en informatique. Mis à part ça et déformer tous mes propos t'as jamais dis grand chose.

Tout ce que dit Polo est dans mes posts précédents, dans les posts d'autres fils et dans les posts d'autres participants.
Il faudrait juste que tu les lises.
Cela t'éviterait de ne jamais répondre à une objection en parlant toujours d'autre chose et en répétant en boucle que les ordinateurs font du traitement automatisé des données comme si tu venais de découvrir le fil à couper le beurre.

[Forthman]

Hello les gens,

Un sujet traitant du Forth, il fallait bien que j'y jette un oeil
Je programme en Forth depuis tout petit (débuts sur Hector HRX, j'avais 8 ans)
Mon pseudo m'a été donné par mes copains de classe au début des années 90 car
j'étais le seul mec qui programmais dans ce langage "bizarre"

J'ai bien tenté d'apprendre d'autres langages comme le C, Python, Java...etc...
Mais à chaque fois c'est pareil ça me gonfle car je pourrais faire la même chose en Forth,et plus vite.
Et le Forth a une telle souplesse d'utilisation, et permet de telles pirouettes... c'est magique !
En gros, le Forth, quand tu y a goûté (un peu plus que les exemples bidons qui ressortent à chaque fois),
bien tu ne peux plus t'en passer

Mais voilà, il y a un "Mais"... Et plusieurs même...

1 - Il n'existe pas UN seul Forth
Déjà il y a plusieurs "standard"
Tout en respectant ces standards, suivant les distributions, il y aura des mots spécifiques
Et dans bien des cas, le langage est fourni avec ses sources, et il est possible de bidouiller
en profondeur "son" Forth.
J'utilise moi-même un forth "à moi" où certains mots ne s'utilisent pas de la façon "standard"
Donc niveau portabilité des programmes on est pas à 0/20 mais plutôt -1000/20
Pire que la portabilité, la lisibilité pose également problème car si je parle couramment "mon Forth"
Il m'est difficile de lire les exemples de Ludwig1 (bon, c'est pas super compliqué hein, mais je dois me concentrer un peu)

2 - Forth est un langage de NERD !
Comme je l'ai écrit au dessus, le Forth permet de faire de grosses pirouettes, et en faisant preuve
d'ingéniosité, on peut obtenir des résultats bluffants en simplicité, rapidité, et taille (souvent les 3 à la fois)
Du coup on se retrouve à passer 80% du temps à coder du Forth pour améliorer son Forth...
Je traînais il y peu sur le forum google dédié au Forth, j'étais bien content de voir que ce langage n'était pas
complètement mort, et mon premier post a été "qui programme de vrais applications en Forth aujourd'hui"
Et bien pas un ne m'a simplement répondu "moi" les réponses étaient toutes du genre : "c'est très utilisé dans ######"
(vous pouvez remplacer les # par un mot vague désignant une activité quelconque )

3 - La grosse tête
Pour moi le plus gros problème de ce langage.
Ce langage donne l'impression d'être un dieu de l'informatique, je pense que c'est un peu pareil avec les autres
langages quand on commence à bien le maîtriser, mais en Forth ce sentiment est vraiment fort.
Du coup on se retrouve avec des gens qui veulent imposer leurs façons de coder aux autres.
Et le prix des Forth commerciaux est surréaliste

Donc, J'adore le Forth, mais je ne le conseille à personne

[pm42]

J'ai bien tenté d'apprendre d'autres langages comme le C, Python, Java...etc...
Mais à chaque fois c'est pareil ça me gonfle car je pourrais faire la même chose en Forth,et plus vite.

Tout dépend de ce que tu veux faire. J'ai un programme d'un million de lignes en Java qui fait tourner des traitements semi-critiques.
Je ne pense pas qu'on puisse faire la même chose en Forth ni plus vite. Dans d'autres langages si, mais pas Forth.

Et le Forth a une telle souplesse d'utilisation, et permet de telles pirouettes... c'est magique !

A un certain niveau de programmation. Quand tu programmes d'autres choses à un autre niveau d'abstraction, c'est exactement l'inverse. Cela dépend vraiment des usages.

En gros, le Forth, quand tu y a goûté (un peu plus que les exemples bidons qui ressortent à chaque fois),
bien tu ne peux plus t'en passer

Point de vue très perso. J'ai pas mal pratiqué et cela ne m'a pas fait ça. Ceci dit, même si j'ai des préférences, il n'y a aucun langage qui me fait cet effet, j'utilise vraiment ce qui est adapté suivant les circonstances.

3 - La grosse tête
Pour moi le plus gros problème de ce langage.
Ce langage donne l'impression d'être un dieu de l'informatique, je pense que c'est un peu pareil avec les autres
langages quand on commence à bien le maîtriser, mais en Forth ce sentiment est vraiment fort.

Je ne sais pas. C'est vraiment un truc perso là aussi cette impression.

Donc, J'adore le Forth, mais je ne le conseille à personne

Point de vue sympa et ton enthousiasme fait plaisir à voir.

[Forthman]

J'ai un programme d'un million de lignes en Java qui fait tourner des traitements semi-critiques.

Je ne suis pas dans l'informatique, et je ne sais pas ce qu'est un traitement semi-critique
et je n'imagine pas le temps qu'il faut pour taper 1 million de lignes... (genre 1 ligne par seconde ça fait déjà 277 heures )

Dans ma jeunesse je m'amusais à reproduire des jeux d'arcade, j'ai fait quelques utilitaires du temps du DOS (texte, disques...etc...)
maintenant les fois où je programme c'est pour faire un peu d'automatisation (dernièrement j'ai automatisé un plateau diviseur pour ma fraiseuse)
mais surtout pour générer du code pour mes machines numériques. (des bricoles quoi )

Pour l'effet "grosse tête" si t'as du temps à perdre, va jeter un oeil sur le groupe forth google,
à chaque question les mecs partent dans tous les sens certains de détenir la vérité

[pm42]

Je ne suis pas dans l'informatique, et je ne sais pas ce qu'est un traitement semi-critique

Critique = si ça plante, des gens meurent en gros. C'est varié. Du soft dans les avions bien sur mais aussi dans le médical ou bêtement la téléphonie. Si un soft plante dans un réseau téléphonique et que les gens ne peuvent pas appeler pendant 10 min, le mec qui fait un arrêt cardiaque meurt pendant que son conjoint essaie d'appeler les secours.

Semi-critique = si ça plante, ça met plein de gens dans la merde, tu as un risque réglementaire/juridique mais personne ne meurt.

et je n'imagine pas le temps qu'il faut pour taper 1 million de lignes... (genre 1 ligne par seconde ça fait déjà 277 heures )

Quelques années à plusieurs. A une époque, les programmeurs faisaient du 35 lignes/jour débuggées tout compris quelque soit le langage, la méthodologie sur du soft pro. Je ne sais pas si ça a beaucoup bougé.

Dans ma jeunesse je m'amusais à reproduire des jeux d'arcade, j'ai fait quelques utilitaires du temps du DOS (texte, disques...etc...)
maintenant les fois où je programme c'est pour faire un peu d'automatisation (dernièrement j'ai automatisé un plateau diviseur pour ma fraiseuse)
mais surtout pour générer du code pour mes machines numériques. (des bricoles quoi )

Sympa. Effectivement, faire ça en Forth est marrant et pas con si on maitrise le langage.

Pour l'effet "grosse tête" si t'as du temps à perdre, va jeter un oeil sur le groupe forth google,
à chaque question les mecs partent dans tous les sens certains de détenir la vérité

Ok, si j'ai le temps, je jette un oeil.

[Garion]

Discussion intéressante (et puis ça ne pollue pas les autres sujets ).
Personnellement, mon soft a presque atteint le million de ligne en 15 ans, aujourd'hui (6 ans plus tard), on en est 1.5 million mais j'ai 3 programmeurs en plus.
Je programme en Pascal (parce que le projet a été commencé avec ce langage), donc un langage "classique".
Le Forth, je ne l'ai jamais pratiqué, mais ça a l'air séduisant (j'aime bien les langages bas niveau, j'ai beaucoup pratiqué l'assembleur, et je le pratique encore pour des procédures critiques en temps de calcul). Mais le langage qui m'a le plus marqué, c'est l'ADA. Je l'ai pratiqué dans les années 90, et j'ai vraiment trouvé ça génial particulièrement pour sa notion de Tâche et de rendez-vous qui rend la parallélisation tellement naturelle.

[pm42]

Je programme en Pascal (parce que le projet a été commencé avec ce langage), donc un langage "classique".

J'en ai fait pas mal aussi mais comme pas mal de monde, je suis passé au C (pas forcément un progrès) puis à l'objet.

Mais le langage qui m'a le plus marqué, c'est l'ADA. Je l'ai pratiqué dans les années 90, et j'ai vraiment trouvé ça génial particulièrement pour sa notion de Tâche et de rendez-vous qui rend la parallélisation tellement naturelle.

La complexité des compilateurs pour garder de la perf a tué le langage : en gros, c'était l'enfer à faire tourner sur micro-ordinateur contrairement au Pascal, au C, etc.
Pour le parallélisme, la logique de tâche/rendez-vous est pas mal mais maintenant, on essaie surtout de faire du multi-machines avec des approches map/reduce par ex. En utilisant bien des lambdas, c'est aussi très élégant.

[invite2800a7c8]

Salut,

Bonjour,
Sauf que...
Travailler sur la pile, est tout de même assez casse gueule: une fonction empile ou dépile un truc de trop et ça part en vrille.

Ça ne part pas vraiment en vrille, ça fait un petit message « Stack Underflow » et ça arrête la machine. Il y a un gestionnaire d’erreur complet.
Regarde Ici : https://www.forth.com/download/
C’est gratuit, tu peux tester et vérifier par toi-même. Je considère que tu connais Forth,
Mais comme ce n’est pas le cas de tout le monde (je suppose), ma réponse contiendra donc des explications plus générales que toi tu connais déjà.

Comment sépare-t-on le user-land du kernel-land dans ces conditions (si le concept existe dans une extension de forth) ? ? ? Probablement par une pirouette en (berk) assembleur...

Tu as bien des façons de faire, tu crées un Dictionnaire User et quand tu lances l’application, tu verrouilles les autres dictionnaires.
Tu fais un package
Tu utilises la mémoire étendue
Etc…

Il faut bien noter que Forth n'est pas seulement un langage, c'est le système complet (ou en tout cas il peut l'être). D'où l'usage du terme de machine virtuelle par-ci, par là (encore un terme vague dont le contexte détermine la signification sur plus de 90% de ses propriétés).
Donc on parle de quoi et dans quel contexte (je n'irais pas mettre un linux sur un micro 4 bits, tout comme je ne coderais pas en assembleur un os pour un système multi-tâches, idem pour le choix d'un langage).

Pour être précis, c’est un processeur virtuel implanté en mémoire avec un jeu d’instructions extensible par l’utilisateur. Le jeu d’instructions de bases est normalisé
ISO et ANSI. Le jeu d’instruction ou plus précisément les mots, sont répartis dans différents dictionnaire. Si tu introduits la commande words au clavier, le système va t’afficher les mots disponibles.
Le processeur Virtuel fonctionne avec deux piles, la pile de données et la pile de retour. Chaque cellule de la pile de donnée peut être considérée comme un registre particulier du processeur virtuel.

Forth est un système/langage extensible. à l'époque, c'était pas rien, mais de nos jour, c'est d'une banalité...C'est une force, mais aussi une faiblesse, car la même fonctionnalité basique (commutation de tâche avec séparation de droit par exemple) aura pu être développée de différentes façons par différents éditeurs de "macro système/langage". Il en découle alors les mêmes incompatibilités qu'entre les différents dialectes de basic (exemple pris presque au hasard).

A ma connaissance, la notion de macro n’existe pas dans Forth. Comme déjà dit, le seul travail de programmation consiste à construire un mot nouveau que l’on rajoute dans le dictionnaire. Si tu construis deux fois le même mot, le système émet un Warning et la méta compilation est refusée.

La seule grande réussite de Forth est cachée dans PostScript qui ne se vante pas de cette filiation (serait-elle honteuse ? ? ?).

La bonne blague, t’es tout de même pas naïf au point de croire que chez Adobe ils vont se mettre à crier sur les toits avec quels outils ils travaillent ? Comme tous les autres, ils te fourguent des outils dont ils sont sur que tu passeras au moins 5 fois plus de temps qu’eux pour faire la même chose.
Un exemple parmi d’autres, le système d’exploitation UNIX sur les stations SUN ainsi que tous les serveurs SUN tournaient sur Forth, ensuite est venu Java, je te laisse deviner comment c’est arrivé. Tu crois vraiment qu’ils vont te dire comment ils ont fait ? Mais si tu veux vraiment savoir essai de demander à Mitch Bradley.

Depuis, les compilos "classiques" (C, C++, ...) ont fait d'énormes progrès en termes d'optimisation, le développeur peut écrire presque comme un cochon, et le code tourne presque aussi vite qu s'il avait été affûté à la main. Idem pour les os qui sont devenus très complexes et puissants.

Tout à fait, mais le fait est qu’en Forth il n’existe pas de compilateur au sens commun du terme. Résultat des courses pas de syntaxe à apprendre. La seule chose à savoir c’est ce que fait un mot (instruction) et ça c’est parfaitement bien documenté.
Le compilateur, si on peut appeler ceci un compilateur, se ramène à deux mots.
Le premier mot c’est : lire (deux points) le second c’est ; (lire point-virgule)
Ça s’utilise comme ça :

: Dire_Bonjour ( --- ) \ Fait un carriage return et affiche le texte compris entre S'' et ''

  CR 
  S’’  Salut la foule, bien venue dans le monde Forth’’
  Type

;

Pour revenir à nos jours:
Les cross-tools permettent de développer dans un environnement confortable, le temps de la programmation aux clés sur la machine cible est révolu.

????

On essaie de séparer le spécifique à développer du générique qu'on peut retrouver dans un système (à choisir) qu'il "suffit" de paramétrer pour sa machine cible.

Je n’ai pas souvenir avoir un jour fait autrement, on méta compile pour une cible donnée.

Si j'ai un dev à faire, je choisi un environnement tel que je saurai trouver des ressources humaines et si possible une communauté active importante pour aboutir. L'usage de technos un peu étranges peut mettre un projet en danger par la simple démission du magicien de 7ème niveau dans le langage sblurg qu'on aurait choisi pour une raison particulière.

Je ne vois pas le PB, t’as une norme, elle est claire, elle décrit les mots et leur utilisation de façon extrêmement explicite, la seule question à se poser est: que faut ’il mettre sur la pile de donnée pour faire fonctionner le mot en question, puis que fait ce mot, puis quel résultat il retourne sur la pile de donnée. En clair, le problème que tu soulèves n’existe pas.

Ah bon, ils te donnent le source de leur système, là où t'as raqué 399$ ? ? ?
Ça m’étonnerait.

Dans l’hypothèse ou t’as fait le dowload que je t’ai indiqué, tu vas ici :
C:\ForthInc-Evaluation\SwiftForth\src\ide\ win32
C’est une grande partie des sources et ça fait 0,00$

Et chez Boeing Military Aircraft & Missile Systems (dans la liste des utilisateurs), ils te donnent leurs sources aussi (au fait, il n'y a pas la NASA dans la liste).

Les développeurs livrent les sources à leurs clients, c’est la règle. Boeing et autres sont des utilisateurs.
T’as oublié Patriott, ça ne te dis rien ?

Pour la NASA voir ici les archives connues:

http://web.archive.org/web/201010242...gsfc.nasa.gov/

Ici une Remarque s’impose, la NASA comme beaucoup d’autres dans le spatial ont utilisés le processeur Forth RTX 2000 puis RTX 2010 de Harris. Ce processeur contient une machine Forth, cette fois-ci implantée dans le silicium.

https://ntrs.nasa.gov/search.jsp?R=19930073240

La fabrication du processeur RTX 2010 fut par la suite transférée chez Intersil.
Ici
http://www.intersil.com/content/dam/...-rtx2010rh.pdf

C'est MPE qui assurait le support technique pour la programmation

http://www.mpeforth.com/

Pour la petite histoire, les popovs avaient une copy conforme de ce processeur. La majeure partie de leur spatial était basé la dessus.
Puis vint l’avènement de VHDL et des FPGA ultra puissantes, cela à permis de concevoir à peu de frais des processeurs Forth dédiés. Mais bien plus important, on ne divulgue plus rien. J’ai eu à participer à ce type de projets.


Exemple d'application:
http://www.xilinx.com/applications/a...munitions.html


Tu ne crois tout de même pas qu’ils vont se mettre à programmer avec du C ou du C++ ?

Cordialement
Ludwig

[pm42]

Comme d'hab, c'est totalement faux. Tu confonds les outils utilisés par Adobe et le langage Postscript lui même qui est de plus parfaitement documenté.
Pour les stations Sun, c'est le bios (ou équivalent) qui était en Forth et ça n'a rien à voir avec Unix vu qu'il a tourné sur de nombreuses machines sans ça. Rien à voir avec Java non plus.

Le ???? sur la cross-compilation est aussi significatif.

Le reste est du même acabit. Comme je le disais, écrire autant, connaitre si peu de choses et faire autant d'erreurs est impressionnant.

[invite2800a7c8]

Re

Pour les stations Sun, c'est le bios (ou équivalent) qui était en Forth et ça n'a rien à voir avec Unix vu qu'il a tourné sur de nombreuses machines sans ça. Rien à voir avec Java non plus.

Il se trouve que j'ai travaillé avec. Si jamais tu es face à une de ces stations,
faire commande STOP a puis WORDS,
t'auras toutes les commandes UNIX qui vont s'afficher à l'écran, elles sont toutes écrites en Forth
pour une raison toute simple, Forth contient un Parser et un interpréteur de commandes.

Cordialement
Ludwig

[pm42]

Il se trouve que j'ai travaillé avec. Si jamais tu es face à une de ces stations,

Oui moi aussi sur plusieurs générations des dites machines, avec des 68000, des 386, des Sparc, etc.

t'auras toutes les commandes UNIX qui vont s'afficher à l'écran, elles sont toutes écrites en Forth

N'importe quoi. Au départ, SunOS était une variante de BSD puis a mergé avec Sys V, est devenu Solaris.
Dans tous les cas, Unix était écrit en C.

Tu confonds simplement les commande du bios avec celles de l'OS.

pour une raison toute simple, Forth contient un Parser et un interpréteur de commandes.

Oui tout comme Lisp, le shell et plein d'autres langages.
Là encore, aucun rapport.

[polo974]

Salut,
...
Tu utilises la mémoire étendue
Etc…

oh purée, ça faisait longtemps que je n'avais plus entendu parler de "mémoire étendue"...

...

A ma connaissance, la notion de macro n’existe pas dans Forth. ...

quand le parlais de macro système/langage, il s'agissait d'un Forth de base (standard) auquel a été adjoint tout un tas d'extensions...

...
Tout à fait, mais le fait est qu’en Forth il n’existe pas de compilateur au sens commun du terme.

Oui, on a tous compris, Forth n'est pas commun... Mais qu'il y a quand même un genre de compilo...

...


????

Pour ne pas passer pour un has-been, une recherche sur gogol ou wiki t'aurait renseigné...

...


Pour la NASA voir ici les archives connues:
...

ça date de plus de 25 ans...

Ici une Remarque s’impose, la NASA comme beaucoup d’autres dans le spatial ont utilisés le processeur Forth RTX 2000 puis RTX 2010 de Harris. Ce processeur contient une machine Forth, cette fois-ci implantée dans le silicium.

Sauf que la doc dit:
""" RTX Microcontrollers support the C and Forth programming languages. """
Bref, c'est un (drôle) de micro durci qu'on peut programmer en C ou en Forth, ce n'est pas un "processeur Forth", et au vu de l'archi, en 90, il devait déjà être en fin de vie...

...

Tu ne crois tout de même pas qu’ils vont se mettre à programmer avec du C ou du C++ ?

On trouve les même en COBOL...

[inviteb9f49292]

N'importe quoi. Au départ, SunOS était une variante de BSD puis a mergé avec Sys V, est devenu Solaris.
Dans tous les cas, Unix était écrit en C.

Tu confonds simplement les commande du bios avec celles de l'OS.

Je confirme !!! c'est bien le "bios" des stations sun qui est en forth (ce qui m'avait épaté à l'époque), il n'y a AUCUN rapport avec UNIX. Mais peut-être ont-ils repris des mots clefs identiques à des commandes UNIX classique (?). Et si j'ai le courage, et qu'elle marche toujours, je me suis gardé une pizza-box (sunstation 5 ou 10, peut être 20) et même une ultra (je ne sais plus le modèle) à la piaule, je pourrais essayer...

Et le post-script est antérieur à adobe (tu confondrais pas avec le pdf des fois?)

Les développeurs livrent les sources à leurs clients, c’est la règle. Boeing et autres sont des utilisateurs.
T’as oublié Patriott, ça ne te dis rien ?

Ca dépends si c'est marqué dans le contrat, et en général ça se paye... donc c'est bien loin d'être une généralité...