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 Zenitram (site web personnel) . Évalué à 1. Dernière modification le 28 janvier 2012 à 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 G.bleu (site web personnel) . Évalué à 8.
COBOL je t'ai reconnu !
[^] # Re: Mes idéaux
Posté par dave . Évalué à 5. Dernière modification le 28 janvier 2012 à 17:46.
Tu veux dire ?
Sinon C++ répond plutôt bien à ce que tu décris. Peut être pas aussi portable que ça néanmoins. Sinon,
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 Zenitram (site web personnel) . Évalué à 0.
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 dave . Évalué à 2.
Non, c'est juste que ton
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 Zylabon . É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 wilk . É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 Fabimaru (site web personnel) . É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 Jean B . Évalué à 6.
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 Marotte ⛧ . Évalué à 1. Dernière modification le 30 janvier 2012 à 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 Marotte ⛧ . Évalué à 1.
compilerinterpréter. Pardon aux familles.[^] # Re: Mes idéaux
Posté par gasche . É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 Marotte ⛧ . É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 gasche . Évalué à 5. Dernière modification le 30 janvier 2012 à 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 BB . É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 gasche . É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 BB . Évalué à 3.
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.
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 barmic . Évalué à 2.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mes idéaux
Posté par gasche . É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 rewind (Mastodon) . Évalué à 5.
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 Zenitram (site web personnel) . Évalué à 2.
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 GuieA_7 (site web personnel) . É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.
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 JGO . Évalué à 9.
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 Sytoka Modon (site web personnel) . É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 Zenitram (site web personnel) . Évalué à 3.
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 Sytoka Modon (site web personnel) . É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 BB . Évalué à 1.
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 nud . É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 Tonton Th (site web personnel, Mastodon) . Évalué à 2.
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.
[^] # Re: Mes idéaux
Posté par GuieA_7 (site web personnel) . Évalué à 3.
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 Philippe F (site web personnel) . É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 gasche . É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 Zenitram (site web personnel) . Évalué à 2.
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"
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 gasche . É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 GuieA_7 (site web personnel) . Évalué à 6.
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 Troy McClure (site web personnel) . É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 gasche . Évalué à 2.
Merci d'avoir bien écrit ce que j'essayais de dire.
[^] # Re: Mes idéaux
Posté par JGO . É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 !
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 wilk . É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 JGO . Évalué à 3.
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 wilk . É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 pasScott pasForstall . É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 reno . É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 pasScott pasForstall . É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 reno . É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 nud . Évalué à 1.
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 Tonton Th (site web personnel, Mastodon) . Évalué à 2.
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 ?
[^] # Re: Mes idéaux
Posté par pasScott pasForstall . É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 barmic . É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 ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mes idéaux
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
QuickBasic 4.5 for Microsoft MS-DOS;)[^] # Re: Mes idéaux
Posté par Dr BG (site web personnel) . Évalué à 2.
Pascal, si je me souviens bien de ma première année de fac.
[^] # Re: Mes idéaux
Posté par claudex . É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
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mes idéaux
Posté par Dr BG (site web personnel) . Évalué à 2.
En D, ça fonctionne aussi.
[^] # Re: Mes idéaux
Posté par gasche . É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 Blackknight (site web personnel, Mastodon) . Évalué à 1.
Au risque de me répéter : Ada où tout type discret peut servir.
[^] # Re: Mes idéaux
Posté par Blackknight (site web personnel, Mastodon) . É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 gasche . É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 Alex . É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 Blackknight (site web personnel, Mastodon) . É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 Blackknight (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 02 février 2012 à 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
Bon, ok, c'est pas terrible... Non, c'est carrément nul mais faisable :D
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 gasche . É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 Blackknight (site web personnel, Mastodon) . Évalué à 1.
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 :
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 vois pas la difficulté là, hormis syntaxique. Un bloc declare suffit normalement. Je dois pas avoir compris ce que tu voulais dire :)
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 barmic . Évalué à 2.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mes idéaux
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
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 pasScott pasForstall . É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 JGO . Évalué à 2.
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 uncase entier:en dehors de l'enum.[^] # Re: Mes idéaux
Posté par pasScott pasForstall . É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 barmic . Évalué à 3.
Merci tu es le premier qui répond en connaissant given/when. Pour rappel :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mes idéaux
Posté par reno . Évalué à 3.
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)).
Le cast est une opération "dangereuse": il faut pouvoir les identifier facilement(grep). Et avec la syntaxe actuelle ce n'est pas possible.
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 Tonton Th (site web personnel, Mastodon) . Évalué à 2.
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 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...
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.
Arf, on a dû avoir le même professeur de C :)
[^] # Re: Mes idéaux
Posté par reno . É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 gasche . É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 reno . É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 gasche . É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 reno . Évalué à 2.
Merci.
[^] # Re: Mes idéaux
Posté par GuieA_7 (site web personnel) . Évalué à 2.
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.
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 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.
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 barmic . Évalué à 2.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mes idéaux
Posté par wilk . É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
[^] # Re: Mes idéaux
Posté par GuieA_7 (site web personnel) . É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 barmic . Évalué à 2.
En effet mais ça a fait du bruit. Quelque chose d'optionnel dans un standard ça pose de gros problèmes.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mes idéaux
Posté par JGO . Évalué à 2.
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 dave . É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 Sytoka Modon (site web personnel) . Évalué à 3.
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 GuieA_7 (site web personnel) . É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 Gui13 (site web personnel) . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à 3.
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)
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 dave . É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 wilk . É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 mdlh . É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 Blackknight (site web personnel, Mastodon) . É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
C'est le cas depuis presque 30 ans.
Même remarque qu'au-dessus, sachant en plus qu'il s'agissait du premier langage objet normalisé ANSI/ISO
Tu peux normalement compiler ton code Ada83 sans problème avec un bon vieux Gcc d'aujourd'hui.
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
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 devnewton 🍺 (site web personnel) . Évalué à 3.
Quelques questions sur l'univers Ada:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mes idéaux
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 30 janvier 2012 à 14:43.
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.
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 là). Perso, je n'ai pas essayé.
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 devnewton 🍺 (site web personnel) . Évalué à 1.
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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mes idéaux
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
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 devnewton 🍺 (site web personnel) . Évalué à 1.
Sans Maven, tu ne te serais jamais aperçu de ce conflit!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mes idéaux
Posté par Blackknight (site web personnel, Mastodon) . É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 devnewton 🍺 (site web personnel) . Évalué à 2.
C'est un bug de ce module?
http://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mes idéaux
Posté par Blackknight (site web personnel, Mastodon) . É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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mes idéaux
Posté par ckyl . É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 Blackknight (site web personnel, Mastodon) . Évalué à 1.
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é.
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.
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 ckyl . Évalué à 2.
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.
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.
J'ai du mal à voir la pertinence de la comparaison.
[^] # Re: Mes idéaux
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
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.
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 ckyl . Évalué à 4.
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.
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 Blackknight (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 30 janvier 2012 à 23:13.
Merci pour le lien, pour ça, je plussoie ton commentaire.
On est d'accord et dans ce cas, on est bien dans la gestion manuelle de la dépendance.
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.
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 devnewton 🍺 (site web personnel) . Évalué à 1.
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 :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mes idéaux
Posté par barmic . Évalué à 3.
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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mes idéaux
Posté par ckyl . Évalué à 2.
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.
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.
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 nud . Évalué à 2.
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 devnewton 🍺 (site web personnel) . Évalué à 2.
Peut être qu'ils ont compris mais avec un langage bien dynamique, le compilateur ne les prévient pas assez!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mes idéaux
Posté par wilk . Évalué à 1.
C'est surtout les ABI-tudes des utilisateurs qui ne respectent pas la compatibilité ascendante !
[^] # Re: Mes idéaux
Posté par reno . Évalué à 3.
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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mes idéaux
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 0. Dernière modification le 30 janvier 2012 à 18:17.
Voilà, t'as tout compris et heureusement pour nous, les environnements seront bientôt tous codés en Java.
Oui parce que je distribue pas les sources à ceux qui peuvent pas les installer.
[^] # Re: Mes idéaux
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mes idéaux
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
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 devnewton 🍺 (site web personnel) . Évalué à 2.
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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mes idéaux
Posté par claudex . É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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mes idéaux
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
C'est souvent juste pour aider les utilisateurs qui ne savent pas taper:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mes idéaux
Posté par claudex . Évalué à 4.
Il y a bien plus que ça dans les scripts en général.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mes idéaux
Posté par Jux (site web personnel) . É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 Blackknight (site web personnel, Mastodon) . Évalué à 1.
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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mes idéaux
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Est-ce si gênant ?
Ce serait vrai si on ne savait pas faire d'IHM au-dessus de commandes shell.
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 devnewton 🍺 (site web personnel) . Évalué à 2.
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.
Je vise le maximum d'OS, donc au moins Linux, Windows et Mac OS et plus si possible.
Les porteurs, ça court les rues, c'est bien connu!
Les interpréteurs des langages populaires sont installables facilement pour 99% des utilisateurs.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mes idéaux
Posté par CrEv (site web personnel) . Évalué à 3.
Heu... hurd ? ha non, je sais tu es en train de préparer le port pour MultiDeskOs !
[^] # Re: Mes idéaux
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 0.
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 Jux (site web personnel) . Évalué à 1.
Qt ?
[^] # Re: Mes idéaux
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 6.
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 Blackknight (site web personnel, Mastodon) . É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 Sytoka Modon (site web personnel) . É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 lendemain . Évalué à 5.
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 Sytoka Modon (site web personnel) . É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 vincent LECOQ (site web personnel) . É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 warwick . Évalué à 1.
Je plussoie et j'ajoute les regex intégrées.
[^] # Re: pour moi
Posté par Zenitram (site web personnel) . Évalué à 3.
(presque) cadeau
[^] # Re: pour moi
Posté par Anonyme . Évalué à 3. Dernière modification le 29 janvier 2012 à 13:47.
Mais c'est du C++ ! /o\
[^] # Re: pour moi
Posté par Fabimaru (site web personnel) . Évalué à 4.
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 pasScott pasForstall . É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 ckyl . É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 pasScott pasForstall . É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 Sytoka Modon (site web personnel) . É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 rewind (Mastodon) . É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 BB . Évalué à 2.
VHDL
->[]
[^] # Re: pour moi
Posté par Sytoka Modon (site web personnel) . É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 gasche . Évalué à 3.
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 rewind (Mastodon) . É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 barmic . É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é.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: pour moi
Posté par ckyl . É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 Fabimaru (site web personnel) . Évalué à 9.
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 gasche . É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 pasScott pasForstall . É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 Jux (site web personnel) . É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 pasScott pasForstall . É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 gasche . É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 pasScott pasForstall . Évalué à 0.
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.
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 gasche . Évalué à 2.
Ce n'est pas cohérent avec ce que tu disais dans ton message précédent:
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 pasScott pasForstall . É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.
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?
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 pasScott pasForstall . É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 Fabimaru (site web personnel) . É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.
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 devnewton 🍺 (site web personnel) . Évalué à 2.
Comment ça se passe sur Android où plein d'applications sont écrites en Java?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pour moi
Posté par pasScott pasForstall . É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 Zenitram (site web personnel) . Évalué à 2.
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 devnewton 🍺 (site web personnel) . É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...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pour moi
Posté par gasche . É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 Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
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 Paul . É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 pasScott pasForstall . É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 reno . É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 claudex . É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…
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Dépend de l'usage
Posté par rewind (Mastodon) . É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 BB . É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 Miguel Moquillon (site web personnel) . Évalué à 6.
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).
ç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.
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 dave . Évalué à 3. Dernière modification le 28 janvier 2012 à 18:14.
À 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 :
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 rewind (Mastodon) . Évalué à -1.
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 dave . É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 GuieA_7 (site web personnel) . Évalué à 4.
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 dave . Évalué à 0. Dernière modification le 29 janvier 2012 à 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 GuieA_7 (site web personnel) . É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 dave . Évalué à 3. Dernière modification le 30 janvier 2012 à 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 gasche . É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 barmic . Évalué à 4.
Ç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.
Tu veut dire qu'en plus OCaml est plus simple/plus maintenanble que la version C ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Hum ...
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 6.
Tu veux bien nous filer un benchmark avant de dire que le code Caml est ultra-lent ?
[^] # Re: Hum ...
Posté par Miguel Moquillon (site web personnel) . Évalué à 0.
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 barmic . Évalué à 2.
Oui mais le fonctionnel pose des problèmes dans les interactions systèmes.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Hum ...
Posté par gasche . Évalué à 6.
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 dave . Évalué à 0.
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 Perthmâd (site web personnel) . É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 gasche . É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 Miguel Moquillon (site web personnel) . É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 gasche . Évalué à 2.
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.
À 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 Miguel Moquillon (site web personnel) . É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) :
Autrement dit : la fonction applesInCart est déclaré comme étant l'ensemble des pommes dans le caddie.
En C :
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 reno . É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 gasche . É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 reno . É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 dave . Évalué à 3. Dernière modification le 29 janvier 2012 à 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 reno . Évalué à 4.
Ça tombe bien parce que pour moi, la récursion terminale n'est souvent pas un intérêt.
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?
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 Antoine . Évalué à 2.
Les langages non-fonctionnels aussi...
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 gasche . Évalué à 2. Dernière modification le 29 janvier 2012 à 19:20.
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 reno . É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
Mais pas forcément aussi performant: il faut un compilateur assez compliqué je pense pour optimiser ça..
[^] # Re: Hum ...
Posté par gasche . Évalué à 4.
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).
Pas de soucis:
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 reno . É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 gasche . Évalué à 3.
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.
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.
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):
(
zipWith (+)envoie la liste des sommes terme-à-terme de deux listes de même taille, ettailrenvoie 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 Troy McClure (site web personnel) . É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 gasche . É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 3oufac 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 BFG . Évalué à 2.
Est-il possible de faire quelque chose comme ça :
? 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 gasche . Évalué à 3. Dernière modification le 30 janvier 2012 à 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.[^] # Re: Hum ...
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 7.
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 Zylabon . É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 dave . Évalué à 0.
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 Paul . Évalué à 3.
Le tout en langage naturel bien sûr.
[^] # Re: Il n'existe pas.
Posté par dave . É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 Antoine . Évalué à 4.
Il me semble que c'était de l'ironie.
[^] # Re: Il n'existe pas.
Posté par dave . Évalué à 2. Dernière modification le 28 janvier 2012 à 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 Maclag . Évalué à 6.
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 Fabimaru (site web personnel) . É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 BB . É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 gasche . Évalué à 3.
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.
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 wilk . Évalué à 1.
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 gasche . Évalué à 3.
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 wilk . É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 Sytoka Modon (site web personnel) . É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 reno . É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 Thomas Douillard . É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 pasScott pasForstall . É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 lolop (site web personnel) . Évalué à 3.
Ça coûte quand même une pomme.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: J'aimerais
Posté par gasche . É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 pasScott pasForstall . Évalué à 1.
Ok, je la refais alors, en version complete:
AnimationBlock et CompletionBlock sont des typedefs de base, SHORT_ANIMATION un #define.
C'est en tout cas vachement plus lisible que:
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 BB . É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.
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 wilk . Évalué à 4.
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 Def . É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 Antoine . Évalué à 2.
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 Fabimaru (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 3.
Beaucoup de langages correspondent à ce que tu cherches: D, ooc, nimrod, Object Pascal, Ada...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'aimerais
Posté par reno . É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 Sytoka Modon (site web personnel) . É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 Jux (site web personnel) . Évalué à 4.
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 claudex . É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).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: J'aimerais
Posté par Littleboy . Évalué à 2.
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 Louis Roché (site web personnel) . Évalué à 2.
As tu des noms pour les outils emacs ?
[^] # Re: J'aimerais
Posté par Littleboy . Évalué à 2.
En libre: CEDET, plus search&replace a la main...
En proprio: Xrefactory
[^] # Re: J'aimerais
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
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 Sytoka Modon (site web personnel) . É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 Meku (site web personnel) . É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 gasche . É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 Sytoka Modon (site web personnel) . É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 barmic . Évalué à 4.
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 ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'aimerais
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
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.
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 :
J'adore le message de warning à la compilation :
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 là 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 là. Mais bon, c'est une norme ISO alors ça va prendre encore un peu de temps ;)
[^] # Re: J'aimerais
Posté par barmic . Évalué à 2.
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.
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++.
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 à, 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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'aimerais
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
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 !! :)
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.
C'est du complément et ça va dans la lignée du langage
[^] # Re: J'aimerais
Posté par reno . Évalué à 4.
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 Blackknight (site web personnel, Mastodon) . Évalué à 1.
Oui, c'est vrai, les interfaces pourraient jouer ce rôle-là.
[^] # Re: J'aimerais
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Oui c'est dommage parce que ça permet de faire des trucs sympas quand même
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 :
est équivalent à
[^] # Re: J'aimerais
Posté par steph1978 . Évalué à 3.
Et ça, ça fait pas l'affaire ?
# ocaml...
Posté par Obi MO (site web personnel) . É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 Kévin Guilloy . É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 karteum59 . É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 gasche . Évalué à 2.
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 Obi MO (site web personnel) . Évalué à 1.
[^] # Re: ocaml...
Posté par Kévin Guilloy . Évalué à 0.
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.
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.
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 gasche . Évalué à 2.
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:
(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.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.
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 lendemain . Évalué à 2.
Peut être scala qui a accès à toutes les lib de java.
[^] # Re: ocaml...
Posté par small_duck (site web personnel) . É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 Ontologia (site web personnel) . Évalué à 3.
Il y a un projet de OcamlPro pour pallier à cela : https://github.com/OCamlPro/ocaml-reentrant/
Tu peux peut être aider ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ocaml...
Posté par gasche . Évalué à 3. Dernière modification le 30 janvier 2012 à 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...
# Le langage ideal? ... C'est de faire le sien!
Posté par Matthieu Lemerre (site web personnel) . É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
[^] # Re: Le langage ideal? ... C'est de faire le sien!
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est linearML ?
"La première sécurité est la liberté"
# Ce que j'en pense...
Posté par Maclag . Évalué à 8.
http://xkcd.com/927/
# Le langage idéal
Posté par Meku (site web personnel) . É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 reno . É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 Guillaume D. . É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 reno . É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 MichaelMure (site web personnel) . É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 Patrick Lamaizière (site web personnel) . Évalué à 2. Dernière modification le 30 janvier 2012 à 00:11.
C'est très limité le référence counting.
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.
les pixels au peuple !
[^] # Re: Vala ?
Posté par houra . É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 houra . Évalué à 1.
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
[^] # Re: Lazarus
Posté par MichaelMure (site web personnel) . Évalué à 1.
Ça ma intrigué, du coup j'ai cherché un peu. Un message sur la mailing list des dev' sur le sujet:
https://mail.gnome.org/archives/vala-list/2010-November/msg00096.html
# Common Lisp !
Posté par Axioplase ıɥs∀ (site web personnel) . É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 Mildred (site web personnel) . Évalué à 5.
[^] # Re: L'idéal
Posté par gasche . Évalué à 6.
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 janvier 2012 à 19:17.
Et python aussi... je ne sais pas pourquoi il passe toujours à travers les gouttes dans ces discussions sur la portée lexicale.
[^] # Re: L'idéal
Posté par gasche . É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é
nonlocalcomme 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 Jean B . Évalué à 3.
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 février 2012 à 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 Jean B . Évalué à 4.
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:
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 Axioplase ıɥs∀ (site web personnel) . É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 gasche . É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 février 2012 à 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:
[^] # Re: L'idéal
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
J'évoque Common Lisp, parce que
[^] # 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 Ontologia (site web personnel) . Évalué à 5.
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
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un langage ontologique et métaphorique
Posté par gasche . É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 Ontologia (site web personnel) . Évalué à 2.
J'assume complètement le fait que le but est de faire un jouet :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un langage ontologique et métaphorique
Posté par reno . Évalué à 3.
Tu veux créer un nouveau business loto, c'est ça?
[^] # Re: Un langage ontologique et métaphorique
Posté par oao . Évalué à 2.
urbi (langage pour robotique) peut être une source d'inspiration.
Exemple :
[^] # Re: Un langage ontologique et métaphorique
Posté par Ontologia (site web personnel) . É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 :
.
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
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un langage ontologique et métaphorique
Posté par oao . É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 janvier 2012 à 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:
# Programmation Fonctionnelle
Posté par _ . Évalué à 1. Dernière modification le 30 janvier 2012 à 16:09.
É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 janvier 2012 à 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 reno . É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 gasche . É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 janvier 2012 à 15:45.
Autrement dit, il n'y a pas besoin d'ordre supérieur pour dériver des équations du style
et en tirer parti.
[^] # Re: Programmation Fonctionnelle
Posté par Axioplase ıɥs∀ (site web personnel) . É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 janvier 2012 à 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 gasche . É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 janvier 2012 à 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 Axioplase ıɥs∀ (site web personnel) . É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.
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:
et plus loin:
Donc il doit bien y avoir un rapport quelque part.
[^] # Re: Programmation Fonctionnelle
Posté par Axioplase ıɥs∀ (site web personnel) . É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 février 2012 à 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 gasche . É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/freepour obtenir un algorithme en C par exemple, on se retrouve souvent à vouloir ajouter unfreeaprès un appel terminal.Par exemple (le premier qui me vient en tête, pas forcément le meilleur) :
Si tu dois insérer des
malloc/free, la façon la plus naturelle est la suivante :(On libère seulement
gauchecardroiteest 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
gauchedans une pile de "trucs à libérer après avoir calculé le résultat final":Ç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.
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 _ . Évalué à 1. Dernière modification le 31 janvier 2012 à 17:50.
Il y a à ce propos des excellents slides de François Pottier.
[^] # Re: Programmation Fonctionnelle
Posté par Axioplase ıɥs∀ (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.