Lisp et Ti - Page 5

Nil
a écrit : Un Goto peut casser une boucle + "correcte" et ainsi te foutre une merde pas possible dans tes variables.

Exemple?

Quand je dis que les gotos sont pratiques, je ne parle pas pour moi, je n'en utilise jamais (absolument, je n'ai pas un seul programme Pascal ou C avec un goto).

Ils sont pratiques pour moi en tout cas.

(c'est marrant comme les codeurs C ont la fâcheuse habitude de ne pas commenter, ou de commenter en Franglais ou en Français des banlieues)

Ben, dans ce cas, le langage n'y est pour rien. /* I always comment my C source code in correct English like this. */

Et si on veut mettre plusieurs instructions, on fait quoi? On ne peut pas? Parce que sinon, il faudra bien marquer le début et la fin des "expressions".

Ben on met des parenthèses... ou begin et end, ce qui revient au même mais est plus lisible pour les gros blocs. De la même façon qu'en C tu mets des accolades... ou dans le cas de ? : des parenthèses aussi...

On n'a jamais de mauvaise surprise.

Là c'est vrai qu'il ne faut pas trop en rajouter. Je connais des gens (moi) qui ont le chic, quel que soit le langage, pour oublier les parenthèses précisément au mauvais endroit...

Alors là, carrément, rien ne me dit que la fonction renvoie un fichier

J'ai dit « on se doute », pas « on sait ». Et si ce qui t'intéresse c'est l'équivalent des prototypes de fonctions, j'ai déjà dit qu'il y avait des fichiers d'interface pour ça.
Tu dis que lire, c'est lire, pas parser, soit, mais alors ce qu'il faut lire c'est l'interface. Si tu veux lire le fichier d'implémentation (pour moi, le fichier d'interface fait partie du code source) c'est que tu t'intéresses à l'intérieur du corps des fonctions et que tu veux comprendre ce qu'elles font, eh bien, si tu comprends ce qu'elles font tu sais leur type et je ne vois donc pas l'utilité de le déclarer de façon redondante dans l'implémentation.

Si une fonction s'appelle ouvre_fichier, on se doute qu'elle ouvre un fichier ; si on se contente de survoler le source pour en avoir une vague idée, le type de retour de la fonction est un détail à ce stade (de toute façon, si l'on rencontre plus loin un appel de cette fonction, la forme de cet appel rendra clair le type de retour). Et je te ferai remarquer que si la fonction stocke le fichier dans une variable globale, même en C, il faudra bien que tu "parses" le corps de la fonction pour savoir de quelle variable il s'agit...
En revanche, si une fonction et ses paramètres ont des noms peu explicites, indiquer les types ne va pas beaucoup aider le lecteur...

Le C ne complexifie pas du tout les choses.

Tu as probablement raison, mais le fait est que dans le cas des chaînes de caractères il les non-simplifie à un point franchement abusif.

Tiens Kevin, comme je sais que tu soignes ton orthographe, deux petites remarques :
-- implicite prend un e (même au masculin)
-- ambigu n'a pas de tréma. Le tréma en français n'a de sens que placé sur une voyelle qui en suit une autre et indique qu'on doit les considérer comme séparées (ça revient en gros à mettre un h entre les deux). Donc on écrit "ambigu", mais comme un u qui suit un g (ou un q) ne se prononce normalement pas s'il est lui-même suivi d'une voyelle (cf. algue, aguicher, aiguiser, arguer...) on ne peut écrire "ambigue" ni "ambiguité" qui donneraient phonétiquement resp. ambig et ambig-ité. Donc dans ces deux cas on met un tréma sur la deuxième voyelle pour séparer --> ambiguë, ambiguïté.

(#116)

Pas du tout. Plusieurs petits programmes qui allouent chacun très peu de mémoire = le treshold de GC sera rarement ou jamais dépassé = il y aura pas ou très peu de GC. Un gros programme qui alloue beaucoup de mémoire = le treshold sera dépassé à plusieurs reprises = il y aura beaucoup de GC. C'est l'existance du treshold (de la borne inférieure en dessous de laquelle il n'y a pas de GC) qui fait qu'il n'y a pas proportionnalité.

N'importe quoi!
Les routines qui n'allouent PAS de mémoire n'allouent PAS de mémoire! => ZERO allocation.
De toute façon il est évident que le temps consommé par les GC est proportionnel à la quantité d'allocations, et que si on veut le comptabiliser, c'est un temps constant à rajouter à la durée d'une allocation.

TIGCC est un cas bien particulier.

Il y a donc plein de cas bien particuliers, en C.

Rien ne remplace le C!

Le Caml *peut* remplacer le C dans la plus grande partie des applications.

Et même si quelque chose remplaçait le C, ça serait le C++ ou peut-être le Java, mais certainement pas le CAML.

lol!
En suivant ton propre raisonnement, comme Caml est nettement (!) plus efficace que C++ et que Java, comme c'est un langage objet et qu'il offre donc toutes leurs possibiltés, il faut SUPPRIMER C++ et Java au profit de Caml

f(a)+f(b) est nettement plus naturel.

Dogme.

En lisant (f a)+(f b), on dirait presque du LISP.

Il y a une lointaine parentée (langages fonctionnels)

(f a b c) est de la syntaxe LISP (notation polonaise préfixée et entourée de parenthèses)!

Mais bien sûr la parenthèse extérieure est stupide. f a b c est très bien.

Arrête de mentir! CAML n'a pas les mêmes performances que le C!!! Dans le bench,

Va vite prendre de la juvamine!

Et quand bien même tu refuse de l'admettre pour le C, c'est une évidence flagrante pour C++ et java que Caml est un langage plus puissant sur tous les plans. Tout ce qui est programmé dans ces langages pourrait (devrait, selon le raisonnement kevin) être fait en Caml, et serait ainsi plus efficace.

Et j'ai déjà montré pourquoi ça sera encore pire pour des programmes réels.

Tu n'as rien montré du tout.

Non, c'est toi qui es d'extrêmement mauvaise foi à continuer de renier le fait que GCC bat Ocaml en vitesse et en consommation de mémoire (en temps d'exécution), alors que le bench que toi, tu m'as indiqué, montre le contraire!

En mémoire consommée, je n'ai jamais dit le contraire, même si la différence est sans importance.
En vitesse, ils sont à égalité. Allez, pour te faire plaisir, j'admets le 0.13%

Non. Un langage trop abstrait dégrade les performances.

Dogme de la religion Koflerienne.

Contre-exemple du dogme : Caml.

et je trouve que le C est plus lisible.

Parce que tu as mauvais goût

L'erreur est justement de faire le compte de l'abstraction. L'abstraction n'est pas un but, c'est juste un moyen d'obtenir de la lisibilité et de la portabilité. Le C est déjà très lisible et très portable, donc ce n'est pas la peine d'aller plus loin en abstraction.

Quoique tu en penses, l'abstraction est un but en soi. Sans abstraction, l'informatique serait restée à l'âge de pierre.

Ce que tu penses, c'est qu'on est allé assez loin et qu'on peut se permettre de stopper le progrès. des gens comme toi existaient ils y a 10 ans, 20 ans, 30 ans, 40 ans. Heureusement, on ne les a pas écouté.

Et je ne vois pas du tout pourquoi on ne programmerait pas un Athlon de la même manière qu'un 8086.

He bien c'est grave, voilà tout.

Ça donnerait des programmes bien plus efficaces que le bloatware qu'on voit de nos jours.

Ca donnerait des programmes bien moins efficaces. Mais tu as raison, retournons tous à l'assembleur, le plus puissant des langages!

Arrête de nier les faits!

A qui le dis tu.

Le fait que tu ne saches pas distinguer entre une généralisation injustifiée et un fait est très inquiétant!

A qui le dis tu.

( « Un langage trop abstrait dégrade les performances. » )

Si. Si ça marche correctement, ce n'est pas dangereux.

Le fait que ça marche correctement n'a rien à faire avec le fait que c'est dangereux. Dans un mois, Bob modifiera son code et il ne trouvera pas l'erreur dans ce merdier.

Ce ne sont pas du tout des problèmes insolubles! Pour le problème d'effets de bord, il suffit d'écrire des macros protégés contre les effets de bord:
http://tigcc.ticalc.org/doc/gnuexts.html#SEC63

Il n'existe pas de problèmes insolubles de toute façon.
Il n'existe que des problèmes.
Ceci en est un.

Ce n'est pas "terriblement porc", c'est souvent très pratique, et de toute façon, toute autre définition n'aurait pas de sens, donc ce n'est pas ambigü, et il n'y a donc aucune raison pratique de ne pas l'accepter.

C'est terriblement porc, sans aucun conteste possible, et il faut être fou pour programmer comme ça.

Carrément pas. Il faut commencer à lire la fonction en entier pour pouvoir

Non, le plus souvent juste le début suffit. Ou regarder les motifs de filtrage. Le type y est transparent.

Si, parce que tu dis que "Caml est plus efficace que les mathématiques".

En bref, tu m'imposes des opinions pour pouvoir ensuite les réfuter.
lamentable.

Thèse de Church-Turing: le lambda-calcul (de Church) est strictement équivalent à la machine de Turing. En d'autres mots, les langages fonctionnels sont strictement équivalents en expressivité aux langages impératifs. Aucun contre-exemple connu. Donc ce n'est pas un "paradigme mathématique ou logique plus puissant".

Church

Mais ton erreur est dans ta vision de l' « équivalence », qui n'a en fait rien de canonique ni d'immédiat.

(Z/pZ)* est isomorphe à Z/(p-1)Z, mais l'isomorphisme est incalculable sans énumérer tous les éléments (heureusement, sinon toute la cryptographie s'effondrerait). Même si les deux groupes sont les mêmes, la vision est différente et l'un doit être privilégié sur l'autre dans certaines situations.

De même, les langages fonctionnels ont beaux être équivalents aux impératifs (c'est à dire que l'on peut faire la même chose), ils sont plus en phase avec l'algorithmie (forcément, puisqu'ils sont issus de recherches d'informatique théorique...) et sont plus puissants.

Non, c'est le souci de clarté et de non-ambigüité qui y pousse.

Le souci de clarté et de non-ambiguité est exacerbé par le fait que les priorités sont bizarres et que le langage est naturellement ambigu.

Il y a forcément des priorités qui peuvent surprendre.

Oui.
Encore que... en cherchant un peu, je n'en trouve pas du tout, mais admettons...
Toujours est il que ça n'a rien à voir avec le C.

Désolé, mais je ne te crois pas, là. Rien que par le fait qu'on vient d'un autre langage de programmation où les priorités sont différentes de manière subtile, on peut être surpris par les priorités d'un langage (même si ce dernier n'y est pour rien).

Bon, d'accord, quelqu'un qui a pris des mauvaises habitudes de C aura besoin d'un peu (pas beaucoup) de pratique pour désapprendre ce qu'il a appris. (En fait il aura surtout du mal à se mettre à la rigueur)

As-tu déjà essayé gcc -ansi -pedantic?

Est ce que « gcc -ansi -pedantic » est « le C » ?

Mais la notation utilisée dans pratiquement tout le reste des Mathématiques est plus courante, donc son emploi serait nettement plus logique.

certainement pas.
La théorie ZF est complètement stupide pour un ordinateur! Le lambda calcul est beaucoup plus logique.
ZF qui sert pour les mathématiques courantes a été inventée alors que les ordinateurs n'existaient pas, ce qui n'est pas le cas du lambda-calcul qui a été au contraire développé *pour* l'informatique.

timoleon
a écrit : Ben on met des parenthèses... ou begin et end, ce qui revient au même mais est plus lisible pour les gros blocs. De la même façon qu'en C tu mets des accolades... ou dans le cas de ? : des parenthèses aussi...

Je ne vois pas la différence avec le C alors. En C aussi, on n'a pas besoin de mettre d'accolades si on met une seule instruction.

En revanche, si une fonction et ses paramètres ont des noms peu explicites, indiquer les types ne va pas beaucoup aider le lecteur...

Si, quand-même. Le nom n'indique pas forcément le type, il indique juste le contenu.

Tu as probablement raison, mais le fait est que dans le cas des chaînes de caractères il les non-simplifie à un point franchement abusif.

Tu peux toujours écrire une librairie d'abstraction. Il y en a même certaines qui existent déjà (glib par exemple).

Tiens Kevin, comme je sais que tu soignes ton orthographe, deux petites remarques :
-- implicite prend un e (même au masculin) -- ambigu n'a pas de tréma. Le tréma en français n'a de sens que placé sur une voyelle qui en suit une autre et indique qu'on doit les considérer comme séparées (ça revient en gros à mettre un h entre les deux). Donc on écrit "ambigu", mais comme un u qui suit un g (ou un q) ne se prononce normalement pas s'il est lui-même suivi d'une voyelle (cf. algue, aguicher, aiguiser, arguer...) on ne peut écrire "ambigue" ni "ambiguité" qui donneraient phonétiquement resp. ambig et ambig-ité. Donc dans ces deux cas on met un tréma sur la deuxième voyelle pour séparer --> ambiguë, ambiguïté.

OK, merci, j'essayerai de m'en rappeler. Avec le temps que je ne lis plus de français ailleurs que sur Internet où "presk tou l mond ecri kom sa", je commence à ne plus savoir écrire certains mots correctement.

(#118)

En quoi être souple est-ce une mauvaise chose??? Plus un langage est souple, mieux c'est!

La souplesse prise isolément est une bonne chose.
Mais justement, la souplesse ne peut pas être prise isolément. En contrepartie, la trop grande souplesse du C a des conséquences négatives.

1. Tu avoues toi-même que c'est pratique, ce qui est une excellente raison de le garder (et de l'utiliser).

Non!
C'est de la paresse!!
Je te croyais contre la paresse.

2. S'il est utilisé correctement, goto

Un goto utilisé correctement est un goto inutilisé.

La gestion des chaînes de caractères se base sur ce qu'elles sont vraiment: des chaînes (tableaux) de caractères.

Gérons donc tout l'ordinateur en ce basons sur ce qu'il est vraiment.
Interdisons les boucles, tout en goto.
Programmons en Hexa.
Interdisons les drivers et communiquons directement avec le matériel.

Les pointeurs font partie des bases du C.

C'est un problème.

(#119)

Un code Pascal peut aussi devenir illisible, mais (à mon sens) beaucoup moins

Je trouve quand même que Pascal est un langage remarquablement clair.
(Infiniment plus que le C, en tout cas.)

De toutes façons, le C étant un langage quasi "universel" - plus que le C++ -(compilos disponibles sur la majorité des plateformes, programmation des PICS en C...), je ne pense pas qu'il disparaisse avant longtemps.

Non, certes.
Ce serait stupide de seulement essayer de le faire disparaître, il reste et restera indispensable.
Mais il doit laisser de la place à d'autres langages qui ont montré qu'ils étaient plus puissants.

(#120)

Ils sont pratiques pour moi en tout cas.

Alors tu as un mauvais style de programmation.

(#123)

Je ne vois pas la différence avec le C alors. En C aussi, on n'a pas besoin de mettre d'accolades si on met une seule instruction.

if (x==0) { ... ?

HIPPOPOTAME
a écrit : N'importe quoi!

Non, c'est toi qui dis n'importe quoi:

Les routines qui n'allouent PAS de mémoire n'allouent PAS de mémoire! => ZERO allocation.

Mais je te parle justement des routines qui allouent de la mémoire. Il y en a forcément, sinon le bench est totalement biaisé en faveur des langages à GC.

De toute façon il est évident que le temps consommé par les GC est proportionnel à la quantité d'allocations,

Seulement si on a passé le treshold.

et que si on veut le comptabiliser, c'est un temps constant à rajouter à la durée d'une allocation.

C'est une approximation, ça.

Il y a donc plein de cas bien particuliers, en C.

Non, pas tellement.

Le Caml *peut* remplacer le C dans la plus grande partie des applications.

Mais il ne le fera pas parce qu'il est trop différent de ce que presque tout le monde apprend.

lol!
En suivant ton propre raisonnement, comme Caml est nettement (!) plus efficace que C++ et que Java, comme c'est un langage objet et qu'il offre donc toutes leurs possibiltés, il faut SUPPRIMER C++ et Java au profit de Caml

Non, au profit du C, qui est encore plus efficace!

>f(a)+f(b) est nettement plus naturel. Dogme.

Ce n'est pas un dogme, c'est plus naturel parce que c'est la notation mathématique que tout le monde apprend. Si tu veux qu'on trouve (f a)+(f b) plus naturel, il faudra commencer par révolutionner l'enseignement des Mathématiques au monde. Bonne chance!

Mais bien sûr la parenthèse extérieure est stupide. f a b c est très bien.

Et f f a b f a b c f a b f a b c f a b f a b c, c'est très bien aussi???

Et quand bien même tu refuse de l'admettre pour le C, c'est une évidence flagrante pour C++ et java que Caml est un langage plus puissant sur tous les plans. Tout ce qui est programmé dans ces langages pourrait (devrait, selon le raisonnement kevin) être fait en Caml, et serait ainsi plus efficace.

Non, il devrait être fait en C, et serait ainsi encore plus efficace!

>Et j'ai déjà montré pourquoi ça sera encore pire pour des programmes réels. Tu n'as rien montré du tout.

Relis mes messages précédents, parce que j'ai l'impression que tu as raté un épisode.

En mémoire consommée, je n'ai jamais dit le contraire, même si la différence est sans importance.

La différence n'est certainement pas sans importance. La quantité de RAM d'un ordinateur n'est pas infinie.

En vitesse, ils sont à égalité. Allez, pour te faire plaisir, j'admets le 0.13%

Donc ils ne sont pas à égalité.

Et la taille des exécutables, tu en dis quoi?

>Non. Un langage trop abstrait dégrade les performances.
Dogme de la religion Koflerienne.

Non, cf. ci-dessous.

Contre-exemple du dogme : Caml.

Contre-exemple invalide. Cf 2-3 paragraphes plus haut.

Parce que tu as mauvais goût

Sans commentaire.

Ca donnerait des programmes bien moins efficaces. Mais tu as raison, retournons tous à l'assembleur, le plus puissant des langages!

Euh, je te signale que "programmer un Athlon de la même manière qu'un 8086" ne veut pas forcément dire en assembleur. Le C existait aussi sur 8086.

>Arrête de nier les faits!
A qui le dis tu.

>Le fait que tu ne saches pas distinguer entre une généralisation injustifiée et un fait est très inquiétant! A qui le dis tu.

Sans commentaire.

( « Un langage trop abstrait dégrade les performances. » )

Exemple invalide. Cf. plus haut.

Le fait que ça marche correctement n'a rien à faire avec le fait que c'est dangereux. Dans un mois, Bob modifiera son code et il ne trouvera pas l'erreur dans ce merdier.

Quelle erreur? Il n'y en a pas dans les macros en question (du moins tu n'en as pas trouvées ), et s'il y en a ailleurs, les macros n'y changeront rien.

Ceci en est un.

Ce n'en est pas un si on sait ce qu'on fait.

C'est terriblement porc, sans aucun conteste possible, et il faut être fou pour programmer comme ça.

Pas du tout. Ça peut être très pratique. On a déjà utilisé ça dans TIGCCLIB:
#ifdef _NEED_COMPLEX_MAIN
#define enter_ghost_space() ({extern unsigned long *__save__sp__;_INCLUDE_PATCH(save_the_sp);enter_ghost_space();(*__save__sp__)|=0x40000;})
#endif

Non, le plus souvent juste le début suffit. Ou regarder les motifs de filtrage. Le type y est transparent.

Et la valeur de retour?

En bref, tu m'imposes des opinions pour pouvoir ensuite les réfuter. lamentable.

Ça s'appelle la "réduction à l'absurde".

De même, les langages fonctionnels ont beaux être équivalents aux impératifs (c'est à dire que l'on peut faire la même chose), ils sont plus en phase avec l'algorithmie (forcément, puisqu'ils sont issus de recherches d'informatique théorique...) et sont plus puissants.

Euh, plus en phase avec l'algorithmie, je ne dirais pas vraiment. L'algorithme effectivement utilisé par la machine sera forcément impératif, donc tu t'éloignes de l'algorithme réel en utilisant un langage fonctionnel.

Est ce que « gcc -ansi -pedantic » est « le C » ?

C'est un compilateur qui est, à des bogues près, un compilateur C90 100% conforme.
Tu peux aussi avoir un compilateur C99 proche d'être conforme en utilisant gcc -std=c99 -pedantic.

certainement pas.
La théorie ZF est complètement stupide pour un ordinateur! Le lambda calcul est beaucoup plus logique. ZF qui sert pour les mathématiques courantes a été inventée alors que les ordinateurs n'existaient pas, ce qui n'est pas le cas du lambda-calcul qui a été au contraire développé *pour* l'informatique.

Ce n'est pas une raison de ne pas utiliser la notation courante pour les appels de fonction.

HIPPOPOTAME a écrit :
La souplesse prise isolément est une bonne chose. Mais justement, la souplesse ne peut pas être prise isolément. En contrepartie, la trop grande souplesse du C a des conséquences négatives.

C'est très vague, ce que tu racontes là, et je ne suis pas du tout d'accord.

Non!
C'est de la paresse!! Je te croyais contre la paresse.

Ce n'est pas forcément de la paresse d'utiliser quelque chose de pratique. Et puis, le C, en tant que langage proche de la machine, propose les fonctionnalités d'une machine. Les sauts en font partie.

Un goto utilisé correctement est un goto inutilisé.

C'est un dogme, ça, et j'ai déjà dit à plusieurs reprises ce que j'en pense. Sans arguments, tu n'iras pas loin avec ce dogme.

>La gestion des chaînes de caractères se base sur ce qu'elles sont vraiment: des chaînes (tableaux) de caractères.
Gérons donc tout l'ordinateur en ce basons sur ce qu'il est vraiment.
Interdisons les boucles, tout en goto.
Programmons en Hexa. Interdisons les drivers et communiquons directement avec le matériel.

>Les pointeurs font partie des bases du C. C'est un problème.

Non, c'est ce qui fait la puissance (d'expressivité) et l'efficacité du C.

HIPPOPOTAME a écrit :
if (x==0) { ... ?

if (!x) ...; tout simplement. (Et ça me fait mal aux yeux de lire du ==0. On dirait du Java.)

>>>De toute façon il est évident que le temps consommé par les GC est proportionnel à la quantité d'allocations,
Seulement si on a passé le treshold.

On l'a passé.
Regarde les quantités de mémoire consommée.

C'est une approximation, ça.

Je pense que c'est globalement assez juste.
Il y aurait juste quelques nuances à faire sur la taille des blocs alloués.
En tout cas, Caml gère ça très bien, avec différents niveau de GC (mineur et majeur). C'est très bien fait.

>>> Le Caml *peut* remplacer le C dans la plus grande partie des applications.
Mais il ne le fera pas parce qu'il est trop différent de ce que presque tout le monde apprend.

C'est en effet la seule et unique raison qui freine le développement du Caml.
Mais plutôt que de croire que les programmeurs sont des gens bornés et conservateurs, je préfère espérer qu'il y aura une évolution dans la bon sens.
Caml fait déjà sensation au sommet : recherche informatique, concours de programmation. Je pense et j'espère que la base laborieuse lui accordera au final une place.

Non, au profit du C, qui est encore plus efficace!

Non, au profit de l'assembleur, qui est encore plus efficace!

Le C n'est pas un langage objet. Porter un programme C++ ou Java en C, c'est un boulot fou. Caml est plus adapté, d'autant plus qu'il est aussi efficace.

Ce n'est pas un dogme, c'est plus naturel parce que c'est la notation mathématique que tout le monde apprend.

« Ce n'est pas un dogme, parce que c'est la religion que tout le monde apprend »

Si tu veux qu'on trouve (f a)+(f b) plus naturel, il faudra commencer par révolutionner l'enseignement des Mathématiques au monde.

Non non, pas besoin.
Par exemple, pour tous les taupins de France qui ont choisi l'option informatique, (f a)+(f b) est plus naturel. Et pourtant, pour être des matheux, ce sont des matheux.

Et f f a b f a b c f a b f a b c f a b f a b c, c'est très bien aussi???

C'est même un délice.

Tu as souvent des fonctions comme ça dans tes sources. Ca ne fait qu'aggraver ton style de programmation

Non, il devrait être fait en C, et serait ainsi encore plus efficace!

Ce serait *aussi* efficace.
En fait, dans ce cas particulier, ce serait sans doute plus efficace en Caml qu'en C parce que Caml est déjà un langage objet (et efficace). En C, il faudrait reprendre toutes les constructions objets et ce serait mal foutu.

Relis mes messages précédents, parce que j'ai l'impression que tu as raté un épisode.

Relis mes objections précédentes, parce que j'ai l'impression que tu as raté un épisode.

La différence n'est certainement pas sans importance. La quantité de RAM d'un ordinateur n'est pas infinie.

Consommer 400ko ou 450ko n'a pas d'importance.

Donc ils ne sont pas à égalité.

Oui oui
J'ai dit que j'admettais le 0.13%.
gentil, gentil.

Et la taille des exécutables, tu en dis quoi?

Si tu veux, je veux bien faire la somme de la taille de tous les exécutables qui sont sur mes disques durs, et la somme de la taille de tous les autres fichiers...

>Non. Un langage trop abstrait dégrade les performances.

Dogme de la religion Koflerienne.
Non, cf. ci-dessous.

Un dogme de la religion Koflerienne ne saurait être remis en cause.
Bon, voyons ça...

Contre-exemple invalide. Cf 2-3 paragraphes plus haut.

Le contre exemple est invalide parce qu'il remet en cause le Dogme.
Aucune argumentation allant à l'encontre du Dogme ne saurait être juste. Les preuves du Dogme n'ont pas été réfutées, d'ailleurs. Ce qu'Hippopotame a écrit n'existe pas.
Aucun bench allant à l'encontre du Dogme ne saurait être juste. Un tel bench est honteusement biaisé par les hérétiques.

Euh, je te signale que "programmer un Athlon de la même manière qu'un 8086" ne veut pas forcément dire en assembleur. Le C existait aussi sur 8086.

Prenons alors un ENIAC comme exemple.

Pas du tout. Ça peut être très pratique. On a déjà utilisé ça dans TIGCCLIB:
#ifdef _NEED_COMPLEX_MAIN
#define enter_ghost_space() ({extern unsigned long *__save__sp__;_INCLUDE_PATCH(save_the_sp);enter_ghost_space();(*__save__sp__)|=0x40000;}) #endif

Ca n'a rien à voir avec l'autre exemple, ici les structures sont complètes et fermées!
Ca reste moche, mais modérément moche

Et la valeur de retour?

Ben tu regardes ce que ça retourne
Si tu vois | [] -> 0, c'est un entier.

Euh, plus en phase avec l'algorithmie, je ne dirais pas vraiment.

Evidemment si. C'est fait pour.

L'algorithme effectivement utilisé par la machine sera forcément impératif, donc tu t'éloignes de l'algorithme réel en utilisant un langage fonctionnel.

N'importe quoi.
Au contraire, on s'éloigne de la machine réelle mais on se rapproche de l'algorithme. Au niveau de la machine réelle, il n'y a ni fonctions ni boucles, ni aucun sucre algorithmique.

Ce n'est pas une raison de ne pas utiliser la notation courante pour les appels de fonction.

Ce n'est pas non plus une raison d'utiliser la notation courante pour les appels de fonction.

C'est très vague, ce que tu racontes là, et je ne suis pas du tout d'accord.

Oui, c'est vague car ça recouvre l'ensemble du langage.
Et je supposais bien que tu n'étais pas d'accord.

Ce n'est pas forcément de la paresse d'utiliser quelque chose de pratique.

Phrase très juste.

C'est un dogme, ça, et j'ai déjà dit à plusieurs reprises ce que j'en pense. Sans arguments, tu n'iras pas loin avec ce dogme.

Ce n'est pas mon dogme.
C'est admis par tout programmeur un peu sérieux.

Non, c'est ce qui fait la puissance (d'expressivité) et l'efficacité du C.

D'un côté, c'est vrai que le C sans pointeur, ce ne serait vraiment rien!
De l'autre côté, c'est justement ce genre de choix sur lesquels est bâti le langage qui mène à C=crap.

if (!x) ...; tout simplement.

ben oui et?
Les parenthèses sont toujours là, autour de ton unique expression....

>La gestion des chaînes de caractères se base sur ce qu'elles sont vraiment: des chaînes (tableaux) de caractères.
Gérons donc tout l'ordinateur en ce basons sur ce qu'il est vraiment.
Interdisons les boucles, tout en goto.
Programmons en Hexa. Interdisons les drivers et communiquons directement avec le matériel.

J'avais un copain, en 4ème, qui développait de minis fichiers exécutables tout en hexa, "on the fly"... Ca tuait tout le monde (c'était un autiste de la prog asm).

Sinon, Kevin, tu fais quoi, comme études ? et HIPPO ? (c'est pour savoir, par rapport au goto)

Je ne vois pas la différence avec le C alors. En C aussi, on n'a pas besoin de mettre d'accolades si on met une seule instruction.

Mais c'est bien ce que je dis depuis le début : il n'y a PAS de endif, ni en C, ni en caml. Et il est inutile d'en créer un parce qu'on peut, dans les deux cas, regrouper des instructions.

Au fait, hippopotame, tu n'as pas parlé d'un des énormes avantages de Caml qui est l'existence du "toplevel", un interpréteur interactif qui est capable de parser et d'évaluer directement une déclaration ou une expression et d'en renvoyer le type et le résultat, ce qui permet de faire une bonne partie du débuggage avant même la compilation. Bien sûr ça ne remplace pas complètement un débuggeur (y a pas de breakpoints) (il existe aussi un débuggeur classique) mais c'est tellement efficace et pratique qu'on n'a pratiquement jamais à utiliser le débuggeur (d'ailleurs je ne m'en suis jamais servi). Ça permet aussi d'éviter de se référer à la doc quand on a simplement un doute sur le type d'une fonction (on tape le nom de la fonction et hop, il donne son type. Comme en plus la plupart des fonctions de la bibliothèque ont des arguments nommés, ça suffit souvent pour se rappeler comment on utilise la fonction). Et comme quand on tape une déclaration il renvoie son type, ça permet souvent de voir des fautes qui passeraient à la compilation (si le type qu'il donne n'est pas celui auquel on s'attend). C'est grâce au "toplevel", en particulier, que je corrige 99 % de mes erreurs de parenthésage (en général, après avoir déclaré une fonction, on peut la tester un peu avec des arguments types pour vérifier qu'elle se comporte comme il faut). Bref c'est génial et je ne connais pas d'équivalent en C (ça n'est probablement pas réalisable). Et avec le filtrage, c'est ce qui m'a le plus manqué quand je me suis mis au C...
Je pense qu'un tel système de débuggage performant est une caractéristique essentielle d'un langage de programmation. Et, mis à part peut-être pour certaines parties d'un code critiques pour la vitesse, mieux vaut à mon avis être 0,13 % ou je ne sais combien plus lent et exempt de bugs. Pour ces certaines parties, je rappelle qu'il est très facile de faire un programme caml avec une partie programmée en C (ou l'inverse d'ailleurs, mais j'en vois moins l'intérêt)

À part ça, pour ceux qui aiment les langages "obfuscated" (hippopotame, toi qui as cité unlambda...) j'en ai un joli : http://compsoc.dur.ac.uk/whitespace/

Il n'existe pas de problèmes insolubles de toute façon.

Très juste.
« Quand il n'y a pas de solution, c'est qu'il n'y a pas de problème. » (proverbe shadok)

=> Robick(4,1)
=> Robick(3,2)

(j'ai confondu avec #load...) Vive la cohérence.

Ben en fait #load ne fait pas réellement partie du langage : c'est une directive du toplevel, justement. #load "fichier_objet" lui indique de charger le fichier objet (ça peut aussi être une bibliothèque entière).
Ça n'existe pas dans le source proprement dit puisque quand on compile on spécifie tous les fichiers objets nécessaires sur la ligne de commande.

open est différent parce qu'il peut apparaître dans le code source...

Sinon, Kevin, tu fais quoi, comme études ? et HIPPO ? (c'est pour savoir, par rapport au goto)

mathématiques en 2ème année à l'école normale supérieure ; je viens de finir ma maîtrise et je commence un DEA. Comme cours d'informatique : compilation & sémantique, logique informatique & lambda-calcul.

tu n'as pas parlé d'un des énormes avantages de Caml qui est l'existence du "toplevel"

Ouaip
D'ailleurs, une bonne partie de ce que je fais en Caml, je ne le fais que dans le top level (petits programmes).

Au fait g plutot une solution plus simple a propos des histoires des operateurs qui sont pas les meme en flotant et en non flotant (vous parliez de la multiplication entre autres)


Une raison tres simple a ne pas utiliser le meme caractere (enfin c simple mais débile) c simplement par fénéantise, car cela simplifit un peu l'analyseur syntaxiquen gramatical et dans certaines mesure l'analyseur sémantique.

Normal, si par ex on prend "*" pour les entiers et "x" pour les flotants
il suffit d'une gramaire :

floatexpr: float 'x' float
intepxr: int '*' int

(en gros)

Oui, ça simplifie l'analyse.
Mais en plus de ça, ça ne marcherait pas si c'était le même caractère pour deux types différents : le typage serait impossible.

(En Caml, * sert à multiplier les entiers et *. les réels)

>Autant programmer objet en assembleur...
Juste une remarque. Je l'ai fait, et c'est plutot assez simple.
Pas de quoi fouetter un chat.

Autre remarque. 99% du code fait dans le monde n'a strictement rien a voir avec de l'algorithmie. Juste une suite d'appel de fonctions bateaux.

Le C++ plus que le C est une aberration.
Le C99 fout la merde en important des specif du C++.
Les "langages objets" sont trop objets : qui n'a jamais cree de classe juste pour une fonction.

Le goto bien utilise permet de faire un code clair. Mal utilise c'est dur, mais ca reste lisible (Mais qui a deja lu du code utilisant vraiment des goto a outrance. En plus y'avait pas de nom de labels mais des chiffres.) Alors que maintenant, il y a des noms de labels qui indiquent le but du saut.

Le caml est un langage d'evaluation.
Le c est un langage proche du langage machine.

Le caml est relativement standard car peu utilise
Le C est tellement utilise que les derives y sont inevitables. Elles ne sont pas si grandes.
Le java commence a tomber dans le cote obscur du non-portable.

La gestion des chaines de caracteres en C est chiante. Elle a juste le merite de montrer comment ca se passe vraiment. Une fois habitue, c'est pas la mort.

>les langages fonctionnels sont strictement équivalents en expressivité aux langages impératifs.
Essaye de trouver le correspondant de :
*( ((void *) *) 0x74) = (void *) MyHandler;
en CAML.
Les casts en C, c'est peut etre chiant mais puissant.

Quant a l'asm inline, il peut etre tres utile pour faire des petites fonctions inlines qui utilisent quelques instruction specifiques du processeur, permettant un code bien plus performant. Relativement encapsule dans des fichiers headers, cela reste relatviement protable. (Ex: multiplication cross 32x32 en 64 bits, ou seuls les 32 bits de points forts nous interressent).

Quant a l'assembleur Ithanium, il est pas si horrible que ca. Je le trouve meme plus simple que le x86. Suffit d'avoir l'habitude. Ok, par contre, la doc a lire est assez imposante. Mais rien de difficile. Il me tarde de parler directement a un ithanium sans intermediaire.

>Mais tu as raison, retournons tous à l'assembleur, le plus puissant des langages!
Dans mes bras mon frere ! Tu veux ta carte de membre honoraire du club ?


>Gérons donc tout l'ordinateur en ce basons sur ce qu'il est vraiment.
>Interdisons les boucles, tout en goto.
>Programmons en Hexa.
>Interdisons les drivers et communiquons directement avec le matériel.
Dans mes bras mon frere ! (bis)
Voila la vrai vie de developpeurs assembleurs.


Suis-je le seul a aimer parler avec mon proc ?

>Autant programmer objet en assembleur...
Juste une remarque. Je l'ai fait, et c'est plutot assez simple. Pas de quoi fouetter un chat.

Faisable, et même tout à fait gérable si on s'y prend bien.
Mais faut quand même pas abuser, on peut tolérer ça d'un pphd, mais c'est pas une pratique pour d'honnêtes gens

Le C++ plus que le C est une aberration.

Je suis d'accord!

Le caml est relativement standard car peu utilise

C'est juste. Il gardera longtemps l'avantage d'être très standard et unifié.

Essaye de trouver le correspondant de :
*( ((void *) *) 0x74) = (void *) MyHandler; en CAML.

Un code qui contient ça n'est pas un code honnête
(i.e. c'est de trop bas niveau pour être du Caml. Un vrai programmeur snob ne va pas lire comme une brute à une adresse XXX )

Quant a l'assembleur Ithanium, il est pas si horrible que ca. Je le trouve meme plus simple que le x86. Suffit d'avoir l'habitude.

Moi je le trouve très bien, à première vue (je n'en ai jamais fait). Beaucoup plus systématique que le x86. N'empêche que se souvenir de toutes les règles pour faire des calculs en parrallèles, de tous les petits détails... ça va le temps d'une routine optimisée, mais bon...

>Mais tu as raison, retournons tous à l'assembleur, le plus puissant des langages! Dans mes bras mon frere ! Tu veux ta carte de membre honoraire du club ?

Calculatrice. Calculatrice seulement

Suis-je le seul a aimer parler avec mon proc ?

Le Saturn, le seul qui ait une conversation intéressante

>Moi je le trouve très bien, à première vue (je n'en ai jamais fait). Beaucoup plus systématique que le x86. N'empêche que se souvenir de toutes les règles pour faire des calculs en parrallèles, de tous les petits détails... ça va le temps d'une routine optimisée, mais bon...

L'Ithanium 2 a fait vole pas mal des regles de parallelisme. Tout ou presque est parallelisable. Et le 3 s'annonce splendide

>Le Saturn, le seul qui ait une conversation intéressante
Mais non, tout le monde est interressant apres 10 minutes.

Nil
a écrit : Sinon, Kevin, tu fais quoi, comme études ? et HIPPO ? (c'est pour savoir, par rapport au goto)

Mathématiques et Informatique à l'Universität Wien (Université de Vienne, Autriche). J'en suis à mon 4^ème semestre (2^ème moitié de la 2^ème année).

timoleon
a écrit : Mais c'est bien ce que je dis depuis le début : il n'y a PAS de endif, ni en C, ni en caml. Et il est inutile d'en créer un parce qu'on peut, dans les deux cas, regrouper des instructions.

Oui, mais il faut marquer la fin du bloc, et c'est cela que HIPPOPOTAME a essayé de mettre en doûte.

Au fait, hippopotame, tu n'as pas parlé d'un des énormes avantages de Caml qui est l'existence du "toplevel", un interpréteur interactif qui est capable de parser et d'évaluer directement une déclaration ou une expression et d'en renvoyer le type et le résultat, ce qui permet de faire une bonne partie du débuggage avant même la compilation. Bien sûr ça ne remplace pas complètement un débuggeur (y a pas de breakpoints) (il existe aussi un débuggeur classique) mais c'est tellement efficace et pratique qu'on n'a pratiquement jamais à utiliser le débuggeur (d'ailleurs je ne m'en suis jamais servi). Ça permet aussi d'éviter de se référer à la doc quand on a simplement un doute sur le type d'une fonction (on tape le nom de la fonction et hop, il donne son type. Comme en plus la plupart des fonctions de la bibliothèque ont des arguments nommés, ça suffit souvent pour se rappeler comment on utilise la fonction). Et comme quand on tape une déclaration il renvoie son type, ça permet souvent de voir des fautes qui passeraient à la compilation (si le type qu'il donne n'est pas celui auquel on s'attend). C'est grâce au "toplevel", en particulier, que je corrige 99 % de mes erreurs de parenthésage (en général, après avoir déclaré une fonction, on peut la tester un peu avec des arguments types pour vérifier qu'elle se comporte comme il faut). Bref c'est génial et je ne connais pas d'équivalent en C (ça n'est probablement pas réalisable). Et avec le filtrage, c'est ce qui m'a le plus manqué quand je me suis mis au C...

Ça me rappelle le VB. Il y a ça aussi en VB. Et c'est tout à fait possible en C, il faudrait juste un IDE qui sache faire ça. C'est une propriété de l'environnement de compilation, pas du langage.

PpHd
a écrit : Le C99 fout la merde en important des specif du C++.

Pas vraiment. Tout ce qui est lourd en C++ (classes/objets, templates, surchargement, ...) ne fait pas partie du C99. Ce qui en fait partie (déclarations à l'intérieur du code, tableaux de taille variable, long long, nombres complexes, ...) sont de petits trucs qui améliorent l'expressivité du langage sans le compliquer beaucoup. Je trouve le C99 une réussite. Seule critique d'ordre majeur: les expressions contenant des instructions (({...;...;...})) du GNU C n'ont pas été officialisées. C'est une extension très utile pour faire des macros sans problèmes avec les effets de bord. Mais bon, de toute façon, la compatibilité avec les compilateurs non-GNU ne m'intéresse pas vraiment actuellement.

Le goto bien utilise permet de faire un code clair. Mal utilise c'est dur, mais ca reste lisible (Mais qui a deja lu du code utilisant vraiment des goto a outrance. En plus y'avait pas de nom de labels mais des chiffres.) Alors que maintenant, il y a des noms de labels qui indiquent le but du saut.

Entièrement d'accord.

PpHd a écrit :
>Mais tu as raison, retournons tous à l'assembleur, le plus puissant des langages! Dans mes bras mon frere ! Tu veux ta carte de membre honoraire du club ?

>Gérons donc tout l'ordinateur en ce basons sur ce qu'il est vraiment.
>Interdisons les boucles, tout en goto.
>Programmons en Hexa.
>Interdisons les drivers et communiquons directement avec le matériel.
Dans mes bras mon frere ! (bis) Voila la vrai vie de developpeurs assembleurs.

Suis-je le seul a aimer parler avec mon proc ?

 pea.l 'oi.'*16
 pea.l 'si m'
 pea.l ' aus'
 pea.l ' y a'
 pea.l ', il'
 pea.l 'peur'
 pea.l 'pas '
 pea.l "'aie"
 pea.l 4*65536+'N'
 pea.l 3(a7)
 clr.l -(a7)
 move.l $c8,a0
 move.l $1a9*4(a0),a0
 jsr (a0)
 lea.l 44(a7),a7
 rts

HIPPOPOTAME a écrit :
Un code qui contient ça n'est pas un code honnête

Si. La programmation proche du matériel, ça existe. Même sur PC. Pense aux drivers. Il faut bien les programmer, eux aussi.

(i.e. c'est de trop bas niveau pour être du Caml. Un vrai programmeur snob ne va pas lire comme une brute à une adresse XXX )

Mais *( ((void *) *) 0x74) = (void *) MyHandler;, ça ne lit pas l'adresse 0x74, ça y écrit!

Ça me rappelle le VB. Il y a ça aussi en VB. Et c'est tout à fait possible en C, il faudrait juste un IDE qui sache faire ça. C'est une propriété de l'environnement de compilation, pas du langage.

Une fois de plus, « c'est tout à fait possible en C, il faudrait juste un IDE qui sache faire ça » mais il n'y a pas d'IDE qui sache faire ça.
D'autre part, je doute quand même que ce soit aussi facile qu'en Caml : le C n'est pas un langage qui se compile "à la volée".

Entièrement d'accord.

Pour poursuivre sur le goto : je veux bien admettre qu'il y a quand même des usages propres de goto. En fait, un seul et unique usage propre : pour sortir de plusieurs boucles imbriquées. C'est pour celà que C devrait contenir une instruction break généralisée pour quitter N accolades en même temps. Ca permettrait d'éradiquer goto une fois pour toutes.

Mais bon, en fait, aussi bien goto que break ou continue devraient être interdits!#taliban#

Si. La programmation proche du matériel, ça existe. Même sur PC. Pense aux drivers. Il faut bien les programmer, eux aussi.

Bien sûr! Toutes ces choses de bas niveau (drivers, Os) doivent être faits en assembleur ou en C.
Et la couche de programmation de haut niveau, intelligente, devrait être faite en langage adapté. En Caml, notamment.

1.Je suis desole : je trouve qu'un break ou un continue sont bien plus sales qu'un goto. C'est vraiment une aberration pour se passer de 'goto'.

2. J'ai compare C / CAML (Gcc 2.85 -O3 -s -fomit-frame-pointer et CAML Light -O fast -custom). Le programme etait tout simple :

let somme n =
let s = ref(0) in
for i = 1 to n do
s := !s + i
done;;
let somme2 n =
let s = ref(0) in
for i = 1 to n do
s:= !s + somme i
done;;
begin
print_int (somme2 1000)
end;;
(Et l'equivalent C).

Resultat: C est 50x + rapide que CAML. La taille des executables etait 30Ko pour le C, 17Ko pour CAML avec runtime, et 270Ko sans runtime (stand alone).
Mais c'est surement a cause de Ligh, non ?

oui, essayes avec Ocaml....

Et puis compile avec -Os pour les comparaisons de taille.

Mais c'est surement a cause de Ligh[t], non ?

Eh bien... oui !!!

Si tu as vraiment utilisé le vieux machin qui s'appelle Caml-light, il s'agit de la version 0.74 (la version actuelle est 3.06).

Ils avaient appelé ça Caml-light à l'époque en comparaison avec les versions *précédentes* de la machine virtuelle, qui étaient encore plus lourdes.

Je n'arrive pas à comprendre pourquoi ils n'ont pas viré de leur ftp cette version hypra-obsolète qui en plus est bourrée de bugs (enfin il me semble, même si je n'ai pas d'exemples en tête), d'autant plus que la syntaxe du langage n'est pas 100 % compatible avec les versions stables (ils ont corrigé quelques incohérences) et que les fonctions de la bibliothèque standard ne s'appellent pas pareil ! Si au moins ils écrivaient dessus « obsolète » en énorme, mais même pas, on a l'impression que c'est un truc actuel. N'importe quoi.

Je ne crois pas qu'il y ait de compilateur natif pour la version 0.74 ; je soupçonne que ton stand alone n'est autre que le fichier bytecode avec la machine virtuelle en prime. Donc la taille est augmentée de celle de la machine virtuelle...

J'essaye de compiler ton test pour voir...
Compile pas...
hum, oui normal la fonction somme ne retourne rien, non plus que somme2 d'ailleurs ? tu as dû te planter en postant. Bon je corrige...

ocamlc sans option -> 24k
avec -custom (=inclut la machine virtuelle) -> 144k
ocamlopt (natif) (win32) -> 125k. Hum, c'est gros.
Ah oui mais l'autre tu l'as strippé... bon, strip -> 69k. Je me disais aussi. Mais enfin ça reste gros. (moi pour le C j'ai 3 Ko et non 30 ??) Problème de stub je suppose, vu que le prg est minuscule...

Bon pour la vitesse j'ai pas le temps de faire un bench sérieux, j'ai pas de chrono rien, mais c'est autour de 15 secondes dans les 2 cas avec une valeur de 100000. Donc voici le code que j'ai utilisé :
en C :

#include <stdio.h>

int somme (int n) {
  int s = 0;
  int i;
  for (i = 1; i <= n; i++)
    s = s + i;
  return s;
}

int somme2 (int n) {
  int s = 0;
  int i;
  for (i = 1; i <= n; i++)
    s = s + somme(i);
  return s;
}

int main () {
  printf ("%d", somme2 (100000));
}

En caml :

let somme n = 
  let s = ref(0) in
  for i = 1 to n do 
    s := !s + i
  done; !s
let somme2 n = 
  let s = ref(0) in 
  for i = 1 to n do 
    s:= !s + somme i 
  done; !s
let _ = print_int (somme2 100000)

Mais je signale que sa version de GCC (2.85??? Je pense que ça doit être 2.95) est elle aussi préhistorique.