Quel langage? - Page 4

Moi j'ai commencé par le basic, est ça m'a bien aidé pour la prog C . Commencer par le C est bcp plus difficile, parce qu'il te faut plein de notions que tu n'as pas quand tu commences à programmer. En BASIC (A part pour les crétins finis), tu fais évoluer ton style de programmation au fur et à mesure que tu programmes des trucs plus complexes, et au final, pour passer au C, le plus difficile sera d'assimiler la notion de pointeur ().

Personnellement, ça a été BASIC (QBASIC, VB, TI-BASIC) -> ASM 68k -> C. Et ensuite le C++ et le Java à l'université.

j'ai les mêmes origines que kevin

Lesquels?

Par exemple, le compilateur d'Intel fait du très bon code.

Non! Demande-toi pourquoi tant de gens programment en C et pas en O'Caml?

Pour la même raison que les OS n'ont pas fait d'avancée conceptuelle fondamentale depuis 30 ans (sauf Hurd?). Pour la même raison que l'informatique théorique a une avance gigantesque sur la pratique : parce que l'info est un domaine extrêmement conservateur, où on préfère utiliser des vieilleries préhistoriques comme le C (en les rafistolant plus ou moins au fil des années) plutôt que d'évoluer vraiment.

Le Caml est un langage trop en avance pour s'imposer largement, mais il a quand même son petit succès

Et ben, goto est un idiome util et expressif.

En assembleur, oui.
Dans un langage évolué, non.

De toute façon, en caml, il n'y a pas de discussion possible : goto n'est pas interdit pour le plaisir d'interdire, mais parce qu'il n'a aucun sens dans un langage fonctionnel comme celui ci.

Il a d'exotique que pratiquement plus personne ne l'utilise ailleurs que dans l'environnement Delphi de nos jours.

Pascal a donc de banal que plein de gens l'utilise aujourd'hui avec Delphi.

Soit (le BASIC est bien pour débuter ), mais le Caml a aussi ses symboles d'opérateurs bizarres!

Bof, non.
Le maximum de bizarrerie qu'on pourrait trouver, ce serait les opérateurs à point pour manipuler les réels (+. /. etc). Le reste est assez classique

Rien à voir à la pléthore de symboles étranges du C (++, &, <<=, *). Note que je ne critique pas du tout ces symboles, ils donnent son efficacité au C. Mais ce n'est pas forcément limpide pour le débutant.

C'est soit un langage avec des mots longs à taper et qui donnent des sources énormes (BASIC, Pascal, ADA), soit un langage avec une syntaxe qui nécessite un peu d'habitude (C etc.).

Ou alors c'est un langage à la fois compact, avec des mots courts, et doté d'une syntaxe simple et lisible, comme le Caml.

mais ce n'est pas naturel du tout, ni en Mathématiques de base, ni en Informatique.

C'est d'un naturel transparent, à la fois en maths, en informatique et dans la pratique pour le débutant.

Sa lenteur, tu veux dire.

Tu as bien lu : sa vitesse

Le C est plus rapide!

Le caml est à peu près aussi rapide.
Et je te parle d'un vrai langage, pas d'un proto-assembleur

Les fonctionnalités "sales" ne sont pas "fausses"! Il y a une grosse différence là.

Les fonctionnalités "sales" sont "sales". Elles donnent des programmes incorrects, buggués et indébuggables, impossibles à entretenir et non portables.
Les programmeurs qui codent en C comme des singes sont un fléau.

Ce n'est pas parce que monsieur Dijkstra a dit que goto est nul que c'est le cas! Dijkstra était un excellent informaticien, mais ça n'empêche pas qu'il ait dit de plein de choses utiles qu'elles étaient "nulles" parce qu'il ne les aimait pas pour une raison ou pour une autre. Suivre la doctrine des "grands" sans réfléchir est une attitude stupide qui a mené à des crimes contre l'humanité comme l'inquisition...

Heureusement je n'ai pas attendu Djiskstra pour bannir goto de mon vocabulaire. A vrai dire, je ne connaissais pas ses positions sur ce point. c'est un monsieur très sensé.

les conversions entiers<->flottants sont automatiques, et heureusement!

Quelle horreur!!

Et puis la déclaration à l'intérieur du code style C99/C++ n'est pas si différente de ça...

C'est l'une des raisons qui font que pour moi le C peut être très sale (alors que c'est interdit en Pascal).

arghhh je sors de l'EFREI (l'école où sont palp, RAGE2K, etan21 et technic) et j'ai jamais entendu parler de caml autrepart qu'ici !!!!!!

Pour la même raison que les OS n'ont pas fait d'avancée conceptuelle fondamentale depuis 30 ans (sauf Hurd?).Pour la même raison que l'informatique théorique a une avance gigantesque sur la pratique : parce que l'info est un domaine extrêmement conservateur

Hum ça sent fort le TROLL !!!

Si le C a tant de succès et que le caml n'est utilisé que dans le milieu scolaire français (et encore dans quelques écoles seulement), c'est qu'il y a peut-être des raisons !!!!!

Et pourtant ... Einstein a bien réussi à imposer ses idées alors que quasiment personne ne comprenait ses théories !!!!

Si le C a tant de succès, c'est qu'il y a peut-être des raisons !!!!!

J'ai donné ces raisons.

Einstein a bien réussi à imposer ses idées alors que quasiment personne ne comprenait ses théories !!!!

Einstein a fait de l'informatique?

Kevin Kofler :
Les fonctions qui retournent des fonctions...

Les fonctions qui retournent des fonctions...

jcop
: Et pourtant ... Einstein a bien réussi à imposer ses idées alors que quasiment personne ne comprenait ses théories !!!!

C'est débile ce que tu dis Et Galilée, alors ?

C'est vrai qu'il y a des domaines en info qui ont peu voire pas évolué depuis 30 ans. Mais c'est parce que ça a fait ses preuves !

Sinon j'aimerais savoir ce que "l'informatique théorique" a d'avance sur "l'informatique pratique" ! L'INRIA nous cacherait des trucs ? Genre un processeur dont le fonctionnement serait radialement différent ?

Moumon > le problème c'est qu'à l'époque de Galilée tout le monde était inculte et ne croyait qu'à la bible ...

C'est pourtant évident !!
On utilise des OS dont les concepts ont 30 ans et n'ont guère évolué depuis, on utilise des langages archaïques idem. Alors qu'on dispose de techniques avancées, par exemple de démonstrations de programmes, des abstractions plus puissantes... Mais l'informatique concrète ne suis pas. Il est impossible de faire avancer radicalement les choses, parce que les systèmes existant sont quand même "suffisament" bons pour s'en contenter.


Je cite ici des réflexions qui ne sont pas de moi (forum ens), et qui concernent le système UNIX :

* Je ne vois pas pourquoi on devrait tolérer que, si je décide de
fournir à Duchnock (un de mes amis) un compte sur ma machine
(c'est-à-dire le droit de l'utiliser - à distance, typiquement) je
devrais automatiquement lui fournir le droit de DoSer cette machine,
ou même de ralentir plus que de <tant> (un nombre fixé par moi pour
Duchnock précisément) les choses que je fais sur cette machine,
*quelle que soit* la manière dont il s'y prendrait. (Le problème
technique souligné ici est la faible résistance d'Unix fasse aux
DoS, due à l'absence de comptabilité précise par classes du
scheduling.)

* Je ne vois pas pourquoi on devrait tolérer que, si je lance des
opérations bourrines en accès disque sur ma machine, ça devrait
perturber le plus légèrement la lecture de fichiers son que j'ai
lancée en fond. (Le problème technique souligné ici est l'absence
de scheduling sur les périphériques externes comme les contrôleurs
IDE et l'absence de capacités hard-real-time d'Unix.)

* Je ne vois pas pourquoi on devrait tolérer que, si j'upgrade
l'application Machin pendant que Machin tourne (et accède dans tous
les sens à ses fichiers de configuration), Machin puisse être
perturbée par l'upgrade. (Le problème technique souligné ici est
l'absence de vraies transactions fiables et visibles au niveau
utilisateur dans le filesystem. Noter que même le simple fait de
faire deux déplacement simultanés et atomiques de fichiers n'est pas
possible sous Unix - hallucinant !)

* Je ne vois pas pourquoi on devrait tolérer que le lancement d'un
nombre raisonnable, disons 3·10^5, de tâches simultanées (ce n'est
pas grand-chose pour une machine censément capable de traiter 104
fois ce nombre d'opérations élémentaires en une seconde) puisse
gêner le système, notamment le bon déroulement d'autres tâches sur
le système, ou rencontrer des limites arbitraires. (Le problème
technique souligné ici est la présence de tables foireuses de taille
limitée dans le noyau, et d'ailleurs le concept général de « mémoire
noyau », de tables statiques de données, etc.)

* Je ne vois pas pourquoi on devrait tolérer que, si <n> personnes
veulent travailler en commun sur un projet sur une machine, elles
doivent demander à l'administrateur de cette machine des manoeuvres
spécifiques comme la création d'un « groupe ». (Le problème
technique souligné ici est l'extraordinaire limitation du système de
permissions d'Unix ; les ACL sont ou seraient un net progrès, mais
il reste des choses criticables à ce chapitre dans un Unix avec
ACL.)

* Je ne vois pas pourquoi on devrait tolérer que, si je veux donner à
un sous-ensemble de mes fichiers un accès plus restreint à moi-même,
mais sans cryptographie, (i.e. il faudrait taper un nouveau mot de
passe spécifique pour accéder à ces fichiers), je dois demander des
opérations spéciales à l'administrateur de la machine, et encore,
même avec son concours ce n'est pas génial. (Le problème technique
souligné ici est l'absence de véritables tokens négociables et
hiérarchisable de sécurité, un peu comme dans le point précédent.)

* Je ne vois pas pourquoi on devrait tolérer que, si un ami me fournit
une image, disons, iso9660, contenant des fichiers, j'aie besoin de
privilèges spéciaux ou d'employer des utilitaires peu commodes pour
faire les opérations normales de lecture, copie, etc, des fichiers
contenus dans l'image. (Le problème technique souligné ici est
l'absence de fs manipulables proprement en userland complet. Ce
problème est un peu soulagé, comme plusieurs des précédents,
d'ailleurs, par l'existence de User-Mode Linux, mais ce n'est pas
encore terrible, loin de là.)

* Speaking of which, je ne vois pas pourquoi on m'impose d'organiser
mes fichiers selon un arbre hiérarchique plutôt qu'un Web abstrait
si cela correspond mieux à mon souhait d'organisation mentale. (Le
problème technique souligné ici est l'imposition d'un filesystem
hiérarchique envahissant et user-visible de façon insistante.)

* Je ne vois pas pourquoi on m'imposerait, si j'ai quinze machines à
ma disposition, de décider moi-même sur laquelle je veux que mes
programmes tournent (ben patate - sur la plus puissante qui est
disponible ! et de la façon la plus efficace possible !) ou sur
quel disque je veux que mes fichiers soient stockés. (Le problème
technique souligné ici est l'absence de fonctionnalités distribuées
d'Unix.)

* Je ne vois pas pourquoi on me force à distinguer des choses appelées
« programmes » et d'autres appelées « fonction(nalités) » de ces
programmes : par exemple, j'ai beau avoir un programme gimp qui fait
certaines choses et un browser Mozilla qui en fait d'autres, je ne
peux pas trivialement placer dans les menus de Mozilla des fonctions
de gimp. (Cela peut sembler ne pas être un problème d'Unix, ça, et
il est vrai qu'il est très vaste et dépasse largement le cadre des
limitations d'Unix. Mais le fait qu'Unix impose à ses processus une
vision si étroite les uns des autres et une communication aussi
pauvre, cela n'aide *vraiment* pas à résoudre ce genre de
problèmes.)

* Je ne vois pas pourquoi je devrais accepter, quand je programme,
toutes sortes de limitations bizarres et fumées sur la gestion des
événements asynchrones. (« Thou shalt not call malloc() from a
signal handler or great evil shall betide thee... » et autres
âneries. Le problème technique souligné ici est qu'Unix est
totalement merdique dans sa gestion de tout ce qui est asynchrone -
à tel point que certains vont jusqu'à recommander de ne pas utiliser
de threads, ce qui est quand même le monde à l'envers - et impose
des sérialisations totalement débiles et crades, ou une gestion
débile des exceptions.)

* Je ne vois pas pourquoi je devrais accepter, quand je veux éteindre
mon ordinateur, de faire autre chose que simplement appuyer sur le
bouton Power (dans la mesure où le matériel le supporte...) et,
quand je le rallume, de ne pas retrouver (si je le souhaite !) ma
session dans l'état exact où je l'avais laissé. (Le problème
technique souligné ici est l'absence de persistence des structures
Unix autres que le filesystem, et encore. Noter cependant que pour
un portable on s'en sort - au prix cependant d'un effort particulier
du matériel.)

* Je ne vois pas pourquoi Unix ne devrait pas tourner *et offrir de
complètes garanties de protection et de sécurité* sur mon 8088 ou ma
calculatrice sous prétexte que leur processeur n'a pas d'unité de
protection mémoire ; en clair, sous prétexte que les concepteurs
d'Unix étaient trop bêtes ou trop ignorants pour faire les choses en
logiciel donc ont cru bon de les faire faire au matériel. (Là, il y
a un bout de troll, mais le problème technique quand même souligné
est l'absence de vrais modèles mathématiques de la sécurité dans
Unix, qui fait vaguement confiance à des composantes matérielles au
lieu de demander des preuves négociables de sécurité.)

* Je ne vois pas pourquoi sous prétexte que les programmeurs de mon
logiciel d'échange de mails sont des abrutis incapables de
programmer sans faute et qu'ils ont fait un trou de sécurité dans le
dit programmeje devrais craindre pour *autre chose* que pour la
gestion des mails sur ma machine - genre, pour mes fichiers
personnels. (Le problème technique souligné ici est l'absence de
sandboxing satisfaisant dans Unix.)

(...) Je tiens à souligner qu'on « sait »
faire tout ce que j'ai évoqué ci-dessus, je ne demande pas des choses
utopiques, et même la plupart des points ont des proofs-of-concept,
mais ces systèmes expérimentaux ne sont pas vraiment développés car
les programmeurs se tournent tous vers Unix, donc non seulement Unix
est insatisfaisant mais il fait même du mal au développement de systèmes meilleurs car il est « assez bon »...

Linux 2.6 fait beaucoup de ces choses très bien. Par exemple, avec SELinux (inclus dans Linux 2.6), on a ACLs, sandboxing de programmes (y compris "limiter l'accès à 'soi-même', c'est-à-dire à certains programmes sous son propre compte utilisateur") etc.
Quant à placer les menus d'une application dans une autre, il y a un OS existant qui fait ça très bien: Windows! Cf. OLE2. Mais sous Linux, il y a aussi des technologies équivalentes comme KParts. Malheureusement sous-utilisées.
Quant à tourner sans MMU, il y a ucLinux. Évidemment, si un programme écrit par dessus la mémoire du noyau, exit la sécurité. Mais il n'y a pas de solution autre que de tout faire tourner dans une machine virtuelle (ce qui est leeent, surtout sur un 8088 ).

Bref, ils essayent bien de règler tous ces problèmes, et sont déjà bien avancés sur certains. Seulement, dans le monde réel, il y a des considérations de compatibilité antérieure à faire qu'il n'y a pas dans la théorie pure.

Pour l'histoire des transactions atomiques, c'est un problème théorique seulement. J'ai toujours fait mes apt-get dist-upgrade en pleine utilisation du système, et je n'ai jamais eu de problèmes avec ça.

Hippohmu
:

Lesquels?

Par exemple, le compilateur d'Intel fait du très bon code.

Et celui de GCC est tout à fait comparable. (Sur x86. Sur Itanic, c'est autre chose, mais c'est une architecture qui n'arrivera nulle part de toute façon, l'AMD64 a gagné, même Intel s'y met.)

Non! Demande-toi pourquoi tant de gens programment en C et pas en O'Caml?

Pour la même raison que les OS n'ont pas fait d'avancée conceptuelle fondamentale depuis 30 ans (sauf Hurd?). Pour la même raison que l'informatique théorique a une avance gigantesque sur la pratique : parce que l'info est un domaine extrêmement conservateur, où on préfère utiliser des vieilleries préhistoriques comme le C (en les rafistolant plus ou moins au fil des années) plutôt que d'évoluer vraiment.

Cf. ma réponse à ta longue citation.

Le Caml est un langage trop en avance pour s'imposer largement, mais il a quand même son petit succès

C'est toujours l'excuse de ceux qui n'arrivent pas à s'imposer: "On est trop en avance sur notre temps."

Et ben, goto est un idiome util et expressif.

En assembleur, oui. Dans un langage évolué, non.

Dans un langage impératif évolué, oui. Mais tu sembles avoir très peu d'expertise en programmation impérative...

De toute façon, en caml, il n'y a pas de discussion possible : goto n'est pas interdit pour le plaisir d'interdire, mais parce qu'il n'a aucun sens dans un langage fonctionnel comme celui ci.

Si j'ai le choix entre des trucs bizarres comme les fonctions en valeur de retour et un truc solide et pratique comme goto, mon choix est vite fait. (Indice: Ce n'est pas le même que le tien. )

Il a d'exotique que pratiquement plus personne ne l'utilise ailleurs que dans l'environnement Delphi de nos jours.

Pascal a donc de banal que plein de gens l'utilise aujourd'hui avec Delphi.

Soit. Mais ma conclusion reste valable: Delphi est le seul compilateur Pascal utilisé en pratique, il n'est pas portable, et le langage qu'il comprend est un dialecte du Pascal que les autres compilateurs ne comprennent pas, donc le Pascal n'est pas un langage portable en pratique.

Soit (le BASIC est bien pour débuter ), mais le Caml a aussi ses symboles d'opérateurs bizarres!

Bof, non. Le maximum de bizarrerie qu'on pourrait trouver, ce serait les opérateurs à point pour manipuler les réels (+. /. etc). Le reste est assez classique

Moi, dans vos snippets de code, je vois bien plus de symboles auxquels il faut s'habituer: ' -> | etc. Pour toi, ces symboles sont habituels parce que tu les utilises tout le temps. C'est la même chose pour moi (et d'autres programmeurs C) avec << et >>.

Rien à voir à la pléthore de symboles étranges du C (++, &, <<=, *). Note que je ne critique pas du tout ces symboles, ils donnent son efficacité au C. Mais ce n'est pas forcément limpide pour le débutant.

Le Caml non plus.

C'est soit un langage avec des mots longs à taper et qui donnent des sources énormes (BASIC, Pascal, ADA), soit un langage avec une syntaxe qui nécessite un peu d'habitude (C etc.).

Ou alors c'est un langage à la fois compact, avec des mots courts, et doté d'une syntaxe simple et lisible, comme le Caml.

Il n'y a pas que des mots, il y a aussi des symboles!
Certes, il y a let écrit en entier, mais pour le reste...

Sa lenteur, tu veux dire.

Tu as bien lu : sa vitesse

Le C est plus rapide!

Le caml est à peu près aussi rapide.
Et je te parle d'un vrai langage, pas d'un proto-assembleur

Le C est un vrai langage!
Il est "de moyen niveau", c'est-à-dire qu'il réunit les avantages d'un langage de haut niveau avec ceux de l'assembleur.

Les fonctionnalités "sales" ne sont pas "fausses"! Il y a une grosse différence là.

Les fonctionnalités "sales" sont "sales". Elles donnent des programmes incorrects, buggués et indébuggables, impossibles à entretenir et non portables.

C'est ce que le lavage de cerveau de la secte anti-goto laisse croire. Mais c'est faux. Évidemment qu'on peut abuser de ces fonctionnalités de manière à donner des programmes illisibles, bogués etc. Mais si on sait bien programmer, on peut au contraire les utiliser pour donner des programmes plus courts, et donc plus simples, plus lisibles et moins bogués!

Les programmeurs qui codent en C comme des singes sont un fléau.

Les programmeurs qui programment comme des porcs sont toujours un problème, même dans le langage le plus restrictif au monde. Si on programme comme un porc, le problème est là, pas dans le langage.

Ce n'est pas parce que monsieur Dijkstra a dit que goto est nul que c'est le cas! Dijkstra était un excellent informaticien, mais ça n'empêche pas qu'il ait dit de plein de choses utiles qu'elles étaient "nulles" parce qu'il ne les aimait pas pour une raison ou pour une autre. Suivre la doctrine des "grands" sans réfléchir est une attitude stupide qui a mené à des crimes contre l'humanité comme l'inquisition...

Heureusement je n'ai pas attendu Djiskstra pour bannir goto de mon vocabulaire. A vrai dire, je ne connaissais pas ses positions sur ce point. c'est un monsieur très sensé.

N'essaye pas de me raconter que tu as eu ces idées dogmatiques tout seul, sans que personne ne t'ait jamais rien dit à ce sujet! L'antigotoisme est une idée reçue...

les conversions entiers<->flottants sont automatiques, et heureusement!

Quelle horreur!!

Ben, ce sont des nombres (plus précisément des réels) des 2 côtés! Pourquoi ne devrait-on pas pouvoir les assigner?!

plus courts, et donc plus simples, plus lisibles et moins bogués!

Ca n'est pas logique comme relation. C'est pas parce que c'est plus court que c'est plus simple, encore moins que c'est plus lisible, et je ne vois pas du tout le rapport avec moins buggé . A la rigueur, le seul avantage de faire un programme plus court est qu'il prend moins d'espace sur le disque dans son format source . Mais un programme en C très court peut être extremement complexe, illisible, buggé, et plus lent à compiler (par contre, il y a de fortes chances qu'il soit moins lent à parser ²).
Sinon, la gestion des ACL sous Linux est *merdique*. On a d'ailleurs l'impression en les utilisant qu'elle n'est là que pour une certaine compatibilité avec Windows, et qu'elle est posée à la façon d'une cerise sur une choucroute.
Pour revenir au Pascal, le Delphi est totalement compatible avec le Pascal Objet. Le seul mot clé à changer est class <-> object (ce qui est - c'est vrai - une hérésie). Après, c'est certain que toutes les classes ne peuvent pas être dispos sur toutes les plateformes, mais ça, c'est pareil dans tous les langages (Même le Java, mais je ne vais pas m'étendre là dessus. Mon point de vue est assez proche de Kevin sur ce point).

Kevin Kofler
: Et celui de GCC est tout à fait comparable. (Sur x86. Sur Itanic, c'est autre chose, mais c'est une architecture qui n'arrivera nulle part de toute façon, l'AMD64 a gagné, même Intel s'y met.)

Bah, je ne nie pas que gcc est un des plus importants compilateurs. Simplement il n'est ni aussi parfait ni aussi irremplaçable qu'on voudrait le faire croire.

C'est toujours l'excuse de ceux qui n'arrivent pas à s'imposer: "On est trop en avance sur notre temps."

Il arrive parfois à s'imposer :
http://caml.inria.fr/contests-eng.html

Dans un langage impératif évolué, oui. Mais tu sembles avoir très peu d'expertise en programmation impérative...

s/Hippohmu/Kevin Kofler/
s/impérative/fonctionnelle/

Si j'ai le choix entre des trucs bizarres comme les fonctions en valeur de retour et un truc solide et pratique comme goto, mon choix est vite fait. (Indice: Ce n'est pas le même que le tien.)

Errare Humanum Est.

Perseverare Diabolicum.

Moi, dans vos snippets de code, je vois bien plus de symboles auxquels il faut s'habituer: ' -> | etc. Pour toi, ces symboles sont habituels parce que tu les utilises tout le temps.

Je crois assez naturel, même pour un débutant, qu'une fonction qui à 1 associe 15 s'écrive 1 -> 15.

C'est la même chose pour moi (et d'autres programmeurs C) avec << et >>.

C'est tout de même moins évident. Ca suppose par exemple de connaître un peu l'écriture binaire, la représentation interne des nombres.

Le Caml non plus.

La première fois où j'ai lu du caml, j'ai trouvé ça plus lisible que la première fois où j'ai lu du C.

Il n'y a pas que des mots, il y a aussi des symboles!
Certes, il y a let écrit en entier, mais pour le reste...

Le reste quoi?

Le C est
un vrai langage! Il est "de moyen niveau", c'est-à-dire qu'il réunit les avantages d'un langage de haut niveau avec ceux de l'assembleur.

Non, il garde les désavantages de l'assembleur (presque pas de typage, pas de chaînes de caractères ou autres structures de données évoluées, des goto, peu d'outils de haut niveau) avec une syntaxe qui essaie de se détacher de la rudesse de l'assembleur, mais qui reste très rustique.

C'est ce que le lavage de cerveau de la secte anti-goto laisse croire. Mais c'est faux. Évidemment qu'on peut abuser de ces fonctionnalités de manière à donner des programmes illisibles, bogués etc. Mais si on sait bien programmer, on peut au contraire les utiliser pour donner des programmes plus courts, et donc plus simples, plus lisibles et moins bogués!

Si tu rêves de faire des programmes plus courts, plus simples, plus lisibles et moins bogués, tu devrais plutôt programmer en Caml
En outre tu pourrais ainsi te passer du goto : c'est vraiment le paradis!

Les programmeurs qui programment comme des porcs sont toujours un problème, même dans le langage le plus restrictif au monde. Si on programme comme un porc, le problème est là, pas dans le langage.

Le problème est dans le laxisme du langage, qui autorise tous les abus.

N'essaye pas de me raconter que tu as eu ces idées dogmatiques tout seul, sans que personne ne t'ait jamais rien dit à ce sujet! L'antigotoisme est une idée reçue...

C'est une idée vraie, donc que chaque émettre peut émettre tout seul.

Ben, ce sont des nombres (plus précisément des réels) des 2 côtés! Pourquoi ne devrait-on pas pouvoir les assigner?!

Je suis d'accord pour transtyper automatiquement des entiers entre eux, ou des réels entre eux (pas dans les langages très fortement typés comme caml, bien sûr!)

Mais entre réels et entiers, celà pose à mon avis des gros problèmes. Mathématiquement, bien sûr, l'ensemble des entiers est inclus dans celui des réels. Mais un entier informatique n'est PAS un entier mathématique, et un réel informatique n'est PAS non plus un réel mathématique.

Informatiquement, l'ensemble des entiers est le plus souvent un anneau Z/nZ, avec n=2^8, 2^16, 2^32.... Alors que l'ensemble des réels informatiques a une structure totalement différente, ce n'est même pas un anneau, et il n'y a aucune espèce de morphisme entre les deux ensembles.

Qui plus est, du point de vue de l'implémentation, les deux types sont codés en mémoire de façon complètement différente, et les instructions assembleur pour les manipuler sont elles aussi complètement différentes. Les vitesses de calcul sont aussi totalement différentes.

Bref, je considère plus sain de différentier correctement ces deux types de données, qui n'ont rien à voir en interne.

moi le langage le plus simple que j'ai trouvé c'est bien le C !!!!

Je crois assez naturel, même pour un débutant, qu'une fonction qui à 1 associe 15 s'écrive 1 -> 15.

déjà là je bloque... 1 -> 15 ça n'a pas de sens pour moi.

Ben c'est comme en maths 1->15 <=> f(1)=15

A 1, la fonction associe 15.
On écrit ça "1, flèche, 15"... Notation d'une profonde subtilité, accessible seulement à l'élite...

Kevin Kofler :
Tu n'as pas encore plus compliqué pour débuter?

Caml n'est pas compliqué, il est complexe. Et tu n'as pas du tout besoin d'en maîtriser toute la complexité pour y programmer. Je pense que c'est un très bon langage pour débuter, notamment pour cette raison.

Les fonctions qui retournent des fonctions...

moui mais bien sûr, quand Hippo dit « les goto... » il est dogmatique et borné, et là toi tu es quoi... ?
Non en fait je ne comprends pas très bien où tu veux en venir... personne ne t'oblige à faire des fonctions qui retournent des fonctions, et d'autre part en C tu peux retourner des pointeurs vers des fonctions non ?
Bon je crois que je vois ce qui te dérange : c'est les fonctions à plusieurs variables ? mais encore une fois il n'est pas du tout nécessaire d'avoir compris en détail le principe de la curryfication (euh c'est bien ça le mot ?) et des applications partielles pour utiliser ces fonctions ! les applications partielles, c'est très puissant et souvent pratique mais je suis d'accord qu'il ne faut pas commencer par là, en attendant il te suffit d'admettre comme un simple choix de notation le fait que les types des fonctions de plusieurs variables se notent avec des flèches partout et d'apprendre la syntaxe --- peut-être un tout petit peu inhabituelle, mais franchement pas compliquée hein --- de l'application de ces fonctions comme si c'était un choix arbitraire. Tu as tout le temps, plus tard, de comprendre pourquoi c'est comme ça, ce que ça cache (des fonctions qui retournent des fonctions) et surtout ce que ça permet.
Sinon, à propos du fait plus général que les fonctions sont des valeurs comme les autres :
--- je ne vois vraiment pas pourquoi on restreindrait artificiellement ce qu'on a le droit de faire avec des fonctions. D'ailleurs :

Oui, c'est nul, les langages qui limitent l'expressivité avec des excuses du style "ce n'est pas propre"!

-> c'est nul, les langages qui limitent l'expressivité avec des excuses du style "ah oui, mais une fonction c'est pas pareil tu comprends, alors tu ne fais pas n'importe quoi avec."
--- y a des langages (dont caml, oui, mais d'autres aussi) qui considèrent les *objets* comme des valeurs ordinaires... et un objet est quelque chose de beaucoup plus compliqué qu'une fonction.
--- il est souvent très utile de passer des fonctions en paramètre, typiquement à une fonction de tri tu vas passer une fonction de comparaison... et il y a même ça dans la bibliothèque standard du C... tu n'utilises jamais les pointeurs vers les fonctions en C ? si ? mais alors qu'est-ce qui te choque exactement ? le fait qu'on puisse définir des fonctions locales à la volée ? là c'est sûr que si on peut le faire en C, je ne sais pas comment et c'est sans doute lourd voire de l'ordre du hack. Donc, quoi ? c'est l'expressivité et la puissance du langage qui te gênent ? tu es jaloux en fait, c'est ça ? "quelle horreur, ça permet de faire des trucs qu'on ne peut pas faire en C".
Enfin bref, très sérieusement je ne comprends *vraiment* pas ta remarque. Comment peux-tu présenter une possibilité offerte par le langage comme un défaut, alors que tu es libre de ne pas utiliser cette possibilité si elle ne te plaît pas ?

"[D]éfinir des fonctions locales à la volée" en C? Tu veux dire comme ça:

#define fwrite(p,s,n,f) (((unsigned(*)(int(*)(int,FILE*),void*,int,int, \
  FILE*))(int[]){0x4E56,0,0x48E7,0x1F38,0x286E,8,0x246E,12,0x3A2E,16,0x3C2E, \
  18,0x266E,20,0x3E2B,10,0x3207,0x41,0x40,0x3741,10,0x4244,0xBC44,0x6322, \
  0x4243,0xBA43,0x6316,0x2F0B,0x121A,0x4881,0x3F01,0x4E94,0x5C8F,0x4A40, \
  0x6D0C,0x5243,0xBA43,0x62EA,0x5244,0xBC44,0x62DE,0x3747,10,0x3004,0x4CEE, \
  0x1CF8,0xFFE0,0x4E5E,0x4E75})(fputc,p,s,n,f))

Ce "bijou" est extraît d'une ancienne TIGCCLIB...

Tu comprendras pourquoi ça a été viré dans les versions actuelles (au profit de tigcc.a).

Et le problème de pouvoir utiliser une fonction comme toute autre variable: Ben, déjà que ça présuppose qu'on puisse exécuter du code à un endroit modifiable dynamiquement (pile, heap etc.). Ce n'est pas le cas sur TI-89/92+/V200 par exemple. Ce même style de présupposition est fait par GCC pour les "trampolines" des "nested functions", ce qui fait que je suis obligé d'émettre un warning dans GCC pour rappeler au programmeur de définir EXECUTE_IN_GHOST_SPACE. (Il faudra d'ailleurs que je remplace ça par une auto-importation utilisant le nouveau linker.) (Pour le code du message 110, il marche parce que la fonction "générée à la volée" ne l'est pas vraiment, elle est constante et donc émise avec le code par TIGCC.) Et si ce hack non-documenté n'existait pas, on ferait quoi? Ben, on ne pourrait pas supporter cette feature du tout. Et c'est la même chose pour les fonctions des langages fonctionnels. Franchement, j'ai marre de ce genre de présuppositions non-portables.

[EDIT: /s/assomption/présupposition/g/]

Oui, je suis d'accord que caml est inadapté à des petites machines telles que des calculatrices, bien sûr. Enfin bon, c'est quand même portable, dans certaines limites (et franchement, qu'est-ce qui est portable sans *aucune* limite ? même un programme en C ansi tu trouveras toujours des plateformes baroques sur lesquelles il ne tourne pas. Et quand on utilise une machine qui a des possibilités, il serait dommage de ne pas les utiliser parce que ce n'est pas portable non ? je pense que connaître le C est utile, mais pour commencer un langage de plus haut niveau est meilleur : il te permet de te concentrer sur le programme lui-même sans t'arracher les cheveux sur des détails d'implémentation.
Sinon, il me semble t'avoir déjà dit que l'Assomption c'est quand la Vierge monte au ciel . Je ne vois pas très bien le rapport avec les fonctions qui retournent des fonctions .
Quand je parle de définir des fonctions à la volée je pense à quelque chose comme ça par exemple : let machaine = "Hello world" in button#connect#clicked ~callbackfun () -> print_endline machaine)

[troll]Ah non, on réussit à donner à "baroque" un sens noble et toi tu persistes à l'utiliser dans le sens péjoratif...[/troll]

bon ok s/aroqu/yzarr

De toute façon, je ne vois pas pourquoi utiliser une fonction comme toute autre variable, "ça présuppose qu'on puisse exécuter du code à un endroit modifiable dynamiquement"...

Le langage que voulait développer Thibaut à une époque pour TI était une sorte de pascal fonctionnel aussi, non ? (ah non, il me semble que c'était l'inverse, que c'était tout en déclaratif et on déclarait les fonctions comme des variables). Ah, et le nom me revient : l'Azur (une dédicace à Alizée ? ).

Sally :
Sinon, il me semble t'avoir déjà dit que l'Assomption c'est quand la Vierge monte au ciel . Je ne vois pas très bien le rapport avec les fonctions qui retournent des fonctions .

Mon usage de "assomption" est un anglicisme au même titre que ton usage de "baroque".
Mais j'ai corrigé l'erreur.

Et d'ailleurs, <SARCASM>ma chère demoiselle</SARCASM>, "bizarre" s'écrit avec un "i"!