reno a écrit 3886 commentaires

Très bon exemple : je ne connais aucun numéro de téléphone des me correspondants. Ces trucs la sont dans mon répertoire, et basta.

Bah, tu es juste de mauvaise foi:
1) avec le DNS, je ne connais aucune adresse IP non plus.
2) quand il y a eu le changement de numérotation, tu as du quand même dut changer les numéros dans ton répertoire,
et bien là c'est presque pareil avec le DNS tu ne devrais pas voir la différence, mais il y aura quand même une période de transition avec des problèmes potentiels.

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

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

pourquoi un mot-clef spécial pour caster

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

que reproches-tu au case ?

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

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..

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.

Piller illégalement le noyau Linux?
Pas sûr: à moins de modifier le noyau Linux sans fournir les sources ou bien d'utiliser dans un module propriétaire les symboles en export "GPL only", tu ne pilles pas le noyau Linux puisque tu respecte la licence d'utilisation..
Et il y a des zones grises comme le pilote NVidia..

En Java, même si j'aime bien ce langage, tout est dans tout et vice-versa, et ça, ça me gêne pas mal quand même..

Bah, tu peux générer automatiquement des pseudo-header si tu veux, et puis si tu code des interfaces c'est un peu comme si tu définissais des header, non?

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..

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

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

Tu veux créer un nouveau business loto, c'est ça?

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.

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

Pas besoin de la fonction intermédiaire..

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

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

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

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

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

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

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

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

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

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

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..

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

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..

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..

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..

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..

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..

C'est un non-sens en termes d'utilisabilité.

Personnellement je trouve ta réaction assez nulles: imagines qu'on "cache" ces réglages dans un sous-menu pour paramétrage avancé, il est où le problème dans ce cas?
Je trouve aussi que faire ce genre de réglage est une perte de temps pour les développeurs, mais c'est leur choix et tant que les défauts sont bien faits et que ces réglages "avancés" ne gênent pas le réglage des paramètres normaux, ça n'est pas un problème.

La vue par colonne a été retirée : le rapport complexité induite dans le code par rapport au nombre d'utilisateurs ayant été jugé insuffisant.
Tiens, KDE évolue comme GNOME…

Bah, ils ont réécrit cette partie de Dolphin donc c'est plutôt logique qu'il y ait des fonctionnalités qui sautent, c'est pareil a chaque réécriture!

Là où ils se comporteraient comme GNOME c'est si il y a quelqu'un qui fait le portage et qu'ils l'envoient bouler "parce que ça ne correspond pas à leur vision" (cf Cinnamon).
Pour autant que je sache, c'est rarement le cas dans le projet KDE, ils ont plutôt le défaut contraire: activer par défaut des fonctionnalités qui ne sont pas prêtes techniquement: par exemple Nepomuk.

Wai, bonne idée, c'est quand que Redhat abandonne cette daube de RPM ? :)

La même année que les distrib Linux remportent le desktop.

En effet c'est un langage qui se veut sûr, donc particulièrement pertinent pour des applications critiques dont l'évolution doit fiables et maîtrisées (on prend souvent comme exemple les applications faite pour l'énergie, les banques, etc).

En effet, tout le monde souhaite avoir ce type langage (Ada), c'est vraiment frustrant que ça n'existe pas encore (Ada) un langage conçu par un groupe de gens (Ada) pour des applications critiques (Ada) dont l'évolution doit fiables et maîtrisées (Ada), mais je suis sûr que dès qu'un langage comme ça existera (Ada), ça sera un grand succès :-( :-(

J'espère que ce langage supportera la programmation par contrat (Ada 2012), un concept intéressant (Eiffel) pour améliorer la maintenabilité des programmes.

Euh tu parles de quelle industrie? Parce que ton texte est assez nébuleux: Invention du "web" par/pour les sciences --> L'industrie se l'accapare, profite et centralise --> Les scientifiques se plaignent

Les scientifiques se plaignent juste du lobbying des journaux de publications, pour le reste il y a de la place pour tout le monde..

Il à a des cas où le stylet reste assez utile, tout ce qui touche à une grande précision dans le touché (style cliquer sur un élément petit comme une barre de recherches…).

Si tu as raison qu'un stylet peut être utile pour "tout ce qui touche à une grande précision dans le touché", ton exemple est mauvais!!
Une barre de recherche sur une tablette ou un smartphone qui nécessite un stylet, c'est un symptôme d'une GUI mal foutue, conçue pour une sourie et pas adaptée pour un écran tactile.
Un bon exemple serait: pour dessiner.