Tes indices de boucles, tu les préfères nommés comment, "indice" ? i, j ou k comme indices de boucle, n ou m comme limites de boucles ou nombre d'éléments, f, g ou h pour des fonctions, ce ne sont pas des noms "bêtes", ce sont des notations rapides à écrire qui viennent des maths, et qui sont souvent tout à fait clairs dans un contexte local.
Je suis d'accord que les attributs d'objets ou les variables globales doivent avoir des noms explicites, mais localement dans une fonction, je préfère un code concis et clair plutôt qu'un code bourré de noms de variables à rallonge qui ne l'explicitent pas réellement.
ben oui, il paraît qu’il y en a qui sont des filles…
Naturellement, je répondais en me plaçant de mon propre point de vue, et sans présumer de généralité à ce sujet. À chaque fois que je dis "femme", il faut lire "(ou hommes pour les femmes hétéros ou les hommes homosexuels)".
De la même manière que lorsque je mentionne Emacs, on peut lire entre les lignes "ou Vim pour les femmes et les tapettes".
mon commentaire est valable pour les deux commentaires.
Vous allez voir que bientôt il va être politiquement incorrect de ne pas être bisexuel...
Mon commentaire à moi était une blague tout à fait sérieuse, à ceci près que tant qu'à être dans le domaine du rêve, j'aurais dû demander une ingénieur (ingénieuse ?) plutôt qu'une stagiaire. Et s'il est sexiste de préférer la compagnie des femmes, alors je suis sexiste. Je pense que j'y survivrai.
En fait, l'idéal, c'est l'approche choisie pour le prochain Gnome: des réglages par défaut parfaits, et aucune option. Corollaire: les fenêtres de préférences ne comporteront ainsi qu'un seul bouton: annuler.
Pour prendre une image, imaginons un designer qui présente à quelqu'un la nouvelle maquette qu'il a conçu pour son site:
- Attentions, ce n'est qu'un premier brouillon: je me suis concentré sur l'organisation des éléments sur la page et la lisibilité, pas sur l'aspect graphique. Que pensez-vous de cette organisation ?
- Il n'y a pas d'images. Vous pensez vraiment que je peux envisager d'avoir un site sans images ? Revenez quand vous aurez mis des images !
Je pense qu'il faut faire une distinction entre ce qu'est Lisaac et ce que tu attends d'un outil de travail. Lisaac, si j'ai bien compris, c'est de la recherche, avec des objectifs plus ou moins bien définis. Ce que tu attends d'un outil de travail, c'est par exemple les garanties de sécurité fournies par l'utilisation d'une machine virtuelle, un framework complet, une bibliothèque fournie, etc.
Attaquer Lisaac sur ces points n'est pas pertinent, sauf s'il s'agit d'attaquer ses objectifs. Si tu nous dit que Lisaac a parmis ses objectifs quelque chose qui le rend intrinsèquement moins XXX que Java, alors c'est une remarque intéressante. Si tu nous dit que dans l'implémentation actuelle, il est moins XXX que Java, qu'est-ce que ça signifie ? (remplacer XXX par l'épithète de son choix)
Ça ne peut signifier qu'une chose, c'est qu'étant donné l'état "en développement" de Lisaac, tu ne le choisirais pas pour un projet sérieux à but productif. J'ose espérer que personne ne choisirait un langage dans un stade aussi expérimental pour ça.
Si on commence à flinguer tous les nouveaux langages qui ne sortent pas directement aussi aboutis que le framework Java, où va-t-on ? D'ailleurs, même si quelqu'un sortait un langage aussi abouti que Java du jour au lendemain, on lui ferait le reproche qu'il n'existe pas de programmeurs sachant l'utiliser.
Maintenant, sur le point précis dont on parlait, parce que je m'égare: le langage Lisaac, comme le langage Java, permet d'incorporer du code natif facilement. La plateforme Lisaac, à l'opposée de la plateforme Java, ne permet (peut-être) pas de limiter cela. Cependant, la plateforme actuelle, on s'en fiche un peu, ce qui est intéressant c'est les concepts. Je n'ai pas vu dans ce qu'il a été dit de Lisaac quoi que ce soit qui me laisse penser qu'on ne puisse pas compiler à destination d'une machine virtuelle, et donc profiter des mêmes bénéfices en matière de sécurité. Mais c'est de ça qu'il serait intéressant de discuter, pas du nombre de bugs ou de fonctionnalités de l'implémentation actuelle, qui est du code destiné à la recherche.
Un chercheur n'est pas une équipe d'ingénieurs, enfin. Si les concepts sont suffisamment intéressants et forment un tout cohérent, alors les ingénieurs prendront le relai et en feront quelque chose de fini.
(L'ingénieur peut être la même personne que le chercheur, mais ce n'est pas la même phase du travail de "recherche et développement")
M'enfin, le Java aussi on peut le mixer avec du C, et plus haut tu le cites pour ses apports en matière de sécurité, faudrait savoir.
Je suis d'accord avec ton argument concernant Java (plus de sécurité sauf si on sort consciemment du cadre édicté par le langage), mais il est valable aussi pour Lisaac.
Tu mélanges allégrement cas spécifiques et cas généraux, et je n'arrive plus à être sûr de ce que tu veux dire. Tu as l'air de penser qu'en exhibant des contre-exemples de programmes pouvant être prouvés, tu démontres quelque chose. Depuis le début, je dis que je suis d'accord sur le fait que des cas restreints peuvent être prouvables. Le problème vient quand tu généralises à tous les programmes écrits dans un langage Turing complet.
Nous avons aussi un problème de compréhension au sujet du formalisme utilisé pour la discution. Je parle de machines de Turing, et d'états de machines de Turing, et toi tu me parles d'erreurs d'arrondi et de CPU. Ce n'est pas du tout mon domaine, et j'ajouterais que ça ne m'intéresse pas trop puisque, si on a des problèmes de prouvabilité au niveau des machines de Turing "parfaites", ce n'est pas en ajoutant des possibilités d'erreur au niveau du codage des nombres, ou des problèmes de concurrence, qu'on rendra les choses plus facilement prouvables.
Il ne dit absolument pas que pour un programme quelconque spécifié il est impossible d'écrire un autre programme qui le valide ou l'invalide.
S'il est possible pour un programme quelconque fixé d'écrire mécaniquement un programme qui le valide ou l'invalide, alors il est possible d'écrire un programme qui valide ou invalide tous les programmes.
S'il est possible pour un programme quelconque de trouver un programme qui le valide ou l'invalide, mais qu'on ne peut pas mécaniser ce processus, alors cela revient à dire que c'est algorithmiquement indécidable. C'est donc un objectif inaccessible si la thèse de Church-Turing est vraie, on y revient.
Si on restreint le problème comme tu le fais aux programmes utilisant une mémoire finie, on sort de l'infaisable théorique pour arriver dans l'infaisable pratique, ce qui nous fait une belle jambe. Ca devient faisable théoriquement parce qu'on peut essayer tous les états possibles du programme, mais je serais curieux de voir une méthode générale plus efficace.
il ne s'agit pas de valider le programme pour un seul et unique jeu de données, mais pour un ensemble de données toutes bornées.
Eh bien, soit tu pars d'un jeu de données initial et tu énumères les états en vérifiant qu'on ne revient jamais dans un état déjà visité, soit tu énumères tous les états atteignables et tu vérifies qu'aucun d'eux n'est sur un cycle. Je ne suis pas sûr qu'énumérer les états atteignables soit faisable en général sans énumérer toutes les données initiales possibles, ce qui reviendrait à exécuter le programme pour chaque jeu de données possible.
Formulé plus simplement, ce que je ne vois pas, c'est comment tu prouves qu'un état n'est pas sur un cycle sans partir d'un état initial, avancer jusqu'à cet état, et prouver qu'ensuite on ne revient pas à un état déjà visité. (Par état, je parle d'un état d'une machine de turing associé à ce qui est écrit sur le ruban.)
Typiquement ton programme est un graphe où les noeuds sont des états et les arêtes des transitions. Tu peux faire mieux qu'énumérer tous les états (et donc toutes les données possibles) à condition de pouvoir compacter plusieurs noeuds en un seul, c'est à dire qu'au lieu d'avoir des états de type: (X, d) avec d un jeu de données, tu auras des états de type (X, D) avec D un ensemble de jeux de données.
Ce qui m'intrigue, c'est comment on pourrait faire cette compaction dans le cas général. Je n'ai pas de preuve formelle que ce soit impossible de le faire de manière plus efficace qu'en énumérant tout, mais intuitivement ça me semble évident.
Bon, désolé, j'avais préparé quelque chose de mieux écrit, et suite à un clic mal placé, j'ai tout perdu. Pour résumer:
il est possible d'écrire un programme validant la terminaison d'un autre programme spécifique dont l'ensemble des données (interne et externe) sont bornées en taille mémoire. En d'autres termes une machine de Turing qui n'a pas une bande infinie...
C'est ce que je disais plus haut, et à quoi tu répondais "euh non, pas du tout": tu peux toujours exécuter le programme et voir ce que ça donne. Si tu bornes la taille mémoire utilisable, que tu stockes tous les états complets du programme et qu'à chaque étape tu vérifies que tu ne retombes pas dans un état déjà visité, alors en un temps irréaliste et avec une mémoire irréaliste, tu peux savoir si ton programme s'est terminé ou pas pour ces données là.
C'est un résultat relativement inutile. J'ose espérer que quand on parle de "preuve de programme" on essaye d'avoir une certaine généralité. Ici, on devra réappliquer la même procédure pour chaque nouveau jeu de données, et cette procédure ne fait rien économiser par rapport à exécuter le programme sans rien prouver.
Malheureusement les résultats un peu généraux sont algorithmiquement indécidables.
La page française mentionne l'indécidabilité algorithmique du problème suivant, par exemple: « le programme calcule un résultat correct par rapport à la spécification ».
(Ce qui, encore une fois, ne veut pas dire que l'on ne peut jamais rien prouver. En restreignant les problèmes considérés, on peut se ramener à des cas gérables.)
Prouver qu'un programme se termine ne veut pas dire démontrer qu'un programme se termine.
Tu peux aussi démontrer qu'il ne se termine pas. Mais dans la plupart des cas, tu ne pourras démontrer ni l'un ni l'autre, et c'est tout le problème.
Par contre sur un programme donné, dont on connait par avance les specs et les états souhaitables il est possible (même programmatiquement) de voir
a) Si on ne rencontre effectivement que des états souhaitables
b) Si on termine le programme.
Par état souhaitable, tu veux dire état dont on sait qu'il mêne au bon résultat (et à une terminaison du programme) ? Si c'est le cas, alors la détermination des états souhaitables revient à prouver le programme, et est impossible dans le cas général par quelque chose de puissance équivalente à une machine de Turing (MT).
prouver le b) n'est qu'une question de temps.
Prouver qu'un programme termine (sur un jeu de données fixé) n'est qu'une question de temps: il suffit de l'exécuter. Prouver qu'un programme ne termine pas est une autre paire de manches.
Je pense qu'il est temps de recentrer un peu le débat, car on s'éloigne un peu. Tu disais que du moment qu'on a un langage Turing complet, on peut prouver ses programmes. Or, tout langage Turing complet permet de produire des programmes dont on ne peut pas prouver la terminaison avec quelque chose de la même puissance qu'une MT.
Je ne sais pas comment expliquer ça de manière plus claire. Tu as l'air de penser qu'à partir du moment où on choisit un programme en particulier, alors il devient prouvable. Ce n'est vrai que dans des cas particuliers. Il n'est pas possible d'écrire un programme validant la terminaison d'un autre programme quelconque. Tu peux penser qu'un humain peut le faire, mais ça suppose que la thèse de Church-Turing est fausse. En tout cas, une MT ne peut pas le faire, c'est un résultat mathématique bien établi.
Si une JVM ne donne pas d'interface vers l'extérieur et ne contient pas de failles, alors tu peux générer du bytecode arbitraire, ça ne te permettra pas de faire quoi que ce soit à l'OS derrière la JVM.
Par "pas de code natif", je suppose qu'il voulait interdir l'utilisation de JNI, qui est la principale interface vers l'extérieur de la JVM. Quand tu utilises JNI, tu codes en C (ou équivalent), alors, naturellement, ce n'est pas plus sûr que coder en C. Sans JNI, et en admettant l'utilisation d'une JVM sans failles, je ne pense pas qu'il y ait moyen de faire grand chose.
Il y a une différence entre dire "peut être simple à faire" et "est faisable". Ce n'est pas parce que quelque chose est simple dans certains cas que c'est toujours faisable.
Quand tu dis qu'à partir du moment où on a un langage Turing complet, on peut prouver le code, je ne comprends pas "dans certains cas, c'est facile".
Si tu confirmes que dans ce que tu appelles "prouver le code", on peut inclure "prouver que le programme se termine", alors ton hypothèse "on peut prouver n'importe quel programme d'une machine de Turing" repose sur le fait que le cerveau humain est plus puissant qu'une machine de Turing.
à partir du moment ou on a un code turing complet et un compilateur/interpreteur déterministe on peut prouver un code. Le contraire serait inquiétant.
Peut-être faudrait-il préciser ce qu'on entend par "prouver", parce que pour moi, même prouver qu'un programme s'arrête, c'est balaise... alors prouver qu'il fait bien ce que l'on veut...
Peut-être parlais-tu de prouver que le code produit est bien "identique" au code source ?
C'est à prendre en compte, mais ce n'est pas lié au fait qu'un langage soit de haut niveau. Brainfuck est difficile à appréhender que Ruby, bien qu'étant de plus bas niveau.
Lisp (langage cité par le post grand-parent) n'est pas spécialement un langage de haut niveau, tout dépend du formalisme dans lequel on se place. C'est quasiment une traduction directe du lambda calcul, donc ça pourrait être qualifié de "bas niveau". Il y a même eu des machines comprenant directement le Lisp.
Au final tu cantonnes toi même Ruby à un petit marché
Vilain fredix, arrête de cantonner Ruby, s'il te plaît.
La difficulté de maintenance et d'évolution [...]
Rails facilite la maintenance et l'évolution de la même manière que le développement. Ses atouts qui rendent le développement rapide rendent également la maintenance et l'évolution relativement aisés. Je parle d'expérience, pour avoir dû gérer un projet dont le cahier des charges évoluait de jour en jour, de façon parfois drastique.
En fait, je dirais même que Rails est plutôt destiné aux projets qui ne sont pas bien définis ou qui vont beaucoup évoluer. De même que Ruby est surtout efficace pour prototyper rapidement une application, au détriment de la rapidité d'exécution.
En entreprise il peut y avoir d'autres sortes d'utilisateurs : des grosses applis internes (banques, assurances, etc.) qui demande des architectures N-tiers parfois avec de hautes performances.
En entreprise, il peut y avoir des besoins forts en termes de performance. Il peut aussi y avoir des besoins forts en terme de rapidité de développement et d'évolution. Qui a dit que les mêmes outils devaient servir dans tous les cas ?
Les cas où Rails est trop lent et où il est le facteur limitant sont relativement réduits: jusqu'à quelques centaines d'utilisateurs concurrents, un gros serveur bien configuré n'aura pas vraiment de mal. Un bon serveur a un coût négligeable pour une entreprise qui a plusieurs centaines d'utilisateurs concurrents. Et multiplier les serveurs est un bon moyen de monter en charge tout en améliorant la fiabilité. Alors, certes, gérer des millions d'utilisateurs concurrents (la précision est importante) est peut-être difficile en Rails, mais ça représente une portion infime des besoins des entreprises.
Je n'essaye pas de dire que Ruby et Rails sont des outils universels, mais je pense qu'il est vraiment simple d'identifier quand un projet sera trop lourd pour cet outil, et que dans les autres cas, lorsque c'est possible, on gagne à l'utiliser.
De toutes façons, 78,3% [Peterson et al.] des gens qui prétendent savoir augmenter la productivité sont des gens qui n'ont jamais rien produit de concret. Et combien font 3 x 12%, hein, je te le demande ? Allez, je t'aide, c'est comme 3 x 3 x 4%. Question subsidiaire, en supposant que P != NP, combien faut-il de programmeurs appliquant la méthode XP pour changer une ampoule ?
Formulé autrement, parce que je conçois que ce ne soit pas très clair: qu'est-ce que c'est que ces âneries ? Je ne sais pas si tu essayes de faire passer un message, c'est un peu masqué par la forme ridicule de tes propos, mais tu as l'air d'être passé complètement à côté du fait que mon post était une plaisanterie.
En admettant que tu sois sérieux, j'aimerais bien savoir où tu as cru voir quelqu'un prétendre que le "facteur humain" n'était pas le plus important.
On chipote sur le langage alors que le facteur humain est largement plus bloquant
Mais voyons, on chipote aussi sur le facteur humain. Si tu as des doutes à ce sujet, tu n'as qu'à créer un journal disant que tu hésites entre aller à l'Epita et à la fac.
Un des intérêts de Ruby, c'est ses capacités de metaprogrammation, et le fait qu'on peut facilement créer avec ce que des gens appellent DSL (domain specific language). On en voit un bon exemple avec Rails, qui définit des nouveaux "mots clés" à tour de bras. Faire quelque chose de similaire en Java était, la dernière fois que j'en ai fait, difficile et sans grand intérêt.
(avertissement: défenseurs des drosophiles, passez votre chemin.)
En français, une alternative est un choix entre deux possibilités, il n'y a pas de "troisième alternative". Même si tu as certainement raison sur ce que l'auteur voulait dire, l'interprétation de celui qui lui répond est tout à fait légitime.
Il n'y a rien qui m'énerve plus que le relativisme absolu, alors forcément, je réagis :)
Et c'est pas avec le langage informatique, mais avec sa cervelle qu'on travaille.
En une heure de temps, la cervelle peut résoudre un nombre limité de problèmes. Selon les cas, la cervelle peut travailler à résoudre le problème sur lequel elle travaille, ou bien travailler à résoudre les problèmes posés par son outil. L'informaticien est donc plus efficace lorsque son outil n'oblige pas sa cervelle à penser à l'outil, mais la laisse se concentrer sur le problème réel.
Je préfère Ruby à Perl parce que j'ai moins besoin de réfléchir à son fonctionnement (et je préférais Perl à C pour les mêmes raisons). Je n'ai pas à me souvenir si le nom de ma variable doit commencer par un $, un % ou un @, si je dois utiliser des crochets ou des accolades, comment sont automatiquement convertis les types, etc. De nombreuses fois, plutôt que d'ailler regarder dans l'API comment on fait une chose, je l'ai écrite comme je pensais que ça devrait s'écrire... et ça a marché.
Pour reprendre ton argument, je pourrais dire qu'un bon mathématicien n'est pas là pour aimer les mathématiques, mais pour trouver des théorèmes. Ce n'est pas avec un formalisme qu'on travaille, mais avec sa cervelle. Par conséquent, il ne sert pas à grand chose de développer de nouveaux formalismes équivalents à des formalismes existants. Par exemple, le lambda calcul ne sert à rien puisqu'il est équivalent aux machines de Turing.
Et pourtant, en formulant les choses différemment, on peut parfois trouver une solution plus facilement. Quand il est difficile/pénible d'exprimer un concept dans un langage, on ne peut pas attendre du programmeur d'utiliser ce concept naturellement. Ce n'est pas qu'une histoire de concision.
Évidemment, la plupart des langages de programmation visent l'universalité, et donc essayent d'incorporer le plus possible de concepts. Ce n'est pas pour cela que ces concepts sont naturels, et ce n'est pas suffisant pour conclure que tous les langages se valent.
[^] # Re: Vim
Posté par Yusei (Mastodon) . En réponse au journal Qu'est-ce qu'un outils de développement de rève ?. Évalué à 4.
Ce qu'il te faut, dans ce cas, c'est Cream.
http://cream.sourceforge.net/
[^] # Re: Un outils qui empeche les nommages nom comprehensible.
Posté par Yusei (Mastodon) . En réponse au journal Qu'est-ce qu'un outils de développement de rève ?. Évalué à 9.
Je suis d'accord que les attributs d'objets ou les variables globales doivent avoir des noms explicites, mais localement dans une fonction, je préfère un code concis et clair plutôt qu'un code bourré de noms de variables à rallonge qui ne l'explicitent pas réellement.
[^] # Re: Facile
Posté par Yusei (Mastodon) . En réponse au journal Qu'est-ce qu'un outils de développement de rève ?. Évalué à 8.
Naturellement, je répondais en me plaçant de mon propre point de vue, et sans présumer de généralité à ce sujet. À chaque fois que je dis "femme", il faut lire "(ou hommes pour les femmes hétéros ou les hommes homosexuels)".
De la même manière que lorsque je mentionne Emacs, on peut lire entre les lignes "ou Vim pour les femmes et les tapettes".
(Ça y est, je suis mort)
[^] # Re: Facile
Posté par Yusei (Mastodon) . En réponse au journal Qu'est-ce qu'un outils de développement de rève ?. Évalué à 8.
Vous allez voir que bientôt il va être politiquement incorrect de ne pas être bisexuel...
Mon commentaire à moi était une blague tout à fait sérieuse, à ceci près que tant qu'à être dans le domaine du rêve, j'aurais dû demander une ingénieur (ingénieuse ?) plutôt qu'une stagiaire. Et s'il est sexiste de préférer la compagnie des femmes, alors je suis sexiste. Je pense que j'y survivrai.
# Facile
Posté par Yusei (Mastodon) . En réponse au journal Qu'est-ce qu'un outils de développement de rève ?. Évalué à 10.
Quelques esclaves (aka stagiaires) pour coder à ma place.
("Esclave" et "stagiaire" sont à entendre au féminin, évidemment)
[^] # Re: Résumé du journal supprimé
Posté par Yusei (Mastodon) . En réponse au journal Un journal a été supprimé !. Évalué à 9.
[^] # Re: On peut rire de tout ...
Posté par Yusei (Mastodon) . En réponse au journal Campagne de pub Mozilla. Évalué à 10.
(Firefox, aux onglets actifs, lutte efficacement contre le vieillissement)
[^] # Re: C'est trop compliqué !
Posté par Yusei (Mastodon) . En réponse au journal Des langages de haut niveau. Évalué à 3.
- Attentions, ce n'est qu'un premier brouillon: je me suis concentré sur l'organisation des éléments sur la page et la lisibilité, pas sur l'aspect graphique. Que pensez-vous de cette organisation ?
- Il n'y a pas d'images. Vous pensez vraiment que je peux envisager d'avoir un site sans images ? Revenez quand vous aurez mis des images !
[^] # Re: C'est trop compliqué !
Posté par Yusei (Mastodon) . En réponse au journal Des langages de haut niveau. Évalué à 3.
Attaquer Lisaac sur ces points n'est pas pertinent, sauf s'il s'agit d'attaquer ses objectifs. Si tu nous dit que Lisaac a parmis ses objectifs quelque chose qui le rend intrinsèquement moins XXX que Java, alors c'est une remarque intéressante. Si tu nous dit que dans l'implémentation actuelle, il est moins XXX que Java, qu'est-ce que ça signifie ? (remplacer XXX par l'épithète de son choix)
Ça ne peut signifier qu'une chose, c'est qu'étant donné l'état "en développement" de Lisaac, tu ne le choisirais pas pour un projet sérieux à but productif. J'ose espérer que personne ne choisirait un langage dans un stade aussi expérimental pour ça.
Si on commence à flinguer tous les nouveaux langages qui ne sortent pas directement aussi aboutis que le framework Java, où va-t-on ? D'ailleurs, même si quelqu'un sortait un langage aussi abouti que Java du jour au lendemain, on lui ferait le reproche qu'il n'existe pas de programmeurs sachant l'utiliser.
Maintenant, sur le point précis dont on parlait, parce que je m'égare: le langage Lisaac, comme le langage Java, permet d'incorporer du code natif facilement. La plateforme Lisaac, à l'opposée de la plateforme Java, ne permet (peut-être) pas de limiter cela. Cependant, la plateforme actuelle, on s'en fiche un peu, ce qui est intéressant c'est les concepts. Je n'ai pas vu dans ce qu'il a été dit de Lisaac quoi que ce soit qui me laisse penser qu'on ne puisse pas compiler à destination d'une machine virtuelle, et donc profiter des mêmes bénéfices en matière de sécurité. Mais c'est de ça qu'il serait intéressant de discuter, pas du nombre de bugs ou de fonctionnalités de l'implémentation actuelle, qui est du code destiné à la recherche.
Un chercheur n'est pas une équipe d'ingénieurs, enfin. Si les concepts sont suffisamment intéressants et forment un tout cohérent, alors les ingénieurs prendront le relai et en feront quelque chose de fini.
(L'ingénieur peut être la même personne que le chercheur, mais ce n'est pas la même phase du travail de "recherche et développement")
[^] # Re: C'est trop compliqué !
Posté par Yusei (Mastodon) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Je suis d'accord avec ton argument concernant Java (plus de sécurité sauf si on sort consciemment du cadre édicté par le langage), mais il est valable aussi pour Lisaac.
[^] # Re: C'est trop compliqué !
Posté par Yusei (Mastodon) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Nous avons aussi un problème de compréhension au sujet du formalisme utilisé pour la discution. Je parle de machines de Turing, et d'états de machines de Turing, et toi tu me parles d'erreurs d'arrondi et de CPU. Ce n'est pas du tout mon domaine, et j'ajouterais que ça ne m'intéresse pas trop puisque, si on a des problèmes de prouvabilité au niveau des machines de Turing "parfaites", ce n'est pas en ajoutant des possibilités d'erreur au niveau du codage des nombres, ou des problèmes de concurrence, qu'on rendra les choses plus facilement prouvables.
S'il est possible pour un programme quelconque fixé d'écrire mécaniquement un programme qui le valide ou l'invalide, alors il est possible d'écrire un programme qui valide ou invalide tous les programmes.
S'il est possible pour un programme quelconque de trouver un programme qui le valide ou l'invalide, mais qu'on ne peut pas mécaniser ce processus, alors cela revient à dire que c'est algorithmiquement indécidable. C'est donc un objectif inaccessible si la thèse de Church-Turing est vraie, on y revient.
Si on restreint le problème comme tu le fais aux programmes utilisant une mémoire finie, on sort de l'infaisable théorique pour arriver dans l'infaisable pratique, ce qui nous fait une belle jambe. Ca devient faisable théoriquement parce qu'on peut essayer tous les états possibles du programme, mais je serais curieux de voir une méthode générale plus efficace.
Eh bien, soit tu pars d'un jeu de données initial et tu énumères les états en vérifiant qu'on ne revient jamais dans un état déjà visité, soit tu énumères tous les états atteignables et tu vérifies qu'aucun d'eux n'est sur un cycle. Je ne suis pas sûr qu'énumérer les états atteignables soit faisable en général sans énumérer toutes les données initiales possibles, ce qui reviendrait à exécuter le programme pour chaque jeu de données possible.
Formulé plus simplement, ce que je ne vois pas, c'est comment tu prouves qu'un état n'est pas sur un cycle sans partir d'un état initial, avancer jusqu'à cet état, et prouver qu'ensuite on ne revient pas à un état déjà visité. (Par état, je parle d'un état d'une machine de turing associé à ce qui est écrit sur le ruban.)
Typiquement ton programme est un graphe où les noeuds sont des états et les arêtes des transitions. Tu peux faire mieux qu'énumérer tous les états (et donc toutes les données possibles) à condition de pouvoir compacter plusieurs noeuds en un seul, c'est à dire qu'au lieu d'avoir des états de type: (X, d) avec d un jeu de données, tu auras des états de type (X, D) avec D un ensemble de jeux de données.
Ce qui m'intrigue, c'est comment on pourrait faire cette compaction dans le cas général. Je n'ai pas de preuve formelle que ce soit impossible de le faire de manière plus efficace qu'en énumérant tout, mais intuitivement ça me semble évident.
[^] # Re: C'est trop compliqué !
Posté par Yusei (Mastodon) . En réponse au journal Des langages de haut niveau. Évalué à 2.
C'est ce que je disais plus haut, et à quoi tu répondais "euh non, pas du tout": tu peux toujours exécuter le programme et voir ce que ça donne. Si tu bornes la taille mémoire utilisable, que tu stockes tous les états complets du programme et qu'à chaque étape tu vérifies que tu ne retombes pas dans un état déjà visité, alors en un temps irréaliste et avec une mémoire irréaliste, tu peux savoir si ton programme s'est terminé ou pas pour ces données là.
C'est un résultat relativement inutile. J'ose espérer que quand on parle de "preuve de programme" on essaye d'avoir une certaine généralité. Ici, on devra réappliquer la même procédure pour chaque nouveau jeu de données, et cette procédure ne fait rien économiser par rapport à exécuter le programme sans rien prouver.
Malheureusement les résultats un peu généraux sont algorithmiquement indécidables.
Pour conclure de mon côté, je renverrais les lecteurs intéressés, s'il en reste, vers le théorème de Rice pour plus de détails:
http://en.wikipedia.org/wiki/Rice's_theorem
http://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_de_Rice
La page française mentionne l'indécidabilité algorithmique du problème suivant, par exemple: « le programme calcule un résultat correct par rapport à la spécification ».
(Ce qui, encore une fois, ne veut pas dire que l'on ne peut jamais rien prouver. En restreignant les problèmes considérés, on peut se ramener à des cas gérables.)
[^] # Re: C'est trop compliqué !
Posté par Yusei (Mastodon) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Une preuve fausse n'a pas beaucoup d'intérêt.
Tu peux aussi démontrer qu'il ne se termine pas. Mais dans la plupart des cas, tu ne pourras démontrer ni l'un ni l'autre, et c'est tout le problème.
Par état souhaitable, tu veux dire état dont on sait qu'il mêne au bon résultat (et à une terminaison du programme) ? Si c'est le cas, alors la détermination des états souhaitables revient à prouver le programme, et est impossible dans le cas général par quelque chose de puissance équivalente à une machine de Turing (MT).
Prouver qu'un programme termine (sur un jeu de données fixé) n'est qu'une question de temps: il suffit de l'exécuter. Prouver qu'un programme ne termine pas est une autre paire de manches.
Je pense qu'il est temps de recentrer un peu le débat, car on s'éloigne un peu. Tu disais que du moment qu'on a un langage Turing complet, on peut prouver ses programmes. Or, tout langage Turing complet permet de produire des programmes dont on ne peut pas prouver la terminaison avec quelque chose de la même puissance qu'une MT.
Je ne sais pas comment expliquer ça de manière plus claire. Tu as l'air de penser qu'à partir du moment où on choisit un programme en particulier, alors il devient prouvable. Ce n'est vrai que dans des cas particuliers. Il n'est pas possible d'écrire un programme validant la terminaison d'un autre programme quelconque. Tu peux penser qu'un humain peut le faire, mais ça suppose que la thèse de Church-Turing est fausse. En tout cas, une MT ne peut pas le faire, c'est un résultat mathématique bien établi.
[^] # Re: C'est trop compliqué !
Posté par Yusei (Mastodon) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Par "pas de code natif", je suppose qu'il voulait interdir l'utilisation de JNI, qui est la principale interface vers l'extérieur de la JVM. Quand tu utilises JNI, tu codes en C (ou équivalent), alors, naturellement, ce n'est pas plus sûr que coder en C. Sans JNI, et en admettant l'utilisation d'une JVM sans failles, je ne pense pas qu'il y ait moyen de faire grand chose.
[^] # Re: C'est trop compliqué !
Posté par Yusei (Mastodon) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Quand tu dis qu'à partir du moment où on a un langage Turing complet, on peut prouver le code, je ne comprends pas "dans certains cas, c'est facile".
Si tu confirmes que dans ce que tu appelles "prouver le code", on peut inclure "prouver que le programme se termine", alors ton hypothèse "on peut prouver n'importe quel programme d'une machine de Turing" repose sur le fait que le cerveau humain est plus puissant qu'une machine de Turing.
[^] # Re: C'est trop compliqué !
Posté par Yusei (Mastodon) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Peut-être faudrait-il préciser ce qu'on entend par "prouver", parce que pour moi, même prouver qu'un programme s'arrête, c'est balaise... alors prouver qu'il fait bien ce que l'on veut...
Peut-être parlais-tu de prouver que le code produit est bien "identique" au code source ?
[^] # Re: C'est trop compliqué !
Posté par Yusei (Mastodon) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Lisp (langage cité par le post grand-parent) n'est pas spécialement un langage de haut niveau, tout dépend du formalisme dans lequel on se place. C'est quasiment une traduction directe du lambda calcul, donc ça pourrait être qualifié de "bas niveau". Il y a même eu des machines comprenant directement le Lisp.
[^] # Re: air de déjà vu
Posté par Yusei (Mastodon) . En réponse au journal Ror ne se porte plus très bien ? Quid des autres ?. Évalué à 2.
Vilain fredix, arrête de cantonner Ruby, s'il te plaît.
Rails facilite la maintenance et l'évolution de la même manière que le développement. Ses atouts qui rendent le développement rapide rendent également la maintenance et l'évolution relativement aisés. Je parle d'expérience, pour avoir dû gérer un projet dont le cahier des charges évoluait de jour en jour, de façon parfois drastique.
En fait, je dirais même que Rails est plutôt destiné aux projets qui ne sont pas bien définis ou qui vont beaucoup évoluer. De même que Ruby est surtout efficace pour prototyper rapidement une application, au détriment de la rapidité d'exécution.
En entreprise, il peut y avoir des besoins forts en termes de performance. Il peut aussi y avoir des besoins forts en terme de rapidité de développement et d'évolution. Qui a dit que les mêmes outils devaient servir dans tous les cas ?
Les cas où Rails est trop lent et où il est le facteur limitant sont relativement réduits: jusqu'à quelques centaines d'utilisateurs concurrents, un gros serveur bien configuré n'aura pas vraiment de mal. Un bon serveur a un coût négligeable pour une entreprise qui a plusieurs centaines d'utilisateurs concurrents. Et multiplier les serveurs est un bon moyen de monter en charge tout en améliorant la fiabilité. Alors, certes, gérer des millions d'utilisateurs concurrents (la précision est importante) est peut-être difficile en Rails, mais ça représente une portion infime des besoins des entreprises.
Je n'essaye pas de dire que Ruby et Rails sont des outils universels, mais je pense qu'il est vraiment simple d'identifier quand un projet sera trop lourd pour cet outil, et que dans les autres cas, lorsque c'est possible, on gagne à l'utiliser.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Yusei (Mastodon) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 2.
- Mauvaise développeur implique mauvais code, donc PHP est aussi bien qu'un autre langage.
- Linux (codé en C) est plus abouti que The Hurd (codé en C), donc le choix du langage n'est pas important.
C'est bien ça ?
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Yusei (Mastodon) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 3.
Formulé autrement, parce que je conçois que ce ne soit pas très clair: qu'est-ce que c'est que ces âneries ? Je ne sais pas si tu essayes de faire passer un message, c'est un peu masqué par la forme ridicule de tes propos, mais tu as l'air d'être passé complètement à côté du fait que mon post était une plaisanterie.
En admettant que tu sois sérieux, j'aimerais bien savoir où tu as cru voir quelqu'un prétendre que le "facteur humain" n'était pas le plus important.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Yusei (Mastodon) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 2.
Mais voyons, on chipote aussi sur le facteur humain. Si tu as des doutes à ce sujet, tu n'as qu'à créer un journal disant que tu hésites entre aller à l'Epita et à la fac.
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Yusei (Mastodon) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 2.
[^] # Re: *hum hum*
Posté par Yusei (Mastodon) . En réponse au journal Mes prédictions pour 2008. Évalué à 2.
En français, une alternative est un choix entre deux possibilités, il n'y a pas de "troisième alternative". Même si tu as certainement raison sur ce que l'auteur voulait dire, l'interprétation de celui qui lui répond est tout à fait légitime.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Yusei (Mastodon) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 3.
Le langage est important justement parce que j'ai autre chose à faire que de coder. Je n'aime pas coder.
Elle est bien bonne, celle là. Au passage, je doute fort que nous ayons le même métier.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Yusei (Mastodon) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 4.
En une heure de temps, la cervelle peut résoudre un nombre limité de problèmes. Selon les cas, la cervelle peut travailler à résoudre le problème sur lequel elle travaille, ou bien travailler à résoudre les problèmes posés par son outil. L'informaticien est donc plus efficace lorsque son outil n'oblige pas sa cervelle à penser à l'outil, mais la laisse se concentrer sur le problème réel.
Je préfère Ruby à Perl parce que j'ai moins besoin de réfléchir à son fonctionnement (et je préférais Perl à C pour les mêmes raisons). Je n'ai pas à me souvenir si le nom de ma variable doit commencer par un $, un % ou un @, si je dois utiliser des crochets ou des accolades, comment sont automatiquement convertis les types, etc. De nombreuses fois, plutôt que d'ailler regarder dans l'API comment on fait une chose, je l'ai écrite comme je pensais que ça devrait s'écrire... et ça a marché.
Pour reprendre ton argument, je pourrais dire qu'un bon mathématicien n'est pas là pour aimer les mathématiques, mais pour trouver des théorèmes. Ce n'est pas avec un formalisme qu'on travaille, mais avec sa cervelle. Par conséquent, il ne sert pas à grand chose de développer de nouveaux formalismes équivalents à des formalismes existants. Par exemple, le lambda calcul ne sert à rien puisqu'il est équivalent aux machines de Turing.
Et pourtant, en formulant les choses différemment, on peut parfois trouver une solution plus facilement. Quand il est difficile/pénible d'exprimer un concept dans un langage, on ne peut pas attendre du programmeur d'utiliser ce concept naturellement. Ce n'est pas qu'une histoire de concision.
Évidemment, la plupart des langages de programmation visent l'universalité, et donc essayent d'incorporer le plus possible de concepts. Ce n'est pas pour cela que ces concepts sont naturels, et ce n'est pas suffisant pour conclure que tous les langages se valent.