Journal Votre langage idéal ?

Posté par . Licence CC by-sa
8
28
jan.
2012

Suite à la sortie de Rust qui n'a franchement pas déclenché les passions, je me suis demandé : quel est le langage idéal ? Et forcément, comme tous les goûts et les couleurs sont dans la nature, chacun a sa propre opinion sur le sujet. Alors, je pose la question à la grande communauté linuxfr : quel est votre langage idéal en terme de fonctionnalités ? Bon, on évitera de citer des langages existants tel quel, parce qu'aucun langage n'est parfait.

De mon côté, j'aimerais bien un langage impératif procédural genre C, avec gestion manuelle de la mémoire, mais avec des fonctionnalités supplémentaires. J'aimerais bien avoir du sous-typage (héritage sans polymorphisme) histoire d'éviter de caster quand on adopte une conception objet. J'aimerais aussi avoir un système du genre interface ou template histoire de pouvoir faire du code un peu générique. J'aimerais avoir des generics à la Java pour être un peu plus sûr au niveau des types dans les containers. En revanche, je ne mettrais aucun des trucs à la mode du genre closure, programmation fonctionnelle, garbage collector. Surtout, je ne mettrai pas la concurrence dans le langage, parce qu'on n'a pas encore assez d'expérience sur le parallélisme pour savoir quel est le bon paradigme à utiliser, et fixer un paradigme dans le langage est à mon sens une erreur.

Et vous, vous en pensez quoi ?

  • # Mes idéaux

    Posté par (page perso) . Évalué à  1 . Dernière modification : le 28/01/12 à 16:30

    Un qui soit fait de manière concertée entre plusieurs entreprises, "plusieurs" étant supérieur à 10 minimum, montrant que c'est pas une entreprise dans son coin qui veut faire un truc qu'il jettera quand plus besoin ou qu'il fera évoluer la licence ou l'évolution comme il a envie (Allez, une liste : Go, Rust, Java, C#...)
    Un qui passe les organismes les plus connu (genre ISO)
    Un qui ne casse pas la compatibilité au bout de 10 ans, un que je sais que je pourrai compiler le code das 10 ans (pas exemple : Python)
    Un qui soit utilisé par beaucoup de monde
    Un qui marche autant sur une petite machine qu'une grosse (non, pas de machine virtuelle)

    Bon, ça existe (je laisse trouver le/les noms ;-) ), avec ses défauts certes, mais c'est le prix à payer quand ça existe depuis 30 ans et que ça tourne sur des milliers d'architectures différentes ;-).

    • [^] # Re: Mes idéaux

      Posté par . Évalué à  8 .

      COBOL je t'ai reconnu !

    • [^] # Re: Mes idéaux

      Posté par . Évalué à  5 . Dernière modification : le 28/01/12 à 17:46

      (pas exemple : Python)

      Tu veux dire ?

      (pas python par exemple)

      Sinon C++ répond plutôt bien à ce que tu décris. Peut être pas aussi portable que ça néanmoins. Sinon,

      un que je sais que je pourrai compiler le code dans 10 ans

      Je pense que tu parles du C évidemment, notamment pour la portabilité.

      Bon mais je sais que tu codes en C++, donc tu es de parti pris, de même quand tu donnes ton lien plus bas.

      Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

      • [^] # Re: Mes idéaux

        Posté par (page perso) . Évalué à  0 .

        (pas exemple : Python)

        Tu veux dire ?

        Euh... Essaye de compiler du code Python 2 avec Python 3 pour voir.
        Non, c'est vrai, ce n'est pas du tout un problème connu, c'est pas comme si plein de code n'était pas bloqué à Python 2...

        Avec ce genre de surprise, Python est un langage avec une confiance 0 dans la pérennité du code.

        • [^] # Re: Mes idéaux

          Posté par . Évalué à  2 .

          Non, c'est juste que ton

          (pas exemple)

          ne me semblait pas syntaxiquement correct. Je suis d'accord avec toi qu'un code python n'est pas très pérenne. Mais ça, c'est parce que la compatibilité a été volontairement cassée avec python3. Peut être que python2 peut compiler du code python1 par exemple (mais je ne m'avancerai pas trop là dessus non plus).

          Je suis donc d'accord que python n'est pas un exemple pour la stabilité, c'est dommage mais c'est comme ça, et je trouve que c'est normal avec les machines virtuelles, on les mets à jour, les API évoluent, c'est comme ça... C'est l'intérêt des langages interprétés. C'est plus difficile d'aller modifier la syntaxe d'un langage compilé, on a tout intérêt à ce qu'elle reste stable pour éviter de réécrire un compilateur à chaque fois je suppose...

          Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

        • [^] # Re: Mes idéaux

          Posté par . Évalué à  1 .

          Ce n'est pas un problème. Python2 est maintenu, et le sera très longtemps vu la quantité de (gros) systèmes qui reposent dessus. Python3, j'avoue que je ne sais pas. Tout les systèmes d'exploitation proposent les deux environnements, le plus gros problème c'est le manque de portabilité potentiel des shebang.

          Please do not feed the trolls

        • [^] # Re: Mes idéaux

          Posté par (page perso) . Évalué à  3 .

          On n'est pas bloqué et il n'y a pas de surprise vu que la version 2 est encore maintenue et pour pas mal de temps encore...
          Du reste, dans la plupart des cas la migration sera triviale, le seul problème c'est les librairies et ça c'est valable pour tous les langages même s'ils ne changent pas eux-même...

          La pérennité du code c'est valable dans une bulle, et dans ce cas peu importe si le langage évolue ou pas...

        • [^] # Re: Mes idéaux

          Posté par (page perso) . Évalué à  2 .

          Si on essaie d'améliorer les choses, de corriger des mauvais choix passés (plutôt que de se les traîner jusqu'à la fin des temps), alors on risque de casser la compatibilité.
          Si on garde la compatibilité, alors on peut être accusé de demi-mesures, de garder des choses ante-diluviennes et donc d'avoir trop de manières de faire la même chose et de rendre le langage trop complexe.

          J'avoue que je n'ai pas vu si il y avait des alternatives à l'évolution de Python, et je n'ai pas fait migrer de script.

          • [^] # Re: Mes idéaux

            Posté par . Évalué à  6 .

            Si on garde la compatibilité, alors on peut être accusé de demi-mesures

            Oui mais quite à casser la compatibilité ascendante, Python 3 aurait put aller beaucoup plus loin. Entendons nous bien, je suis tout à fait d'accord sur le fait que Python 3 est meilleur que Python 2.

            Mais à partir du moment ou il a été décidé de casser la compatibilité, il aurait fallut en profiter pour nettoyer le langage bien plus profondeur. Faire en sorte que la bibliothèque standard respecte la PEP-8 par exemple. Ou encore fournir plus de méthodes au types de base, remplacer certaines primitives comme len() par des méthodes.

            Enfin bref, pour avoir migré du code Python 2 en Python 3 récemment, le sentiment que j'en retire est que certes c'est mieux, mais je ne suis pas certain que le jeux en valait la chandelle.

        • [^] # Re: Mes idéaux

          Posté par . Évalué à  1 . Dernière modification : le 30/01/12 à 10:34

          Tu peux toujours obtenir la version 2 de Python. Donc oui, tu peux toujours le compiler ton ancien code...

          Sur le site python.org : The current production versions are Python 2.7.2 and Python 3.2.2.

          • [^] # Re: Mes idéaux

            Posté par . Évalué à  1 .

            compiler interpréter. Pardon aux familles.

            • [^] # Re: Mes idéaux

              Posté par . Évalué à  3 .

              Distinction à la noix, Python fait de la compilation vers du bytecode depuis des lustres. "Interpréter" ne veut plus rien dire de nos jours, c'est du FUD répandu par des gens qui veulent entretenir une distinction ignorante et subjective entre différents langages de programmation.

              Python est lent (ou plutôt, très difficile à rendre rapide) parce que c'est un langage dynamique dont les constructions de base permettent de faire tout et n'importe quoi sans garantie sur le code (enfin avec une certaine retenue, c'est moins délirant que le monkey-patching qu'adorent les rubystes dégénérés), pas parce qu'il serait "interprété" plutôt que "compilé".

              • [^] # Re: Mes idéaux

                Posté par . Évalué à  2 .

                Je suis assez d'accord avec toi. En fait je me demande si on ne pourrait pas dire qu'un langage interprété est un langage compilé à la volée ? C'est bien toujours du code machine in fine.

                • [^] # Re: Mes idéaux

                  Posté par . Évalué à  5 . Dernière modification : le 30/01/12 à 11:26

                  Non, je ne pense pas. Pour moi une implémentation qui compile à la volée est un compilateur (... à la volée). Note le choix du mot "implémentation" et pas "langage"; un langage n'est pas forcément défini par une implémentation unique, ça n'a pas de sens par exemple de dire que C est langage "interprété" parce qu'il existe des interpréteurs de C.

                  Littéralement un interpréteur est une implémentation qui exécute le programme directement en parcourant le code source, sans aucune étape de transformation intermédiaire. En pratique il y a toujours une phase de parsing voire de simplification et tu as donc une définition molle de "travaille sur une donnée qui a conservé la structure du programme initial". Toute phase de transformation globale qui change sa structure (pour la simplifier en général) est une forme de compilation.

                  Le terme "interpréter" a encore du sens quand on fait des sémantiques formelles de langages de programmation théoriques, où certaines sémantiques (sémantiques opérationnelles) sont clairement des "interprétations", et d'autres (exécution sur machines virtuelles, ou même certaines sémantiques dénotationnelles) des "compilations". Pour ce qui est des langages réels raisonnables, il faut l'éviter comme la peste car il est entouré de trop de bêtises.

                  • [^] # Re: Mes idéaux

                    Posté par . Évalué à  2 .

                    Perso. je m’en tiens à la définition à grand papa : la compilation doit permettre d’obtenir un exécutable pour la machine (pas virtuelle, physique) sur laquelle le programme va s’exécuter. Du coup, oui, un code « compilé » est plus performant qu’un code interprété. Peut-être vaut-il mieux parler de langage avec machine virtuelle ou pas.

                    • [^] # Re: Mes idéaux

                      Posté par . Évalué à  5 .

                      Mais dans ce cas, je peux aussi dire qu'aucun langage n'est "compilé" selon ta définition, puisque le jeu d'instruction x86 est une machine virtuelle dont les opcodes sont reconverties au vol par le processeur vers des sets de microcode RISC-style plus efficaces, en tout cas sur toutes les architectures récentes (eg. Sandy Bridge).

                      Ou alors les téléphones portables qui gèrent le bytecode Java au niveau matériel (cf. Jazelle), ça fait de Java (ou Scala, Clojure...) un langage compilé selon ta définition ?

                      • [^] # Re: Mes idéaux

                        Posté par . Évalué à  3 .

                        opcodes sont reconverties au vol par le processeur vers des sets de microcode RISC-style

                        Je ne m’y connais pas, mais dit comme ça, j’aurai plutôt classé ça comme de la traduction, non ? C’est-à-dire qu’il y une équivalence directe entre l’opcode et la série d’instructions RISC-style, un peu comme l’assembleur je veux dire.

                        Ou alors les téléphones portables qui gèrent le bytecode Java au niveau matériel (cf. Jazelle), ça fait de Java (ou Scala, Clojure...) un langage compilé selon ta définition ?

                        Parfaitement. Et j’ajouterai que comme la notion de compilation va forcément avec une cible de compilation, je dirai que le Java est un langage (partiellement) compilé pour Jazelle, alors qu’il n’est qu’interprété pour des processeurs plus classiques. D’après la page wikipedia, le bytecode java n’est pas totalement compris par le hard. Sans oublier que, comme dit par toi-même je crois, cette histoire d’interprété/compilé concerne avant tout l’implémentation, et n’est pas une qualité intrinsèque d’un langage.

              • [^] # Re: Mes idéaux

                Posté par . Évalué à  2 .

                Python est lent (ou plutôt, très difficile à rendre rapide) parce que c'est un langage dynamique dont les constructions de base permettent de faire tout et n'importe quoi sans garantie sur le code (enfin avec une certaine retenue, c'est moins délirant que le monkey-patching qu'adorent les rubystes dégénérés), pas parce qu'il serait "interprété" plutôt que "compilé".

                C'est toi qui parle de FUD ? Les new-style classes (http://realmike.org/blog/2010/07/18/introduction-to-new-style-classes-in-python/) qui n'ont de nouveau que le nom, permettent d'écrire des classes qui n'ont plus la « dynamicité » classique et qui consomment moins de ressources et moins de mémoire. Ça n'est pas plus compliqué que de savoir gérer sa mémoire en C/C++.

                Il reste des langages qui ne sont pas compilés mais directement exécutés, les scripts shell par exemple. Pour ruby le passage à du JIT est assez récent aussi.

                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                • [^] # Re: Mes idéaux

                  Posté par . Évalué à  4 .

                  Consommer moins de mémoire c'est bien, mais de là qualifier mon reproche de "FUD" je pense que tu vas un peu loin. Les new-style classes garantissent que le nombre de membres des instances d'une classe ne change pas; c'est bien, mais ça ne suffit pas : la preuve, CPython ne va toujours pas follement plus vite qu'avant, et est bien plus lent qu'une implémentation codée avec efforts équivalents¹ pour un langage plus sobre, LuaJIT.

                  Si tu veux un truc qui ressemble à du python et qui est vraiment implémentable rapidement, il vaut mieux parler de RPython à mon humble avis.

                  ¹: oui c'est important de prendre en compte l'effort qui va dans les implémentations; on ne peut pas vraiment comparer l'état de Pypy et celui des machines virtuelles Javascript par exemple, parce que dans le second cas des dizaines d'années de travail ont été investies au total, pour rendre rapide des implémentations d'un langage très difficile à implémenter rapidement.

    • [^] # Re: Mes idéaux

      Posté par . Évalué à  5 .

      Un qui passe les organismes les plus connu (genre ISO)

      Je ne suis pas sûr que ce soit un gage de sérieux. Sans même aller jusqu'aux affaires qui ont eu lieu avec ODF, je pense que le processus pour accoucher de C++11 a été assez catastrophique. Il y a une inertie à l'ISO qui peut être assez rédhibitoire quand il s'agit de faire évoluer un langage.

      • [^] # Re: Mes idéaux

        Posté par (page perso) . Évalué à  2 .

        Il y a une inertie à l'ISO qui peut être assez rédhibitoire quand il s'agit de faire évoluer un langage.

        Effectivement, il n'y a pas plus rapide qu'une bonne vieille dictature (ça a bien prouvé son efficacité), ça marche aussi pour la politique réelle.

        Question de choix, je préfère la démocratie lente à la dictature rapide : mettre des gens d'accord sera toujours plus lent qu'imposer un choix arbitraire.

    • [^] # Re: Mes idéaux

      Posté par (page perso) . Évalué à  9 .

      Je pratique (ou ai pratiqué) le C++ et le Python à titre personnel comme à titre professionnel, et ce sont 2 langages que j'affectionne beaucoup.

      Je vais répondre à la pique sur Python. Tu penses que la cassure Python2/Python3 est une erreur, et tu as raison dans la mesure où, si cette politique était appliquée au C++, cela provoquerait une catastrophe. Mais les situations de Python et de C++ sont très différentes, et donc ce qui est bon pour l'un ne l'est pas forcément pour l'autre. Je m'explique.
      Le Python a une implémentation de référence (CPython), qui est utilisée par 99% des gens. On peut trouver ça dommage. Mais bon cette implémentation est libre, gratuite, multiplateforme, plutôt performante, ce qui fait que globalement on n'a pas trop à se plaindre.

      • Du coup quand une nouvelle version sort, on peut si on le veut utiliser les nouvelles fonctionnalités tout de suite, pas la peine de se demander quand est-ce que la majorité des implémentation auront un support suffisant (par exemple la gestion catastrophique des templates par VC++6), ou bien de faire plusieurs version du même code suivant le compilateur (avec de la compilation conditionnelle). Pas non plus de fonctionnalité dans le standard mais implémentée par personne ('import' du C++).
      • La branche 2 sera maintenue par l'équipe Python pendant des années ; en plus les dernières versions de cette branche (2.6, 2.7) se sont beaucoup rapprochées de la branche 3. Au final l'effort à fournir est minime (et il existe un outil officiel qui fait la conversion) et on a des années pour faire ce petit effort. À côté de ça, dans la pratique, malgré la non cassure du monde C++, si tu trouves un vieux projet C++ qui a traîné des années sans avoir bougé, pas sûr qu'il compilera sans problème, pour peu qu'il s'appui sur d'autres bibliothèques qui elles auront évolué. De toutes les manières un code non maintenu finit par mourir.
      • Il y a évidemment bien moins de logiciel en Python qu'en C++, et leur code est sûrement bien plus petit (c'est bête mais pragmatique).

      Je vis en faisant du Python (c'est donc un peu plus qu'un simple amusement sans conséquence), et le passage à Python3 ne m'effraie du tout, j'ai même hâte de le faire.
      Les langage C++ et Python évoluent de manière différente, mais à mon avis les 2 le font assez bien (même si je suis assez déçu de la dernière version de C++).

      • [^] # Re: Mes idéaux

        Posté par . Évalué à  9 .

        La branche 2 sera maintenue par l'équipe Python pendant des années.

        J'ai des trucs écrits en fortran 77 et je code principalement en C89 (une fois j'ai essayé d'apprendre fortran 90 mais j'ai tout oublié, et en C j'utilise parfois quelques trucs de C99 mais globalement, je me limite à la base de la base : pour ce que je fais ça me suffit).

        Je n'imagine même pas que gcc puisse un jour même lointain arrêter le support de f77 ou c89. Alors si on me dit que le support de python 2 c'est « des années », ça sous-entend déjà qu'ils pourraient décider d'arrêter et ça rassure pas du tout pour la pérennité de l'éventuel code que je pourrais écrire si je m'y mettais.

        • [^] # Re: Mes idéaux

          Posté par (page perso) . Évalué à  3 .

          Le Fortran évolue rapidement et profondément... Enfin, plus que le C ;-) Comme dans tous les langages, a chaque version, ils annoncent qui suppriment quelques anciennes formes afin de nettoyer le langage de vieux truc. Le Fortran d'aujourd'hui n'a plus grand chose à voir avec le F77.

          • [^] # Re: Mes idéaux

            Posté par (page perso) . Évalué à  3 .

            (...) qui suppriment quelques anciennes formes afin de nettoyer le langage de vieux truc.

            Supprime, ou taggent en "legacy"? Ca fait une sacré différence.
            Un compilo Fortran d'aujourd'hui peut-il compiler du F77?
            Mon reproche envers l'évolution de Python n'est pas qu'ils fassent évoluer le langage, mais qu'ils jettent la compatibilité (l'outil "automatique" n'est pas si automatique que ça, en tous cas sur mon code il a complètement abandonné). Le "legacy", c'est important (pour certains, certes).

            • [^] # Re: Mes idéaux

              Posté par (page perso) . Évalué à  3 .

              Je pense que gfortran a évidemment un mode de compatibilité F77 mais à vrai dire, je ne veux plus voir du F77 car le Fortran moderne, c'est quand même autre chose...

              Sinon, il fallait pas prendre Python mais Perl, mes programmes réalisés il y a 15 ans marche toujours sans aucune modification aujourd'hui ;-)

              • [^] # Re: Mes idéaux

                Posté par . Évalué à  1 .

                mode de compatibilité F77

                Mais il y a des constructions qui ont été supprimées. Je sais que c’est au moins le cas pour le f95 (cf. wikipedia anglaise).

              • [^] # Re: Mes idéaux

                Posté par . Évalué à  4 .

                La différence qui compte c'est quand même la fin de l'obligation de compter les colonnes, qui est quand même un changement important qui a cassé la compatibilité avec tout le code ancien.

                Pour les plus jeunes, en Fortran 77, les 6 premiers caractères de la ligne sont utilisés pour les étiquettes, les caractères 7 à 72 servaient pour le code, et le reste était ignoré, donc était utilisé pour mettre des annotations. Cette façon de faire adaptée aux cartes perforées peut provoquer des bugs assez comiques si l'on n'y prend garde...

                • [^] # Re: Mes idéaux

                  Posté par (page perso) . Évalué à  2 .

                  les 6 premiers caractères de la ligne sont utilisés pour les étiquettes,

                  Tsss... les cinq premières colonnes sont utilisée pour un éventuel label numérique, et la sixième pour un éventuel caractère indiquant que c'est la suite de la carte précédente.

                  * Ils vendront Usenet quand on aura fini de le remplir.

        • [^] # Re: Mes idéaux

          Posté par (page perso) . Évalué à  3 .

          ça sous-entend déjà qu'ils pourraient décider d'arrêter et ça rassure pas du tout pour la pérennité de l'éventuel code que je pourrais écrire si je m'y mettais.

          Ce n'est pas un sous entendu : le destin de la branche 2 est de mourir, remplacée par la branche 3 (encore une fois les différences sont minimes et valent le coup à mon avis). Donc effectivement, si ta façon de bosser est d'écrire du code, et de ne plus y toucher pendant 30 ans, alors non le Python n'est pas pour toi. Mon post n'avait pas pour but de faire la promotion de Python, il a déjà une active communauté (que d'autre bons langages n'ont pas).

          Il faut bien voir qu'une nouvelle version de Python sort en moyenne tous les 2 ans, avec à chaque fois des fonctionnalités bien vues, qui vont permettre d'améliorer lentement mais sûrement les applications. Passer de Fortran77 a Fortran90, ça serait comme passer de Python1.0 à Python3.0, ce que personne ne fait, ne serait-ce que parce que personne n'utilise plus la branche 1, et les premières versions de la branche 2 ne doivent plus l'être non plus. Si il y avait eu Fortran79, Fortran81, etc... avec à chaque fois tous les compilateurs mis à jour en même temps, des fonctionnalités alléchantes mais qui permettent une évolution progressive, peut-être que ton code Fortran77 aurait été amené en douceur vers Fortran90, pour un code plus simple et maintenable (peut être même plus efficace, je ne connais pas Fortran).

          • [^] # Re: Mes idéaux

            Posté par (page perso) . Évalué à  5 .

            Cette notion que casser des programmes qui marchent, c'est toujours "les améliorer" me fatigue. Un programme qui a été développé, qui marche bien, qui est en prod depuis plusieurs années, pourquoi devrait-il être modifié ?

            • [^] # Re: Mes idéaux

              Posté par . Évalué à  1 .

              Personne ne t'oblige à le modifier. Tu gardes la même version du compilateur et voilà. Tu dois le modifier si tu comptes continuer à le compiler avec des versions suivantes du langages, ce que tu fais si tu veux profiter des nouvelles fonctionnalités ajoutées depuis son écriture (ou le combiner avec des projets qui le font).

              C'est donnant-donnant, si tu veux profiter des nouvelles fonctionnalités ajoutées par les développeurs, tu acceptes aussi de prendre en compte les modifications qu'ils ont effectuées pour améliorer la qualité du langage ou se simplifier la vie.

              Si tu refuses ce choix, pas de problème, (si l'implémentation est libre) le compilateur avec la version qui t'intéresse tu l'as, tu le gardes en prod depuis des années, et tu pourras continuer à l'utiliser tant que tu veux... et que tu ne changes pas ton environnement, et ouais, mais pourquoi changer un environnement qui marche en prod depuis des années de toute façon ?

              • [^] # Re: Mes idéaux

                Posté par (page perso) . Évalué à  2 .

                Personne ne t'oblige à le modifier. Tu gardes la même version du compilateur et voilà.

                Cool, donc si je veux mélanger deux lib, faut prier pour que ce soit la même version du compilo... Euh... C'est justement le reproche!

                Ca serait plus évident alors d'appeler le langage avec un autre nom, pour bien dire "vous en chierez autant que si vous essayer de faire cohabiter un programme Python avec un programme Java"

                et ouais, mais pourquoi changer un environnement qui marche en prod depuis des années de toute façon ?

                Support de sécurité, souhait d’avoir les nouveautés?
                Dans les langages qui font attention, ça n'oblige pas à recoder...
                C'est justement la remarque, balayées genre "ben on s'en fout". Ben non, des gens ne s'en foutent pas.

                • [^] # Re: Mes idéaux

                  Posté par . Évalué à  3 .

                  Je suis bien conscient et je n'ai pas dit qu'on s'en moquait, loin de là. Mais je pense qu'il faut assumer un peu. Quand on lit le message ci-dessus on dirait que les développeurs Python/whatever lui mettent un flingue sur la tempe pour le forcer à changer son code. Ben non, il a codé contre une version donnée du langage, il peut continuer à maintenir l'environnement de programmation qu'il avait, sans changer une seule ligne. S'il doit changer c'est parce qu'il veut utiliser du nouveau, et là il faut accepter que la nouveauté a aussi des inconvénients.

                  Je comprends très bien ta critique de l'instabilité de certains langage. Mais c'est quelque chose dont les gens sont au courant, et qu'il faut assumer. Si ta priorité c'est d'écrire du code en production qui tourne pendant des années sans aucune maintenance, tu utilises un langage connu pour être resté stable (ou au moins avoir soigné la compatbilité arrière) dans le passé. Tu codes pas ton truc dans le dernier langage de script à la mode.

                  Tout ça est une question de compromis faits par des adultes responsables et consentants. On ne va pas me faire pleurer sur le thème "bouh je suis forcé de mettre à jour mon code", c'est pas vrai, personne n'est obligé à quoi que ce soit, les gens font leurs choix.

            • [^] # Re: Mes idéaux

              Posté par (page perso) . Évalué à  6 .

              Cette notion que casser des programmes qui marchent, c'est toujours "les améliorer" me fatigue. Un programme qui a été développé, qui marche bien, qui est en prod depuis plusieurs années, pourquoi devrait-il être modifié ?

              Je ne force personne à changer son code (enfin sauf mes collègues ! :) ). Ceci dit, je pense que dans l'ensemble, en informatique, on souffre beaucoup plus du pattern "ah oui ce truc a été écrit par Jean-Louis y a 15 ans, personne ne sait ce que ça fait exactement alors on y touche pas" que gens qui aiment réécrire leur code en mieux.

              Ça ne veut pas dire qu'ils faillent tout refaire depuis zéro tous les 3 mois ; mais dans le cas présent passer 2 jours en 10 ans, ça me paraît acceptable. Tous les choix techniques sont des compromis, et en tant que Pythoniste je suis content que cela soit cette voie qui soit prise (plutôt que l'immobilisme de Java par exemple).

              De toutes les façons, il ne faut pas rêver, un système informatique nécessite de la maintenance, l'immortalité n'est pas de ce monde. Si il veut recompiler son programme Fortran77 avec le dernier GCC et bénéficier des dernières optimisations, il faut que des gens aient porté Fortran77 avec la dernière infrastructure de GCC. S'il veut juste tourner sur le dernier Linux sans recompiler son programme, il faut que les développeurs Linux fassent attention à ne pas casser l'ABI. Si il ne veut rien changer du tout au soft, et compte faire tourner la bécane telle quelle pendant 30 ans, il lui faudra quand même prévoir des pièces de rechange, car le hardware ça vieillit.

              Mais si un jour plus personne n'est prêt à payer (en temps ou en argent peu importe) pour que Fortran77 soit maintenu dans GCC, et bien le support sera jeté, c'est comme ça. Mais croire que ne rien toucher suffira pour que ça continue à marcher comme avant, alors que le coeur de GCC aurait été réécrit pour bénéficier des dernières avancées en terme de compilation, c'est se mettre le doigt dans l'oeil. On ne peut pas avoir le beurre et l'argent du beurre.

              Pour l'instant la communauté Fortran77 est sûrement assez active, peut-être même que des tas de gens sont prêts à payer pour ne pas avoir à changer leur vieux code. Mais au final il y a forcément des gens qui payent cette maintenance. Et comme c'est du libre, on peut en profiter sans avoir soi-même payer quoi que soit ; mais rien de magique la dedans.

              • [^] # Re: Mes idéaux

                Posté par (page perso) . Évalué à  4 .

                Pour l'instant la communauté Fortran77 est sûrement assez active

                hum je crois qu'ils sont tous dans le formol

              • [^] # Re: Mes idéaux

                Posté par . Évalué à  2 .

                Merci d'avoir bien écrit ce que j'essayais de dire.

              • [^] # Re: Mes idéaux

                Posté par . Évalué à  3 .

                Je connais des projets scientifiques écrits en python 2. Ça a déjà été galère quand j'ai mis à jour ma machine de 2.5 vers 2.7 (je ne connais que très très peu python). Si ces projets ne sont pas activement maintenus (les étudiants finissent leur thèse puis passent à autre chose), il sera impossible de les exécuter quelques années après l'abandon de python2. Ou alors avec un vieux livecd de 2012, s'ils démarrent encore sur les ordinateurs de demain. De l'autre côté, un grand nombre de programmes de calcul reposent encore sur blas/lapack/linpack, des mastodontes en fortran 77. Personne n'a envie de réécrire des millions de lignes de code en f77 qui fonctionnent bien et ont été méticuleusement testées sur au moins vingt ans, et tout le monde veut bien les utiliser. Je n'ai pas l'ambition d'écrire le prochain Lapack, mais si j'écris quelque chose d'utile, autant que des gens puissent continuer à l'utiliser quand je passerai à autre chose.

                Mes scripts perl qui ont 10 ans sans maintenance dans /usr/local/bin et fonctionnent à l'identique depuis de nombreuses années, ceux de 1994 fonctionneraient encore si à l'époque j'avais su en écrire. Comme je suis heureux de ne jamais avoir à me dire que peut-être demain je devrai les réécrire en perl 6 ou 7 !

                Requiring end-user programmers to change just a few language constructs, even language constructs which no well-educated developer would ever intentionally use is tantamount to saying "you should not upgrade to a new release of Perl unless you have 100% test coverage and can do a full manual audit of your codebase." […] It is very important that existing software written in Perl continue to work correctly. If end-user developers have adopted a bug as a feature, we need to treat it as such. -- http://perldoc.perl.org/perlpolicy.html#BACKWARD-COMPATIBILITY-AND-DEPRECATION

                En tant qu'utilisateur final des langages de programmation, je préfère éviter les langages à date de péremption. Je souhaite bon courage aux pythonistes pour maintenir leur code à chaque évolution de leur langage.

                • [^] # Re: Mes idéaux

                  Posté par (page perso) . Évalué à  1 .

                  Python en lui-même n'a aucune date de péremption, c'est un logiciel libre, tu as les sources, qu'est-ce qui pourrait t'empêcher de le faire tourner, lui et les applis développées avec, dans 50 ans ? Si quelque chose t'en empêche ce sera les composants du système, les librairies en C qu'il utilise etc. Mais pas le langage lui-même.

                  Pour ce qui est du courage des développeurs pour suivre les upgrades du langage, rassure toi c'est trivial dans la grande majorité des cas. Surtout, c'est ridicule par rapport aux problèmes de compatibilités extérieurs (libs, système, bdd, utilisateurs...)

                  • [^] # Re: Mes idéaux

                    Posté par . Évalué à  3 .

                    c'est un logiciel libre, tu as les sources, qu'est-ce qui pourrait t'empêcher de le faire tourner, lui et les applis développées avec, dans 50 ans ?

                    Je n'ai pas les compétences pour maintenir python moi-même. Si python2 n'est plus maintenu, ma distribution le retirera quand les mainteneurs de la distro se lasseront de backporter des patches. Je suis un utilisateur final de langages de scripts, j'ai des commandes simples comme changer les permissions sur un arbre de fichiers, renommer une série de fichiers selon une convention de nommage. Je veux juste que mes scripts continuent de fonctionner dans le futur. Dóoù mes choix de langages.

                    • [^] # Re: Mes idéaux

                      Posté par (page perso) . Évalué à  0 .

                      C'est quitte ou double. Le risque c'est qu'un langage qui n'évolue plus sera moins sujet à être maintenu qu'un langage qui évolue. C'est une histoire d'équilibre, un langage qui évolue lentement et donc facile à suivre ou un langage qui n'évolue plus et qui risque de devenir obsolète brutalement.

                      • [^] # Re: Mes idéaux

                        Posté par . Évalué à  3 .

                        Tu te focalises, je pense, sur un point non pertinent.

                        Ce qui fait qu'un langage est maintenu, c'est pas sa capacité a évoluer, c'est la taille de la communauté d'utilisateur.
                        On peut pas vraiment dire que C, bash et Java soient réputés pour leurs évolutions, et pourtant ils sont pleinement supportes un peu partout et par une tres large communauté.
                        A l'inverse, brainfuck n'evolue pas d'un poil, et son support est plutôt limite.

                        La question des évolutions, c'est un problème d'adéquation avec les besoins de ladite communauté.
                        Si la communauté recherche un langage stable a la java ou du code compile y'a 15 ans tourne toujours strictement a l'identique, ben voila quoi.

                        Visiblement, la communauté python a l'air contente avec le changement, donc c'est que Guido (Brasleti?) a fait le bon choix.

                        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                        • [^] # Re: Mes idéaux

                          Posté par . Évalué à  4 .

                          C'est le problème avec les langages, leur évolution est souvent soit trop lente comme le C qui par exemple n'a toujours pas corrigé des erreurs flagrantes (pas de mot clef pour cast, le comportement par défaut de case...) et d'autre qui évoluent trop brutalement: Perl6 c'est pas une évolution de Perl5, c'est carrément un nouveau langage.

                          Je trouve aussi que l'évolution de Python se fait a un bon rythme.

                          • [^] # Re: Mes idéaux

                            Posté par . Évalué à  1 .

                            Ben le rythme d'évolution dépend directement de la cible du langage et de ce pour quoi il est utilise.

                            Un langage utilise comme ciment pour 90% des fondations de l'informatique moderne, t'as pas forcement envie de te taper une migration + revalidation en permanence.

                            Un truc comme python qui est utilise dans un contexte super agile et pas particulièrement critique (oui, hormis qq gros outils a la mercurial , python est généralement pas utilise dans des taches critiques), forcement ça ouvre a plus de souplesse.

                            Un langage qui a je pense rate ça, c'est Java qui aurait pu bien beneficier de qq coup de dépoussiérant (genre ces foutues generis a la con ou les iterateurs a la mord moi le noeud qui arrivent a te sortir une NPE).

                            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                            • [^] # Re: Mes idéaux

                              Posté par . Évalué à  3 .

                              Le C évolue cf C99, et le futur C11, mais c'est quasiment uniquement par l'ajout de nouvelle fonctionnalité, pas en corrigeant les erreurs du passé: je crois que l'unique exception est le remplacement de l’infâme gets par gets_s, c'est trop peu, dommage..

                              • [^] # Re: Mes idéaux

                                Posté par . Évalué à  1 .

                                mais c'est quasiment uniquement par l'ajout de nouvelle fonctionnalité, pas en corrigeant les erreurs du passé

                                C'est parfois même à l'extrême, pour preuve les nouveaux keywords en _Foo parce que on ne veut pas casser la moindre ligne de code pré-existant...

                          • [^] # Re: Mes idéaux

                            Posté par (page perso) . Évalué à  2 .

                            le C qui par exemple n'a toujours pas corrigé des erreurs flagrantes (pas de mot clef pour cast, le comportement par défaut de case...)

                            Franchement, tu aurais dû attendre vendredi avant de poser une telle bombe : pourquoi un mot-clef spécial pour caster, et que reproches-tu au case ?

                            * Ils vendront Usenet quand on aura fini de le remplir.

                            • [^] # Re: Mes idéaux

                              Posté par . Évalué à  2 .

                              Perso, je hait ce concept de devoir breaker (et je trouve dangereux de se baser sur le fait de pas breaker volontairement).
                              Et pouvoir switch/caser que des int, c'est un peu moche.

                              Mais ça a rien de spécifique au C.

                              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                              • [^] # Re: Mes idéaux

                                Posté par . Évalué à  2 .

                                Mis à part Perl (avec le given when) quel langage procédural ou objet (je veux dire mis à part les langages fonctionnels avec le pattern matching) a un switch/case différent ?

                                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                                • [^] # Re: Mes idéaux

                                  Posté par (page perso) . Évalué à  2 .

                                  quel langage procédural ou objet (je veux dire mis à part les langages fonctionnels avec le pattern matching) a un switch/case différent ?

                                  QuickBasic 4.5 for Microsoft MS-DOS ;)

                                  * Ils vendront Usenet quand on aura fini de le remplir.

                                • [^] # Re: Mes idéaux

                                  Posté par (page perso) . Évalué à  2 .

                                  Pascal, si je me souviens bien de ma première année de fac.

                                • [^] # Re: Mes idéaux

                                  Posté par (page perso) . Évalué à  1 .

                                  C# fait un switch sur les string en plus des int http://msdn.microsoft.com/en-us/library/06tc147t%28v=vs.71%29.aspx

                                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                                • [^] # Re: Mes idéaux

                                  Posté par . Évalué à  2 .

                                  Le switch (sur les valeurs) de Go est le "switch done right" (pour peu qu'on se contente d'une fonctionnalité si faible alors qu'on peut avoir des filtrages de motifs nettement plus sympathiques): switch statements in Go.

                                • [^] # Re: Mes idéaux

                                  Posté par (page perso) . Évalué à  1 .

                                  Au risque de me répéter : Ada où tout type discret peut servir.

                                  • [^] # Re: Mes idéaux

                                    Posté par (page perso) . Évalué à  1 .

                                    Par contre, c'est vrai, il n'y a effectivement rien sur les cases avec chaines de caractères. Ada n'est pas la panacée ou l'El Dorado des langages, on peut pas tout avoir non plus :D

                                    • [^] # Re: Mes idéaux

                                      Posté par . Évalué à  2 .

                                      En même temps, le switch sur les chaînes de caractères est une fonctionnalité assez douteuse. Les chaînes de caractères viennent à priori toutes de l'utilisateur (ou de l'environnement), donc il faut être robuste à différent détails et il est rare qu'on puisse tester exactement l'égalité avec quelque chose (on voudra plutôt tolérer certains changements, les différences majuscules/minuscules par exemple, les espacements...).

                                      Pour chaque cas de "switch" qui entre dans ce cadre (on peut switcher si on choisit une méthode de normalisation de l'entrée et qu'on compare à des formes normales), il y a sans doute une tripotée de cas où le switch sur les chaînes est utilisé à tort à la place de fonctionnalités plus robustes (aux fautes de frappe dans le code etc.), comme les énumérations, les symboles, ou un type algébrique.

                                      (Mais oui Ada n'est pas la panacée; par exemple la généricité par spécialisation est très lourde à utiliser, on aurait envie d'une forme plus simple de polymorphisme paramétrique.)

                                      • [^] # Re: Mes idéaux

                                        Posté par . Évalué à  2 .

                                        En fait, lorsqu'il parle de switch sur chaines de caractères, je pense qu'il veut dire switch sur d'autres objets que les entiers, ce qui peut également être casse gueule.

                                        • [^] # Re: Mes idéaux

                                          Posté par (page perso) . Évalué à  1 .

                                          Non, je parlais bien de switch/case sur les chaînes de caractères, ce qui est hautement casse-gueule à mon avis.
                                          Par contre, le switch/case sur autres choses, ça ne me fait pas peur tant que le quelque chose est de type discret.

                                      • [^] # Re: Mes idéaux

                                        Posté par (page perso) . Évalué à  1 . Dernière modification : le 02/02/12 à 17:57

                                        Tout à fait d'accord avec toi, je n'y vois pas énormément d'intérêt. Ceci dit, on peut faire un truc assez cool, c'est de faire un case sur une énumération après avoir tenté de récupérer la valeur d'énumération dans une chaîne avec

                                        procedure Get(Item : out Enum);
                                        
                                        

                                        Bon, ok, c'est pas terrible... Non, c'est carrément nul mais faisable :D

                                        (Mais oui Ada n'est pas la panacée; par exemple la généricité par spécialisation est très lourde à utiliser, on aurait envie d'une forme plus simple de polymorphisme paramétrique.)

                                        La généricité déjà est lourde mais quand tu parles de généricité par spécialisation, tu parles bien de ça qu'on trouve en C++ ?
                                        Si c'est le cas, je savais même pas qu'on pouvait le faire en Ada

                                        • [^] # Re: Mes idéaux

                                          Posté par . Évalué à  3 .

                                          Non, je parlais du fait général de compiler les génériques/templates (et de comprendre/expliquer leur comportement) en remplaçant l'instantiation d'une template par son code (au lieu de pouvoir raisonner de façon plus légère sur des fonctions polymorphes, etc.; comment définir des génériques ou leurs instances localement, en profondeur dans la définition d'une fonction ?). Ada ne permet pas la spécialisation conditionnelle dont tu parles. Peut-être tant mieux, car ça rend la fonctionnalité drôlement compliquée, ce qui n'est pas terrible pour un langage orienté sûreté; en contrepartie on perd certains usages utiles de la méta-programmation (quand on a en plus l'expansion récursive), mais bon il faut bien s'arrêter un jour.

                                          • [^] # Re: Mes idéaux

                                            Posté par (page perso) . Évalué à  1 .

                                            Non, je parlais du fait général de compiler les génériques/templates (et de comprendre/expliquer leur comportement) en remplaçant l'instantiation d'une template par son code

                                            Oui, les generics sont effectivement assez compliqués à mettre en oeuvre. Un exemple "rigolo", c'est l'instanciation successive de trois génériques pour obtenir une matrice de complexes donc les composantes sont des réels (cf ARM). Ca donne un truc comme ça :

                                            package Complex_type is new Ada.Numerics.Generic_Complex_Types(Short_Float);
                                            use Complex_type;
                                            package Real_Arrays is new Ada.Numerics.Generic_Real_Arrays(Short_Float);
                                            use Real_Arrays;
                                            package Complex_Arrays is new Ada.Numerics.Generic_Complex_Arrays(Real_Arrays, Complex_type);
                                            
                                            

                                            au lieu de pouvoir raisonner de façon plus légère sur des fonctions polymorphes

                                            C'est la grande bataille entre faire du pur objet en utilisant héritage, surdéfinition et faire du template. Quand utiliser quoi ? D'ailleurs, je trouve les templates plus complexes à manipuler, quelque soit le langage, qu'un graphe d'héritage

                                            comment définir des génériques ou leurs instances localement, en profondeur dans la définition d'une fonction ?

                                            Je vois pas la difficulté là, hormis syntaxique. Un bloc declare suffit normalement. Je dois pas avoir compris ce que tu voulais dire :)

                                            Ada ne permet pas la spécialisation conditionnelle dont tu parles. Peut-être tant mieux, car ça rend la fonctionnalité drôlement compliquée, ce qui n'est pas terrible pour un langage orienté sûreté;

                                            Tout à fait d'accord. Personnellement, je trouve la méta-programmation assez compliquée à manipuler et j'ai déjà assez de problèmes comme ça à coder sans :D

                                            • [^] # Re: Mes idéaux

                                              Posté par . Évalué à  2 .

                                              C'est la grande bataille entre faire du pur objet en utilisant héritage, surdéfinition et faire du template. Quand utiliser quoi ? D'ailleurs, je trouve les templates plus complexes à manipuler, quelque soit le langage, qu'un graphe d'héritage

                                              Je ne vois pas où est la subtilité. Quand il s'agit de manipuler différentes classes, on fait un template, quand on cherche à spécialisé une classe on fait de l'héritage.

                                              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                                              • [^] # Re: Mes idéaux

                                                Posté par (page perso) . Évalué à  1 .

                                                Je ne vois pas où est la subtilité. Quand il s'agit de manipuler différentes classes, on fait un template, quand on cherche à spécialisé une classe on fait de l'héritage.

                                                Oui effectivement, en réfléchissant à un exemple, je me demande si j'ai pas dit une connerie :D
                                                Donc, j'en ai bien un mais bon, il est bof.
                                                J'ai une classe qui permet de gérer des configurations sous forme de dépôt. Les configurations étant différentes, elles héritent toutes d'un même comportement issu d'une configuration abstraite, Configuration.
                                                Si je veux stocker les configurations par type, je peux soit :
                                                - Définir un dépôt abstrait Depot et le dériver pour chacune des sous-classes de Configuration (méthode Java avant l'introduction des génériques et classique des cours de POO)
                                                - Définir le dépôt comme étant générique et instancier ce générique par sous-classe de Configuration

                                                Mais bon, ok, c'est bof ;)

                                • [^] # Re: Mes idéaux

                                  Posté par . Évalué à  2 .

                                  Aucun, pas a a ma connaissance en tout cas.
                                  Java ajoute le switch case sur les enums cela dit, c'est pratique. Et Java7 parlait de faire un switch sur des strings. On est clairement du pattern matching d'ocaml.

                                  Comme je disais, c'est pas spécifique au C, mais le coup de forcer le break est idiot a mon avis, et fait de l'exception la règle.
                                  Et meme, l'exception est une pratique dangereuse.

                                  If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                  • [^] # Re: Mes idéaux

                                    Posté par . Évalué à  2 .

                                    Java ajoute le switch case sur les enums

                                    C'est autorisé par gcc --std=c89 --pedantic, et gcc t'avertit quand tu as oublié une des possibilités de ton enum (-Wswitch) ou quand tu ajoutes un case entier: en dehors de l'enum.

                                    • [^] # Re: Mes idéaux

                                      Posté par . Évalué à  1 .

                                      D'un autre cote, les enums C, c'est des entiers avec un nom, la différence avec #define est tres conceptuelle, encore heureux que tu peux switcher dessus...

                                      Les enums java sont des classes/objet a part entière.

                                      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                  • [^] # Re: Mes idéaux

                                    Posté par . Évalué à  3 .

                                    Merci tu es le premier qui répond en connaissant given/when. Pour rappel :

                                    • ça s'applique sur n'importe quel type
                                    • ça utilise une comparaison plus sophistiquée qu'une simple égalité, mais le « Smart match »
                                    • break automatique

                                    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                            • [^] # Re: Mes idéaux

                              Posté par . Évalué à  3 .

                              Franchement, tu aurais dû attendre vendredi avant de poser une telle bombe

                              Je ne cherche pas à troller, je pensais que c'était des critiques assez courantes. J'ai même éviter mes reproches plus controversées (initialiser par défaut les variables, avoir par défaut une vérification des débordement entier, de tableau (désactivable localement/globalement)).

                              pourquoi un mot-clef spécial pour caster

                              Le cast est une opération "dangereuse": il faut pouvoir les identifier facilement(grep). Et avec la syntaxe actuelle ce n'est pas possible.

                              que reproches-tu au case ?

                              Qu'il a le mauvais comportement par défaut: si tu oublie de mettre un break (nécessaire dans 99% des cas), ton programme continue dans le cas le suivant, ce qui peut être utile, mais ça ne devrait pas être le comportement par défaut.
                              Perso j'ajouterais 3 mots clef: new_switch, new_case, goto_next, new_switch est juste pour séparer l'ancienne et la nouvelle syntaxe, new_case est l'équivalent de (break; case:), goto_next permet d'aller au case suivant (rarement utile mais parfois si cf Duff device), mais bon ça n'a de sens que si ce genre de syntaxe est standardisée autrement c'est comme l'histoire de faire des macros pour faire ressembler C au Pascal..

                              • [^] # Re: Mes idéaux

                                Posté par (page perso) . Évalué à  2 .

                                reproches plus controversées (initialiser par défaut les variables, avoir par défaut une vérification des débordement entier, de tableau (désactivable localement/globalement)).

                                Effectivement, c'est controversable. Si on considère le C comme un assembleur portable (ce qu'il est en fait :) et non comme un langage "généraliste". Pour moi, l'initialisation par défaut des variables automatiques n'a plus de sens de nos jours : elle n'est pas toujours nécessaire, et le compilateur détecte très souvent les cas litigieux. La vérification des débordements d'entier, c'est déja un plus, mais devoir automatiser ce genre de contrôle dénote souvent un problème d'analyse.

                                Quand au débordement de tableaux, oui, des efforts sont faits sur les chaines de caractères, qui sont, depuis le début de l'epoch, un souci permanent.

                                Le cast est une opération "dangereuse": il faut pouvoir les identifier facilement(grep). Et avec la syntaxe actuelle ce n'est pas possible.

                                Le cast est peut-être dangereux, et c'est vrai que greper un cast, à première vue, ce n'est pas évident :) je vais voir ça après le déjeuner...

                                Qu'il a le mauvais comportement par défaut: si tu oublie de mettre un break (nécessaire dans 99% des cas), [snip] 3 mots clef: new_switch, new_case, goto_next,

                                Personnellement, je trouve qu'il a le bon comportement par défaut : il permet de regrouper de façon naturelle les cas qui doivent déclencher les mêmes actions. Quand à ces trois nouveaux mots-clef, je t'invite à poster un exemple complet de mise en oeuvre, juste pour avoir les idées plus claires.

                                c'est comme l'histoire de faire des macros pour faire ressembler C au Pascal..

                                Arf, on a dû avoir le même professeur de C :)

                                * Ils vendront Usenet quand on aura fini de le remplir.

                                • [^] # Re: Mes idéaux

                                  Posté par . Évalué à  2 .

                                  Et bien ce code:
                                  switch ( ... ) {
                                  case 1:
                                  case 2:
                                  __[code A]
                                  break;
                                  case 3:
                                  __[code B]
                                  case 4:
                                  __[code C]
                                  }
                                  deviendrait:
                                  new_switch ( ... ) {
                                  new_case 1,2:
                                  __[code A]
                                  new_case 3:
                                  __[code B]
                                  goto_nextcase;
                                  new_case 4:
                                  __[code C]
                                  }

                                  PS:
                                  Désolé pour la lisibilité, rentrer du code avec Chrome ne marche pas.

                                  • [^] # Re: Mes idéaux

                                    Posté par . Évalué à  2 .

                                    Rentrer du code marche certainement si tu utilises une bonne syntaxe, par exemple le fait de préfixer chaque ligne de code par quatre espaces.

                                    • [^] # Re: Mes idéaux

                                      Posté par . Évalué à  2 .

                                      Bah non:
                                      icone:
                                      ceci est un test l1
                                      ceci est un test l2

                                      manuellement 4 espaces:
                                      a1
                                      a2

                                      • [^] # Re: Mes idéaux

                                        Posté par . Évalué à  2 .

                                        Il faut mettre une ligne vide entre le bloc de code et le bloc paragraphe précédent (... sinon ça fait partie du bloc paragraphe).

                • [^] # Re: Mes idéaux

                  Posté par (page perso) . Évalué à  2 .

                  Ça a déjà été galère quand j'ai mis à jour ma machine de 2.5 vers 2.7 (je ne connais que très très peu python)

                  Je souhaite bon courage aux pythonistes pour maintenir leur code à chaque évolution de leur langage.

                  Il n'y a pas à toucher un programme qui tourne en 2.5 pour qu'il tourne en 2.7 : la cassure est avec la branche 3, les versions d'une même version ont bien heureusement la compatibilité ascendante.

                  Personne n'a envie de réécrire des millions de lignes de code en f77 qui fonctionnent bien et ont été méticuleusement testées sur au moins vingt ans, et tout le monde veut bien les utiliser.

                  C'est bien ce que je dis, il y au moins une personne qui passe son temps libre, ou bien qui est payée, pour maintenir f77 dans GCC. Si demain ce n'est plus le cas, et que tu es le dernier utilisateur, tu devras aussi te garder sous le coude la dernière distribution gérant f77, et utiliser une machine virtuelle par exemple.

                  Si ces projets ne sont pas activement maintenus (les étudiants finissent leur thèse puis passent à autre chose), il sera impossible de les exécuter quelques années après l'abandon de python2. Ou alors avec un vieux livecd de 2012, s'ils démarrent encore sur les ordinateurs de demain.

                  Je ne sais pas quand le support de Python2.7 sera perdu dans la pratique ; si des tas de gens sont prêts à payer pour qu'il soit maintenu (plutôt que passer les 2h à modifier leur programme) ça peut être dans longtemps (de base le projet Python a tablé sur 5 ans, mais dans les distributions comme Debian ça devrait être là plus longtemps). Mais effectivement, si en 2025 tu es vraiment intéressé pour faire tourner le code de tes thésards de 2010, tu devras peut être te garder une Debian de 2024 + Machine Virtuelle, c'est bien triste pour toi. Quelque chose me dit que si personne n'est motivé pour passer quelques heures sur ces programmes d'ici 15 ans, c'est qu'ils ne doivent pas être si utiles que ça... Je peux comprendre cependant que tu sois déçu.

                  Mes scripts perl qui ont 10 ans sans maintenance dans /usr/local/bin

                  Pareil que f77 (quelqu'un fait la maintenance).

                  Tout cela est une histoire d'offre et de demande en quelque sorte. Une communauté peut se former pour faire Python2.8, Python2.9 etc.. qui ne cassent pas la compatibilité. Si ça ne se fait pas, c'est que les "conservateurs" ne sont pas prêts à payer, simplement.

                  Je ne dis pas que l'approche de Python ("progressiste") est mieux que l'approche Fortran ("conservatrice"); les 2 ont leurs avantages et leurs inconvénients. L'approche des langages n'est que le reflet de leur communauté ; il faut croire que la communauté Python préfère corriger les petites erreurs (je le répète, elles sont petites), plutôt que de pénaliser les futures implémentations. Je préfère l'approche Python, sans nier qu'elle a aussi des inconvénients ; tous les choix techniques sont des compromis, je l'ai déjà dit.

                  En ce qui me concerne faire évoluer mes programmes n'est pas une contrainte mais une véritable philosophie (et même un grand plaisir).

                  • [^] # Re: Mes idéaux

                    Posté par . Évalué à  2 .

                    C'est bien ce que je dis, il y au moins une personne qui passe son temps libre, ou bien qui est payée, pour maintenir f77 dans GCC. Si demain ce n'est plus le cas, et que tu es le dernier utilisateur, tu devras aussi te garder sous le coude la dernière distribution gérant f77, et utiliser une machine virtuelle par exemple.

                    Je ne sais pas ce qu'il en ai pour le cas précis de fortran, mais les langages comme le C et le C++. L'implémentation de la dernière norme inclue l'implémentation des précédentes. Autrement dis un compilateur C99 bouffe du C89 par essence (c'est l'inverse qui n'est pas vrai), si non ce ne serait pas un compilateur C99.

                    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                    • [^] # Re: Mes idéaux

                      Posté par (page perso) . Évalué à  1 .

                      Pour pypy, la question est posée de supporter à la fois la 2 et la 3 sur la même base de code.

                      http://pypy.org/py3donate.html

                      Planned stages of work

                      The goal of this project is to write an interpreter that interprets version 3 of the Python language. To be precise we would aim at having a Python 3.2 interpreter together in the same codebase as the python 2.7 one.

                      At the end of the project, it will be possible to decide at translation time whether to build an interpreter which supports Python 2.7 or Python 3.2 and both versions will be nightly tested and available from nightly builds.

                    • [^] # Re: Mes idéaux

                      Posté par (page perso) . Évalué à  3 .

                      Un bémol cependant : il me semble que des fonctionnalités obligatoires du C99 vont devenir optionnelles dans la version suivante (genre les nombres complexes). Si c'est le cas, un code C99 (utilisant ces fonctionnalités) ne passera pas forcément sur un compilateur C11.

                      • [^] # Re: Mes idéaux

                        Posté par . Évalué à  2 .

                        En effet mais ça a fait du bruit. Quelque chose d'optionnel dans un standard ça pose de gros problèmes.

                        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                  • [^] # Re: Mes idéaux

                    Posté par . Évalué à  2 .

                    Mes scripts perl qui ont 10 ans sans maintenance dans /usr/local/bin

                    Pareil que f77 (quelqu'un fait la maintenance).

                    Mais oui bien sûr quelqu'un le fait. Tout l'objet de mon message, c'est de dire qu'en tant qu'utilisateur des langages de programmation, je préfère choisir les langages où les auteurs et la communauté ont la volonté de maintenir le langage sans déjà prévoir de le rendre obsolète. C'est le cas de la communauté perl5 (lire la page que je cite). Ce n'est apparemment pas le cas de python, et une bonne raison pour moi d'éviter de me rendre dépendant d'un truc qui pourrait ne plus être supporté une fois que j'aurai passé du temps à développer mes scripts.

                    • [^] # Re: Mes idéaux

                      Posté par . Évalué à  3 .

                      Python évolue, mais son but premier est bien d'avoir un langage de script tout en un et stable.

                      Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

                  • [^] # Re: Mes idéaux

                    Posté par (page perso) . Évalué à  3 .

                    l'approche Fortran ("conservatrice")

                    Je ne peux pas laisser passer cela. A chaque nouvelle version, Fortran déclare des structures obsolètes... Fortran est un des plus vieux langage et un des langages qui a le plus évolué tant sur le fond que sur la forme ! Python a coté a les vertèbres bloquées ;-)

                    Juste trois exemples, Fortran 90 a amené le free form (on écrit comme dans les autres langages, plus d'histoire de numéro de colonne), Fortran 2003 a amené l'héritage simple (Fortran est un langage objet ce que n'est pas le C) et la version 2008 introduit le co-array, c'est à dire en gros des tableaux qui s'étendent sur un cluster... On aime ou on n'aime pas mais il ne faut pas dire que c'est conservateur...

                    • [^] # Re: Mes idéaux

                      Posté par (page perso) . Évalué à  1 .

                      Ok alors toutes mes excuses ; le C est conservateur, pas le Fortran (les conservateurs ce sont les pappies qui s'accrochent à leur f77 :) )

      • [^] # Re: Mes idéaux

        Posté par (page perso) . Évalué à  2 .

        À côté de ça, dans la pratique, malgré la non cassure du monde C++, si tu trouves un vieux projet C++ qui a traîné des années sans avoir bougé, pas sûr qu'il compilera sans problème, pour peu qu'il s'appui sur d'autres bibliothèques qui elles auront évolué. De toutes les manières un code non maintenu finit par mourir.

        Je suis complètement d'accord.
        Dans ma boite, quand on a mis à jour le GCC qu'on utilisait pour compiler, on a dû passer quelques jours pour corriger des warnings et bugs que le mode plus strict du compilo a mis en lumière.
        De même, quand on met à jour une librairie qu'on utilise, si jamais l'interface a changé on est obligé de reprendre du code (un exemple qui me vient à l'esprit: udev).

        Donc effectivement, la pérennité du C++ n'est pas garantie si tu mets pas les mains dans le code au moins une fois par ans, disons.

        • [^] # Re: Mes idéaux

          Posté par (page perso) . Évalué à  3 .

          warnings et bugs que le mode plus strict du compilo a mis en lumière.

          Ca montre que le programme avait été mal codé (mauvais compilo avant qui acceptait le mauvais code), pas que le langage était mauvais.
          Sans compter qu'une fois les bugs corrigés, ben ton ancien compilo sur ta vieille machine pourra toujours compiler... Ca peut être pratique (pour moi, c'est un point bloquant si quand je corrige un bug, ça ne marche plus sur un vieil compilo)

          De même, quand on met à jour une librairie qu'on utilise, si jamais l'interface a changé on est obligé de reprendre du code (un exemple qui me vient à l'esprit: udev).

          Le rapport avec un langage? C'est un argument qui marche contre 100% des langages, pourquoi plus C++ qu'un autre? On parle des différence entre les langages, pas des différences entre les humains changeant les API. Mais bon, je te dirai de changer d'OS si son API non spécifique à l'OS change sans assurer la compatibilité, mon code pour Windows 95 (15 ans!) fonctionne toujours sous Windows 8 (en C, donc non, ce n'est pas un problème du langage, juste de ton OS)

          PS : librairie, tu vends des livres? Library, c'est bibliothèque en français.

          PPS : si tu avais été sadique, tu aurai pu balancer un exemple qui était valide mais qui ne l'est plus ;-). Si je me souviens bien
          for (int A=0;;);
          A=0;
          était 100% valide mais plus maintenant. Mais je ne connais pas d'autre exception.

          • [^] # Re: Mes idéaux

            Posté par . Évalué à  1 .

            Le c++ pas plus que le C n'ont intérêt à casser la compatibilité ascendante.

            Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

          • [^] # Re: Mes idéaux

            Posté par (page perso) . Évalué à  3 .

            C'est important les humains qui changent les api justement...

            L'upgrade est un problème quand le rapport difficulté/gain n'est pas bon. Hors il dépend intimement du langage. En python par exemple, faire évoluer un programme est à a fois facile et apporte beaucoup. Les problèmes de compatibilités sont donc largement amortis. En revanche avec un langage beaucoup plus difficile à faire évoluer effectivement le ratio n'est pas toujours bon on a beaucoup plus intérêt à ne pas casser la compatibilité ascendante.

            Concrètement les programmes en C que j'ai écris il y a 20 ans ils seront sûrement compilable sans rien changer, mais de toutes façons de fait je ne les compile plus et je ne les réutilise pas non plus. En revanche les programmes en python que j'ai écris il y a 8 ans ils ont évolués tous les ans, malgré les pertes de compatibilité je les utilise toujours.

            Bref, il ne faut pas prendre en compte que la compatibilité d'un code avec le langage mais aussi la compatibilité d'un code avec soit-même ;-)

    • [^] # Re: Mes idéaux

      Posté par . Évalué à  3 .

      Des technologies perennes qui ont ete ecrites dans leur coin, et ensuite presente a d'autres pour creer une sorte de consortium autour, j'en connais pas mal. Des technologies concues depuis le debut avec un consortium, deja j'en connais beaucoup moins, et ca devient ensuite pas perenne. Je parle de regroupement d'entreprises, pas d'un development libre.

      Autant je suis d'accord sur le fait qu'il n'y ai pas qu'une seule entreprise impliquee sur le long terme, je suis d'accord. Mais au depart, je preferais qu'une seule entreprise se concentre sur l'elaboration et ensuite souhaite partager la gouvernance. Sinon, ca tombe dans le bordel total du syndrome pouce-index, ou tout le monde veut son propre truc inclus des la premiere version et on se retrouve avec un bordel infame que personne n'utilisera dans le long-terme.

    • [^] # Re: Mes idéaux

      Posté par (page perso) . Évalué à  7 .

      Bon, vu que tout le monde a cité le couple C/C++, j'en choisis un autre qui vaut, à mon humble avis, le coup d'oeil et dont on parle rarement, Ada

      Un qui soit fait de manière concertée entre plusieurs entreprises, "plusieurs" étant supérieur à 10 minimum, montrant que c'est pas une entreprise dans son coin qui veut faire un truc qu'il jettera quand plus besoin ou qu'il fera évoluer la licence ou l'évolution comme il a envie (Allez, une liste : Go, Rust, Java, C#...)

      C'est le cas depuis presque 30 ans.

      Un qui passe les organismes les plus connu (genre ISO)

      Même remarque qu'au-dessus, sachant en plus qu'il s'agissait du premier langage objet normalisé ANSI/ISO

      Un qui ne casse pas la compatibilité au bout de 10 ans, un que je sais que je pourrai compiler le code das 10 ans (pas exemple : Python)

      Tu peux normalement compiler ton code Ada83 sans problème avec un bon vieux Gcc d'aujourd'hui.

      Un qui soit utilisé par beaucoup de monde

      Bon, là, effectivement, c'est sûr que ça pêche. Ceci dit, la communauté est ultra-compétente (voire trop des fois ?) et il est facile d'obtenir un coup de main

      Un qui marche autant sur une petite machine qu'une grosse (non, pas de machine virtuelle)

      La question ne se pose même pas. C'est quasiment prévu pour :)

      Ensuite pour répondre au journal d'origine, les petits suppléments :
      - Programmation concurrente normalisée (de bien plus haut niveau que ce qui se fait en Java d'ailleurs)
      - Programmation distribuée normalisée
      - Interfaçage avec le C/C++, le Java (depuis peu et pas prévu par la norme), le Fortran et le Cobol

      Sinon, le sous-typage sans polymorphisme, c'est dedans, les génériques et les interfaces aussi.
      Cerise sur le gâteau, Gcc (enfin gnat) est d'une précision redoutable dans ses messages d'erreur à la compilation.

      • [^] # Re: Mes idéaux

        Posté par (page perso) . Évalué à  3 .

        Quelques questions sur l'univers Ada:

        • est-ce qu'il est facile d'écrire un programme multiplateforme?
        • est-ce qu'il est facile de déployer un programme multiplateforme? (ie bytecode ou crosscompilation simplissime)
        • est-ce qu'il existe un outil de gestion des dépendances à la Maven?

        Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

        • [^] # Re: Mes idéaux

          Posté par (page perso) . Évalué à  1 . Dernière modification : le 30/01/12 à 14:43

          est-ce qu'il est facile d'écrire un programme multiplateforme?

          Comme pour un programme Java, il y a des choses où il faut faire attention. Je pense notamment à tout ce qui touche les fichiers (casse prise en compte ou pas, droits d'accès). Globalement, l'Ada Reference Manual spécifie tout ce que doit savoir faire un compilateur Ada quelle que soit la plate-forme pour pouvoir s'appeler compilateur Ada.

          est-ce qu'il est facile de déployer un programme multiplateforme? (ie bytecode ou crosscompilation simplissime)

          Il semble qu'il soit possible de générer du bytecode Java (voir la doc associée) mais aussi de s'interfacer avec du Java relativement aisément (voir ). Perso, je n'ai pas essayé.

          est-ce qu'il existe un outil de gestion des dépendances à la Maven?

          Non, inutile de faire deux fois les mêmes bêtises :D
          La seule gestion des dépendances que l'on peut avoir, c'est celle fournit par un système de gestion de paquetages de ta distribution :)
          Trêve de plaisanterie, le développement Ada s'apparente nettement plus à du développement C/C++ qu'à du développement Java avec ses avantages et ses inconvénients. En clair, tout est à la charge du développeur en termes de dépendances.

          • [^] # Re: Mes idéaux

            Posté par (page perso) . Évalué à  1 .

            Trêve de plaisanterie, le développement Ada s'apparente nettement plus à du développement C/C++ qu'à du développement Java avec ses avantages et ses inconvénients.

            C'est dommage, car ça ne correspond pas trop au besoin du libriste amateur qui veut passer le maximum de temps sur le cœur de ses projets et pas sur les problèmes techniques.

            Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

            • [^] # Re: Mes idéaux

              Posté par (page perso) . Évalué à  2 .

              C'est dommage, car ça ne correspond pas trop au besoin du libriste amateur qui veut passer le maximum de temps sur le cœur de ses projets et pas sur les problèmes techniques.

              Hélas, le développement informatique reste avant tout une activité humaine technique et cela se confirme quand je vois tout ce que Maven a lui seul peut apporter comme problèmes techniques comme l'incompatibilité de versions tirées par deux dépendances différentes.

              • [^] # Re: Mes idéaux

                Posté par (page perso) . Évalué à  1 .

                Sans Maven, tu ne te serais jamais aperçu de ce conflit!

                Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                • [^] # Re: Mes idéaux

                  Posté par (page perso) . Évalué à  2 .

                  Trop gros, passera pas !!
                  Pour répondre quand même, Maven ne dit rien quand il y a ce conflit. Pour être précis, il s'agit d'un conflit entre plusieurs versions de log4j et c'est le plus fort qui gagne sans que Maven dise quoique ce soit.

                  • [^] # Re: Mes idéaux

                    Posté par (page perso) . Évalué à  2 .

                    C'est un bug de ce module?

                    A project's dependency tree can be expanded to display dependency conflicts.

                    http://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html

                    Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                    • [^] # Re: Mes idéaux

                      Posté par (page perso) . Évalué à  1 .

                      Non mais dependency:tree est un outil d'analyse qui marche tout aussi bien que ldd. Il n'empêche absolument pas les conflits d'apparaître.

                      Au final, ce que je veux dire, c'est que Maven n'est pas la panacée et que passée une certaine taille de projet, on ne maitrise plus la configuration complète de son développement et la multitude de dépendances tirées de droite et de gauche.

                      • [^] # Re: Mes idéaux

                        Posté par (page perso) . Évalué à  3 .

                        Si tu as des besoins avancés de gestion de dépendances, il y a |Ivy](http://ant.apache.org/ivy/index.html) qui est très bon pour ça et utilisable pour n'importe quel langage.

                        Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                  • [^] # Re: Mes idéaux

                    Posté par . Évalué à  2 .

                    Et t'es sur que c'est pas simplement des pom mal maintenus ? Si la version n+1 pète la compat et qu'un dit log4j >= n et l'autre log4j >= n+1 bha tu te retrouves avec n+1 par ce que c'est ce que les gens qui ont écrit les pom ont demandé... à tord.

                    Maven c'est une bonne idée; très mal réalisée (la conf est complètement stupide). Mais faut pas l'accuser de n'importe quoi.

                    Après le vrai problème; qui existe dans tout les langages mais qui est exacerbé en Java du fait de la réutilisation massive de nombreux composant non inclus dans le runtime, c'est comment avoir deux versions de la même lib en parallèle dans la même appli.

                    • [^] # Re: Mes idéaux

                      Posté par (page perso) . Évalué à  1 .

                      Et t'es sur que c'est pas simplement des pom mal maintenus ? Si la version n+1 pète la compat et qu'un dit log4j >= n et l'autre log4j >= n+1 bha tu te retrouves avec n+1 par ce que c'est ce que les gens qui ont écrit les pom ont demandé... à tord.

                      Il n'y a pas d'histoire de tord ou de raison. tout le monde n'utilise pas forcément les mêmes versions d'une même bibliothèque. Simplement, Maven n'est pas la panacée et ne résout pas ces problèmes que l'on a aussi en gérant à la main. Cependant, à la main, on maitrise mieux son environnement de développement et on peut peser le pour et le contre d'inclusion de telle ou telle bibliothèque, notamment les problèmes de compatibilité.

                      Maven c'est une bonne idée; très mal réalisée (la conf est complètement stupide). Mais faut pas l'accuser de n'importe quoi.

                      Je ne l'accuse pas de n'importe quoi, je dis que c'est juste un outil automatique et comme tout outil automatique, il cache énormément de choses qu'il vaudrait mieux maitriser et qui ne peut résoudre certains problèmes qui sont déjà difficiles à régler pour des humains.

                      Après le vrai problème; qui existe dans tout les langages mais qui est exacerbé en Java du fait de la réutilisation massive de nombreux composant non inclus dans le runtime, c'est comment avoir deux versions de la même lib en parallèle dans la même appli.

                      Tout à fait d'accord mais quand tu codes une appli en C/C++, il est quand même rare, me semble-t-il, de lier avec deux versions d'un même composant sans qu'il ne se passe de collision.

                      • [^] # Re: Mes idéaux

                        Posté par . Évalué à  2 .

                        Il n'y a pas d'histoire de tord ou de raison.

                        Bien sur que si. Si un soft1 en version X dépend d'un soft2 en version Y à Z ce n'est pas du tout la même chose qu'un soft2 en version supérieur à Y. Mais en général tout le monde se fou de faire les dépendances correctement (être strict à aussi des inconvénients) et ca pète à runtime par ce que tu te retrouves avec la version Z. La faute ne revient pas à l'outil mais au mec qui à ecrit le pom.

                        Il cache énormément de choses qu'il vaudrait mieux maitriser

                        T'as exactement les mêmes problèmes pour le faire à la main. Sauf que dans 90% des cas, ca marche très bien avec la version automatique. T'as juste perdu ton temps pour rien.

                        C'est aussi bête que de dire que le boulot fait par les gestionnaires de paquets et les packageurs ne sert à rien. Ca marche mieux pour eux par ce qu'ils construisent une configuration figée.

                        Tout à fait d'accord mais quand tu codes une appli en C/C++, il est quand même rare, me semble-t-il, de lier avec deux versions d'un même composant sans qu'il ne se passe de collision.

                        J'ai du mal à voir la pertinence de la comparaison.

                        • [^] # Re: Mes idéaux

                          Posté par (page perso) . Évalué à  1 .

                          Bien sur que si. Si un soft1 en version X dépend d'un soft2 en version Y à Z ce n'est pas du tout la même chose qu'un soft2 en version supérieur à Y. Mais en général tout le monde se fou de faire les dépendances correctement (être strict à aussi des inconvénients) et ca pète à runtime par ce que tu te retrouves avec la version Z. La faute ne revient pas à l'outil mais au mec qui à ecrit le pom.

                          Mon soft A dépend de soft1 qui dépend de Y en version 1 mais dépend aussi de soft2 qui lui dépend de Y en version 2. Dans mon pom, je ne gère que la dépendance vers soft1 et soft2. Qui est en faute ? Celui qui n'a pas upgradé vers la version 2 ?
                          Ça, je ne le maitrise pas et c'est juste ça qui me gêne.

                          T'as exactement les mêmes problèmes pour le faire à la main. Sauf que dans 90% des cas, ca marche très bien avec la version automatique. T'as juste perdu ton temps pour rien.
                          Non, je n'ai pas perdu mon temps. Je connais ce que j'inclus et je le maîtrise. Trop de dépendances ? Ok, on prend une lib plus légère.

                          C'est aussi bête que de dire que le boulot fait par les gestionnaires de paquets et les packageurs ne sert à rien. Ca marche mieux pour eux par ce qu'ils construisent une configuration figée.

                          Désolé mais je vois pas le rapport et je ne crois pas avoir dit quelque chose de la sorte.

                          • [^] # Re: Mes idéaux

                            Posté par . Évalué à  4 .

                            Ça, je ne le maitrise pas et c'est juste ça qui me gêne.

                            http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies

                            Soit il y a une solution viable (soft2 est correct avec la version 1 ou soft1 est correct avec la version 2) et tu peux la forcer. Soit y'a pas de solution à ton problème.

                            Non, je n'ai pas perdu mon temps. Je connais ce que j'inclus et je le maîtrise. Trop de dépendances ? Ok, on prend une lib plus légère.

                            Gère un projet un tant soit peu important avec qui à 10 ans d'historique et on en reparle. De même pour faire un système d'intégration continue, gérer à la main c'est tout réinventer.

                            Une fois que tu as tes builds en place, et que tu développes en testant alors les erreurs d'assemblage qui pourraient se produire tu les détectes immédiatement (autrement y'a un problème dans les tests). Si tu le fais à la main, tu ne vas pas pouvoir intégrer de manière agressive dès le début de ton projet, donc tu détecteras ces problèmes très très tard.

                            Maven à des milliards des défauts mais la tu reproches un truc qui touche n'importe quel gestionnaire de dépendance.

                            Après si tu bosses sur une appli constituée d'un seul module qui dépend de 10 JAR externes, et qui produit un seul JAR qui n'est consommé par aucun autre des tes produits; effectivement tu peux le faire à la main.

                            • [^] # Re: Mes idéaux

                              Posté par (page perso) . Évalué à  1 . Dernière modification : le 30/01/12 à 23:13

                              Merci pour le lien, pour ça, je plussoie ton commentaire.

                              Soit il y a une solution viable (soft2 est correct avec la version 1 ou soft1 est correct avec la version 2) et tu peux la forcer. Soit y'a pas de solution à ton problème.

                              On est d'accord et dans ce cas, on est bien dans la gestion manuelle de la dépendance.

                              Gère un projet un tant soit peu important avec qui à 10 ans d'historique et on en reparle. De même pour faire un système d'intégration continue, gérer à la main c'est tout réinventer.

                              Excusez-moi, maître, je ne suis qu'un simple novice. Je ne suis rien face à votre expérience de projet de 10 ans d'historique...
                              Bon, là, maintenant, tu te calmes, on se connait pas, je sais pas ce que tu fais dans la vraie vie, tu ne sais pas ce que je fais dans la vie (même si c'est pas dur à trouver) alors arrêtes de me prendre de haut parce qu'à part m'énerver, ça sert à rien.

                              Maven à des milliards des défauts mais la tu reproches un truc qui touche n'importe quel gestionnaire de dépendance.

                              J'ai jamais dit parlé d'autres gestionnaires, mon garçon. On me parle de Maven, je parle de Maven. Et effectivement, ce que je reproche à Maven, je le reproche aussi aux autres.

                      • [^] # Re: Mes idéaux

                        Posté par (page perso) . Évalué à  1 .

                        Tout à fait d'accord mais quand tu codes une appli en C/C++, il est quand même rare, me semble-t-il, de lier avec deux versions d'un même composant sans qu'il ne se passe de collision.

                        C'est extrêmement courant au contraire et souvent on n'a souvent aucun avertissement, ce qui donne des bugs très subtils et très pénibles à trouver :-(

                        Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                    • [^] # Re: Mes idéaux

                      Posté par . Évalué à  3 .

                      Après le vrai problème; qui existe dans tout les langages mais qui est exacerbé en Java du fait de la réutilisation massive de nombreux composant non inclus dans le runtime, c'est comment avoir deux versions de la même lib en parallèle dans la même appli.

                      Je doute qu'un logiciel qui aille dans cette direction (vouloir utiliser parallèlement différente versions de la même bibliothèque) puisse aller bien loin sans causer une vague de suicide chez les développeurs. On ne déclare pas des dépendances pour le plaisir et surtout pas sans une concertation avec l'ensemble de l'équipe. Je ne vois pas comment on peut maintenir un logiciel (d'une certaine taille, hein) qui possède plusieurs versions d'une même bibliothèque (incompatible entre elles parce que sinon ça ne sert à rien) et cela pour plusieurs bibliothèques.

                      Mais pour ce genre de méthodes, peut être que OSGi/iPjoo pourrait faire l'affaire (les bundles déclarent leurs dépendances et on laisse le soin au framework de résoudre les dépendances).

                      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                      • [^] # Re: Mes idéaux

                        Posté par . Évalué à  2 .

                        Je doute qu'un logiciel qui aille dans cette direction (vouloir utiliser parallèlement différente versions de la même bibliothèque) puisse aller bien loin sans causer une vague de suicide chez les développeurs.

                        Bien sur que si. C'est même ce que demande les développeurs.

                        C'est un cas très courant. La plupart des applications d'entreprises sont des gros assemblages de modules, dont chacun dépend de pas mal de choses. Et c'est très difficile de synchroniser tout le monde sur des versions identiques de lib. Par ce que tout les modules développés en interne n'évoluent pas forcement à la même vitesse, par ce que tu es dépendant de projet tiers, ou par ce que tu as une bonne raison d'utiliser une version précise.

                        On ne déclare pas des dépendances pour le plaisir et surtout pas sans une concertation avec l'ensemble de l'équipe.

                        Avec ton équipe oui. Le problème c'est que le bundle final c'est un assemblage du boulot de 3..20 équipes qui bossent chacune sur une fonctionnalité.

                        De même tu te retrouves souvent à intégrer des modules qui n'ont pas été développé avec un produit donné en vue. Par exemple je développe une lib interne pour un produit 1 et d'un seul coup le produit 2 l’intègre aussi. Rien ne te dit que produit 1 et produit 2 sont d'accord sur les versions de lib.

                        Mais pour ce genre de méthodes, peut être que OSGi/iPjoo pourrait faire l'affaire

                        C'est l'idée oui. Ce que tu voulais à la base c'est avoir accès à une interface, tout ce qu'il faut pour implémenter cette interface ca devrait être caché et isolé pour n'avoir aucun impact sur le reste du monde.

                        Mais on pratique actuellement on y va plus à la hache qu'autre chose.

                        • [^] # Re: Mes idéaux

                          Posté par . Évalué à  2 .

                          C'est un cas très courant. La plupart des applications d'entreprises sont des gros assemblages de modules, dont chacun dépend de pas mal de choses. Et c'est très difficile de synchroniser tout le monde sur des versions identiques de lib. Par ce que tout les modules développés en interne n'évoluent pas forcement à la même vitesse, par ce que tu es dépendant de projet tiers, ou par ce que tu as une bonne raison d'utiliser une version précise.

                          Alors, il faut apprendre aux développeurs java le concept de compatibilité ascendente et de stabilité des API/ABI. Enfin, note qu'on matraque déjà ça aux développeurs ruby mais que ça ne veut pas rentrer.

                          • [^] # Re: Mes idéaux

                            Posté par (page perso) . Évalué à  2 .

                            Peut être qu'ils ont compris mais avec un langage bien dynamique, le compilateur ne les prévient pas assez!

                            Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                          • [^] # Re: Mes idéaux

                            Posté par (page perso) . Évalué à  1 .

                            C'est surtout les ABI-tudes des utilisateurs qui ne respectent pas la compatibilité ascendante !

            • [^] # Re: Mes idéaux

              Posté par . Évalué à  3 .

              C'est dommage, car ça ne correspond pas trop au besoin du libriste amateur

              Hum, si tu regardes le monde du libre le C/C++ y est très bien représenter, ce n'est donc pas vraiment le problème principal..

              • [^] # Re: Mes idéaux

                Posté par (page perso) . Évalué à  2 .

                Si tu n'as pas le temps d'écrire 36 scripts de cross-compilations et de monter 40 machines virtuelles pour tester tous les environnements, mais que tu veux quand même livrer un projet qui tourne sur le maximum de distributions et même sur quelques OS privateurs, C/C++ est inutilisable.

                Ou alors tu acceptes de juste distribuer les sources avec un INSTALL_DEMERDEZ_VOUS.txt.

                Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                • [^] # Re: Mes idéaux

                  Posté par (page perso) . Évalué à  0 . Dernière modification : le 30/01/12 à 18:17

                  Si tu n'as pas le temps d'écrire 36 scripts de cross-compilations et de monter 40 machines virtuelles pour tester tous les environnements, mais que tu veux quand même livrer un projet qui tourne sur le maximum de distributions et même sur quelques OS privateurs, C/C++ est inutilisable.

                  Voilà, t'as tout compris et heureusement pour nous, les environnements seront bientôt tous codés en Java.

                  Ou alors tu acceptes de juste distribuer les sources avec un INSTALL_DEMERDEZ_VOUS.txt.

                  Oui parce que je distribue pas les sources à ceux qui peuvent pas les installer.

                  • [^] # Re: Mes idéaux

                    Posté par (page perso) . Évalué à  2 .

                    Voilà, t'as tout compris et heureusement pour nous, les environnements seront bientôt tous codés en Java.

                    Java, Python, Ruby, Perl, PHP... Beaucoup de logiciels libres se basent sur des langages interprétés/bytecompilés. La difficulté de distribuer des binaires compilés n'y est certainement pas étrangère.

                    Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                    • [^] # Re: Mes idéaux

                      Posté par (page perso) . Évalué à  1 .

                      Java, Python, Ruby, Perl, PHP... Beaucoup de logiciels libres se basent sur des langages interprétés/bytecompilés. La difficulté de distribuer des binaires compilés n'y est certainement pas étrangère.

                      Certes mais quoi qu'il arrive, il faut bien un moment où on descend au niveau du binaire compilé dépendant de l'architecture sous-jacente.
                      Mais il est vrai que de distribuer un .py ou un .pl est plus simple que de trouver un packager qui acceptera de s'assurer que tout marche.

                      Après n'utiliser que des binaires n'est pas non plus obligatoire, si on prend un système comme FreeBSD, tout est fait pour utiliser les sources et au final, ça marche plutôt bien.

                      • [^] # Re: Mes idéaux

                        Posté par (page perso) . Évalué à  2 .

                        si on prend un système comme FreeBSD, tout est fait pour utiliser les sources et au final, ça marche plutôt bien.

                        Ca marche bien, mais seulement dans le cadre de FreeBSD.

                        Ce qui n'existe pas, à ma connaissance, c'est un moyen de distribuer une application écrite dans un langage compilé comme C++, Pascal ou Ada aussi facilement que dans un langage interprété/byte compilé.

                        Un .py/.pl/.jar, je peux le mettre en téléchargement et les utilisateurs de pratiquement toutes les combinaisons d'OS, processeurs et distributions pourront s'en servir.

                        Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                        • [^] # Re: Mes idéaux

                          Posté par (page perso) . Évalué à  6 .

                          Je ne suis pas un spécialiste de la distribution mais vu les scripts de démarrage de la plupart des applications java, je doute qu'un .jar soit suffisant quand le projet devient un peu conséquent.

                          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                          • [^] # Re: Mes idéaux

                            Posté par (page perso) . Évalué à  1 .

                            C'est souvent juste pour aider les utilisateurs qui ne savent pas taper:

                            java -jar monsupersoft.jar
                            
                            

                            Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                            • [^] # Re: Mes idéaux

                              Posté par (page perso) . Évalué à  4 .

                              Il y a bien plus que ça dans les scripts en général.

                              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                              • [^] # Re: Mes idéaux

                                Posté par (page perso) . Évalué à  4 .

                                Si le projet Java utilise des libs native, ça peut aussi demander quelques mises à jour de variables d'environnements.

                        • [^] # Re: Mes idéaux

                          Posté par (page perso) . Évalué à  1 .

                          Ca marche bien, mais seulement dans le cadre de FreeBSD.

                          Je pense que c'est juste un choix. Après tout, les ports FreeBSD, ce ne sont que des Makefiles, des fichiers de checksum et des fichiers patch. Il n'y a donc pas grand chose qui puisse empêcher la portabilité d'un tel système, si ce n'est inclure dans le système de base des choses qui n'y sont pas normalement dans une distrib Linux.

                          • [^] # Re: Mes idéaux

                            Posté par (page perso) . Évalué à  2 .

                            Donc il faut demander à tes utilisateurs d'installer des outils de développement, de savoir taper des commandes et de te taper des Makefile tenant compte des N OS et distributions.

                            Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                            • [^] # Re: Mes idéaux

                              Posté par (page perso) . Évalué à  1 .

                              Donc il faut demander à tes utilisateurs d'installer des outils de développement

                              Est-ce si gênant ?

                              de savoir taper des commandes

                              Ce serait vrai si on ne savait pas faire d'IHM au-dessus de commandes shell.

                              et de te taper des Makefile tenant compte des N OS et distributions.

                              C'est du libre, fais le pour les OS que tu vises et s'il y a une demande pour ton soft sur un OS que tu ne possèdes pas ou ne cible pas, il y aura bien dans la nature un porteur. C'est d'ailleurs ce qui se passe pour une bonne partie des logiciels sous Linux.

                              De toutes façons, tu auras toujours le problème de la présence ou de l'absence de la machine virtuelle pour l'OS que tu vises. Aujourd'hui, en Java, je n'ai pas machine virtuelle disponible en binaire pour FreeBSD, je suis obligé de recompiler.

                              • [^] # Re: Mes idéaux

                                Posté par (page perso) . Évalué à  2 .

                                Est-ce si gênant ?

                                Pas pour un outil de développement, mais pour une application grand public, comme le jeu que je développe par exemple, le public visé n'a pas envie de se prendre la tête.

                                C'est du libre, fais le pour les OS que tu vises

                                Je vise le maximum d'OS, donc au moins Linux, Windows et Mac OS et plus si possible.

                                s'il y a une demande pour ton soft sur un OS que tu ne possèdes pas ou ne cible pas, il y aura bien dans la nature un porteur

                                Les porteurs, ça court les rues, c'est bien connu!

                                De toutes façons, tu auras toujours le problème de la présence ou de l'absence de la machine virtuelle pour l'OS que tu vises.

                                Les interpréteurs des langages populaires sont installables facilement pour 99% des utilisateurs.

                                Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

                                • [^] # Re: Mes idéaux

                                  Posté par (page perso) . Évalué à  3 .

                                  Je vise le maximum d'OS, donc au moins Linux, Windows et Mac OS et plus si possible.

                                  Heu... hurd ? ha non, je sais tu es en train de préparer le port pour MultiDeskOs !

                                • [^] # Re: Mes idéaux

                                  Posté par (page perso) . Évalué à  0 .

                                  Les porteurs, ça court les rues, c'est bien connu!

                                  Ben vu le nombre de lib natives qu'embarque ton jeu, il doit bien en exister quelques uns quand même...

                • [^] # Re: Mes idéaux

                  Posté par (page perso) . Évalué à  1 .

                  Qt ?

            • [^] # Re: Mes idéaux

              Posté par (page perso) . Évalué à  6 .

              C'est dommage, car ça ne correspond pas trop au besoin du libriste amateur qui veut passer le maximum de temps sur le cœur de ses projets et pas sur les problèmes techniques.

              Détrompe toi !
              Grâce au design intelligent d'Ada, le libriste passe plus de temps à coder le cœur de ses projets qu'à en débugger des pointeurs déréférencés !
              95% des logiciels libres écrits en C gagneraient sans doute à être écrits en Ada !
              D'ailleurs, je vais m'y remettre de ce pas !

        • [^] # Re: Mes idéaux

          Posté par (page perso) . Évalué à  2 .

          J'ai pas parlé de cross compilation mais je dirais juste que c'est aussi simple que d'avoir un compilateur croisé Arm sur plate-forme Intel... Donc, c'est pas si facile :D

          Mais ça existe ;)
          Une petite recherche Google m'a rapporté ça par exemple.

  • # Sather

    Posté par (page perso) . Évalué à  5 .

    Un langage à la Eiffel en plus simple et sans la covariance : Sather !

    Sather a presque tout : des types mutable ou immutable clairs. Un arbre d'héritage simple ou seul les feuilles peuvent être instanciés et ou l'on peux surtypé (chose fondamentale que l'on presque nulle pars)... Sather a aussi la notion d'iterator intégré dans les classes sous forme de coroutine, cela permet de faire des boucles ayant un taux d'erreur très faible et d'une clarté limpide (rien à voir avec les bouses de classes parallèles du C++).

    http://www.gnu.org/software/sather/docs-1.2/tutorial/iterators.html

    Il manque une petite mise à jour de l'ensemble ;-) A mon avis, il faut aussi un environnement parallèle de base fiable (pSather ?) et surtout, on a besoin de nos jours de pouvoir intégrer dans le langage la programmation événementielle, genre les slots de Qt ? Il est aussi important de pouvoir programmer en utilisant des fonctions non bloquantes sans faire des usines à gaz... J'aime bien aussi le framework Coro de Perl qui pourrait être une bonne base d'inspiration.

    http://search.cpan.org/dist/Coro/Coro/Intro.pod

    Le langage doit permettre de faire des programmes parallèles de type calcul (MPI - Fortran - Performance) et de type serveur (exemple ejaberd - Erlang - Robustesse)...

    Si on pars sur un langage typé (compilé), il faut aussi la compilation modulaire (chose que ne faisait pas le compilateur Sather) et évidement des espaces de noms... Donc il faut aussi un CPAN structuré et central comme le CPAN (pas une hiérarchie idiote en reverse DNS comme le java).

    Enfin, le langage doit normaliser le mappage des objets dans le format ELF afin de faciliter les passerelles avec les autres langages, notamment le C !

    • [^] # Re: Sather

      Posté par . Évalué à  5 .

      (pas une hiérarchie idiote en reverse DNS comme le java).

      C'est pas plutôt les "DNS" qui sont inversé?
      On lit de gauche à droite, donc on s'attend à une lecture global.moins_global.encore_moins_global.etc .

      • [^] # Re: Sather

        Posté par (page perso) . Évalué à  6 .

        Le problème n'est pas la !

        Java prône une organisation basée sur les noms de domaine des projets. C'est idiot. Le CPAN de Perl est organisé autour des thématiques. Lorsqu'un domaine émerge, tous les projets contribuent et le sous (et les sous) domaine(s) prennent de l'ampleur. Par exemple Moose:: DBI:: POE:: etc.

        Bref, le CPAN est un réseau hiérarchique collaboratif constructif alors qu'avec Java, tu pioches des JAR à droite et à gauche...

  • # pour moi

    Posté par (page perso) . Évalué à  9 .

    notre bon vieux C des chaumières, réhaussé d'un foreach et des tables de hash de PERL.
    surtout pas des templates.
    surtout pas un garbage collector ou autre horreur ralentissante de ce type.
    surtout pas de fonctionnalités qui appartiennent normalement a l'OS.
    peut être une syntaxe mettant en valeur les section parallelisables, sans que ce soit forcé ni calculé.

    • [^] # Re: pour moi

      Posté par . Évalué à  1 .

      Je plussoie et j'ajoute les regex intégrées.

    • [^] # Re: pour moi

      Posté par (page perso) . Évalué à  4 .

      surtout pas un garbage collector ou autre horreur ralentissante de ce type.

      Plus tu travailles sur un problème tentaculairement gros et plus le nombre d'intervenants augmente (avec du turn-over), et bien plus le nombre d'erreurs de ce type va être grand, et à la fin le temps les résoudre va exploser.
      Alors un garbage collector me semble un bon compromis dans un bon nombre de cas. Il faut choisir quel inconvénient est le plus acceptable.

      Quel alternative? La gestion manuelle? Les compteurs de références (prend garde au cycle). Si quelqu'un a la solution miracle, il est le bienvenu.

      • [^] # Re: pour moi

        Posté par . Évalué à  7 .

        Ca depend enormement de ce que tu fais aussi.
        Sur un process qui dure longtemps (serveur), le gc me parait indispensable. Ou plutot, il est idiot de s'en passer.
        Ne serait ce que pour eviter la heap fragmentation. Tu te fout de savoir si tu vas te prendre une pause de 500ms ici et la, t'as rien a gagner a grapiller le peu de ram que tu gagnerais (potentiellement perdu en fragmentation) et le temps passe a debugger les pb de memoires est mieux passe a faire autre chose.

        Sur une interface graphique, une pause de 50ms, c'est la fin du monde.
        Dans le monde mobile, les applis tournent tellement peu longtemps que le gc n'apporte rien du tout et va te tuer sur les pauses.

        En gros, c'est comme tout, ca depend.

        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

        • [^] # Re: pour moi

          Posté par . Évalué à  3 .

          Oui enfin avoir des temps de réponse déterministes ça peut aussi être utile pour un serveur. Ce qui ne veut pas dire que c'est impossible avec un GC mais que ça demande des technos pointues disponible dans peu de langage et d'architecturer correctement ses applis.

          Si tout le monde s'en battait sérieux dans les serveurs Azul ferait pas son beurre avec son pauseless GC et des armées d'ingé passeraient leur temps à essayer de voir ce qu'on arrive à faire.

          • [^] # Re: pour moi

            Posté par . Évalué à  3 .

            Oui, tout comme c'est un probleme quand ton serveur avec 16Go de heap se prend un full gc dans la gueule.
            Cela dit la tendance actuelle est plutot a scaler horizontalement des petites box (probablement entre autres pour eviter ce genre de pb).

            Rien n'est jamais aussi simple, et je me dit qu'une pause gc est inacceptable pour, par exemple, google et ses suggestions instantanees.

            Dans l'ensemble c'est pas souvent un probleme.
            Si c'etait tant un probleme que ca, on aurait pas un ecosysteme aussi riche que ca en Java, pour reutiliser le meme genre d'arguments.

            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

            • [^] # Re: pour moi

              Posté par (page perso) . Évalué à  2 .

              On parle ici du langage pour demain !

              Qui a encore aujourd'hui une machine mono-coeur ? Le langage doit être parallèle dans sa conception, les appels systèmes doivent être non bloquant afin de pouvoir être mis dans des boucles d'évènement. Un certain nombre de structure doivent être clairement immutable ce qui simplifie le travail sur la mémoire.

              Le GC travaille donc en tâche de fond, en fait un peu comme l'OS. A par dans la problématique du temps réel, qui se plaint de l'OS de nos jours ?

              Je ne vois pas l'intérêt de refaire encore un autre langage basé sur une hypothèse de mono-processus de nos jours !

              • [^] # Re: pour moi

                Posté par . Évalué à  2 .

                Dans ces cas là, j'aimerais que tu répondes à la question que je pose dans le journal : quel paradigme de programmation parallèle imposes-tu dans le langage ?

                • [^] # Re: pour moi

                  Posté par . Évalué à  2 .

                  VHDL

                  ->[]

                • [^] # Re: pour moi

                  Posté par (page perso) . Évalué à  3 .

                  Pourquoi veux tu que j'impose quelque chose, nous sommes dans une discution ;-)

                  Je pense que tout le langage de base doit être compatible pour le parallélisme et les fonctions systèmes non bloquantes. Ensuite, le langage doit privilégier les variables immutables plus simple à gérer et posant moins de problème de parallélisme. On doit avoir des boucles d'évènement intégrés dans le langage. A ce niveau là, je pense qu'Erlang montre bien une voie.

                  Bref, il faut arriver à gérer 50 000 processus parallèle simplement et de manière efficace sur un cluster. On sais faire cela aujourd'hui avec MPI qui utilise l'envoi de message... Encore une fois, les objets immutables sont d'une grande aide et Erlang les a mis au coeur du langage.

                  Une autre voie sont les fonctions pures de Fortran90. Mais cela me semble quand même très dédié calcul et peu généralisable...

                  Bref, je ne suis pas un architecte des langages. Je dirais qu'avec les interfaces graphiques, le web2 et le nombre de plus en plus élevé de coeur que nous avons sur une machine, il faut un langage objet parallèle et événementiel qui intègre de base une API efficace sur les tableaux et les tables de hachage. Avec cela, on a de quoi s'amuser pour quelques années ;-)

                  En conclusion, il faudrait Sather dans lequel on introduit toutes les bonnes idées d'Erlang ;-)

        • [^] # Re: pour moi

          Posté par . Évalué à  3 .

          Dans le monde mobile, les applis tournent tellement peu longtemps que le gc n'apporte rien du tout et va te tuer sur les pauses.

          Tu peux, dans une certaine mesure, choisir où se trouvent les pauses. En OCaml par exemple tu as un GC générationnel, avec un tas mineur (petit et rapide à collecter, pas de problème de pause) et un tas majeur pour les vieux objets, plus gros, et collecté incrémentalement. Il n'y a une pause (tas majeur complet et compaction) que dans les situations critiques où il n'y plus assez de mémoire pour continuer à allouer. Le critère de "trop de mémoire" (ou trop de fragmentation) est configurable, tu peux dire "je veux une pause quand j'arrive aux 3/4 de ma mémoire occupée".

          Si ton application ne tourne pas longtemps et n'est pas trop gourmande en mémoire, tu ne vas donc pas avoir de pause. Par contre si ton application est mal codée, même si elle dure peu de temps, elle va finir par manger trop de mémoire. Dans ce cas là, est-ce que tu préfères que cette application subisse une pause, ou que tout ton système se retrouve dans la merde à cause d'un manque de mémoire disponible (OOM killer, etc.)?

          Bref, il me semble que dans le cas des applications à faible durée de vie, la présence d'un GC (bien conçu) ne change pas grand chose; soit elles sont raisonnables en mémoire et il n'y a pas de pause, soit elles ne le sont pas et tu as un problème de toute façon, la pause n'étant pas forcément la pire des solutions.

          • [^] # Re: pour moi

            Posté par . Évalué à  3 .

            Ce que je n'aime pas dans les GC, et qui est aussi un des inconvénients des applications parallèles, c'est le non-déterminisme. Tu ne sais pas quand ton GC va se mettre en route (tout comme tu ne sais pas quelle instruction sera exécutée en premier dans deux morceaux de code concurrents). Du coup, tu t'exposes à des fonctionnement "bizarres" du point de vue de l'utilisateur, ou même à des bugs qui ne se déclenchent que dans une certaine configuration qui n'arrive que tous les 36 du mois.

            • [^] # Re: pour moi

              Posté par . Évalué à  3 .

              En théorie oui, en pratique je ne l'ai pas encore rencontré.

              Tu perds déjà beaucoup avec le scheduler de ton OS (sauf peut être quand il est temps réelle).

              Si c'était un problème si pressent les utilisateurs de Java, Perl, PHP, python, ocaml et autres l'auraient déjà rencontré.

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: pour moi

              Posté par . Évalué à  2 .

              Si tu écris du code concurrent qui n'est pas concurrent bin oui t'auras des problèmes... Autrement c'est prévu à la base que l'ordre et la durée d'exécution ne sont pas détermiste; et tu as prévu tes données et ton flow d'execution pour.

              Avoir un GC ou pas ne change rien à l'affaire. Sauf qu'un bout de tes fils d'execution peut s'arreter un peu plus longtemps que ce que tu avais imaginé. Mais ca pourrait être causé par autre chose qu'un GC. Soit ton code est correct soit il est buggé et la pause ne fait que le mettre en évidence.

          • [^] # Re: pour moi

            Posté par (page perso) . Évalué à  9 .

            tu peux dire "je veux une pause quand j'arrive aux 3/4 de ma mémoire occupée".

            Avoir à configurer la quantité de mémoire à utiliser (ex: Java et son option -Xmx) est pour moi super naze. Comment la détermine-t-on? Pourquoi par exemple je devrais décider que mon Tomcat est sensé utiliser 500Mo ou 1Go? Si le processus a besoin de plus de mémoire que je croyais, il part en vrille. Je veux utiliser des programmes, pas devenir un administrateur de VM.

            • [^] # Re: pour moi

              Posté par . Évalué à  3 .

              Personne n'a dit que c'était à toi (toi utilisateur ou toi développeur) de gérer ça. Mais la mémoire étant finie, il faut bien que les logiciels évitent d'en abuser. Le fait qu'un logiciel utilise un GC ou gère la mémoire à la main ne change rien : il y a une limite à la quantité de mémoire, fixée par le développeur et/ou un intégrateur de distribution et/ou l'utilisateur, et ultimement par la limite physique du système, et si le logiciel abuse, ça pose problème.

              Mon commentaire avait pour seul but de dire qu'isoler des cas particuliers pour dire "dans ce cas là on n'a pas besoin de GC et on ne veut pas de pauses donc on évite le GC" n'est pas forcément pertinent quand ces cas particuliers (logiciel à courte durée d'exécution), justement, sont tout aussi bien gérés par le GC pour éviter les pauses.

              Je suis sûr qu'il y a des cas spécifiques où on ne peut se permettre aucune forme d'allocation dynamique -- GC, ou malloc d'ailleurs -- par exemple dans certains systèmes embarqués temps-réel à fortes contraintes. Mais dans ce cas l'argument va plus loin que "le logiciel ne dure pas longtemps donc je n'ai pas besoin de libérer de la mémoire".

              • [^] # Re: pour moi

                Posté par . Évalué à  1 .

                Ben les pauses sont une catastrophe sur une interface graphique, serieusement.
                Je me fait chier a grapiller 20ms sur le main thread pour afficher une table sans pauses et que ca scrolle de facon impeccable meme sur un 3g, c'est pas pour me prendre une pause a la run loop suivante.
                Quand eclipse se prend un full gc dans la gueule et me fait poireauter 2 secondes avant de me redonner la main, ca fait serieusement chier.

                Et je pense que c'est la raison pour laquelle apple s'est toujours refuse a integrer le gc qu'ils ont pour macos dans ios.
                Les benefices apportes sont trop faible par rapport a la punition.

                If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                • [^] # Re: pour moi

                  Posté par (page perso) . Évalué à  3 .

                  A l'heure des téléphones dual core, est-il possible de faire tourner le GC sur l'autre core que l'UI histoire d'éviter les pauses ?

                  • [^] # Re: pour moi

                    Posté par . Évalué à  5 .

                    Retour a la case depart.
                    L'autre core est la pour une raison, et c'est pas pour le gc. Mes 3 applis sur le store font un usage intensif de GCD et tournent avec un pool de 5 a 15 threads. Ces threads, si je peux les faire tourner sur un deuxieme core et gagner du temps sur mon background processing, ben ca fait ca de gagne pour mes utilisateurs. Quand l'appli demarre et qu'elle doit parser 4Mo de json, si je peux saturer un coeur, ca me fait une demi seconde de gagnee, et ca fait une reelle difference a l'usage.
                    J'ai vu une amelioration massive de fluidite/perfs le jour ou je suis passe d'un 4 a un 4S.

                    Et mon telephone, il a un client mail et calendrier et une synchro iCloud, ca serait cool de faire tourner ca reellement en parallele.
                    Sans compter que faire tourner un cpu, ca bouffe de la batterie, donc si on peut s'en passer tant mieux (encore qu'il reste a prouver l'augmentation de consommation, mais le cote continu doit pas aider).

                    Et faut aussi se coltiner un gc pauseless, ce qui est pas facile a ecrire en premier lieu.

                    L'autre truc aussi, c'est qu'on raisonne beaucoup en comparant a une jvm par exemple, en oubliant que la jvm tourne dans 4Go de ram sur un i7 branche a une prise de courant.
                    Pas sur un arm a 512Mo sur batterie.

                    Dernier point, le monde mobile est comparable au monde du jeu video sur un point: toutes les avancees technologiques sont immediatement consommees pour en faire plus, pas pour apporter du confort au dev.
                    Compares une appli typique de l'epoque 3gs a une appli typique d'aujourd'hui, tu vas voir une enoooorme difference niveau look and feel, animations et tout le tralala.
                    En gros, une appli d'il ya 2 ans tournerait probablement decemment svec gc sur un telephone d'aujourd'hui, mais le pb c'est que les applis d'aujourd'hui en demandent plus.

                    Ca va bien finir par se stabiliser un jour, surtout vu la progression fulgurante du matos.
                    Apple va probablement passer au quad core pour l'ipad3, ce qui nous donne une multiplication par 15 ou 20 de la puissance par rapport au 3g, mais vu que le besoin explose selon la meme courbe, ben au final t'es au meme niveau...
                    Compares avec l'industrie du pc, ca a prit 25 ans pour que le cpu devienne non pertinent (arrivee du core2duo).

                    Met ca en perspective avec la complexite de gerer la memoire avec ARC. Tu definis les relations entre objets (weak/strong) et c'est tout. Une fois tous les 36 du mois du fait un CFRetain/CFRelease, et llvm te gueule dessus quand t'en a oublie un. Une fois tous les 36 du mois, tu crees ton propre auto release pool quand t'alloues localement comme un porc. Instruments te montrera ca en qq minutes.
                    La heap compaction, on s'en fout, les applis sont utilisees en moyenne moins de 5 minutes, c'est pas un gc qui va te sauver si t'arrives a avoior ce genre de pb aussi vite. Ce qui compte plus que tout, c'est la reactivite (ou plutot, l'illusion de reactivite, mais c'est un autre debat ca).
                    Sur ipad, la donne est un peu diffente, mais pas fondamentalement differente.

                    Bref, le gain de confort est extremement faible, les pertes sont loin d'etre negligeables.

                    If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                    • [^] # Re: pour moi

                      Posté par . Évalué à  2 .

                      Ce que tu oublies dans cette belle histoire c'est que les GCs peuvent parfois être justifiés pour des raisons de performance. Concrètement entre un système à GC et un système à reference counting, les GCs (bien codés) sont plus performants en général pour les workflows où tu alloues pas mal, car les incrémentations/décrémentations du refcounting coûtent beaucoup. Donc une des raisons d'utiliser un GC plutôt que du refcounting (automatisé ou manuel) est d'avoir un meilleur throughput.

                      Alors oui, quand tu veux un GC sans pauses (ou une solution de gestion de mémoire sans pauses), tu utilises des algorithmes différents, qui font des compromis différents, et qui rendent les applications moins performantes globalement (qu'un GC qui s'autorise des pauses dans certains cas). Il faut choisir ce qu'on veut optimiser, et je comprends très bien que dans certains domaines applicatifs ce soit un meilleur compromis; typiquement tout ce qui est interface utilisateur, où la réactivité importe plus que la rapidité dans l'absolu.

                      Mais là tu veux le beurre et l'argent du beurre. Tu me dis "on ne peut pas avoir de pauses donc on fait du refcounting", et ensuite "on est vachement limité sur le temps de calcul donc on ne peut pas se permettre un GC". C'est beau d'être en symbiose avec une couche technologique comme tu l'es, mais il ne faut pas que ça te masque la réalité : tous les choix ont leurs avantages et inconvénients, et si de nombreux langages choisissent d'utiliser un GC plutôt que du refcounting, c'est parce que c'est une meilleure approche dans de nombreux cas; ARC n'est pas une technologie magique qui résoud tous les problèmes.

                      • [^] # Re: pour moi

                        Posté par . Évalué à  0 .

                        Ce que tu oublies dans cette belle histoire c'est que les GCs peuvent parfois être justifiés pour des raisons de performance. Concrètement entre un système à GC et un système à reference counting, les GCs (bien codés) sont plus performants en général pour les workflows où tu alloues pas mal, car les incrémentations/décrémentations du refcounting coûtent beaucoup. Donc une des raisons d'utiliser un GC plutôt que du refcounting (automatisé ou manuel) est d'avoir un meilleur throughput.

                        Ben ouais, mais la on parle pas d'un in memory cache avec 16Go de heap ou d'un tomcat qui sert 2000 requêtes/seconde, on parle d'un telephone.
                        Le jour ou les allocations diablement peu couteuses d'un gc feront une différence mesurable sur un telephone, de l'eau aura coule sous les ponts, sans meme compte que ça concerne des applications suffisamment complexes pour nécessiter une equipe de top developeurs de toutes façons, qui sauront resoudre le probleme proprement.

                        Tu me dis "on ne peut pas avoir de pauses donc on fait du refcounting", et ensuite "on est vachement limité sur le temps de calcul donc on ne peut pas se permettre un GC". C'est beau d'être en symbiose avec une couche technologique comme tu l'es, mais il ne faut pas que ça te masque la réalité : tous les choix ont leurs avantages et inconvénients, et si de nombreux langages choisissent d'utiliser un GC plutôt que du refcounting, c'est parce que c'est une meilleure approche dans de nombreux cas; ARC n'est pas une technologie magique qui résoud tous les problèmes.

                        Non, ce que je dit, c'est que le GC apporte tres peu et que les ressources qu'il va consommer seraient bien mieux employées ailleurs. Et qu'on a largement le temps de voir venir avant que le GC devienne un priorité.

                        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                        • [^] # Re: pour moi

                          Posté par . Évalué à  2 .

                          Ben ouais, mais la on parle pas d'un in memory cache avec 16Go de heap ou d'un tomcat qui sert 2000 requêtes/seconde, on parle d'un telephone.

                          Ce n'est pas cohérent avec ce que tu disais dans ton message précédent:

                          L'autre core est la pour une raison, et c'est pas pour le gc. Mes 3 applis sur le store font un usage intensif de GCD et tournent avec un pool de 5 a 15 threads. Ces threads, si je peux les faire tourner sur un deuxieme core et gagner du temps sur mon background processing, ben ca fait ca de gagne pour mes utilisateurs. Quand l'appli demarre et qu'elle doit parser 4Mo de json, si je peux saturer un coeur, ca me fait une demi seconde de gagnee, et ca fait une reelle difference a l'usage.

                          Donc tu as bien parfois des besoins de performances sur ton téléphone. Attention, je n'ai pas dit que tu avais toujours besoin de perfs, au contraire. J'ai dit que je comprends ton insistance sur la fluidité/réactivité et donc le risque lié aux pauses, et que je pense que ça justifie une diminution du throughput global. Par contre tu ne peux pas dire à la fois "on ne veut pas de GC pour éviter les pauses" et d'un autre côté "mais les performances c'est essentiel donc je ne veux pas de GC".

                          Par ailleurs il ne faut pas trop nous faire pleurer sur les 512 Mo de RAM de ton téléphone, c'est ce qu'on avait il y a quelques années seulement sur les ordinateurs desktop, et on raisonnait déjà sur ces choses là. Le GC OCaml par exemple a été développé début 90, pour être compétitif sur les machines de l'époque.

                          • [^] # Re: pour moi

                            Posté par . Évalué à  0 .

                            Qu'est ce que ca a de pas coherent?
                            Le parsing json, il alloue essentiellement sur la stack,le processing en question, il alloue tres peu aussi, ca bouffe juste du cpu, c'est tout.
                            Et GCD ca veut dire grand central dispatch, c'est la lib de threading d'apple, des fois que la partie gc de gcd t'aies confus.

                            Le gc va me bouffer une partie de ce temps cpu et rien m'apporter de concret - c'est pas pour les allocations que je fais que le GC va m'apporter quoi que ce soit.

                            mais les performances c'est essentiel donc je ne veux pas de GC

                            Tout le point des mes messages, c'est justement de dire "performance tout seul, ca veut rien dire, ca depend de quoi on parle".
                            Le throughput global, s'il est toujours inferieur a ce que la machine supporte, qu'est ce qu'on s'en fout de le faire baisser?

                            Par ailleurs il ne faut pas trop nous faire pleurer sur les 512 Mo de RAM de ton téléphone

                            Ola! Tu vas bien vite en besogne mon canard, 512, c'est la rolls, aujourd'hui, tu tables generalement sur 256 (3gs, ipad, ipod), voire 128 pour les malheureux qui doivent encore supporter les 3g (ca devient de moins en moins courant, heureusement).

                            Par ailleurs, ton desktop, il avait 1Go de swap a l'epoque. Ca existe pas sur telephone le swap. En tout cas, pas encore.

                            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                  • [^] # Re: pour moi

                    Posté par . Évalué à  3 .

                    Ah, autre example, pour te donner une idee des pb qu'on rencontre dans le monde mobile.

                    Mes applis au taffs affichent enormement d'images telechargees d'internet, enfin du site web quoi. C'est un peu motre fierte, on a nos photographes a nous pour prendre les photos en haute res et tout.
                    Ces images sont dispo pour le site web en plein de resolutions differentes, du thumbnail au 2048*machin.
                    Bon.

                    On a commence naivement: on choppe la version legerement plus grande que la vue, et on laisse UIImageView redimmensionner.
                    Ca nous a tue sur le main thread, ca saccadait tellement que c'etait pas utilisable, meme dans le simulateur.

                    Bon, ok, on passe sur un background thread et on fait tout en async, ca devrait faire l'affaire.
                    Et ouais, ca scrolle au poil maintenant.
                    On utilise l'appli, pis le telephone chauffe. Et on se rend compte aussi que certaines partie de l'appli, genre traitement des donnees recues sont anormalement lente.

                    Telephone qui chauffe, pas bon, ca veut dire que tu tues la batterie.
                    On sort instruments, ah ouais, resizer un jpeg de 1024 vers 960 avec une qualite correcte, ca pompe. Grave.
                    C'est probablement pour ca qu'apple preconise du png pas compresse en fait.

                    On a fini par deployer notre propre service qui resize a la volee, le client demande l'image dans une taille donnee, n'a rien a redimensionner (et gagne un peu de bande passante en plus). On perd du temps sur le dl (forcemment, du php chez ec2 face a notre static media farm avec akamai devant...), mais au final on s'en sort achement mieux.

                    Si on passe sur du quad core, ca vaut le coup de tenter le redimensionnement local, l'opps team nous en sera reconnaissante d'avoir un seervice en moins, on pourra profiter du cache akaimai que le site web utilise et je flipperais pas de me lever un matin et de trouver le resizer en carafe.
                    Le gc dans tout ca? A branler.

                    On serait dans le monde desktop, je suis meme pas sur qu'on se serait fait chier a choper la bonne taille d'image: tout en 1600, redimensionne en background et zou.

                    If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

              • [^] # Re: pour moi

                Posté par (page perso) . Évalué à  2 .

                Dans l'exemple que je donnais, j'ai mis dans mon Tomcat une grosse grosse Servlet. Je suis obligé de gérer ça (mettre le -Xmx en ligne de commande pour donner la mémoire maximale utilisable), car si je mets une valeur trop basse (celle de Tomcat par défaut) ça explose.
                Donc je dois mettre une valeur au doigt mouillé. Si je la mets trop haut, ça va retarder la phase de ramasse miette et utiliser de la mémoire pour rien.

                Si on a ce problème avec toutes les applis qui tournent sur la machine, ça devient un gros gâchis.
                Je trouve ça bizarre qu'il y ait toujours ce problème avec Java. Il doit y avoir d'autres stratégies que la limite dure et fixe...

          • [^] # Re: pour moi

            Posté par . Évalué à  1 .

            En OCaml par exemple tu as un GC générationnel, avec un tas mineur (petit et rapide à collecter, pas de problème de pause) et un tas majeur pour les vieux objets, plus gros, et collecté incrémentalement. Il n'y a une pause (tas majeur complet et compaction) que dans les situations critiques où il n'y plus assez de mémoire pour continuer à allouer. Le critère de "trop de mémoire" (ou trop de fragmentation) est configurable, tu peux dire "je veux une pause quand j'arrive aux 3/4 de ma mémoire occupée".

            C'est le cas en java aussi en passant (i.e. une grande partie des programmes côté serveur en profite aujourd'hui déjà).

        • [^] # Re: pour moi

          Posté par (page perso) . Évalué à  2 .

          Dans le monde mobile, les applis tournent tellement peu longtemps que le gc n'apporte rien du tout et va te tuer sur les pauses.

          Comment ça se passe sur Android où plein d'applications sont écrites en Java?

          Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

          • [^] # Re: pour moi

            Posté par . Évalué à  6 .

            Ca se passe mal. Pourquoi tu crois qu'un tiers des applis du market, c'est des tasks killer et que les telephones shippent avec un giga la ou un ipad s'en sort avec 256?
            :)

            Plus serieusement, la majorite des applis va etre envoye au dodo et n'alloueront plus.
            Pas d'allocation, pas de palais. Pas de palais... pas de palais!

            Le peu qui reste va etre reveille une fois de temps en temps pour rercevoir son intent, et le processing va etre assez limite, donc tres peu d'allocation.

            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

            • [^] # Re: pour moi

              Posté par (page perso) . Évalué à  2 .

              Ca se passe mal. Pourquoi tu crois qu'un tiers des applis du market, c'est des tasks killer et que les telephones shippent avec un giga la ou un ipad s'en sort avec 256?

              Un jour, il faudra m'expliquer comment on a pu mettre Java sur les mobiles... A part le marketing de Sun (ceci dit, pareil pour les serveurs, vu ce que ça bouffe comme CPU et RAM, même si c'est pas cher à force de trop consommer...). Apple a été très bon sur ce coup à ne pas accepter cette "mode" de programmation (bon, c'est parce qu'il aime bien tout contrôler... Et ça paye!)

              • [^] # Re: pour moi

                Posté par (page perso) . Évalué à  5 .

                Un indice: 36 variantes de CPU et d'API, l'envie de ne déployer qu'un seul et même binaire.

                Malheureusement Java sur mobile a été si mal fichu et les constructeurs si peu collaboratifs qu'aujourd'hui il y a une pratiquement une variante de Java par mobile...

                Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

              • [^] # Re: pour moi

                Posté par . Évalué à  6 .

                Il y a aussi la possibilité de faire des vérifications sémantiques au niveau du bytecode. Si tu veux permettre à tes utilisateurs d'exécuter du code arbitraire venant de distributeurs tiers que tu ne contrôles pas, c'est quand même assez rassurant (même si ça ne suffit pas complètement), tu peux au moins préserver l'intégrité du système.

                Le choix d'Apple c'est de prendre comme brique de base un langage non-sûr et donc difficile à sécuriser, et de mettre un rideau de fer entre les développeurs et l'utilisateur, en mettant en place un point centralisé de contrôle et de validation du code. Comme ça en plus des problématiques de sécurité ils peuvent forcer une consistence de l'interface, mais aussi éliminer des concurrents gênants et se laisser le monopole sur certaines applications. C'est gagnant pour eux et, il faut l'avouer, confortable pour l'utilisateur... tant qu'il n'essaie pas trop d'être indépendant, mais Apple sait se trouver un public de gens qui privilégient leur confort (comment ne pas écrire petit bourgeois en continuation naturelle de ma phrase ? ;)

                Tant pis pour les développeurs qui veulent un peu de flexibilité, pour les applications qui veulent encourager le partage de code entre utilisateurs, les gens qui veulent apprendre à programmer et montrer leur appli à leurs amis sans payer la taxe... C'est un autre compromis, mais à choisir Java et un mobile qui chauffe ça ne me semble pas si mal.

                On pourrait avoir le beurre et l'argent du beurre avec des outils de vérification statique sur des langages plus bas-niveau que Java, un bon sandboxing par défaut (par exemple NaCL et autres projets de LLVM aseptisé), et des modèles de sécurité robustes mais flexibles pour gérer le transfert de droit dans un contexte moins restrictif -- ce que permettraient la sécurité par capabilities par exemple, comme poussé par certains au sein de Googlet et ailleurs.

        • [^] # Re: pour moi

          Posté par (page perso) . Évalué à  2 .

          Dans le monde mobile, les applis tournent tellement peu longtemps que le gc n'apporte rien du tout et va te tuer sur les pauses.

          Ou alors tu peux utiliser un GC temps-réel.
          C'est pas un truc nouveau.

          Tu peux aussi utiliser un langage de haut niveau avec de l'inférence de région, ce qui te permet de désallouer d'un coup tout un tas de données qui auront même pu être allouées sur la pile alors qu'à la mains, tu aurais été forcé de les mettre dans le tas…

      • [^] # Re: pour moi

        Posté par . Évalué à  2 .

        C'est loin d'être la solution miracle, mais j'aime beaucoup Objective-C pour la gestion de la mémoire, mon plus grand regret est que ça n'est quasiment pas utilisé dans le monde du libre. Ça et le fait que ça soit du vrai C par derrière. Et en plus j'aime bien la syntaxe.

        Je rajouterai également qu'un bon langage n'est pas grand chose sans la bonne IDE qui va avec. JAVA tout le monde s'accorde à dire que c'est à peu près moisi, mais JAVA+Eclipse c'est quand même un couple langage/IDE extrêmement bien foutu.

        • [^] # Re: pour moi

          Posté par . Évalué à  3 .

          Objc a tres clairement un excellent compromis entre complexite manuelle et performance (surtout avec ARC).

          Le pb etant que ca depend a 100% des conventions de nommage, va imposer la meme chose dans le monde du c ou du c++.
          l'autre pb etant la dependance sur un runtime (proprio of course) qu'apple a sacrement raffine au fil de ces 15 dernieres annees, celui de gnu lu arrive pas a la cheville. Resultat, t'es confine au monde macos/ios (ce qui me derange pas personnellement, mais ca va gener pas mal de monde, forcement).

          Et en toute honnetete, leur gc est, mouaif, voila quoi.

          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

    • [^] # Re: pour moi

      Posté par . Évalué à  3 .

      Le problème des GCs, c'est surtout qu'entre un GC et un bon GC, il y a une énorme marge, je dirais même qu'il n'y a aucun bon GC actuellement! Car pour obtenir un bon GC il faut qu'il puisse coopérer avec le gestionnaire de mémoire virtuelle de l'OS..

      Qu'est ce c'est qu'un bon GC? C'est un GC:
      - précis: autrement ton GC peut arrêter de fonctionner dans certains cas, le GC Hans Boehm très utilisé dans le libre n'est pas précis.
      - temps réel, autrement ton GC peut induire des pauses dans ton programme, le seul langage qui a une implémentation libre d'un GC temps réel que je connaisse est SuperCollider, il existe quelques autres GC temps réels pour Java: IBM, Azul mais ils sont propriétaires.
      - qui n’empêche pas le gestionnaire de mémoire virtuelle de l'OS de swapper les objets peu utilisés et là pour autant que je sache, ça n'existe pas! Il y a eu de la recherche là-dessus mais le patch pour Linux a été rejeté, dommage..

      Pourtant l'auteur d'Eiffel Bertrand Meyer argumente qu'on ne peut pas avoir de vrai langage à objet sans GC dans son livre OOSC et je trouve qu'il a raison..

  • # Dépend de l'usage

    Posté par (page perso) . Évalué à  10 .

    Ça dépend beaucoup de l'usage, je n'attends pas les même fonctionnalités si je dois faire un soft pour l'embarqué, un site web, un environnement de bureau…

    « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Dépend de l'usage

      Posté par . Évalué à  0 .

      Oui, mais tu programmes rarement dans tous ces domaines à la fois ;) Donc tu as forcément une petite préférence pour un style de programmation ou un domaine où les langages actuels ne te satisfont pas...

  • # Mouai…

    Posté par . Évalué à  10 .

    J’utilise quotidiennement deux langages, et je jongle avec quatre. Il ne me viendrait pas à l’idée de déplacer mes fichiers avec Fortran, ni faire de la programmation numérique avec le shell. Du coup cette recherche du langage ultime est totalement illusoire.

    D’ailleurs tout le monde sait qu’il existe déjà et qu’il s’appelle Python. :)

  • # Hum ...

    Posté par (page perso) . Évalué à  6 .

    J'aimerais bien avoir du sous-typage (héritage sans polymorphisme) histoire d'éviter de caster quand on adopte une conception objet.

    Déjà, parce que tu as une relation de sous-typage, tu auras de toute façon du polymorphisme via le principe de Liskov.
    Le problème de coercicion vient justement que les langages couramment utilisés ne supportent que le typage du second ordre alors que la programmation orientée objet nécessite un typage du second ordre et plus particulièrement le typage F-Bounded (qui résoult le problème des types récursifs).

    En revanche, je ne mettrais aucun des trucs à la mode du genre closure, programmation fonctionnelle,

    ça par contre c'est bien dommage parce que les closures apportent une force indéniable dans l'écriture et la maintenance de code. (Elles ont montrés leur efficacité dans l'écriture de code orienté-objet avec Smalltalk 80.)
    A côté de ceci, la programmation fonctionnelle est une force parce que justement elle permet d'écrire plus simplement du code qui serait bien plus complexe en programmation impérative. Par contre, oui, je suis plus mitigé du mixe forme fonctionnelle et forme impérative que l'on trouve dans certains langages.

    Surtout, je ne mettrai pas la concurrence dans le langage, parce qu'on n'a pas encore assez d'expérience

    C'est à la fois vrai et faux :
    - vrai parce que globalement dans l'industrie du développement logiciel, les codeurs sont pauvres en expériences et en compétences dans ce domaine,
    - faux parce que ce domaine existe depuis bien bien longtemps et que de nombreuses techniques et forme de programmation existent et ont fait leur preuve mais dans des métiers particuliers les nécessitant (communication, transaction financière, ...)

    • [^] # Re: Hum ...

      Posté par . Évalué à  3 . Dernière modification : le 28/01/12 à 18:14

      A côté de ceci, la programmation fonctionnelle est une force parce que justement elle permet d'écrire plus simplement du code qui serait bien plus complexe en programmation impérative.

      À une époque je voulais faire du ocaml pour me changer les idées. J'ai trouvé un TP de classe prépa sur du codage de Huffman en Ocaml. J'ai refait l'exercice en C parce que nous faisions du C à la fac. Je peux vous dire que ce simple exercice amène vraiment à se demander pourquoi continuer à travailler en C (à moins d'être un masochiste irrécupérable bien sûr).

      Comme je suis bon joueur je cite mes sources :

      Par contre, oui, je suis plus mitigé du mixe forme fonctionnelle et forme impérative que l'on trouve dans certains langages.

      Tu parles de python là ? Tu vas en froisser quelques uns, fais attention. :) De plus je code en python et ce serait intéressant que tu développes davantage ce point. Merci par avance.

      Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

      • [^] # Re: Hum ...

        Posté par . Évalué à  -1 .

        Je peux vous dire que ce simple exercice amène vraiment à se demander pourquoi continuer à travailler en C (à moins d'être un masochiste irrécupérable bien sûr).

        Pour les performances ? Ton code en OCaml, il est simple mais il est ultra-lent certainement comparé à un code en C. En plus, ton implémentation en C n'est pas vraiment optimale je pense...

        • [^] # Re: Hum ...

          Posté par . Évalué à  7 .

          Hum****Désolé de te contredire.

          Je ne crois pas que le code Ocaml ait à rougir au niveau des performances. Le code Ocaml est très rapide, et largement compétitif avec le C.

          J'ai choisi de faire un code simple, peut être pas très optimisé et compréhensible car c'est pour un besoin pédagogique et didactique, ce que le code caml remplit beaucoup mieux.

          (En même temps, c'est un faux argument, ce n'est pas à l'humain de faire les optimisations mais au compilateur.)

          Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

          • [^] # Re: Hum ...

            Posté par (page perso) . Évalué à  4 .

            (En même temps, c'est un faux argument, ce n'est pas à l'humain de faire les optimisations mais au compilateur.)

            C'est un peu plus compliqué que ça malheureusement. Même dans les langages fonctionnels, il est par exemple conseillé de faire des récursions terminales, histoire d'utiliser efficacement la pile. Or la version avec récursion terminale est souvent un peu moins jolie que la version naïve.
            Peut être que des compilateurs sont capable de faire cette transformation tout seuls cela dit (je ne suis pas un spécialiste), mais je pense que le programmeur aura toujours une part de responsabilité dans l'optimisation.

            • [^] # Re: Hum ...

              Posté par . Évalué à  0 . Dernière modification : le 29/01/12 à 02:00

              L'optimisation ne doit pas dépendre du programmeur dans le meilleur des mondes. En pratique je ne doute pas que cela soit nécessaire de temps en temps, mais un bon langage doit permettre au programmeur de laisser ses questions sur l'optimisation de côté je pense.

              Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

              • [^] # Re: Hum ...

                Posté par (page perso) . Évalué à  2 .

                En fait nous sommes d'accord je pense, je voulais juste tempérer tes propos. Parce que la phrase "le compilateur n'a qu'a optimiser", je l'ai souvent entendu prononcée par des mauvais codeurs, qui pondent 100 lignes de code toutes pourries, là où 10 lignes simples suffisaient (mais fallait utiliser sa tête).

                D'ailleurs, quand on réécrit du code en 4 fois de lignes, en ayant la volonté première d'avoir un code plus simple, lisible et maintenable, mais qu'en bonus le code devient plus rapide, est-ce de l'optimisation ?

                • [^] # Re: Hum ...

                  Posté par . Évalué à  3 . Dernière modification : le 30/01/12 à 01:10

                  Oui, le langage a beaucoup à voir dans la quantité de lignes de codes et la simplicité de codage.

                  Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

          • [^] # Re: Hum ...

            Posté par . Évalué à  3 .

            Dans ce cas précis, le code de la correction du TP en tout cas a une mauvaise complexité (insertion en temps linéaire par exemple), mais c'est sans doute fait exprès pour que les élèves y arrivent. Il ne serait pas très difficile de transformer ça en un code efficace, en utilisant de meilleures structures de données, sans changer la structure du code, et tu aurais quelque chose de raisonnable (même par rapport à un code en C; deux fois plus lent qu'un code C bien fait est une bonne cible).

        • [^] # Re: Hum ...

          Posté par . Évalué à  4 .

          Ton code en OCaml, il est simple mais il est ultra-lent certainement comparé à un code en C.

          Ça c'est du FUD. http://www.ffconsultancy.com/languages/ray_tracer/comparison.html
          Ce n'est pas parce qu'on écris du code de haut niveau qu'il manque de performance.

          En plus, ton implémentation en C n'est pas vraiment optimale je pense...

          Tu veut dire qu'en plus OCaml est plus simple/plus maintenanble que la version C ?

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Hum ...

          Posté par (page perso) . Évalué à  6 .

          Tu veux bien nous filer un benchmark avant de dire que le code Caml est ultra-lent ?

      • [^] # Re: Hum ...

        Posté par (page perso) . Évalué à  0 .

        Tu parles de python là ? Tu vas en froisser quelques uns, fais attention. :) De plus je code en python et ce serait intéressant que tu développes davantage ce point. Merci par avance.

        Non, en fait je pensais plus à Scala ; Scala est un langage orienté objet et fonctionnel avec une structure impérative.
        Python est différent : c'est un langage impératif doté de constructions fonctionnelles, ce qui n'est pas la même chose.

        Je reste mitigé quant au mixe des deux approches, impératives et fonctionnelles, parce qu'elles sont disjointes ; ce sont deux modes de pensée différentes au delà des simples constructions. En fonctionnel, il est plus naturel de penser top-down et de ce que l'on veut faire (pas comment faire) et le résultat est la composition de fonctions qui décrit les relations déclaratives (et sémantiques) entre les fonctions d'un programme.

        • [^] # Re: Hum ...

          Posté par . Évalué à  2 .

          Je reste mitigé quant au mixe des deux approches, impératives et fonctionnelles, parce qu'elles sont disjointes ; ce sont deux modes de pensée différentes au delà des simples constructions. En fonctionnel, il est plus naturel de penser top-down et de ce que l'on veut faire (pas comment faire) et le résultat est la composition de fonctions qui décrit les relations déclaratives (et sémantiques) entre les fonctions d'un programme.

          Oui mais le fonctionnel pose des problèmes dans les interactions systèmes.

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Hum ...

          Posté par . Évalué à  6 .

          Je reste mitigé quant au mixe des deux approches, impératives et fonctionnelles, parce qu'elles sont disjointes ; ce sont deux modes de pensée différentes au delà des simples constructions. En fonctionnel, il est plus naturel de penser top-down et de ce que l'on veut faire (pas comment faire) et le résultat est la composition de fonctions qui décrit les relations déclaratives (et sémantiques) entre les fonctions d'un programme.

          Je n'accroche pas à cette argumentation. De la façon dont tu le dis, on pense à deux espèces extra-terrestres qui essaient de communiquer sans avoir aucun socle cognitif commun. En pratique on peut très bien mélanger programmation fonctionnelle et impérative, par exemple en OCaml ou en Haskell, et c'est un style tout à fait raisonnable (pas plus complexe en tout cas que la programmation orientée objet avec des effets de bord).

          Je n'accroche pas non plus à l'idée que la programmation fonctionnelle est "déclarative". Certains styles de programmation fonctionnelle, dans certains modes d'usages locaux, peuvent être appelés "déclaratifs", par exemple ce qui repose sur "code is data" (construire une structure de donnée et écrire une fonction d'évaluation pour lui donner un sens), mais c'est l'exception plutôt que la norme, ou alors tu as une vision très, très large de ce que signifie "déclaratif" qui ne veut plus dire grand chose.
          Ce qui est vrai c'est que les programmes fonctionnels tendent à décrire leurs résultats comme la composition d'opérations (plutôt qu'un séquençage d'instructions), mais la vision opérationnelle de ce que l'ordinateur va calculer reste très présente (même dans les langages paresseux par défaut où elle continue à importer pour des raisons de performances). En fait dès que tu veux contrôler les performances du programme, il faut programmer ("dire comment") et plus seulement spécifier ("dire quoi").

          Un cas d'école dans la désillusion de la programmation déclarative est Prolog: c'est un langage qui se veut déclaratif mais qui est en fait sans doute le plus opérationnel des langages que je connaisse: si tu n'as pas précisément conscience de comment le langage va évaluer ton code, tu es mort. Il paraît que d'autres langages logiques font mieux, et c'est bien, mais moi le langage de programmation généraliste déclaratif je n'y crois plus vraiment (comme aux idées selon laquelle l'optimisation serait du ressort du compilateur, jamais du programmeur). Déclaratif sur un domaine spécifique où on peut se le permettre (SQL.. les bons jours), ou pour faire de la preuve, d'accord, mais pour la programmation générale bof.

          • [^] # Re: Hum ...

            Posté par . Évalué à  0 .

            En pratique on peut très bien mélanger programmation fonctionnelle et impérative, par exemple en OCaml ou en Haskell, et c'est un style tout à fait raisonnable

            Oui mais c'est dommage.

            Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

            • [^] # Re: Hum ...

              Posté par (page perso) . Évalué à  0 .

              Toi, tu connais pas les gens qui passent leur temps à essayer d'intégrer les effets au lambda-calcul à coups de types ésotériques... (Et qui en profitent pour réaliser l'axiome du choix dépendant avec.)

              • [^] # Re: Hum ...

                Posté par . Évalué à  2 .

                Ton commentaire ne sert un peu à rien, il faut le dire (enfin je ne savais pas quoi répondre à part "euh... bof" donc pourquoi pas), mais il nous permet d'admirer ton nouvel avatar. Tu essaies de faire de l'effet ! Continue...

          • [^] # Re: Hum ...

            Posté par (page perso) . Évalué à  1 .

            Je distingue constructions impératives ou fonctionnelles de l'approche (impérative ou fonctionnelle). Dans le premier cas, il s'agit d'apport du langage, et dans le second de la manière de penser et d'écrire des programmes. Et donc, c'est sous cette lumière que je reste sceptique quant à proposer un mixte des deux approches parce que par trop différentes (ce qui ne signifie pas que ce n'est pas possible).

            Aussi, lorsque tu écris que l'on peut mélanger la programmation fonctionnelle et impérative avec des langages fonctionnels, je comprend utiliser des constructions impératives pour exprimer certaines choses (qui ne serait peut être pas possible ou compliquer de faire autrement). Et là dessus oui je suis d'accord. Ainsi, dans Haskell (je ne connais pas Caml pour m'exprimer à son sujet), les constructions dîtes impératives sont utilisées avant tout pour exprimer des effets de bord (via les monades).

            Quant à mon expression de "déclaratif", il signifie ni plus ni moins que la manière dont sont écrites les fonctions : en déclarant ce qu'elles font par le biais d'autres fonctions (à opposer à stipuler comment elles doivent le faire).

            • [^] # Re: Hum ...

              Posté par . Évalué à  2 .

              Aussi, lorsque tu écris que l'on peut mélanger la programmation fonctionnelle et impérative avec des langages fonctionnels, je comprend utiliser des constructions impératives pour exprimer certaines choses [...]. Et là dessus oui je suis d'accord.

              Donc je ne comprends pas trop sur quoi on n'est pas d'accord. Pour moi avoir une "approche" fonctionnelle c'est d'utiliser surtout, globalement, des constructions fonctionnelles, et avoir une "approche" impérative c'est d'utiliser surtout, globalement, des constructions impératives (ou, dans certains cas, trouver des façons astucieuses de faire au premier ordre mais sans trop se fatiguer des choses qu'on ferait naturellement avec des fonctions d'ordre supérieur; par exemple un bon programmeur C peut aller très très loin avec juste des tableaux et des boucles).

              Si tu as beaucoup d'effets de bord observables à moyenne/grande échelle dans ton application, tu vas devoir (pour faire ce que tu veux) utiliser surtout des constructions impératives. Si les effets de bord ne sont qu'aux frontières d'interaction, ou alors utilisées localement et pas observables de l'extérieur, on utilise surtout des constructions fonctionnelles. Il me semble donc que la "façon de penser" est fortement correllée avec les constructions utilisées. Sur un choix de design donné (par exemple passage d'état explicite ou par effet de bord), on fait un choix selon son habitude, celles des autres développeurs, et le compromis demandé entre rigide et implicite d'un côté (effets de bords, style monadique compris) et flexible et explicite de l'autre (style fonctionnel).

              Bref, moi je peux lire du code et dire localement quel style il utilise : c'est concret, c'est (relativement) objectif. Par contre les grands discours sur "l'approche", la "façon de penser", "l'esprit" des programmes ou du programmeur, hum, bof.

              Quant à mon expression de "déclaratif", il signifie ni plus ni moins que la manière dont sont écrites les fonctions : en déclarant ce qu'elles font par le biais d'autres fonctions (à opposer à stipuler comment elles doivent le faire).

              À ce compte-là, C est un langage "déclaratif" parce que quand tu écris une fonction tu "déclares" ce qu'elle doit faire.

              • [^] # Re: Hum ...

                Posté par (page perso) . Évalué à  3 .

                Non, une approche ou paradigme est avant tout une façon de penser les choses, les problèmes et les solutions ; les constructions en dérivent donc comme support du paradigme. Et, à l'usage, l'utilisation des constructions du langage vont conditionner aussi la façon de penser. C'est la raison pour laquelle des développeurs qui ont une forte expérience avec les langages dît impératifs vont avoir plus de mal avec les langages fonctionnels.

                Ramener l'approche à une simple définition et utilisation de constructions est une erreur qui a malheureusement fait bcp de mal à la POO. Ainsi, par exemple, j'ai vu un grand nombre de développeurs acquérir une connaissance erronée de la POO au travers de langages comme C++.

                Pour le déclaratif, un exemple vaut tous les discours (enfin c'est ce que l'on dit) :

                applesInCart cart = [ a | a <- filter (== Apples) cart ]
                
                

                Autrement dit : la fonction applesInCart est déclaré comme étant l'ensemble des pommes dans le caddie.

                En C :

                Fruit* applesInCart(int size, Fruit* cart)
                {
                   Fruit* apples = malloc(...);
                   int i, j = 0,;
                   for(i = 0; i < size; i++)
                      if (isApples(cart[i]))
                        apples[j++] = cart[i];
                   return apples;
                }
                
                

                là tu dis ce qu'il faut faire : parcourir les éléments du caddie un par un, tester que l’élément est bien une pomme et si oui l'ajouter dans le tableau à retourner.

    • [^] # Re: Hum ...

      Posté par . Évalué à  0 .

      Je ne connais pas les types F-bounded donc pas de commentaire, mais je trouve ton attitude de puriste fonctionel assez amusante: dans beaucoup d'exemple, la version impérative est beaucoup plus lisible que la version fonctionnelle, donc je pense qu'un langage purement fonctionnel n'a aucune chance de devenir populaire..

      • [^] # Re: Hum ...

        Posté par . Évalué à  7 .

        "lisible" est un qualificatif bien peu précis. On a souvent tendance à confondre ce qui est "facile", car proche de ce qu'on connaît déjà, et ce qui est véritablement "simple" conceptuellement. Je ne sais pas à quels exemples tu penses mais je doute que, pour un lecteur n'ayant aucune connaissance préalable, ni en impératif ni en fonctionnel, il y ait une différence si importante.
        Après la popularité, c'est autre chose, et c'est compliqué.

        Je préférerais une discussion avec plus de faits, d'exemples concrets, d'arguments objectifs, que des arguments du style "c'est moins populaire", "c'est plus lisible", etc.

        • [^] # Re: Hum ...

          Posté par . Évalué à  3 .

          Et bien, l'exemple canonique de factorielle: je trouve l'implémentation impérative beaucoup plus lisible que son implémentation fonctionnelle a performance équivalente, qui utilise la récursion terminale..

          • [^] # Re: Hum ...

            Posté par . Évalué à  3 . Dernière modification : le 29/01/12 à 17:16

            La récursion terminale n'est pas le seul intérêt des langages fonctionnels mais les langages fonctionnels permettent d'écrire des algorithmes récursif de manière élégante et efficace.

            La version récursive de la factorielle existe aussi bien en C et dans d'autres langages impératifs. La vraie question c'est « en quoi le paradigme que j'utilise va bien avec ce que je code. » . Dans de nombreux cas l'impératif est inélégant et inadapté. On ne parle pas récursif/itératif mais de fonctionnel/impératif, ce n'est pas la même chose.

            D'une manière générale je pense que les langages fonctionnels quant ils ne sont pas appréciés sont en général mal connus.

            Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

            • [^] # Re: Hum ...

              Posté par . Évalué à  4 .

              La récursion terminale n'est pas le seul intérêt des langages fonctionnels

              Ça tombe bien parce que pour moi, la récursion terminale n'est souvent pas un intérêt.

              La version récursive de la factorielle existe aussi bien en C

              Et bien oui, avec le C tu as le choix, tu peux utiliser les deux styles(dans une certaine mesure), je répondais au post de Miguel Moquillon(*) qui préfère les langages fonctionnel pur et je montrais donc un exemple où pour moi l'algorithme fonctionnel est moins lisible que l'algorithme impératif (à performance équivalente).
              Je préfère donc les langages ou tu peux avoir les deux, tu me réponds mais je ne suis pas sûr que tu sois en désaccord. Tu as lu en diagonale la discussion?

              D'une manière générale je pense que les langages fonctionnels quant ils ne sont pas appréciés sont en général mal connus.

              Ben voyons! Très élégant comme remarque..

              *: "je suis plus mitigé du mixe forme fonctionnelle et forme impérative que l'on trouve dans certains langages."

            • [^] # Re: Hum ...

              Posté par . Évalué à  2 .

              La récursion terminale n'est pas le seul intérêt des langages fonctionnels mais les langages fonctionnels permettent d'écrire des algorithmes récursif de manière élégante et efficace.

              Les langages non-fonctionnels aussi...

              Dans de nombreux cas l'impératif est inélégant et inadapté.

              Il faudrait préciser ici ce que tu désignes par "impératif". Tous les langages modernes ont une notion de fonction, et beaucoup permettent de les manipuler comme des valeurs à part entière.

          • [^] # Re: Hum ...

            Posté par . Évalué à  2 . Dernière modification : le 29/01/12 à 19:20

            fac n = fac' 1 n
            fac' accu 0 = accu
            fac' accu n = fac' (accu * n) (n - 1)
            
            

            Je trouve ça lisible, personnellement. Tu as un code impératif équivalent "beaucoup plus lisible" sous la main ?

            Par ailleurs, je remarque que let fac n = product [1..n] est aussi un code fonctionnel pur, et plus lisible que les deux versions que tu proposes.

            • [^] # Re: Hum ...

              Posté par . Évalué à  5 .

              Bah oui la version classique:
              fn fact(n)
              int accu = 1;
              for (int i = 2; i <= n; i++) {
              accu = accu * i;
              }
              return accu;

              Pas besoin de la fonction intermédiaire..

              Et puis j'aurais du parler de Fibonacci: http://www.cs.northwestern.edu/academics/courses/110/html/fib_rec.html

              Par ailleurs, je remarque que let fac n = product [1..n] est aussi un code fonctionnel pur, et plus lisible que les deux versions que tu proposes.

              Mais pas forcément aussi performant: il faut un compilateur assez compliqué je pense pour optimiser ça..

              • [^] # Re: Hum ...

                Posté par . Évalué à  4 .

                Pas besoin de la fonction intermédiaire..

                Tant mieux, mais toi tu as besoin d'une variable mutable intermédiaire (donc d'un concept supplémentaire, l'assignation) et d'une boucle for (encore un concept supplémentaire). Pas clair que ta version soit "plus simple", et elle n'est certainement pas "beaucoup plus lisible" (même quand on sait qu'il faut 4 espaces devant chaque ligne pour représenter du code en Markdown).

                Et puis j'aurais dû parler de Fibonacci

                Pas de soucis:

                fib n = fib' 0 1 n
                fib' a b 0 = a
                fib' a b n = fib' b (a + b) (n - 1)
                
                

                Mais pas forcément aussi performant: il faut un compilateur assez compliqué je pense pour optimiser ça..

                Oui et non. La complexité en temps est la même dans tous les cas (linéaire); dans un langage paresseux (si ta liste est construite à la demande), la complexité mémoire est la même. Après la question est de savoir si le compilateur sait optimiser la construction de liste; en pratique GHC sait le faire (donc produira du code équivalent si on le lui demande gentiment), mais je n'aime pas trop abuser de ces optimisations et je me contenterai de dire que c'est la version la plus "lisible", et donc intéressante à donner en premier si les performances ne sont pas critiques, du moment qu'elle a la bonne complexité.

                • [^] # Re: Hum ...

                  Posté par . Évalué à  3 .

                  1) Note que toi tu as besoin d'un autre "concept": la récursion terminale, d'ailleurs personnellement je pense qu'un appel récursif terminal devrait utiliser un mot-clef/annotation différente, comme ça le compilateur peut te prévenir quand tu as fait une erreur et que ta récursion n'est pas terminale en fait.

                  2) Pas de souci pour fibonacci sauf que tu as du reconstruire la fonction exactement comme en code impératif.

                  3) Sinon pour l'évaluation paresseuse, j'ai lu quelques fois des remarques d'utilisateurs qui trouvaient que ça donnait des performances difficiles a maîtriser..
                  Un concept intéressant mais utiliser l'évaluation paresseuse par défaut, ça a un sens pour un langage de recherche, mais pas autrement.

                  • [^] # Re: Hum ...

                    Posté par . Évalué à  3 .

                    Note que toi tu as besoin d'un autre "concept": la récursion terminale

                    Je n'ai pas besoin de ce "concept" pour me convaincre que ces fonctions font ce que je veux. Par ailleurs le fait qu'un appel est terminal ou non peut être vérifié par un critère syntaxique simple. Dans tous les cas son usage ne rend certainement pas le code "moins lisible".

                    Ta focalisation sur la récursion terminale est à mon avis signe du fait que tu te compliques la vie inutilement. Si tu réfléchis à ce que fais un programme fonctionnel en ayant en tête la façon dont c'est compilé vers du langage machine, l'explication de ce qu'est la récursion terminale est un peu technique et cela paraît être un cas particulier spécifique. Par contre si tu raisonnes simplement en terme de "évaluer c'est réduire le programme étapes par étapes vers le résultat", les bonnes propriétés de la récursion terminale viennent tout naturellement (au lieu de raisonner sur la taille de la pile, on raisonne sur la taille du programme réduit), et on n'a pas besoin d'une explication spécifique pour cela. C'est en fait une façon tout à fait valide et simple de penser aux programmes, indépendamment des aspects bas-niveau de la compilation.

                    Pas de souci pour fibonacci sauf que tu as du reconstruire la fonction exactement comme en code impératif.

                    Bien sûr, c'est normal, il n'y a rien de magique à écrire du code fonctionnel. Je n'ai jamais dit, moi, qu'une version serait "beaucoup plus lisible" qu'une autre. Mais c'est vrai que les miennes sont beaucoup plus courtes (grâce au choix opportuniste d'un langage à la syntaxe dépouillée), et aussi plus simples grâce à l'abandon du concept de variable modifiable; je n'ai pas besoin de différencier le calcul de la valeur et son retour.

                    Sinon pour l'évaluation paresseuse, j'ai lu quelques fois des remarques d'utilisateurs qui trouvaient que ça donnait des performances difficiles a maîtriser..

                    Je suis d'accord et je ne suis pas pour utiliser la paresse par défaut à outrance. J'ai écrit mes exemples en Haskell parce que la légèreté syntaxique permet d'illustrer mon point très efficacement, mais dans la vraie vie j'utilise plutôt OCaml, qui est un langage strict par défaut.

                    Par ailleurs il y a des interactions intéressantes entre la paresse et la récursivité : en Haskell on ne recherche pas la récursivité terminale, et elle est même néfaste aux performances en général. Je te laisse creuser le sujet si ça t'intéresse, mais dans tous les cas les fonctions écrites ci-dessus sont strictes de toute façon, donc elles ne seront pas évaluées de façon paresseuse (le compilateur s'en rend bien compte).

                    Pour le fun, une version de fibonacci qui a la bonne complexité et utilise à fond l'évaluation paresseuse (c'est fun et ça fait un bon exercice de gymnastique intellectuelle, mais je ne recommande pas d'écrire comme ça):

                    fib n = fibs !! n
                    fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
                    
                    

                    (zipWith (+) envoie la liste des sommes terme-à-terme de deux listes de même taille, et tail renvoie la liste privée de son premier élément. (!!) est l'accès au n-ième élément d'une liste).

                • [^] # Re: Hum ...

                  Posté par (page perso) . Évalué à  7 .

                  au risque de passer pour un programmeur impératif bas du front, je dois bien avouer que pour moi, tes fonctions fibonacci et factorielle sont parfaitement illisibles.

                  • [^] # Re: Hum ...

                    Posté par . Évalué à  7 .

                    De toute évidence, c'est parce que tu as l'habitude de la programmation impérative, et pas l'habitude des autres styles. Cf. ce que je disais sur la différence entre lisible parce que "proche de ce qu'on connaît" ("facile"), et "conceptuellement simple" ("simple").

                    Si tu veux découvrir une nouvelle façon de programmer (ce qui est toujours une bonne façon de s'améliorer), je t'invite à faire l'effort de comprendre ces exemples (il suffit d'exécuter fib 3 ou fac 3 à la main, sur un papier brouillon, en dépliant les appels pour les remplacer par leur définition), tu en seras éclairé.

                    Si le fait de découvrir quelque chose de nouveau et d'intéressant ne te tente pas, c'est peut-être un signe de bassesse du front effectivement (malheureusement c'est le cas de beaucoup de programmeurs dans l'industrie, mais statistiquemenet pas des gens sur LinuxFR, d'où le "ou" qui va suivre) ou simplement que tu as d'autres priorités que la programmation et c'est tant mieux pour toi.

                    • [^] # Re: Hum ...

                      Posté par . Évalué à  2 .

                      Est-il possible de faire quelque chose comme ça :

                      fac n = fact 1 1 n
                      fact acc i n = fact (acc * i) (i + 1) n
                      fact acc n n = acc
                      
                      

                      ? Si oui, ce serait directement en correspondance avec la version en boucle for. (D'un lointain souvenir, il me semble que les boucles for/while sont un cas particulier des récursions (et plus précisément des récursions terminales))

                      • [^] # Re: Hum ...

                        Posté par . Évalué à  3 . Dernière modification : le 30/01/12 à 12:47

                        Les patterns sont linéaires donc fac acc i n n = ... ne va pas marcher, il faut faire un test d'égalité à la main. Donc ouais, on peut écrire ça comme ça, mais c'est plus compliqué donc sans grand intérêt. À choisir je préfère écrire une boucle for qui descend, si tu veux une correspondance plus forte.

                        int fac(int n)
                        {
                          int acc = 1;
                          for (int i = n; i > 0; --i)
                            acc *= i;
                          return acc;
                        }
                        
                        
              • [^] # Re: Hum ...

                Posté par (page perso) . Évalué à  7 .

                Mais pas forcément aussi performant: il faut un compilateur assez compliqué je pense pour optimiser ça..

                Euh, je suis à peu près sur que 'product' n'est rien d'autre qu'un 'fold-left,' et donc une récursion terminale.
                Soit du code extrêmement clair et optimal.

  • # Il n'existe pas.

    Posté par . Évalué à  3 .

    Aucun compilo n'étant parfait. C'est pas possible.

    Si on veut faire du code patator, on va prendre un langages bas niveau, sans automatismes susceptibles de plomber les perfs, sans abstraction qui concrètement se traduisent par des pléthores de pointeurs à dé-référencer sans cesse par exemple.

    Si on doit produire beaucoup de code, à plein, qui puisse être maintenu des années, sans bug (même avec des programmeurs moyens), pour gérer des objets très complexes... on peut difficilement se passer d'une haute abstraction couteuse en performances.

    Si on suppose disposer d'un compilo parfait, alors se langage pourrait ressembler à une description des données en entrée, et celle des données en sortie (et une description de la machine qui fera tourner le code peut être aussi), un peu à la Coq.

    Please do not feed the trolls

    • [^] # Re: Il n'existe pas.

      Posté par . Évalué à  0 .

      un peu à la Coq.

      Je préfère les œufs au plat.

      Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

    • [^] # Re: Il n'existe pas.

      Posté par . Évalué à  3 .

      ce langage pourrait ressembler à une description des données en entrée, et celle des données en sortie (et une description de la machine qui fera tourner le code peut être aussi),

      Le tout en langage naturel bien sûr.

      • [^] # Re: Il n'existe pas.

        Posté par . Évalué à  1 .

        Je n'ai jamais bien compris l'utilité du langage naturel pour des langages de programmation. L'utilisation de symboles me semblant au contraire plus naturelle.

        Les mathématiques utilisent un langage symbolique adapté, je ne vois pas pourquoi le langage naturel serait adapté à la programmation. Le pire étant les langages qui mélangent allègrement les deux, entretenant une confusion des genres qui est un cauchemar pour le programmeur (java ou C++ par exemple).

        Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

        • [^] # Re: Il n'existe pas.

          Posté par . Évalué à  4 .

          Il me semble que c'était de l'ironie.

          • [^] # Re: Il n'existe pas.

            Posté par . Évalué à  2 . Dernière modification : le 28/01/12 à 20:38

            Mais ma réponse était sérieuse :) cauchemar j'exagère à peine, mais plus on avance dans la compréhension de la programmation, et plus c'est intéressant d'avoir une concision dans l'expression.

            Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

      • [^] # Re: Il n'existe pas.

        Posté par (page perso) . Évalué à  6 .

        (et une description de la machine qui fera tourner le code peut être aussi),

        Et cette dernière sera construite à la volée grâce à un subtile mise en relation d'une imprimante 3D et de FPGA.

        ---------> [ ]

  • # J'aimerais

    Posté par (page perso) . Évalué à  2 .

    Un C++ nettoyé. J'ai regardé la dernière mouture, elle apporte beaucoup de choses géniales, mais je crains que trop de fonctionnalités risque de:
    - le rendre trop complexe pour les nouveaux arrivants
    - que les anciens qui ne se mettent pas à la page continuent de coder à l'ancienne (multiplications de styles). Il y a 10 ans, je connaissais bien le Stoustrup (et autres bouquins avancés) et j'avais l'impression que mes collègues faisaient du «C avec des classes». Pénible. Ça va être à nouveau le cas
    Donc j'ai besoin d'un langage:
    - qui soit rapide (pour des lib de compression par ex (1))
    - qu'on puisse utiliser pour faire de la programmation système (Java ne peut pas utiliser mmap de manière native (2), donc perte de perfs)
    - compatible avec les lib écrites en C (pour pas réinventer libxml, sqlite et autres)
    - dont la syntaxe soit nettoyée pour bien fonctionner avec les IDE (completion et compagnie)

    J'ai besoin d'un autre plus haut niveau. Java, mais sans Oracle (c'est rédhibitoire, j'ai l'impression de vendre mon âme à Satan à chaque fois que je l'utilise).

    Pour les scripts, Python me va, sauf pour:
    - le typage dynamique qui me fait peur quand le projet grossi
    - le «global interpreter lock», c'est naze (et le résoudre avec plusieurs processus c'est naze aussi)

    (1) vous avez vu la différence de perf entre un qzip natif et Java? C'est aux moins du x2
    (2) pourquoi C est plus rapide que java

    • [^] # Re: J'aimerais

      Posté par . Évalué à  -1 .

      Pour le typage dynamique je ne suis pas fan non plus mais il y a moyen de faire les choses proprement en étant rigoureux dans la documentation. Parce qu’au final se reposer sur un système de typage statique n’est pas viable non plus sur un gros projet, car bien souvent ce n’est pas d’un entier ou d’un flottant qu’on a besoin, mais d’un entier entre 1 et 3, d’un flottant positif, d’un vecteur normalisé, etc. Du coup l’un ou l’autre des typages n’apporte pas les garanties nécessaires. Du coup je préfère largement ne pas avoir à taper une liste de déclarations longue comme le bras et passer mon temps plutôt à écrire en doc ce que je veux et ce que je ne veux pas.

      Pour le lock… oui c’est naze, et le multiprocess me fait planter une librairie tiers, c’est assez lourd à gérer…

      • [^] # Re: J'aimerais

        Posté par . Évalué à  3 .

        Parce qu’au final se reposer sur un système de typage statique n’est pas viable non plus sur un gros projet, car bien souvent ce n’est pas d’un entier ou d’un flottant qu’on a besoin, mais d’un entier entre 1 et 3, d’un flottant positif, d’un vecteur normalisé, etc.

        Un système de typage statique réaliste ne capturera pas tous les invariants de ton programme, mais ce n'est pas une raison pour les rejeter en bloc, s'il peut déjà capturer les invariants "faciles" et te laisser raisonner sans aide, ou vérifier dynamiquement, les autres, c'est déjà ça.

        Du coup je préfère largement ne pas avoir à taper une liste de déclarations longue comme le bras

        Manque d'inférence des types ?

        La doc c'est bien joli mais comme ce n'est pas pris en compte par le langage, ça n'aide pas beaucoup pour repérer où est-ce que quelque chose a foiré. En pratique tu veux soit ajouter des outils d'analyse statique qui lisent cette doc et raisonnes statique sur ton programme (cf. Dialyzer pour Erlang), ce qui revient à avoir un système de typage, soit tu veux ajouter des tests/assertions dynamiques pour vérifier que ce qui se passe est cohérent avec ce que tu as documenté; et là sans aide du système tu te retrouves à nouveau à écrire des trucs longs comme le bras, la différence étant qu'ils ont un coût élevé à l'exécution.

        Il me semble que la situation intermédiaire où le langage vérifie statiquement ce qu'il peut, et tu testes dynamiquement le reste (avec un bonus si tu peux spécifier ces deux aspects au même endroit) est préférable à ce que tu décris.

        • [^] # Re: J'aimerais

          Posté par (page perso) . Évalué à  1 .

          Un système de typage statique réaliste ne capturera pas tous les invariants de ton programme, mais ce n'est pas une raison pour les rejeter en bloc, s'il peut déjà capturer les invariants "faciles" et te laisser raisonner sans aide, ou vérifier dynamiquement, les autres, c'est déjà ça.

          Sauf que les invariants "faciles", ceux qui sont détectés à notre place, sont rarement ceux qui posent problème. Du reste c'est plus pour aider le compilateur que le développeur, sinon on obligerait à nommer les arguments en appel de fonction par exemple c'est une erreur beaucoup plus commune et qui passe tranquillement la compilation.

          Par ex ma_fonction(int a, int b), si on inverse a et b le compilateur n'y verra rien. Si a est censé être plus petit que b il n'y verra rien non plus. En python si on applique la règle d'être explicite on écrira ma_fonction(plus_petit, plus_grand) et on appellera toujours en nommant les paramètres ma_fonction(plus_petit=.., plus_grand=...), c'est beaucoup plus sûr et surtout ça s'adresse au développeur, pas au compilateur. Le compilateur lui il se débrouille très bien tout seul, il n'y a qu'à voir les prouesses de pypy.

          • [^] # Re: J'aimerais

            Posté par . Évalué à  3 .

            Sauf que les invariants "faciles", ceux qui sont détectés à notre place, sont rarement ceux qui posent problème.

            J'entends souvent cet argument mais il ne coïncide pas avec mon expérience personnelle de développement, soit dans des langages statiques soit dans des langages dynamiques. Dans un langage statique, le typeur repère très souvent des erreurs dans mon code, et dans un langage dynamique je passe parfois du temps à comprendre et corriger qui auraient été repérées par un système de types -- dernier exemple en date, manipuler dans RoR une donnée que je pensais correspondre à un modèle, mais dont certains champs n'avaient pas été chargés par une couche intermédiaire, et qui n'avait donc, moralement, pas le type attendu.

            Il y a de temps en temps des expériences où on lance des outils d'analyse statique (~typage) sur des programmes écrits dans un langage dynamique (ou au système de typage faiblard, genre C), et on trouve pas mal de bugs. Dans le cas de Dialyzer que j'ai cité plus haut (pour Erlang), il y a par exemple cet article où les développeurs de l'outil l'ont lancé sur une codebase et trouvé plein d'erreurs subtiles, et de cas où les invariants mis dans les commentaires étaient devenu incorrects/périmés avec l'évolution du logiciel :
            Gradual Typing of Erlang Programs: A Wrangler Experience (pdf), Konstantinos Sagonas et Daniel Luna, 2008.

            Après je suis bien conscient que ça dépend des développeurs (par exemple Daniel J. Bernstein a des méthodes secrètes de ninja pour écrire du code juste à la première publication), et des domaines applicatifs (la remarque de BB ci-dessous sur le fait que le code numérique se prête moins au typage est très juste). Est-ce que tu as un lien vers un répertoire versionné d'un de tes logiciels écrits dans un langage non statiquement typé, qui permettrait de vérifier ton idée sur un projet réel. L'idée est de regarder les bugfixes et de voir dans quel cas un système de types plus puissant aurait repéré l'erreur; bien sûr ça ne rend pas compte des erreurs pendant la phase de développement entre deux commits, qui jouent pourtant un rôle important dans le temps total de programmation -- je pense qu'une erreur détectée tout de suite par le typeur est en général plus facile, ou en tout cas plus rapide, à corriger qu'une erreur détectée par un test qui échoue, ne serait-ce que parce qu'il indique précisément la position du problème, plus que même des tests unitaires.

            • [^] # Re: J'aimerais

              Posté par (page perso) . Évalué à  3 .

              Je suis tout à fait d'accord, tout ce que l'on peut vérifier automatiquement est toujours bénéfique, si j'ai bien compris dialyzer est un peu l'équivalent de pylint ?
              Je n'apprécie pas quand c'est au détriment de la lisibilité du code ou que cela m'empêche de profiter du côté dynamique du langage. Pour revenir au langage idéal, qu'il devine tout seul les erreurs de type quand il le peu et ce sera très bien mais qu'il ne m'oblige pas à lui mâcher le travail. Je ne me plaint pas que python sache vérifier la syntaxe avant l'exécution (j'utilise vimflakes par ex).

              Je n'ai pas d'historique de code qui me vient comme ça à montrer (je ne fais que du dev spécifique), mais j'ai regardé, honnêtement j'ai quelques cas d'erreurs de types qui reviennent, string/unicode et float/Decimal. Mais même dans ces cas bien souvent le compilateur n'aurait rien vu car les données arrivent d'un sgbd...

              Pour ce qui est de projets réels, professionnellement je suis passé par C et Java avant Python, et au début je n'y croyait pas non plus, mais maintenant, sur plusieurs années, sur parfois des programmes exactement identiques (réécrits), le temps de maintenance est drastiquement réduit. Pour mon usage c'est le langage idéal.

              Par contre si ce n'était pas pour le boulot et donc des contraintes de rendement, je préfèrerai le C pour son côté plus proche du système.

            • [^] # Re: J'aimerais

              Posté par (page perso) . Évalué à  3 .

              De plus en plus de langage dynamique permettent de déclarer le typage des variables. C'est facultatif mais permet à l'interpréteur de faire quelques optimisations. Perl prends clairement cette voie.

          • [^] # Re: J'aimerais

            Posté par . Évalué à  2 .

            L'appel de fonction par nom de parametre est une bonne idée, mais on peut l'utiliser avec un typage statique ou dynamique.

          • [^] # Re: J'aimerais

            Posté par . Évalué à  2 .

            Ce genre de propriété se vérifie aussi par des contrats / assertions, voire des trucs comme la méthode B (http://fr.wikipedia.org/wiki/M%C3%A9thode_B)

          • [^] # Re: J'aimerais

            Posté par . Évalué à  2 .

            Objc propose la solution ultime a ce probleme, integrer le nom des params a la methode elle meme.
            [UIView animate: block duration: duree options: option withCompletion: block]
            [UITableViewDelegate tableView: table cellForRowAtIndexPath: indexPath]

            ce qui rajoute aussi l'avantage que ton code se lit quasiment comme une phrase, et ca, ca a pas de prix.

            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

            • [^] # Re: J'aimerais

              Posté par (page perso) . Évalué à  3 .

              Ça coûte quand même une pomme.

            • [^] # Re: J'aimerais

              Posté par . Évalué à  2 .

              "duration:duree options:option", si ça se lit comme une de tes phrases habituelles c'est que tu écris drôlement mal.

              • [^] # Re: J'aimerais

                Posté par . Évalué à  1 .

                Ok, je la refais alors, en version complete:

                AnimationBlock animationBlock = ^{
                    view.alpha = 0;
                }
                
                CompletionBlock completionBlock = ^(BOOL finished){
                    if(!finished)
                    {
                        return;
                    }
                    view.alpha = 1;
                }
                [UIView animateWithDuration: SHORT_ANIMATION
                                      delay: 1.0f 
                                    options: UIViewAnimationOptionAllowUserInteraction 
                                  animation: animationBlock
                                 completion: completionBlock];
                
                

                AnimationBlock et CompletionBlock sont des typedefs de base, SHORT_ANIMATION un #define.
                C'est en tout cas vachement plus lisible que:

                View.animate(SHORT_ANIMATION, 1.0f, UIViewAnimationOptionAllowUserInteraction, animationBlock, completionBlock);
                
                

                Et surtout, quand tu l'écris tu demandes pas si le premier parametre est le délai ou la durée.

                If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

        • [^] # Re: J'aimerais

          Posté par . Évalué à  3 .

          Je suis assez d’accord avec toi, dans la théorie ; J’étais assez méfiant sur cette histoire de typage lorsque j’ai commencé à utiliser sérieusement Python. Toutefois depuis maintenant quelques années, je me suis rendu compte qu’en pratique j’ai rarement des problèmes liés au typage. Notons aussi que je fais du numérique, et que lorsque c’est nécessaire je peux quand même spécifier le type d’un tableau, et c’est ce qui m’importe (dtype=int32,float32,float64 et c’est à peu près tout). Du code numérique manipule assez peu de type en réalité, par contre il peut donner beaucoup de contrainte sur la taille, l’intervalle, la précision et l’étendue ainsi que sur les propriétés entre les nombres, toutes choses ne pouvant pas être vérifiés par un compilateur, et accessoirement pénible à gérer proprement (NaN&Co). Le type des variables à manipuler devient un « problème » négligeable et le b.a-ba de tout programmeur numérique, parce qu’une formation mathématique t’apprends nécessairement à bien définir ce que sont tes variables, avant même de réfléchir à une implémentation.

          La doc c'est bien joli mais comme ce n'est pas pris en compte par le langage

          C’est une approche typiquement pythonesque que de dire que le programmeur sait ce qu’il fait, et de rester très souple concernant le langage lui même (typage, pas de protection dans les classes, etc.). Qu’on aime ou pas, je ne dirai pas ce que ça donne sur un gros projet en équipe, mais pour du code à soi, j’ai constaté que toutes ces vérifications de type sont peu utiles et les erreurs liées sont tout aussi vite corrigées dans un code Python. J’ai même acquis la conviction que ça encourage la bonne pratique de bien réfléchir à l’avance à ses structures de données.

          Et pour moi, il est hors de question de vérifier, par exemple qu’un vecteur qui arrive à l’entrée d’une fonction est normalisé, c’est au programmeur qui fait appel à la fonction de vérifier ça. Pour des raisons de performances comme tu le dis… plus par habitude qu’autre chose, parce que de toute façon Python est d’une lenteur effroyable…

          Pour les inférences de type, je n’ai jamais utilisé, donc je ne peux pas dire ce que ça donne en pratique, mais pourquoi pas.

          • [^] # Re: J'aimerais

            Posté par (page perso) . Évalué à  4 .

            Python est d’une lenteur effroyable…

            Tu as essayé pypy ?

            Sur un algo de calcul d'itinéraires j'ai un gain d'un facteur 10 !

      • [^] # Re: J'aimerais

        Posté par . Évalué à  4 .

        Un aspect que je n'ai pas vu développé dans les discussions : les systèmes de types ne sont pas nécessairement une corvée pour le développeur. J'y vois au moins deux avantages, pour un système de type suffisamment puissant.

        En tant que développeur, un travail que je trouve parmi les plus agréables est de représenter ou contraindre le domaine du problème que je cherche à résoudre avec des types. Une fois une interface élégante trouvée, il ne me reste souvent qu'à me laisser guider par les types pour le remplissage… Dans les cas les moins évidents, la solution ne peut apparaître limpide qu'en présence d'informations de types.

        En tant qu'utilisateur de codes existants, des informations de types riches servent d'autodocumentation, et pour les mêmes raisons que ci-dessus, un coup d'œil aux types permet de saisir le domaine et parfois même l'approche choisie par le développeur d'origine.

    • [^] # Re: J'aimerais

      Posté par . Évalué à  2 .

      vous avez vu la différence de perf entre un qzip natif et Java? C'est aux moins du x2

      Pourquoi veux-tu réimplémenter une lib de compression alors que, tu le dis toi-même, il vaut mieux réutiliser l'existant ?

      • [^] # Re: J'aimerais

        Posté par (page perso) . Évalué à  3 .

        Je veux dire que personne ne va écrire une lib ou un codec dans ce langage si c'est pour avoir au final des perfs vraiment limitées. J'ai parlé de gzip parce que justement il existe des implémentations dans les deux langages et ça permet de comparer.

    • [^] # Re: J'aimerais

      Posté par (page perso) . Évalué à  3 .

      Beaucoup de langages correspondent à ce que tu cherches: D, ooc, nimrod, Object Pascal, Ada...

      Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

      • [^] # Re: J'aimerais

        Posté par . Évalué à  2 .

        Le problème c'est que beaucoup de ces alternatives sont très peu mature.
        Par exemple, il me semble qu'il n'y a pas de binding utilisable pour Qt en D, ça calme.
        Ada, dommage que sa syntaxe rebute tout le monde.. Autrement ça serait une bonne alternative..

        • [^] # Re: J'aimerais

          Posté par (page perso) . Évalué à  3 .

          Personnellement, je préfère le begin-end de bash, pascal, fortran, ada aux accolades {} de la tendance C. Je ne pense pas que le frein soit là.

          Ada est verbeux. Je pense que les langages de demain ne doivent plus avoir de header. C'est une erreur, de la duplication de code qui ne sers à rien. Il y a plus de 20 ans, Fortran 90 a montré la voie (je ne sais pas s'il y en a un autre avant) en générant automatiquement les fichiers headers à partir du corps du fichier (les fichiers .mod en fortran 90).

          Un autre soucis est que la mappage avec les objets ELF n'est pas normalisé. Je ne comprends pas pourquoi les langages refusent de normaliser cela parce que cela permet d'avoir des compilateurs compatible (on a le même problème avec le Fortran 90).

          Le langage Ada a été fait pour les militaires. Psychologiquement, cela a tué le langage et continue de le tuer pour bon nombre de gens...

          ...

          • [^] # Re: J'aimerais

            Posté par (page perso) . Évalué à  4 .

            Ada est verbeux. Je pense que les langages de demain ne doivent plus avoir de header. C'est une erreur, de la duplication de code qui ne sers à rien.

            Les headers, c'est LE truc qui est chiant avec le C++. Le refactoring prend beaucoup plus de temps car on doit à chaque fois mettre à jour header et implémentation. J'ai assez peu d'autres doléances vis-à-vis du C++, surtout avec la nouvelle norme et l'arrivée de auto et des lambda.

            • [^] # Re: J'aimerais

              Posté par (page perso) . Évalué à  1 .

              On pourrait imaginer des IDE qui mettent les headers à jour en fonction des modifications du .cpp (et inversément). Kdevelop le fait en partie (modification de la signature quand elle est changée mais ça marche une fois sur deux), je ne vois pas ce qui limite de faire plus (à part le développement évidemment).

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: J'aimerais

                Posté par . Évalué à  2 .

                On pourrait imaginer des IDE qui mettent les headers à jour en fonction des modifications du .cpp

                Ca fait juste 15 ans que ca existe (et il y a meme certains outils avec un support pour Emacs).

          • [^] # Re: J'aimerais

            Posté par (page perso) . Évalué à  3 .

            Ada est verbeux. Je pense que les langages de demain ne doivent plus avoir de header. C'est une erreur, de la duplication de code qui ne sers à rien.

            Personnellement, je trouve que les headers ne servent pas à rien et je préfère de loin lire juste un fichier ads (fichier de spec ou header) que de lire le fichier adb (corps ou body). En plus, il ne faut pas oublier qu'en Ada contrairement au C/C++, le fichier de spec se compile au même titre que le corps ce qui permet de vérifier avant tout chose que tout code client d'un autre respecte bien le contrat prévu. Cela permet aussi la vérification de la compatibilité avant que le corps ne soit réellement codé.
            En C/C++, le header n'est qu'un fichier comme un autre géré par le macroprocesseur (beurk :D) avec tous les désagréments que cela implique (inclusion d'un .cpp/.c dans un autre header, c'est moche mais je l'ai vu :( ).
            En Java, même si j'aime bien ce langage, tout est dans tout et vice-versa, et ça, ça me gêne pas mal quand même... Surtout quand dans ton équipe tu as des spécialistes de la classe de 3000 lignes. Bon, c'est relativisé par l'emploi d'un IDE moderne mais quand même.

            • [^] # Re: J'aimerais

              Posté par (page perso) . Évalué à  3 .

              En Fortran 90, tes modules sont coupés en deux parties, une première ou tu fixes les dépendances (use...) et tu déclare ce qui est public et privé puis une seconde ou tu fais l'implémentation.

              Ensuite, via une moulinette, il est assez facile d'extraire du fichier de la doc qui te donne les en têtes des fonctions et mouline cela sous forme de man. Je faisais à l'époque "man Mon_Module" et hop, toute la doc du module. Bref, un environnement très lié au shell et pratique comme avec les packages Perl ;-)

              Donc pour moi, dupliquer à la main les headers est une mauvaise chose. La doc intégré doit faire partie du langage (cf le POD du Perl) et les outils doivent suivre. De ce coté là, Ada a un train de retard mais il a le droit d'évoluer dans le futur ;-)

              • [^] # Re: J'aimerais

                Posté par (page perso) . Évalué à  2 .

                En Ada, t'as pas besoin de dupliquer quoi que ce soit, le ads sert de doc.

                Et comme dit précédemment, le header ne sert pas juste de doc ou de pré-déclaration, mais il sert aussi de contrat vis à vis des utilisateurs du package.

              • [^] # Re: J'aimerais

                Posté par . Évalué à  2 .

                Un avantage d'avoir une séparation entre implémentation et interface est que ça permet de donner plusieurs interfaces à une même implémentation. Par exemple je peux avoir un fichier M qui est compilé avec une interface S1, utilisée par quelques modules proches qui sont dans le même domaine applicatif et qui connaissent les entrailles de M, et une interface S2 plus restrictive pour l'usage "public" par le reste des composants du projet, dont tu ne veux pas qu'ils dépendent de détails de M qui pourraient changer dans le futur.

                C'est un peu l'équivalent de ce qu'on fait avec les "friend methods" dans certains langages objets, sauf que là tu peux avoir la granularité que tu veux (pas d'interface (= tout public), une interface pour tout le monde, plusieurs niveaux d'interfaces...).

                Ça n'impose pas forcément de distinguer interface et implémentation, certains langages peuvent (dans une implémentation) "celer" des modules avec une signature plus restrictive, et donc on peut obtenir la même chose avec seulement des implémentations, mais c'est une fonctionnalité plus avancée et moins explicite.

                • [^] # Re: J'aimerais

                  Posté par (page perso) . Évalué à  2 .

                  Je répond aux deux...

                  Un simple diff montre qu'il y a duplication.

                  Sinon, effectivement, dans certain cas particulier, une séparation peut être utile comme tu l'indiques. En Fortran, il suffit d'utiliser le préprocesseur avec un #include pour arriver au même résultat. Ces fichiers sont assez rare et portent l'extension .F90 plutôt que .f90 donc bien visible... C'est évidement un contournement mais à mon sens il vaut mieux cela sur quelques fichiers que d'emmerder le programmeur sur 99% des autres fichiers ;-)

                  Ceci dis, je suis très sceptique sur les "friend methods"... Une doc claire avec un API propre me semble le mieux. Vouloir faire des API pour machin mais pas pour truc me semble pas tendre vers de la programmation claire.

            • [^] # Re: J'aimerais

              Posté par . Évalué à  4 .

              il ne faut pas oublier qu'en Ada contrairement au C/C++, le fichier de spec se compile au même titre que le corps

              Maintenant ça se fait aussi avec GCC :
              http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

              Ce n'est probablement pas aussi poussé, mais je ne vois pas très bien ce qui est ajouté ou non par ADA. En C/C++ tu as déjà une vérification du type (moins forte en C qu'en C++ certes). ADA apporte des vérifications de précondition comme le spécifie JML ?

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

              • [^] # Re: J'aimerais

                Posté par (page perso) . Évalué à  2 .

                Ce n'est probablement pas aussi poussé, mais je ne vois pas très bien ce qui est ajouté ou non par ADA.

                L'objectif, Michel, l'objectif !! ;)
                Comme le dit la page que tu fournis, l'objectif est d'accélérer la construction du projet pas de vérifier la cohérence. Je crois que j'ai déjà donné ce lien plus haut qui te donnera plus d'explications.

                En C/C++ tu as déjà une vérification du type (moins forte en C qu'en C++ certes). ADA apporte des vérifications de précondition comme le spécifie JML ?

                C/C++ sont déjà des langages à typage fort, Ada fournit un système de typage qui va plus loin en incluant toutes les contraintes de valeurs pour les types simples et les vérifie seul à la compilation quand c'est possible ou en levant une exception au runtime.
                Petit exemple tout simple :

                procedure Test is
                
                   type MonInt is range 1..5;
                   Titi : MonInt := 5;
                begin
                   Titi := Titi + 1;
                end Test;
                
                

                J'adore le message de warning à la compilation :

                fred@freddy:/tmp $ gnatmake test.adb 
                gcc-4.4 -c test.adb
                test.adb:6:17: warning: value not in range of type "MonInt" defined at line 3
                test.adb:6:17: warning: "Constraint_Error" will be raised at run time
                gnatbind -x test.ali
                gnatlink test.ali
                gnatlink: warning: executable name "test" may conflict with shell command
                
                

                Alors, c'est vrai, l'exemple est simplissime mais dans les cas plus complexes avec énormément de types définis, ce genre d'aide n'est pas négligeable. Tu trouveras tout plein d'infos si ça t'intéresse.

                Ensuite, les énumérations sont de vrais types qui s'utilisent comme tels et on ne peut pas les substituer par leur valeur numérique sans le dire explicitment. D'ailleurs, on n'est pas censé maitriser ce mapping si on ne l'a pas spécifié.
                Encore une fois, plutôt que de donner un exemple ridicule, je vais te donner un lien rien qu'à toi :D

                Pour finir, je me suis aussi intéressé à JML après avoir vu ce qui se faisait en Spark Ada. Spark est un peu particulier puisque c'est un sous-langage d'Ada qui est très contraignant mais qui décrit bien les invariants, les pré-conditions... Du coup, ça avait l'air tellement bien que ce sera inclus dans la révision 2012 sous la forme définie . Mais bon, c'est une norme ISO alors ça va prendre encore un peu de temps ;)

                • [^] # Re: J'aimerais

                  Posté par . Évalué à  2 .

                  C/C++ sont déjà des langages à typage fort, Ada fournit un système de typage qui va plus loin en incluant toutes les contraintes de valeurs pour les types simples et les vérifie seul à la compilation quand c'est possible ou en levant une exception au runtime.

                  Je comprends ce n'est pas tellement un problème de header ou de les compiler mais plus du système de type des langages.

                  Ensuite, les énumérations sont de vrais types qui s'utilisent comme tels et on ne peut pas les substituer par leur valeur numérique sans le dire explicitment. D'ailleurs, on n'est pas censé maitriser ce mapping si on ne l'a pas spécifié.
                  Encore une fois, plutôt que de donner un exemple ridicule, je vais te donner un lien rien qu'à toi :D

                  Je n'ai (malheureusement) jamais touché à ADA., mais les énumérations de Java m'ont l'air d'avoir les même caractéristiques. Et je trouve en effet que c'est de loin bien meilleur que ce que propose le C++.

                  Pour finir, je me suis aussi intéressé à JML après avoir vu ce qui se faisait en Spark Ada. Spark est un peu particulier puisque c'est un sous-langage d'Ada qui est très contraignant mais qui décrit bien les invariants, les pré-conditions... Du coup, ça avait l'air tellement bien que ce sera inclus dans la révision 2012 sous la forme définie là. Mais bon, c'est une norme ISO alors ça va prendre encore un peu de temps ;)

                  Les choses comme JML ou ce qui semble être ajouté à ADA 2012 m'ont l'air nettement plus pertinent que de ce limiter à un système de type. Par exemple

                  // je crois que ce genre de condition sont possibles
                  /*@ requires i > j; @*/
                  public void foo(int i, int j) {
                      // ma méthode
                  }
                  
                  

                  C'est à, mon avis, l'un des points forts de D : http://www.d-programming-language.org/cppdbc.html

                  Mais c'est quelque chose de complémentaire au type.

                  Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                  • [^] # Re: J'aimerais

                    Posté par (page perso) . Évalué à  1 .

                    Je n'ai (malheureusement) jamais touché à ADA.

                    Franchement, le gap, pour un programmeur C/C++ qui aurait idéalement fait un peu de Pascal, est franchement très petit. D'ailleurs, il y a deux docs sympas, un en français pour introduction qui s'appelle "cours Ada95 pour le programmeur C++" et un en anglais, plus ancien mais toujours valable (merci la normalisation) sous le titre "Ada-95: A guide for C and C++ programmers". Enfin, c'est pas la doc qui manque !! :)

                    mais les énumérations de Java m'ont l'air d'avoir les même caractéristiques. Et je trouve en effet que c'est de loin bien meilleur que ce que propose le C++.

                    La différence avec Java, c'est que les énumérations sont natives du langage. En Java, c'est plus du sucre syntaxique à base d'instances statiques mais c'est toujours ça de pris et ça remplit bien la fonction demandée.

                    Les choses comme JML ou ce qui semble être ajouté à ADA 2012 m'ont l'air nettement plus pertinent que de ce limiter à un système de type. Par exemple

                    C'est du complément et ça va dans la lignée du langage

            • [^] # Re: J'aimerais

              Posté par . Évalué à  4 .

              En Java, même si j'aime bien ce langage, tout est dans tout et vice-versa, et ça, ça me gêne pas mal quand même..

              Bah, tu peux générer automatiquement des pseudo-header si tu veux, et puis si tu code des interfaces c'est un peu comme si tu définissais des header, non?

        • [^] # Re: J'aimerais

          Posté par (page perso) . Évalué à  2 .

          Ada, dommage que sa syntaxe rebute tout le monde.. Autrement ça serait une bonne alternative..

          Oui c'est dommage parce que ça permet de faire des trucs sympas quand même

          type Integer_1 is range 1 .. 10;
          type Integer_2 is range 1 .. 10;
          A : Integer_1 := 8;
          B : Integer_2 := A; -- illegal!
          
          

          Du coup, sur les appels de fonctions ou procédures, ça permet souvent de lever l’ambiguïté grâce à des types qui ne représentent pas la même chose. Et quand l’ambiguïté ne peut être levée par le type, on peut utiliser les paramètres nommés et ne pas se soucier de l'ordre de ceux-ci :

          Phi := Arctan (Y => A, X => B);
          
          

          est équivalent à

          Phi := Arctan (X => B, Y => A);
          
          
    • [^] # Re: J'aimerais

      Posté par . Évalué à  3 .

      Java ne peut pas utiliser mmap de manière native

      Et ça, ça fait pas l'affaire ?

  • # ocaml...

    Posté par (page perso) . Évalué à  7 .

    Pour moi ocaml serait vraiment parfait si son écosystème était peu plus large. La lib standard est assez réduite, et il y a assez peu de librairies tierces disponibles en comparaison avec java, python, php, etc. Mais en termes de langage pur, j'ai du mal à imaginer mieux ...

    • [^] # Re: ocaml...

      Posté par . Évalué à  1 .

      Facile :
      - Une surcharge possible des opérateurs pour pouvoir utiliser +, -, *... sur des BigInt par exemple ;
      - des fonctionnalités comme un simple mot clé "return", qui oblige de magouiller avec des variable du genre isFinished ;
      - une meilleur intégration avec de l'existant (par exemple, compatibilité avec des libs C ou interfaçage plus facile, ou compatibilité Java...) ;
      - une syntaxe plus claire.

      • [^] # Re: ocaml...

        Posté par . Évalué à  1 .

        Le langage http://nemerle.org se rapproche peut-être de ce que tu recherches ? (par contre, ça fonctionne au dessus de .NET/Mono... :-/ )

      • [^] # Re: ocaml...

        Posté par . Évalué à  2 .

        • Une surcharge possible des opérateurs pour pouvoir utiliser +, -, *... sur des BigInt par exemple

        Note que tu peux définir tes propres opérateurs infixes, et donc utiliser localement (+),(-),( * ) etc. sur des Bigint, ou alors (plus raisonnable) redéfinir (+.),(-.), etc. sur les bigint pour pouvoir toujours mélanger avec les entiers facilement.

        La bibliothèque standard ne le fait pas (... pour l'instant en tout cas), mais tu peux te faire ta propre lib ou utiliser des bibliothèques (c'est fait, de façon imparfaite pour l'instant, dans Batteries par exemple).

      • [^] # Re: ocaml...

        Posté par (page perso) . Évalué à  1 .

        • Une surcharge possible des opérateurs pour pouvoir utiliser +, -, *... sur des BigInt par exemple ;
        • Bof, tu peux redéfinir les tiens. Et puis ça casse l'inférence de type. Je ne trouve pas cher payé d'utiliser +. ou +! pour éviter d'avoir à écrire les types tout en gardant un typage fort.
        • des fonctionnalités comme un simple mot clé "return", qui oblige de magouiller avec des variable du genre isFinished ;
        • Pour moi c'est une mauvaise idée, tu complexifies l'analyse de type et la construction du flot pour le compilo et la relecture pour les humains (il faut lire toute la fonction des fois qu'il y aurait un return au milieu).
        • une meilleur intégration avec de l'existant (par exemple, compatibilité avec des libs C ou interfaçage plus facile, ou compatibilité Java...) ;
        • Il y a pas mal de bindings C existants et ça semble relativement facile. Il y a également du travail fait pour faciliter l'intégration avec d'autres languages comme java ou javascript, mais j'aurai tendance à abonder dans ton sens (voir mon post original). > - une syntaxe plus claire. *Ça c'est que tu es déformé par des années de syntaxe à la sauce C. Ocaml a une syntaxe minimale, la rendre plus verbeuse serait à mon sens affaiblir le language en temps que tel. Après, il est certain que ça rendrait l'apprentissage plus facile pour tous les programmeurs qui connaissent déjà java, C, C++, etc.
        • [^] # Re: ocaml...

          Posté par . Évalué à  0 .

          Bof, tu peux redéfinir les tiens. Et puis ça casse l'inférence de type. Je ne trouve pas cher payé d'utiliser +. ou +! pour éviter d'avoir à écrire les types tout en gardant un typage fort.

          Seulement, pour peu qu'on aie à travailler avec des types différents (par exemple, de taille différente), se retrouver avec des +, +., +!, ++, +/, etc. n'est pas ce qu'il se fait de plus commode et de plus lisible.

          Il y a pas mal de bindings C existants et ça semble relativement facile. Il y a également du travail fait pour faciliter l'intégration avec d'autres languages comme java ou javascript, mais j'aurai tendance à abonder dans ton sens (voir mon post original).

          Pour en avoir fait un peu, c'est assez mal documenté et nécessite de repasser toutes les fonctions à la main en convertissant chaque argument avec les macros qui vont bien. C'est relativement pénible. Alors, pour une micro bibliothèque, ça passe, mais c'est pas demain la veille qu'il y aura un binding Qt ou OpenGL complet et à jour.

          Ça c'est que tu es déformé par des années de syntaxe à la sauce C. Ocaml a une syntaxe minimale, la rendre plus verbeuse serait à mon sens affaiblir le language en temps que tel. Après, il est certain que ça rendrait l'apprentissage plus facile pour tous les programmeurs qui connaissent déjà java, C, C++, etc.

          Après, on peut rester minimal sans forcément utiliser des tas de symboles. Par exemple, Python fait ça très bien, tout en étant différent du C.

          • [^] # Re: ocaml...

            Posté par . Évalué à  2 .

            Seulement, pour peu qu'on aie à travailler avec des types différents (par exemple, de taille différente), se retrouver avec des +, +., +!, ++, +/, etc. n'est pas ce qu'il se fait de plus commode et de plus lisible.

            Depuis OCaml 3.12 (et avant avec des extensions syntaxiques) on peut faire des "open" de modules dans un contexte local. Avec (encore une fois) du bon support du côté des bibliothèques, tu peux écrire:

            open Batteries
            let rec fibo n = Big_int.(match n with
              | 0 -> of_int 1
              | n -> fibo Int.(n - 1) + fibo Int.(n - 2)
            )
            
            

            (Et tu as fibo : int -> Big_int.t)

            Du coup au lieu d'utiliser des opérateurs différents, tu utilises la construction Module.(expression) pour préciser le contexte local. C'est un peu plus lourd, mais c'est agréable à utiliser en pratique car plus explicite. Ça ne vaut pas des type-classes bien sûr, mais là il s'agit d'une fonctionnalité syntaxique simple et pas d'un concept complexe à ajouter au langage.

            Pour en avoir fait un peu, c'est assez mal documenté et nécessite de repasser toutes les fonctions à la main en convertissant chaque argument avec les macros qui vont bien.

            Tu as raison pour les bindings C, c'est pas facile, mais ça c'est la vie, pour peu qu'un langage s'éloigne un peu du support runtime C c'est vite difficile de faire des ponts (cf. ce billet qui compare les FFI de différents langages). On pourrait vouloir des techniques de bindings mieux vérifiées statiquement et donc moins à la merci des erreurs humaines, mais c'est vite un peu compliqué. Cf. le travail de l'excellent langage ATS.

            Après, on peut rester minimal sans forcément utiliser des tas de symboles. Par exemple, Python fait ça très bien, tout en étant différent du C.

            Je ne vois pas trop en quoi la grammaire Python serait plus "minimale" que celle de OCaml. À vue de nez elles sont du même ordre de grandeur de complexité. Il y a la question de l'indentation significative ou pas, c'est un sujet de troll, ce qui est vrai c'est que ça évite d'écrire explictement certains délimiteurs (begin/end et in/;), mais à part ça je ne vois pas trop la différence.

    • [^] # Re: ocaml...

      Posté par . Évalué à  2 .

      Peut être scala qui a accès à toutes les lib de java.

    • [^] # Re: ocaml...

      Posté par (page perso) . Évalué à  1 .

      J'opine, mais j'ajoute juste un détail supplémentaire: un GC concurrent. N'utiliser qu'un seul processeur à la fois, c'est dommage.

      La réponse des concepteurs du langage est d'écrire des applications multi-processus, ce qui fonctionne pour une certaine classe de problèmes, mais pas pour tous... Intégrez-moi Lwt, la bibliothèque de fibres, au dessus d'une vraie concurrence, et l'on aura enfin une belle alternative à boost::asio pour faire de l'asynchrone et de l'orienté événements.

      • [^] # Re: ocaml...

        Posté par (page perso) . Évalué à  3 .

        Il y a un projet de OcamlPro pour pallier à cela : https://github.com/OCamlPro/ocaml-reentrant/

        Tu peux peut être aider ?

        Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

      • [^] # Re: ocaml...

        Posté par . Évalué à  3 . Dernière modification : le 30/01/12 à 11:53

        Pas du tout, OCaml est un langage visionnaire qui a prévu il y a des années que le futur, c'était langages single-threadé. 20 ans après, Javascript s'y (re)met enfin. Qui va suivre ? L'idée de runtimes indépendants communiquant par passage de messages a de l'avenir...

        Even non-Mozilla SpiderMonkey embeddings had reportedly experienced problems that pushed them toward a similar shared-nothing design. Thus, there was little reason to maintain the non-trivial complexity caused by multi-threading support.

  • # Le langage ideal? ... C'est de faire le sien!

    Posté par (page perso) . Évalué à  1 .

    Moi j'ai essaye plein de langages differents, et je n'etais jamais pleinement satisfait, alors tout simplement j'ai cree le mien

    Globalement il y a trois langages que j'aime bien:
    - le C pour la syntaxe curly brace et la possibilite de faire du bas-niveau (e.g. controller son allocation memoire)
    - Ocaml pour le systeme et l'inference de type
    - Lisp pour la meta programmation, la capacite de definir des langages specifiques

    Alors j'ai ecris mon langage qui fait un mix de tout ca.

    Seul hic: il est pas fini!... :)

    http://l-lang.org/ - Conception du langage L

  • # Ce que j'en pense...

    Posté par (page perso) . Évalué à  8 .

  • # Le langage idéal

    Posté par (page perso) . Évalué à  2 .

    DOORS DXL.

    Non je déconne, c'était une connerie.

    Ça rentrerait plutôt dans le concours du pire langage de tous les temps.

    Un jour faudra que j'écrive un journal à ce sujet, bonne marade garantie.

    • [^] # Re: Le langage idéal

      Posté par . Évalué à  2 .

      C'est pire qu'XSLT? Difficile a croire..
      Sinon je me souviens du premier langage que j'ai utiliser pour travailler, c'était un langage "maison", créer pour "simplifier" l'écriture de tests:
      - on peut utiliser seulement une interface graphique a la souris pour entrer les programmes.
      - les noms de variables sont limités a un caractère(!!!)
      - la sémantique est un mélange entre l'assembleur et le C
      - très, très lent

      P...! quand je pense a la perte de temps et d'argent par rapport à une simple librairie utilisable en C ou Pascal..

      • [^] # Re: Le langage idéal

        Posté par . Évalué à  1 .

        J'ai eu a utiliser un langage maison dans lequel la taille maximale d'une string était de 4 caractères !

  • # Pour répondre a ta question

    Posté par . Évalué à  2 .

    Déjà, je me baserai sur un langage "sain": l'Ada 2012 par exemple pas le C: par défaut pas de débordement entier ou de tableau autorisé (mais avec aussi des types "à la C" avec des noms évocateurs unsafe_int, unsafe_array pour la ou on a besoin de performance), mais avec une syntaxe plus agréable (Scala par exemple).

    Une chose que je pense utile c'est d'avoir aussi le calcul par interval arithmétique plutôt que juste par flottant: connaître la précision des résultats, ça me parait quand même essentiel..

  • # Vala ?

    Posté par (page perso) . Évalué à  3 .

    Voilà mon analyse:
    * C++
    Horriblement complexe, ce qui conduit chaque développeur à utiliser un sous-ensemble des fonctionnalités, de manière incompatible avec son voisin (Google par exemple, n'utilise pas les exceptions). Très difficile à maitriser.
    * Java
    Pas franchement mauvais, mais pas excellent non plus. La machine virtuelle qui mange la RAM, le garbage collector qui passe quand il veut...
    * C
    Très élégant en général, peu complexe, portable, puissant ... Beaucoup de bon point malgré son age. Coté moins bon, la difficulté de faire de l'objet, et trop bas niveau pour coder vite et bien.

    J'ai pendant longtemps eu l'impression qu'il manquait un langage au milieu de tout ça, un genre de chainon manquant. Je pense l'avoir trouvé avec Vala (ou au moins on s'en approche).
    * langage de haut niveau (très inspiré du C#)
    * se compile en C/GObject, donc forte portabilité et réutilisabilité du code (autant pour utiliser du code C en Vala que dans l'autre sens).
    * reference counting, donc une gestion mémoire automatique, en restant déterministe
    * utilise naturellement toute l'infrastructure GNOME (mais on est pas pour autant limité à ça)
    * plein de petit truc qui font que c'est un langage plutôt sympa à utiliser, et très efficace

    Vala Tutorial
    Vala for Java Programmers
    Vala for C# Programmers

    • [^] # Re: Vala ?

      Posté par (page perso) . Évalué à  2 . Dernière modification : le 30/01/12 à 00:11

      reference counting, donc une gestion mémoire automatique, en restant déterministe

      C'est très limité le référence counting.

      utilise naturellement toute l'infrastructure GNOME (mais on est pas pour autant limité à ça)

      Perso ça m'inciterait plutôt à fuir ça...

      Sérieusement quelle est la pérénité de Vala ? Ça m'a l'air porté par Gnome et c'est à peu prêt tout.

      • [^] # Re: Vala ?

        Posté par . Évalué à  2 .

        Valac compile les programmes écrits en Vala en C .
        Vala adopte une syntaxe similaire au C#.
        Sur la page de Vala, il y a une liste de logiciels réalisés en Vala, ça le fait. :)
        à la fin de cette page

        Sedullus dux et princeps Lemovicum occiditur

  • # Lazarus

    Posté par . Évalué à  1 .

    • D'une mon langage idéal, ça dépend de ce qu'il faut faire: aucun langage ne permet de tout faire, et , de temps en temps, il vaut mieux utiliser plusieurs langages qu'un seul. C'est d'ailleurs un peu ce que font les RAD avec la gestion des dessins d'IHM en XML... Au risque de plomber les perfs ( parce qu'une seconde pour faire un maFenetre.setVisible(true), c'est un peu incohérent ).
    • De deux, vous parlez tous des " anciens " et des " nouveaux " langages, mais personne ne parle de celui qui assure une stabilité, une cohérence, avec un RAD assez performant ( Lazarus ), depuis des années: eviV lacsaPeerF !

    Ma vision de langage idéal c'est quoi ?

    C'est un super outil RAD n'utilisant pas le XML pour le design de l'IHM, capable sur la même base de faire ( dans l'ordre ) :
    - du C - avec WXVidgets et GTK3- avec un dessinateur d'IHM intégré
    - du Java je détaille pas mais ça serait bien que la prise en charge soit au niveau de ce que NetBeans propose
    - du C++
    - du Qt
    - du Vala ( Sisi, malgré les " problèmes " de " brevets " )
    - de l'Objective-C
    - du FreePascal
    - Ruby
    - Python
    - Perl
    - PHP
    - js

    Sans compter :
    - Le modeleur UML
    - La synchronisation des sources
    - la gestion des todolists
    - la gestion des SGBD, des SGBD embarquées
    - La machine à café.

    Sedullus dux et princeps Lemovicum occiditur

  • # Common Lisp !

    Posté par (page perso) . Évalué à  5 .

    Comme ça, quel que soit le problème que j'ai à résoudre, je crée le langage idéal si ça n'est pas déjà CL lui-même !

  • # L'idéal

    Posté par (page perso) . Évalué à  5 .

    • Un langage objet à gestion de la mémoire automatique, mais que le langage soit suffisamment souple pour que ce code soit écrit dans ce langage
    • Une VM généraliste (Parrot ?)
    • Un compilateur écrit dans ce langage (self hosting)
    • Un langage à typage statique optionnel (recommandé ou obligatoire pour les arguments des fonctions)
    • Aucune structure de contrôle imposée dans le language, à la smalltalk. Un if se ferait par envoi de message ifTrue/ifFalse sur un objet booléen, en passant un bloc de code en paramètre (comme Smalltalk/Io)
    • Une possibilité (sans doute via le typage statique) de ne pas évaluer directement certains paramètres d'une fonction, et de les transformer en bloc de code à évaluer plus tard (un peu comme Io)
    • Une gestion de la concurrence intelligente, capable de gérer des multicœurs (Go de Google ?)
    • Des variables à portée lexicale (comme les locales en Lua)
    • Une possibilité de compiler le langage si le code à été suffisamment typé statiquement, pour pouvoir écrire la VM dans ce langage
    • [^] # Re: L'idéal

      Posté par . Évalué à  6 .

      Des variables à portée lexicale (comme les locales en Lua)

      Quoi, c'est une fonctionnalité ça ? Je ne dois pas comprendre parce qu'il me semble que c'est la base de la base. Je dirais plutôt que les langages qui ne l'ont pas (ou qui l'amputent d'une façon ou d'une autre) craignent un max (oui, dommage que ça incluse des langages aussi populaires que Coffeescript, ou les premières versions de Ruby).

      • [^] # Re: L'idéal

        Posté par . Évalué à  0 . Dernière modification : le 31/01/12 à 19:17

        oui, dommage que ça incluse des langages aussi populaires que Coffeescript, ou les premières versions de Ruby

        Et python aussi... je ne sais pas pourquoi il passe toujours à travers les gouttes dans ces discussions sur la portée lexicale.

        >>> fs = []
        >>> for i in range(3):
        ...   fs.append(lambda: i)
        ... 
        >>> for f in fs:
        ...   print f()
        ... 
        2
        2
        2
        
        
        • [^] # Re: L'idéal

          Posté par . Évalué à  2 .

          Ce n'est pas un problème de portée lexicale mais de distinction valeur/référence sur les variables. Pour moi il y a problème de portée quand tu voudrais définir une nouvelle variable localement et que tu ne peux pas, ou que tu voudrais accéder à une variable définie plus globalement, mais que tu ne peux pas ou que ce n'est pas "la bonne" variable qui est choisie.

          Il y a bien un problème de ce type en Python (PEP 3104) mais il a été géré de manière raisonnable, c'est pour ça que je n'ai pas mentionné. Cela vient de la distinction C'est moche, mais il y a maintenant un mot clé nonlocal comme rustine pour éviter ça. Ça pose parfois problème pour faire évoluer le langage, comme dans la PEP 3150.

          • [^] # Re: L'idéal

            Posté par . Évalué à  0 .

            Dans ce cas pour moi c'est un problème lié, sinon à la portée lexicale, au mécanisme de closures (à moins que je loupe quelque chose): les types builtins sont capturés par référence alors qu'ils sont passés par valeur aux fonctions. Ce n'est pas seulement un problème d'implémentation de la boucle for (qui ne redéfinit pas un i à chaque pas) si ce dont tu parlais.

            • [^] # Re: L'idéal

              Posté par . Évalué à  3 .

              les types builtins sont capturés par référence alors qu'ils sont passés par valeur aux fonctions

              Non non, ils sont passés par référence, seulement ils sont immuables, c'est tout.

              • [^] # Re: L'idéal

                Posté par . Évalué à  0 . Dernière modification : le 02/02/12 à 01:37

                Ok donc ça signfie que dans ce cas la fermeture possède une référence vers la portée qui contient i plutôt que vers i directement ? Autrement dit, les environnements des closures de python sont mutables.

                Sinon je ne suis pas un habitué de linuxfr mais pourquoi mon post du dessus est-il noté à -1 ? Est-ce que c'est le système qui l'assigne automatiquement ou est-ce que quelqu'un a "downvoté" ce que j'ai mis au-dessus ? Dans le dernier cas pourquoi ? Est-ce que j'ai dit quelque-chose d'offensif ou d'inutile ?

                • [^] # Re: L'idéal

                  Posté par . Évalué à  4 .

                  Ok donc ça signfie que dans ce cas la fermeture possède une référence vers la portée qui contient i plutôt que vers i directement ? Autrement dit, les environnements des closures de python sont mutables.

                  On peut dire ça comme ça. Dans les langages dynamiques comme Python, JavaScript et Ruby les closure gardent un accès à la frame ou elles ont été crée.

                  Ce qui est confusant dans l'exemple plus haut c'est que la boucle for ne crée pas sa propre frame, mais si on réécrit un peut l'exemple:

                  callbacks = []
                  
                  def add_callback(i):
                      callbacks.append(lambda: i)
                  
                  for i in range(3):
                      add_callback(i)
                  
                  for c in callbacks:
                      print c()
                  
                  

                  Cela marche comme attendu.

                  • [^] # Re: L'idéal

                    Posté par . Évalué à  -1 .

                    Oui, j'avais inféré le contournement, mais dans mon modèle mental (érroné) selon lequel les entiers étaient capturés par référence et passé aux fonctions par valeur ça s'expliquait bien :)

    • [^] # Re: L'idéal

      Posté par (page perso) . Évalué à  3 .

      Ça ressemble vachement à Common Lisp, ta description.
      Y'a juste pour la concurrence que j'ai des doutes, mais ça doit être bien géré par certaines implémentations du langage.

      • [^] # Re: L'idéal

        Posté par . Évalué à  2 .

        À ma connaissance CL n'a pas de système de typage digne de ce nom (contrairement à Typed Racket (ex. Typed Scheme) par exemple, donc l'espoir est possible). Après ça dépend de ce qu'on met dans "digne de ce nom", ces temps-ci la moyenne est plutôt à la baisse (Go, Dart...) (enfin non, Rust).

      • [^] # Re: L'idéal

        Posté par . Évalué à  2 . Dernière modification : le 02/02/12 à 02:18

        Je suppose que tu évoques LISP à cause de la partie sur les structures de contrôle et les arguments passés par nom ? En fait, pour ce que Mildred demande la puissance des macros n'est même pas nécessaire j'ai l'impression, de simples fermetures suffisent (c'est ce que fait smalltalk justement pour le if, et le branchement builtin est caché dans la liaison dynamique).

        La partie vraiment pas évidente c'est le typage optionnel. Il y a eu pas mal de littérature sur le gradual typing (ou soft typing) et les blame tracking type systems, mais à l'exceptions de langages comme Racket (évoqué par gasche) il n'y a pas encore d'implémentation sérieuse de ces systèmes à ma connaissance. Dart est un des premiers environnements "grand public" à proposer ça mais la partie typée n'est pas sûre (typesafe)...

        Maintenant, je ne sais pas si Mildred a connaissance de l'existence l'inférence de type si par "typage optionel" elle entendait "annotations de typage optionnelles". Les programmeurs font parfois cet amalgame. Dans le dernier cas, son langage ressemblerait beaucoup à haskell (ou à un ML qui aurait un bon support pour la concurrence, JoCaml peut-être ?). Les deux seuls points que haskell ne remplit pas sont:

        • langage objet: mais les existentiels + typeclasses fournissent une fonctionnalité similaire;
        • une VM généraliste: là-dessus j'ai été récemment assez convaincu par les auteurs de Dart qu'une telle chose n'existe pas. (Je ne leur fais pas super confiance pour le design du langage - quoique Bracha a rejoint la troupe, mais il a aussi un peu déraillé sur son blog récemment - mais pour son implémentation si : ce sont les gens qui ont bossé sur V8, Hotspot avant et self encore avant, ils savent en général de quoi ils parlent.)
        • [^] # Re: L'idéal

          Posté par (page perso) . Évalué à  2 .

          J'évoque Common Lisp, parce que

          • c'est un langage objet à gestion de la mémoire automatique, suffisamment souple pour que ce code soit écrit dans ce langage
          • avec des bonne VM
          • que ça a un compilateur écrit dans ce langage (self hosting)
          • Il y a quand même du typage statique, qui te file plein d'infos et de warnings (avec SBCL)
          • ça a un méga système objet
          • Ça a des macros (sortes de fonctinos qui n'évaluent pas leurs paramètres. Sinon, les FEXPRs ont été bannis il y a longtemps)
          • Ça a des bons bindings de MPI
          • Ça a des variables à portée lexicale (comme les locales en Lua)
          • Ça se compile vers du langage machine.
          • [^] # Re: L'idéal

            Posté par . Évalué à  1 .

            Le typage statique de SBCL reste assez limité malheureusement. Mais bon c'est quasi impossible de typer un langage à macros si le langage de macro n'est pas limité d'une manière ou d'une autre. Meta OCaml (et Scala Virtualized) proposent de la metaprogrammation typesafe mais c'est beaucoup plus limité que LISP. C'est plutôt dans une optique de multi staged programming que d'extensibilité du langage.

  • # Un langage ontologique et métaphorique

    Posté par (page perso) . Évalué à  5 .

    • Un langage qui permette d'intégrer explicitement le temps, par des expressions du type : "Si l'utilisateur a cliqué plus de 3 fois sur le bouton BtnAction en moins de 1 seconde, alors..."
    • Un langage qui permette de définir des interdictions ou des obligations : "Un utilisateur ne peut voter plus de 2 fois pour un autre utilisateur en moins de 10 jours"
      Bref une sémantique basé sur de la logique modale, déontique et temporelle.

    • Un langage orienté agent pour mieux gérer la concurrence (un agent = un thread). Les agents fonctionnent selon le modèle BDI (Belief Desire Intention). L'agent étant assez complexe, on a pas des milliards de threads qui coutent en changement de contexte.

    • Un langage dont la syntaxe est un sous ensemble contrôlé d'une langue naturelle, comme Attempto Controlled English, mais amélioré

    • Un langage dans lequel chaque verbe et non est catégorisé sémantiquement.

    • Un langage dans lequel la création de fonction est une création de vocabulaire qui se raffine selon le contexte (selon la catégorisation sémantique du contexte).

    • Un langage où la métaphore physique et spatiale, plus proche du fonctionnement de notre cerveau, permet de décrire un programme

    Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

    • [^] # Re: Un langage ontologique et métaphorique

      Posté par . Évalué à  4 .

      Fiouu, à côté Lisaac c'était mainstream !

      Enfin c'est bien, on peut sacrément innover en explorant ces choses là.

    • [^] # Re: Un langage ontologique et métaphorique

      Posté par . Évalué à  3 .

      Tu veux créer un nouveau business loto, c'est ça?

    • [^] # Re: Un langage ontologique et métaphorique

      Posté par . Évalué à  2 .

      urbi (langage pour robotique) peut être une source d'inspiration.

      Exemple :

        myTag:
          every (2s)
            echo ("Boucle sans fin"),
        at (button.pressed)
          myTag.stop;
      
      
      • [^] # Re: Un langage ontologique et métaphorique

        Posté par (page perso) . Évalué à  2 .

        C'est très très intéressant !
        C'est marrant, parce que je suis en train de coder un moteur de machine à état fini hiérarchique (HFSM en anglais, pour les mot clés google), qui me fait beaucoup penser à ce langage :
        Un moteur à état fini hiérarchique est une machine à état fini classique, dans lequel on peu trouver une machine à état fini dans un état. Cette machine "hébergée" dans un état s'active lorsqu'on passe dans l'état père :
        Hierarchical Finite State Machine
        .

        J'utilise ce moteur pour animer des agents dans un monde, afin de les doter d'un comportement. De ce fait les transitions sont effectuées à partir d'évènements et de conditions. Les évènements viennent de l'extérieur et les conditions sont des booléens évalués sur l'état interne de l'agent (ici un objet).
        Grâce au type somme de Ocaml, je peux faire une équation booléenne de conditions et évènements.

        Quand je vois ce langage (urbi), je me dis que cela se compile facilement en HFSM

        Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

        • [^] # Re: Un langage ontologique et métaphorique

          Posté par . Évalué à  1 .

          Effectivement ça à l'air conceptuellement proche, en étant basé sur des signaux. Regarde urbi, il est possible de faire d'autres choses que de la robotique, c'est un moteur qui a l'air pas mal, testé, puissant (parallélisme intégré au langage, bindings C++/java...), c'est sous AGPLv3 et c'est une boite française sympa qui s'en occupe :)

      • [^] # Re: Un langage ontologique et métaphorique

        Posté par . Évalué à  1 . Dernière modification : le 31/01/12 à 18:28

        Ça ressemble aussi beaucoup à scala.react.

        C'est une implémentation en scala du FRP avec un langage de dataflow impératif en surface grâce aux continuations délimitées.

        Par exemple, tiré du papier:

        val drags = Events.loop { self =>
          self next mouseDown
          val mu = self.loopUntil(mouseUp) {
            self emit Drag(self next mouseMove)
          }
          self emit Drop(mu)
        }
        
        
  • # Programmation Fonctionnelle

    Posté par . Évalué à  1 . Dernière modification : le 30/01/12 à 16:09

    je ne mettrais aucun des trucs à la mode du genre [...] programmation fonctionnelle

    Étant donné que "programmation fonctionnelle" désigne un style de programmation dans lequel on ne fait pas d'effets de bords (i.e. les fonctions sont des fonctions au sens mathématique), ça n'a pas beaucoup de sens de la "mettre" ou pas dans un langage.

    • [^] # Re: Programmation Fonctionnelle

      Posté par . Évalué à  1 . Dernière modification : le 30/01/12 à 16:54

      Autrement dit, on peut très bien faire de la programmation fonctionnelle en C par exemple. Il suffit de s'assurer que les fonctions sont pures. En contrepartie le debugging, le test, le raisonnement équationnel et la compositionalité s'en trouvent facilités.

      Voir ce texte par exemple.

    • [^] # Re: Programmation Fonctionnelle

      Posté par . Évalué à  2 .

      Oui, enfin le "turing tar pit" (tout les languages peuvent faire la même chose et sont donc équivalents) tu es gentil mais ça ne sert pas à grand chose dans une discussion sur les langages..

      • [^] # Re: Programmation Fonctionnelle

        Posté par . Évalué à  1 .

        Je crois qu'il va falloir inventer le Turing tar pit tar pit :)

        Si j'avais dit: "Ça n'a pas de sens de rajouter des exceptions dans X, parce que tu peux les simuler par une chaîne de tests en retournant un booléen à chaque appel", je serais tombé dans le Turing tar pit parce que c'est une solution moins efficace qu'un support natif, et qui fournit moins de garanties statiques (checked exceptions par exemple).

        Si j'avais dit "Ça n'a pas de sens de rajouter des exceptions dans X, parce que tu peux les simuler par une transformation CPS", je serais tombé dans le Turing tar pit parce que c'est une transformation non locale et non triviale.

        Ce que je voulais dire ici c'est que justement, il n'y pas non seulement pas besoin de support du langage pour faire de la programmation fonctionnelle, mais un langage n'a que peu à offrir en la matière. Il s'agit plus d'une philosophie de programmation.

        Maintenant, certains langages (comme haskell) encouragent ce style de programmation en confinant par typage les effets de bords. Certains environnements (comme scala) encouragent ce style de programmation en fournissant des structures de données persistantes dans la bibliothèque standard. Dans les deux cas, il ne s'agit pas d'une simulation et ça n'a donc rien à voir avec le Turing tar pit.

        Pour en revenir au sujet de départ, je pense que la personne qui a écrit le journal voulait parler de la capacité du langage à abstraire sur les fonctions, qu'on associe souvent aux langages fonctionnels parce qu'elle y est lié historiquement et, je suppose, parce qu'il y a "fonction" dans "fonctionnel". Ma remarque portait là-dessus.

        Gentiement.

        • [^] # Re: Programmation Fonctionnelle

          Posté par . Évalué à  2 .

          Enfin le fait d'avoir des fonctions de première classes (qui peuvent être utilisées comme n'importe quelle valeur) est très utile pour avoir un style fonctionnel sans contraintes, et justement C n'a pas cette fonctionnalité: tu as les pointeurs de fonctions, mais tu ne peux pas pour autant définir des fonctions imbriquées les unes dans les autres, ou plus généralement construire des fonctions dynamiquement au runtime -- on émule ça en faisant de la conversion de clôture à la main pour se ramener à avoir seulement des fonctions toplevel, mais ça revient à demander au programmeur de faire à la main une passe de compilation.

          Par ailleurs, le fait d'avoir un GC est quand même très utile pour la plupart des idiomes de la programmation fonctionnelle (par exemple, sans GC, beaucoup de fonctions ne sont plus naturellement tail-récursives), c'est un style qui alloue beaucoup et dans lequel la durée de vie des valeurs est difficile à maîtriser statiquement. On peut faire de la programmation fonctionnelle sans GC, mais c'est subtil et ça reste plutôt un sujet de recherche.

          • [^] # Re: Programmation Fonctionnelle

            Posté par . Évalué à  1 .

            Le fait d'avoir des fonctions de première classe permet d'abstraire sur des valeurs fonctionnelles mais on peut faire déjà beaucoup de choses fonctionnelles sans ça.

            Ensuite si l'on considère que les fermetures et le GC sont nécessairement liés à la programmation fonctionnelle, alors oui, ça a du sens de dire que le langage supporte la programmation fonctionnelle, mais dans ce cas "closure" et "garbage collector" sont redondants dans la phrase "closure, programmation fonctionnelle, garbage collector". Donc j'ai supposé qu'il entendait par là autre chose.

            • [^] # Re: Programmation Fonctionnelle

              Posté par . Évalué à  1 . Dernière modification : le 31/01/12 à 15:45

              Le fait d'avoir des fonctions de première classe permet d'abstraire sur des valeurs fonctionnelles mais on peut faire déjà beaucoup de choses fonctionnelles sans ça.

              Autrement dit, il n'y a pas besoin d'ordre supérieur pour dériver des équations du style

              concat (xs ++ ys) = concat xs ++ concat ys
              
              

              et en tirer parti.

          • [^] # Re: Programmation Fonctionnelle

            Posté par (page perso) . Évalué à  4 .

            La récursion terminale n'a rien à voir avec le GC !
            Une récursion est terminale si l'appel récursif est en position terminale.
            Ça ne parle pas de gestion de mémoire, manuelle ou non !

            La récursion terminale est liée à l'optimisation d'appels récursifs terminaux (TCO), oui, mais c'est c'est lié à la pile et non au tas, donc pas d'histoire de GC non plus.

            Que voulais-tu dire alors ?
            (Et puis, y'a-tu vraiment des gens qui bossent sur la FP sans GC ? T'as des références récentes ? Je suis curieux…)

            • [^] # Re: Programmation Fonctionnelle

              Posté par . Évalué à  1 . Dernière modification : le 31/01/12 à 16:23

              Oui ça existe encore, JHC utilise la region inference à la place. Certains langages de FRP comme Lustre qui visent l'embarqué se passent aussi de GC si je me souviens bien (en contrepartie, on est limité à certaines primitives pour manipuler le flot d'évènement).

              • [^] # Re: Programmation Fonctionnelle

                Posté par . Évalué à  2 .

                Pour moi JHC est essentiellement du vaporware pour l'instant; par ailleurs il y a déjà eu pas mal d'essais d'utilisation des régions à grande échelle, pour des résultats souvent mitigés -- le travail sur Cyclone était très bon, mais ça restait très compliqué. J'avais lu une rétrospective sur l'inférence de régions pour SML, mais je ne la retrouve plus.

                Les langages synchrones (tu vas vexer des gens en caractérisant Lustre et cie. de "FRP", ces langages reposent sur des concepts qui existaient bien avant la mode récente de la FRP à la sauce Haskell) sont effectivement un cas intéressant où on peut combiner pureté et utilisation très contrôlée de la mémoire, mais je ne les vois pas trop comme des langages généralistes, plutôt comme des langages spécifiques à certains domaines (importants).

                • [^] # Re: Programmation Fonctionnelle

                  Posté par . Évalué à  1 . Dernière modification : le 31/01/12 à 16:57

                  J'ai pas dit que ça marchait, j'ai juste dit que ça existait encore ! Je suis complètement d'accord avec ton commentaire selon lequel c'est encore expérimental.

                  Concernant FRP, je m'en fiche un peu de vexer les gens tant que l'appellation est correcte :) Et là aussi, je n'ai pas sous-entendu que c'était un langage généraliste.

              • [^] # Re: Programmation Fonctionnelle

                Posté par (page perso) . Évalué à  2 .

                Ouais, l'inférence de région, j'en parlais déjà icitte : https://linuxfr.org/nodes/89229/comments/1315214

                Apparemment, l'inférence de région est un problème décidable, mais avec mémoire non bornée (ce qui est simple, c'est comme dire "je ne désalloue que quand le programme a terminé").
                Si tu as des contraintes de mémoire, alors je crois qu'on retombe sur le besoin d'utiliser un GC (car je ne pense pas qu'on aille mélanger gestion automatique et manuelle de la mémoire).

                Quand à Lustre, c'est pas un langage fonctionnel, et c'est extrêmement peu généraliste, comme langage.
                Je suis même pas sûr qu'il soit "Turing Complet" (en tout cas, Esterel ne l'est pas).

                • [^] # Re: Programmation Fonctionnelle

                  Posté par . Évalué à  0 .

                  Quand à Lustre, c'est pas un langage fonctionnel.

                  Vraiment ? Je ne connais pas bien Lustre (j'ai juste vu un exposé de Marc Pouzet une fois puis je l'ai vu cité dans des papiers de FRP) mais il me semblait bien qu'il s'agissait d'un langage fonctionnel au sens ou je l'ai "défini" au-dessus.

                  D'après la wikipedia c'est un language de dataflow et d'après la même wikipedia:

                  Dataflow programming languages share some features of functional languages, and were generally developed in order to bring some functional concepts to a language more suitable for numeric processing.

                  et plus loin:

                  Dataflow programming focuses on how things connect, unlike imperative programming, which focuses on how things happen.

                  Donc il doit bien y avoir un rapport quelque part.

                  • [^] # Re: Programmation Fonctionnelle

                    Posté par (page perso) . Évalué à  3 .

                    J'ai pas fait de lustre depuis… des lustres ! tadam
                    Mais de mémoire, c'est pas muni de fonctions d'ordre supérieur, et les contraintes du langage sont telles qu'on est loin d'avoir les mêmes problèmes qu'avec un simple langage fonctionnel jouet.

                    • [^] # Re: Programmation Fonctionnelle

                      Posté par . Évalué à  1 . Dernière modification : le 02/02/12 à 15:02

                      Il me semble que les primitimes offertes au programmeur sont des fonctions d'ordre supérieur builtin. Et sans cela, c'est fonctionnel au sens "pas d'état", qui est pour moi l'essence du fonctionnel: les langages de dataflow proposent de remplacer l'état mutable par de la transformation de données.

                      Si je me rappelle bien, le langage fournit une interface programmatique pas trop effrayante pour le programmeur non fonctionnel mais il s'agit seulement de sucre syntaxique pour (encore une fois) du FRP.

            • [^] # Re: Programmation Fonctionnelle

              Posté par . Évalué à  4 .

              Ce que je voulais dire, c'est que si on écrit un algorithme récursif dans un langage avec GC, et qu'on essaie d'y ajouter des malloc/free pour obtenir un algorithme en C par exemple, on se retrouve souvent à vouloir ajouter un free après un appel terminal.

              Par exemple (le premier qui me vient en tête, pas forcément le meilleur) :

              let rec tri_fusion liste suffixe = match liste with
              | [] | [_] -> liste @ suffixe
              | _ ->
                let gauche, droite = decoupe liste in
                tri_fusion gauche (tri_fusion droite suffixe)
              
              

              Si tu dois insérer des malloc/free, la façon la plus naturelle est la suivante :

              let rec tri_fusion liste suffixe = match liste with
              | [] | [_] -> liste @ suffixe
              | _ ->
                let gauche, droite = decoupe liste in
                let result = tri_fusion gauche (tri_fusion droite suffixe) in
                free_list gauche;
                result
              
              

              (On libère seulement gauche car droite est un suffixe de la liste d'entrée, donc n'es pas possédée par le code appelant).

              Si tu veux récupérer un appel terminal, il faut faire une transformation de 'passage de continuation' à la main dans le cas particulier du contexte mémoire: à l'appel récursif, mettre gauche dans une pile de "trucs à libérer après avoir calculé le résultat final":

              let rec tri_fusion liste suffixe cadavres = match liste with
              | [] | [_] ->
                List.iter free_list cadavres;
                free_list cadavres;
                liste @ suffixe
              | _ ->
                let gauche, droite = decoupe liste in
                tri_fusion gauche (tri_fusion droite suffixe) (gauche :: cadavres)
              
              

              Ça ne se voit pas dans les langages à GC parce que les actions de libération, qui sont bien effectuées après le retour de la fonction, ne sont pas mémorisées dans la pile d'appel mais redécouvertes a posteriori par le GC quand il parcourt l'espace mémoire; ça permet donc d'avoir plus d'appels terminaux.

              (Et puis, y'a-tu vraiment des gens qui bossent sur la FP sans GC ? T'as des références récentes ? Je suis curieux…)

              ATS est un excellent exemple que j'invite fortement les gens intéressés par la programmation bas niveau et statiquement sûre à regarder. Pour faire de la programmation fonctionnelle sans GC (ou au moins en pouvant décider localement de ne pas l'utiliser), il faut presque nécessairement un système de types linéaires, donc tu peux regarder plus largement dans la littérature de recherche sur les langages à types linéaires -- même si tous ne sont pas orientés contrôle bas-niveau de la mémoire.

    • [^] # Re: Programmation Fonctionnelle

      Posté par (page perso) . Évalué à  6 .

      En plus, c'est à la mode depuis les années 30 !
      Trop hipster pour être utile !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.