La forme forte est réfuté car les humains sont capables de se représenter des concepts et de faire des raisonnements quand bien même ils ne possèdent pas de vocabulaire ou de langues adaptées. Ce qui indiquerait que le cerveau n'utilise pas forcement le langage pour manipuler les concepts.
Ça ressemble plus à un indice contre l'hypothèse qu'à une réfutation formelle. Il est possible que notre langage influe sur la manière dont on pense et qu'on soit quand même capable de penser des choses difficiles à formuler dans notre langage.
Je n'y ai pas réfléchi en détails, mais je prend un exemple de ce qui me reste de mes souvenirs de Lojban. Il y a dans le langage une manière naturelle d'exprimer "à droite de X, qui me fait face", ou bien "à gauche de X, qui fait face à Y". Évidemment, on est capable de concevoir "à gauche de X qui fait face à Y" et de le traduire en position, mais ça demande toujours un temps de réflexion, et de nombreuses personnes ont du mal à imaginer les rotations d'objets ou de point de vue[1]. Il me semble que si ces gens parlaient une langue qui utilise ce genre d'indicateurs de position aussi naturellement que "à ma gauche", leur capacité de faire des rotations mentales serait plus développée. (Ou alors c'est une limite biologique et ils auraient du mal à comprendre les phrases, mais ça me semble moins probable.)
[1]: il me semble qu'on se sert d'ailleurs de ça dans certains tests psychologiques ou tests de QI: on montre une image de main et on demande si c'est une main gauche ou une main droite. Ou bien on demande "parmis ces images, laquelle est une rotation de cet objet ?".
La syntaxe n'a qu'un impact mineur sur la lisibilité des programmes.
C'est tellement peu conforme à mon intuition et à mon expérience personnelle que je ne sais pas vraiment comment y répondre.
On pourrait prendre un cas extrême inspiré du langage Whitespace. Avec un alphabet comportant uniquement deux caractères, l'espace et le retour à la ligne, on peut tout à fait construire un langage qui permet d'exprimer des concepts de haut niveau. Faut être cinglé pour vouloir faire ça, mais on peut.
D'un autre côté, comme c'est un exemple extrême, ce n'est pas très satisfaisant. Et comme la plupart des langages ont été conçus pour être utilisables par des humains, on ne trouvera pas dans la nature d'exemples flagrants de syntaxe qui rend le code illisible, car la sélection naturelle des programmeurs l'aurait éliminée.
(note, au passage, que je n'ai rien contre la syntaxe de Tom, hein :)
Il y a une théorie[1] selon laquelle le langage que l'on parle détermine la manière dont on pense, et dont on comprend le monde. Je la trouve plutôt convainquante, et je pense que ça s'applique aussi à la programmation. Quand syntaxe d'un langage favorise, par exemple, la déclaration de fonctions anonymes, ou bien la possibilité de currifier[2] une fonction, on a tendance à programmer différemment.
Même si je sais que tous les langages Turing-complets permettent la même chose, je ne peux pas penser que la syntaxe n'a pas d'importance. Il n'y a qu'à voir la différence dans les programmes de résolution d'un problème, si l'un a été codé en impératif et l'autre en fonctionnel. De la même manière, on peut souvent voir lorsqu'un type qui code en C est un programmeur qui a fait du fonctionnel avant, ou de l'objet, ou autre. Le paradigme favorise certains choix, et la syntaxe également.
il ne s'agit que des opérateurs numériques et il suffit de rajouter un point pour la version flottantes, c'est quand même pas trés dur à comprendre et à retenir.
Non, c'est pour tous les opérateurs, sauf ceux de comparaison qui sont polymorphiques. Le langage et la lib de base fournissent peu d'opérateurs, justement parce que l'absence de polymorphisme rendrait pénible d'avoir 27 variantes de "+". Du coup, tu as +, +. et +/ pour additionner les entiers, les flottants et les Nums, et pour les autres types il faut utiliser les fonction du style Type.add.
Dans le même style, et même si ce ne sont pas strictement des opérateurs, tu dois mémoriser que pour décrire une liste c'est [ ... ], pour décrire un vecteur c'est [| ... |]. Pour accéder à un élément d'un vecteur, on utilise .(indice), et pour accéder à un élément d'une chaîne, .[indice], etc.
Chaque point pris individuellement n'est pas dur à mémoriser, c'est la somme des détails qui est lourde. En Ruby, pour additionner deux objets on utilise "+", et pour accéder à un élément dans un truc qui en possède plusieurs, on utilise [indice]. Je comprend la justification derrière le choix d'OCaml, mais je trouve quand même la version ruby plus agréable.
exemples ? Je ne vois pas trop de quoi tu veux parler ...
Difficile de faire une liste précise, je ne mémorise pas les exceptions, c'est bien pour ça qu'elles me posent problème :)
Il me vient, à froid:
- tous les exemples ci-dessus.
- le produit cartésien, pour lequel on peut omettre les parenthèses lorsque ce n'est pas ambigu pour le compilateur, mais j'ai rencontré des cas où c'était ambigu pour mon cerveau limité.
- il y a d'autres cas où les parenthèses peuvent être omises, et ça n'aide pas toujours la lisibilité. Je l'ai dit, j'aime bien le Lisp :)
- Il y a plusieurs manières de déclarer une fonction. Je n'en ai retenu qu'une, mais pour débugguer le code des autres il faut toutes les connaîtres.
- Si on veut faire de l'impératif, on peut délimiter les instructions qui renvoient unit par des points virgule, ou bien on peut écrire let () = expression in ... (il y a peut-être une différence entre les deux, mais je ne la connais pas).
J'ai la flemme d'en chercher d'autre, je n'ai pas pour but de démolir OCaml. Puisque je m'en sers, c'est que je trouve les obstacles surmontables, mais quand même pénibles ;)
Il est légitime de se demander:
[...]
- si le virus n'ira pas infecter d'autres plantes (ex la mauvaise herbe contre laquelle on voulait lutter, ...)
- Encore pire, si le virus ne va pas mutter et contaminer les plantes/animaux/.hommes
Euh... en principe on ne balance pas de virus dans la nature, si ? Il me semble que les semences sont fabriquées en laboratoire, et plantées dans des champs après. On peut certainement imaginer plein de scénarios catastrophe, mais celui du virus mutant qui s'enfuit du laboratoire et qui refile à l'homme le gène qui repousse les limaces me semble peut plausible :)
(Encore que, j'aimerais bien repousser les limaces)
Mouais, sans doute que le C ou Java sont des langages préhistoriques, mais il y a un point où le Caml est encore plus préhistorique : c'est son framework
Mouais, alors si tu compares la lib de base d'OCaml et celle du C, je ne sais pas vraiment qui gagne, mais je penche très fort pour OCaml, puisque la notion de "lib de base" pour le C est quasi inexistante. Pour Java, par contre, d'accord.
Ceci dit, s'il n'y a pas de parser XML, d'interface ODBC, etc. dans la lib de base, tout ça existe quand même. Il manque peut être un repository, je ne sais pas trop, chez moi c'est bien proprement intégré par Debian. Quand j'ai besoin de quelque chose, ça se limite souvent à une recherche dans la base des paquets.
Si des langages comme C# ou Java ont un certains succès, c'est bien parce qu'ils proposent tout un framework utilisable et à peu près bien adapté aux besoins des entreprises d'aujourd'hui, pas d'il y a 15 ans.
Ho ho. Je t'accorde que le seul intérêt de Java, c'est son framework, parce que le langage n'est vraiment pas terrible.
Mais si on se basait sur l'existence de bibliothèques et d'IDE pour juger les langages, Java n'aurait jamais été créé. Du côté des IDE, j'ai commencé à faire du Java avec le bloc note de Windows, et c'était pas joyeux.
quid de l'intégration avec le système hôte ?
open Unix
Quid de l'intégration de Caml dans des IDEs un peu mieux foutu que vi ou emacs ?
Là, j'avoue que je n'en connais pas de mieux foutu qu'Emacs.
Quid d'un framework graphique qui fait autre chose que dessiner des droites et des rectangles ?
C'est triste ce que tu penses de GTK2.
Quid de la doc de tout ça (haha, je rigole d'avance à l'ampleur de la tâche)
Il y a un livre publié par OReilly et diffusé sur le net, qui est très bien foutu, bien qu'un peu dense à mon goût.
Quid des capacités cross-plateformes
Je ne sais pas sur quelles plateformes le compilateur d'OCaml tourne, mais tu peux compiler un programme OCaml en bytecode pour JVM, si tu veux.
Moi je reproche à la syntaxe d'OCaml d'être bourrée d'exceptions. Il y a trop de choses qui sont facultatives "quand c'est évident", ça complique la lecture pour ceux qui ne font parlent pas l'OCaml courrament. Généralement j'ignore les exception et je rajoute des parenthèses facultatives pour clarifier, mais quand je lis du code qui n'est pas le mien, il m'arrive de souffrir.
Dans le même style, le fait d'avoir des opérateurs différents pour la même opération sur des types différents, ça rend la lecture et l'apprentissage difficiles. C'est justifié par l'inférence de types, mais c'est pénible de devoir se souvenir quel est l'opérateur à utiliser pour le type que l'on a.
En même temps, on peut difficilement demander à l'homme, ou à n'importe quelle autre espèce, de ne pas modifier son écosystème en y apparaissant. Je ne vois pas pourquoi l'écosystème d'avant la civilisation serait "le bon", vers lequel on devrait tendre (j'ai l'impression que c'est ce que tu veux dire, mais je me trompe peut-être). J'aime bien les forêts, mais je ne sais pas si la proportion idéal est de 90, 50 ou 20%. Et les villes forment aussi un écosystème.
(Si on se base sur le principe "c'était mieux avant", à l'échelle géologique la vie a été une catastrophe pour la Terre. Avant, la Terre était à 100% sans forêts !)
Ça rajoute à des langages (Java, C...) des structures de contrôle permettant le pattern matching. Si tu connais le "match" d'Ocaml, tu es déjà un fan, sinon tu peux essayer de t'imaginer ça comme une version surpuissante du "switch" de C qui, au lieu de prendre des valeurs après "case" prendrait des motifs.
En gros, avec un compilateur qui va bien, on doit pouvoir se ramener avec un programme écrit en C au même niveau de performance/taille d'exécutable que ce qu'on arrive à faire avec Lisaac?
Probablement pas, parce qu'il est plus facile de descendre que de remonter.
Pour ceux que cette explication ne satisfait pas, je vais essayer de faire mieux mais c'est pas gagné. Quand on écrit un programme dans un langage de haut niveau, les mots et les constructions du langage ont du sens qu'il n'est pas toujours possible de traduire dans le langage de bas niveau. Par exemple, dire qu'une classe hérite d'une autre a un sens si on se place à un certain niveau, mais le code en assembleur qui résulte de la compilation ne contient pas cette information.
Pour retrouver l'information à partir du code de bas niveau, il faut être capable de l'analyser pour "remonter" dans les niveaux. Pour certaines choses, c'est possible, par exemple on peut assez facilement à partir de l'assembleur retrouver des structures de boucle. Mais est-ce toujours possible ?
- Le programme compilé ne contient pas forcément toute l'information. Par exemple la hiérarchie d'héritage des classes ne sera probablement pas représentée en entier ou correctement.
- L'analyse de programme est difficile. Tellement difficile que certaines choses sont impossibles. On ne peut pas, par exemple, faire un programme qui peut analyser n'importe quel programme et dire s'il s'arrête ou s'il boucle indéfiniment. D'un autre côté, je doute qu'il soit possible de faire un langage de haut niveau qui permet d'exprimer qu'un programme boucle sans que le code résultant ne puisse être analysé pour le déduire.
- L'analyse de programme est difficile (bis). Un programme, c'est un graphe assez énorme, et pour "remonter", il faut être capable de découvrir des structures de haut niveau dans ce graphe, ce qui n'est pas évident. Pour prendre un exemple simplifié, prend une feuille de papier, et interroge des gens dans la rue. Pour chaque personne, inscris un rond avec leur nom, et puis si deux personnes se connaissent, relie leurs ronds par un trait. Une fois que c'est fini, essaye de retrouver les familles. Une famille, c'est une structure de haut niveau dans ton graphe des "connaissances", mais c'est incroyablement difficile à retrouver si on n'a pas l'information.
Et faire un ordinateur quantique, contenant du vivant, c'est blasphématoire ?
Je crois que tu confonds ordinateur quantique et ordinateur à ADN. Ou alors tu penses à un ordinateur à chat de schrödinger, mais là on ne peut pas être sûr qu'il contient du vivant avant d'avoir ouvert la boîte, ce qui annule la garantie.
Je crois qu'il parlait du if/else en OCaml. Un des défauts (à mon goût) d'OCaml, c'est que sa grammaire contient beaucoup d'exceptions qui peuvent le rendre difficile à lire pour un humain. La doc contient beaucoup de "quand c'est évident, on peut omettre [...]". Pour ma part, j'aime bien le Lisp, et j'aime bien rajouter des parenthèses en OCaml pour éviter tout doute. Quand on écrit: (if condition then 42 else 0), on ne peut avoir aucun doute.
si des gens veulent avoir la liberté fondamentale de ne PAS subir l'influence d'une menace comme les OGM, ils n'ont qu'à aller se faire foutre !
Le problème, c'est que tu trouveras toujours une personne dans le monde qui n'a pas envie de subir l'influence d'une menace comme X, où X est la technologie de ton choix. Pour certaines technologies, on peut choisir de s'isoler, par exemple je peux décider de ne jamais avoir de téléphone. Pour d'autres technologies, c'est impossible: je ne peux pas me protéger contre le risque de recevoir un avion sur la tête, ou contre les risques de guerre nucléaire, à moins de vivre dans un bunker.
Si on considère que le droit de ne pas subir une technologie est fondamental, et après tout pourquoi pas, il faut bien se rendre compte qu'il faudra respecter ce droit pour tout le monde, et que ça impliquerait de renoncer à à peut près toute technologie. Rien que le fait d'utiliser mon téléphone portable peut éventuellement mettre en danger mon voisin, à cause des vilaines ondes, et donc il aurait le droit de m'interdire de l'utiliser.
Ce n'est pas le genre de "liberté fondamentale" qu'on peut accorder comme ça, en pensant à autre chose. Les conséquences seraient trop importantes. Rien à voir avec la liberté "fondamentale" de choisir son navigateur :)
Si on refuse de considérer ce droit "fondamental", alors il faut bien trouver un moyen de se mettre d'accord, et il me semble que le vote est pour l'instant ce qu'on a trouvé de mieux pour départager les gens. L'inconvénient, c'est que dès qu'on touche au "sacré", on peut être sûr que les gens ne se satisferont pas de la décision s'ils sont du côté minoritaire.
Bien entendu, ce qui est sacré (la nature) pour certaines cultures ancestrales (de l'ensemble du monde d'ailleurs) c'est de la merde, par contre interdiction formelle de critiquer ou railler certaines religions monothéistes intolérantes
Je n'ai pas l'impression que l'opinion des "libristes" soit unique et indivisible, concernant la religion. Pour ma part, je ne considère sacrés ni la nature ni le p'tit jésus, et je me fiche royalement de ce qu'en pensent les autres tant que ça ne m'influence pas.
Par contre, quand ce concept de sacré est utilisé pour lutter contre quelque chose que j'aimerais bien voir arriver (je ne pense pas aux OGM, là, plutôt à la lutte contre le vieillissement), j'estime avoir le droit de critiquer.
Le problème d'ajouter des mots clés est que:
- Ils ne pouvaient pas modifier le langage d'origine, et ajouter les mots clés directement à Java ou C, parce que ça serait revenu à créer un nouveau langage, avec tous les défauts que ça implique.
- Du coup ils ont opté pour un préprocesseur. Or, si les mots du langage du préprocesseur sont des mots possibles du langage de destination, ça pose des problèmes. Dans le cas présent, un programme Java dans lequel une variable serait nommée "match" n'aurait pas été une entrée valide pour Tom, s'il avait utilisé le mot clé "march" au lieu de "%match".
sentir si mélanger des gènes de chose qui n'ont rien à voir ensemble n'a pas un caractères essentiellement malsain
Les choses ayant été créées comme elles devaient être, il n'est pas besoin d'être un grand savant pour se rendre compte que vouloir les changer est contre nature, limite blasphématoire.
Je propose d'ailleurs d'interdire l'évolution. D'autant plus qu'elle passe généralement par le sexe, ce qui en plus d'être malsain, est dégoûtant.
Je pense qu'OCaml demande un gros temps d'apprentissage (qui sera beaucoup plus réduit si on connait déjà un langage fonctionnel style Lisp), et est essentiellement utile pour faire des choses compliquées. Pour faire un logiciel simple, du genre de ceux qu'on fait en projet de programmation à la fac, le temps d'apprentissage est trop élevé pour valoir la peine. Bien sûr, une fois qu'on a appris, on peut s'en servir pour faire n'importe quoi, mais il y a une barrière assez élevée au début.
Je ne suis pas franchement convaincu par l'idée d'enseigner aux étudiants à programmer en commençant par OCaml, comme ça a été fait dans certaines facs. Un langage de programmation, c'est un outil pour résoudre les problèmes. Si on n'a pas encore eu de problèmes, on ne peut pas correctement apprendre à les résoudre. Donc je pense qu'il vaut mieux commencer par un langage simplissime et pas trop abstrait, commencer à programmer, et quand on rencontre des obstacles, trouver des langages qui aident à les surmonter.
Par exemple quand on se met à programmer à plusieurs et que la modularisation avec des .h atteint ses limites, on commence à mieux apprécier la programmation objet. Ou bien quand on se met à manipuler des structures de données abstraites et récursives, on se met à sérieusement apprécier la programmation fonctionnelle... du moins en ce qui me concerne.
D'un autre côté, il y a des inconvénient à apprendre d'abord un langage comme le C et ensuite un langage comme OCaml. On commence en ayant peu de contraintes, et ensuite on se trouve face à quelque chose de beaucoup plus formel, qui demande un peu de discipline, et il est difficile de se débarrasser de ses mauvaises habitudes.
Finalement, je ne sais pas ce qui est le mieux, comme ordre d'apprentissage, mais je comprend qu'on pense qu'OCaml est un langage sans applications quand on n'a pas encore souffert en essayant de faire quelque chose de vraiment compliqué dans ces langages préhistoriques que sont le C et ses dérivés (ce qui inclut Java, hein).
En même temps, le tour par tour n'est pas forcément une mauvaise chose. On peut avoir des ordinateurs qui vont super vite pour faire plein de choses, on reste limité par la vitesse de notre cerveau pour prendre les décisions stratégiques. Le tour par tour a des inconvénients (il faut attendre son tour) mais permet de construire une stratégie bien plus satisfaisante qu'en temps réel, où on se retrouve à envoyer des soldats encaisser les coups pour gagner du temps et réfléchir.
Nous ne sommes pas représentatifs de la population française mais d'une communauté de geeks.
Et alors ? Nos achats entrent en compte dans les statistiques globales, on n'est pas rangé à part dans une case "geek". Du coup, quand on achète un ordinateur avec un système libre préinstallé, ça fait un de plus dans les statistiques. Tant que la différence de prix avec l'ordinateur sans OS n'est pas significative, ça vaut le coup.
J'ai un peu essayé Anjuta à une époque, pour voir si je pouvais le suggérer comme alternative à Visual Studio, et la version 1 était pas mal du tout. Seul l'éditeur un peu limité (et n'indentant pas comme j'aime) m'a fait rester à Emacs.
La version 2, par contre, n'a jamais voulu fonctionner chez moi, alors qu'elle promettait d'être bien mieux, et plus facilement extensible. Dommage.
Sinon, je suis surpris de n'avoir vu personne suggérer KDevelop, alors que j'en ai entendu beaucoup de bien un peu partout.
Et en plus, si on le lance avec le nom jmacs (il y en a d'autres), il prend les raccourcis claviers d'emacs. Très pratique quand on veut rapidement éditer un fichier, qu'on est habitué à emacs, mais qu'on n'a pas envie d'attendre qu'il se charge.
Gobo est pas mal, comme biblothèque pour Eiffel, on y trouve plein de choses, même si on en trouve sûrement plus dans la bibliothèque standard de Java (globalement ça a l'air mieux conçu que la bibliothèque de Java, que je trouve assez horrible, mais c'est une question d'esthétique personnelle).
C'est une bonne peur à court et moyen terme, parce qu'on n'a pas envie de tout changer tout le temps, mais à long terme, ça oblige à continuer avec les mauvais choix de design qui ont été faits au début. Et il ne faut pas se leurrer, on fait toujours des mauvais choix au début :)
Personnellement, j'aime bien la politique de GTK, qui est de conserver la compatibilité (au niveau des sources et en principe des binaires) pour tous les Y d'une série de versions X.Y, et de casser la compatibilité quand on change de X. Ça marche plutôt bien, dans la mesure où la bibliothèque 1.2 est encore disponible pour les applications qui ne sont jamais passées à la version 2.
Il me semble que dans le libre on peut se permettre d'avoir moins de scrupules à casser la compatibilité avec les versions antérieures, quand c'est nécessaire, dans la mesure où les utilisateurs ont le code source des versions antérieures, et peuvent continuer à les maintenir s'ils le désirent. Mais évidemment, il ne faut pas en abuser :)
[^] # Re: vous blaguez en fait là ?
Posté par Yusei (Mastodon) . En réponse au journal Stallman et les autographes payant. Évalué à 5.
Moi je préfèrerais qu'on m'offre une bière, plutôt qu'on ne me fasse signer un bout de papier pour avoir la preuve qu'on m'a bien rencontré.
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 2.
Ça ressemble plus à un indice contre l'hypothèse qu'à une réfutation formelle. Il est possible que notre langage influe sur la manière dont on pense et qu'on soit quand même capable de penser des choses difficiles à formuler dans notre langage.
Je n'y ai pas réfléchi en détails, mais je prend un exemple de ce qui me reste de mes souvenirs de Lojban. Il y a dans le langage une manière naturelle d'exprimer "à droite de X, qui me fait face", ou bien "à gauche de X, qui fait face à Y". Évidemment, on est capable de concevoir "à gauche de X qui fait face à Y" et de le traduire en position, mais ça demande toujours un temps de réflexion, et de nombreuses personnes ont du mal à imaginer les rotations d'objets ou de point de vue[1]. Il me semble que si ces gens parlaient une langue qui utilise ce genre d'indicateurs de position aussi naturellement que "à ma gauche", leur capacité de faire des rotations mentales serait plus développée. (Ou alors c'est une limite biologique et ils auraient du mal à comprendre les phrases, mais ça me semble moins probable.)
[1]: il me semble qu'on se sert d'ailleurs de ça dans certains tests psychologiques ou tests de QI: on montre une image de main et on demande si c'est une main gauche ou une main droite. Ou bien on demande "parmis ces images, laquelle est une rotation de cet objet ?".
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 3.
Si tu as une référence, ça m'intéresse. Je ne suis même pas sûr que ce soit réfutable, comme hypothèse.
Tiens, amusant, il y a aussi une page sur wikipedia concernant les langages et l'hypothèse Sapir Whorf: http://en.wikipedia.org/wiki/Sapir-Whorf_and_programming_lan(...)
C'est tellement peu conforme à mon intuition et à mon expérience personnelle que je ne sais pas vraiment comment y répondre.
On pourrait prendre un cas extrême inspiré du langage Whitespace. Avec un alphabet comportant uniquement deux caractères, l'espace et le retour à la ligne, on peut tout à fait construire un langage qui permet d'exprimer des concepts de haut niveau. Faut être cinglé pour vouloir faire ça, mais on peut.
D'un autre côté, comme c'est un exemple extrême, ce n'est pas très satisfaisant. Et comme la plupart des langages ont été conçus pour être utilisables par des humains, on ne trouvera pas dans la nature d'exemples flagrants de syntaxe qui rend le code illisible, car la sélection naturelle des programmeurs l'aurait éliminée.
(note, au passage, que je n'ai rien contre la syntaxe de Tom, hein :)
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 5.
Même si je sais que tous les langages Turing-complets permettent la même chose, je ne peux pas penser que la syntaxe n'a pas d'importance. Il n'y a qu'à voir la différence dans les programmes de résolution d'un problème, si l'un a été codé en impératif et l'autre en fonctionnel. De la même manière, on peut souvent voir lorsqu'un type qui code en C est un programmeur qui a fait du fonctionnel avant, ou de l'objet, ou autre. Le paradigme favorise certains choix, et la syntaxe également.
[1] http://en.wikipedia.org/wiki/Sapir%E2%80%93Whorf_hypothesis
[2] http://en.wikipedia.org/wiki/Currying
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 6.
Non, c'est pour tous les opérateurs, sauf ceux de comparaison qui sont polymorphiques. Le langage et la lib de base fournissent peu d'opérateurs, justement parce que l'absence de polymorphisme rendrait pénible d'avoir 27 variantes de "+". Du coup, tu as +, +. et +/ pour additionner les entiers, les flottants et les Nums, et pour les autres types il faut utiliser les fonction du style Type.add.
Dans le même style, et même si ce ne sont pas strictement des opérateurs, tu dois mémoriser que pour décrire une liste c'est [ ... ], pour décrire un vecteur c'est [| ... |]. Pour accéder à un élément d'un vecteur, on utilise .(indice), et pour accéder à un élément d'une chaîne, .[indice], etc.
Chaque point pris individuellement n'est pas dur à mémoriser, c'est la somme des détails qui est lourde. En Ruby, pour additionner deux objets on utilise "+", et pour accéder à un élément dans un truc qui en possède plusieurs, on utilise [indice]. Je comprend la justification derrière le choix d'OCaml, mais je trouve quand même la version ruby plus agréable.
Difficile de faire une liste précise, je ne mémorise pas les exceptions, c'est bien pour ça qu'elles me posent problème :)
Il me vient, à froid:
- tous les exemples ci-dessus.
- le produit cartésien, pour lequel on peut omettre les parenthèses lorsque ce n'est pas ambigu pour le compilateur, mais j'ai rencontré des cas où c'était ambigu pour mon cerveau limité.
- il y a d'autres cas où les parenthèses peuvent être omises, et ça n'aide pas toujours la lisibilité. Je l'ai dit, j'aime bien le Lisp :)
- Il y a plusieurs manières de déclarer une fonction. Je n'en ai retenu qu'une, mais pour débugguer le code des autres il faut toutes les connaîtres.
- Si on veut faire de l'impératif, on peut délimiter les instructions qui renvoient unit par des points virgule, ou bien on peut écrire let () = expression in ... (il y a peut-être une différence entre les deux, mais je ne la connais pas).
J'ai la flemme d'en chercher d'autre, je n'ai pas pour but de démolir OCaml. Puisque je m'en sers, c'est que je trouve les obstacles surmontables, mais quand même pénibles ;)
[^] # Re: Non!
Posté par Yusei (Mastodon) . En réponse au journal [HS] OGM. Évalué à 3.
Euh... en principe on ne balance pas de virus dans la nature, si ? Il me semble que les semences sont fabriquées en laboratoire, et plantées dans des champs après. On peut certainement imaginer plein de scénarios catastrophe, mais celui du virus mutant qui s'enfuit du laboratoire et qui refile à l'homme le gène qui repousse les limaces me semble peut plausible :)
(Encore que, j'aimerais bien repousser les limaces)
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 4.
Mouais, alors si tu compares la lib de base d'OCaml et celle du C, je ne sais pas vraiment qui gagne, mais je penche très fort pour OCaml, puisque la notion de "lib de base" pour le C est quasi inexistante. Pour Java, par contre, d'accord.
Ceci dit, s'il n'y a pas de parser XML, d'interface ODBC, etc. dans la lib de base, tout ça existe quand même. Il manque peut être un repository, je ne sais pas trop, chez moi c'est bien proprement intégré par Debian. Quand j'ai besoin de quelque chose, ça se limite souvent à une recherche dans la base des paquets.
Ho ho. Je t'accorde que le seul intérêt de Java, c'est son framework, parce que le langage n'est vraiment pas terrible.
Mais si on se basait sur l'existence de bibliothèques et d'IDE pour juger les langages, Java n'aurait jamais été créé. Du côté des IDE, j'ai commencé à faire du Java avec le bloc note de Windows, et c'était pas joyeux.
open Unix
Là, j'avoue que je n'en connais pas de mieux foutu qu'Emacs.
C'est triste ce que tu penses de GTK2.
Il y a un livre publié par OReilly et diffusé sur le net, qui est très bien foutu, bien qu'un peu dense à mon goût.
Je ne sais pas sur quelles plateformes le compilateur d'OCaml tourne, mais tu peux compiler un programme OCaml en bytecode pour JVM, si tu veux.
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 6.
Dans le même style, le fait d'avoir des opérateurs différents pour la même opération sur des types différents, ça rend la lecture et l'apprentissage difficiles. C'est justifié par l'inférence de types, mais c'est pénible de devoir se souvenir quel est l'opérateur à utiliser pour le type que l'on a.
[^] # Re: Mon avis sur les OGM :
Posté par Yusei (Mastodon) . En réponse au journal [HS] OGM. Évalué à 2.
(Si on se base sur le principe "c'était mieux avant", à l'échelle géologique la vie a été une catastrophe pour la Terre. Avant, la Terre était à 100% sans forêts !)
[^] # Re: Hem
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 4.
[^] # Re: Inutile
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 6.
Probablement pas, parce qu'il est plus facile de descendre que de remonter.
Pour ceux que cette explication ne satisfait pas, je vais essayer de faire mieux mais c'est pas gagné. Quand on écrit un programme dans un langage de haut niveau, les mots et les constructions du langage ont du sens qu'il n'est pas toujours possible de traduire dans le langage de bas niveau. Par exemple, dire qu'une classe hérite d'une autre a un sens si on se place à un certain niveau, mais le code en assembleur qui résulte de la compilation ne contient pas cette information.
Pour retrouver l'information à partir du code de bas niveau, il faut être capable de l'analyser pour "remonter" dans les niveaux. Pour certaines choses, c'est possible, par exemple on peut assez facilement à partir de l'assembleur retrouver des structures de boucle. Mais est-ce toujours possible ?
- Le programme compilé ne contient pas forcément toute l'information. Par exemple la hiérarchie d'héritage des classes ne sera probablement pas représentée en entier ou correctement.
- L'analyse de programme est difficile. Tellement difficile que certaines choses sont impossibles. On ne peut pas, par exemple, faire un programme qui peut analyser n'importe quel programme et dire s'il s'arrête ou s'il boucle indéfiniment. D'un autre côté, je doute qu'il soit possible de faire un langage de haut niveau qui permet d'exprimer qu'un programme boucle sans que le code résultant ne puisse être analysé pour le déduire.
- L'analyse de programme est difficile (bis). Un programme, c'est un graphe assez énorme, et pour "remonter", il faut être capable de découvrir des structures de haut niveau dans ce graphe, ce qui n'est pas évident. Pour prendre un exemple simplifié, prend une feuille de papier, et interroge des gens dans la rue. Pour chaque personne, inscris un rond avec leur nom, et puis si deux personnes se connaissent, relie leurs ronds par un trait. Une fois que c'est fini, essaye de retrouver les familles. Une famille, c'est une structure de haut niveau dans ton graphe des "connaissances", mais c'est incroyablement difficile à retrouver si on n'a pas l'information.
# En fait, résultat en faveur d'emacs
Posté par Yusei (Mastodon) . En réponse au journal Vi vs Emacs 3:0 (love with tux). Évalué à 10.
[^] # Re: Mon avis sur les OGM :
Posté par Yusei (Mastodon) . En réponse au journal [HS] OGM. Évalué à 2.
Je crois que tu confonds ordinateur quantique et ordinateur à ADN. Ou alors tu penses à un ordinateur à chat de schrödinger, mais là on ne peut pas être sûr qu'il contient du vivant avant d'avoir ouvert la boîte, ce qui annule la garantie.
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 2.
[^] # Re: Mon avis sur les OGM :
Posté par Yusei (Mastodon) . En réponse au journal [HS] OGM. Évalué à 3.
Le problème, c'est que tu trouveras toujours une personne dans le monde qui n'a pas envie de subir l'influence d'une menace comme X, où X est la technologie de ton choix. Pour certaines technologies, on peut choisir de s'isoler, par exemple je peux décider de ne jamais avoir de téléphone. Pour d'autres technologies, c'est impossible: je ne peux pas me protéger contre le risque de recevoir un avion sur la tête, ou contre les risques de guerre nucléaire, à moins de vivre dans un bunker.
Si on considère que le droit de ne pas subir une technologie est fondamental, et après tout pourquoi pas, il faut bien se rendre compte qu'il faudra respecter ce droit pour tout le monde, et que ça impliquerait de renoncer à à peut près toute technologie. Rien que le fait d'utiliser mon téléphone portable peut éventuellement mettre en danger mon voisin, à cause des vilaines ondes, et donc il aurait le droit de m'interdire de l'utiliser.
Ce n'est pas le genre de "liberté fondamentale" qu'on peut accorder comme ça, en pensant à autre chose. Les conséquences seraient trop importantes. Rien à voir avec la liberté "fondamentale" de choisir son navigateur :)
Si on refuse de considérer ce droit "fondamental", alors il faut bien trouver un moyen de se mettre d'accord, et il me semble que le vote est pour l'instant ce qu'on a trouvé de mieux pour départager les gens. L'inconvénient, c'est que dès qu'on touche au "sacré", on peut être sûr que les gens ne se satisferont pas de la décision s'ils sont du côté minoritaire.
Je n'ai pas l'impression que l'opinion des "libristes" soit unique et indivisible, concernant la religion. Pour ma part, je ne considère sacrés ni la nature ni le p'tit jésus, et je me fiche royalement de ce qu'en pensent les autres tant que ça ne m'influence pas.
Par contre, quand ce concept de sacré est utilisé pour lutter contre quelque chose que j'aimerais bien voir arriver (je ne pense pas aux OGM, là, plutôt à la lutte contre le vieillissement), j'estime avoir le droit de critiquer.
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 4.
- Ils ne pouvaient pas modifier le langage d'origine, et ajouter les mots clés directement à Java ou C, parce que ça serait revenu à créer un nouveau langage, avec tous les défauts que ça implique.
- Du coup ils ont opté pour un préprocesseur. Or, si les mots du langage du préprocesseur sont des mots possibles du langage de destination, ça pose des problèmes. Dans le cas présent, un programme Java dans lequel une variable serait nommée "match" n'aurait pas été une entrée valide pour Tom, s'il avait utilisé le mot clé "march" au lieu de "%match".
[^] # Re: Mon avis sur les OGM :
Posté par Yusei (Mastodon) . En réponse au journal [HS] OGM. Évalué à 5.
Les choses ayant été créées comme elles devaient être, il n'est pas besoin d'être un grand savant pour se rendre compte que vouloir les changer est contre nature, limite blasphématoire.
Je propose d'ailleurs d'interdire l'évolution. D'autant plus qu'elle passe généralement par le sexe, ce qui en plus d'être malsain, est dégoûtant.
[^] # Re: Et beh...
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 9.
Je ne suis pas franchement convaincu par l'idée d'enseigner aux étudiants à programmer en commençant par OCaml, comme ça a été fait dans certaines facs. Un langage de programmation, c'est un outil pour résoudre les problèmes. Si on n'a pas encore eu de problèmes, on ne peut pas correctement apprendre à les résoudre. Donc je pense qu'il vaut mieux commencer par un langage simplissime et pas trop abstrait, commencer à programmer, et quand on rencontre des obstacles, trouver des langages qui aident à les surmonter.
Par exemple quand on se met à programmer à plusieurs et que la modularisation avec des .h atteint ses limites, on commence à mieux apprécier la programmation objet. Ou bien quand on se met à manipuler des structures de données abstraites et récursives, on se met à sérieusement apprécier la programmation fonctionnelle... du moins en ce qui me concerne.
D'un autre côté, il y a des inconvénient à apprendre d'abord un langage comme le C et ensuite un langage comme OCaml. On commence en ayant peu de contraintes, et ensuite on se trouve face à quelque chose de beaucoup plus formel, qui demande un peu de discipline, et il est difficile de se débarrasser de ses mauvaises habitudes.
Finalement, je ne sais pas ce qui est le mieux, comme ordre d'apprentissage, mais je comprend qu'on pense qu'OCaml est un langage sans applications quand on n'a pas encore souffert en essayant de faire quelque chose de vraiment compliqué dans ces langages préhistoriques que sont le C et ses dérivés (ce qui inclut Java, hein).
[^] # Re: Ca bouge dans le monde du libre
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de Glest 2.0. Évalué à 3.
[^] # Re: Choisir le système libre même si on va le remplacer
Posté par Yusei (Mastodon) . En réponse au sondage À matériel identique et garantie égale, mon prochain ordinateur neuf de grande marque, je voudrais l'acheter :. Évalué à 3.
Et alors ? Nos achats entrent en compte dans les statistiques globales, on n'est pas rangé à part dans une case "geek". Du coup, quand on achète un ordinateur avec un système libre préinstallé, ça fait un de plus dans les statistiques. Tant que la différence de prix avec l'ordinateur sans OS n'est pas significative, ça vaut le coup.
[^] # Re: Ce que tu cherches ...
Posté par Yusei (Mastodon) . En réponse au journal Choisir un environnement de dev pour y écrire un plugin. Évalué à 4.
[^] # Re: Anjuta
Posté par Yusei (Mastodon) . En réponse au journal Choisir un environnement de dev pour y écrire un plugin. Évalué à 3.
La version 2, par contre, n'a jamais voulu fonctionner chez moi, alors qu'elle promettait d'être bien mieux, et plus facilement extensible. Dommage.
Sinon, je suis surpris de n'avoir vu personne suggérer KDevelop, alors que j'en ai entendu beaucoup de bien un peu partout.
[^] # Re: Pour ceux qui refusent les usines à gaz...
Posté par Yusei (Mastodon) . En réponse au journal Choisir un environnement de dev pour y écrire un plugin. Évalué à 3.
[^] # Re: Goûtez-y !
Posté par Yusei (Mastodon) . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 3.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Yusei (Mastodon) . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 2.
C'est une bonne peur à court et moyen terme, parce qu'on n'a pas envie de tout changer tout le temps, mais à long terme, ça oblige à continuer avec les mauvais choix de design qui ont été faits au début. Et il ne faut pas se leurrer, on fait toujours des mauvais choix au début :)
Personnellement, j'aime bien la politique de GTK, qui est de conserver la compatibilité (au niveau des sources et en principe des binaires) pour tous les Y d'une série de versions X.Y, et de casser la compatibilité quand on change de X. Ça marche plutôt bien, dans la mesure où la bibliothèque 1.2 est encore disponible pour les applications qui ne sont jamais passées à la version 2.
Il me semble que dans le libre on peut se permettre d'avoir moins de scrupules à casser la compatibilité avec les versions antérieures, quand c'est nécessaire, dans la mesure où les utilisateurs ont le code source des versions antérieures, et peuvent continuer à les maintenir s'ils le désirent. Mais évidemment, il ne faut pas en abuser :)