reno a écrit 3881 commentaires

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.

Avec de bon graphismes vectoriels je vois pas où est le problème.

Bah, heureusement que tu ne crées pas des applications, la taille des icônes n'est pas le problème principal..
Personne n'a dit qu'il y avait une différence fondamentale, mais bon si tu mets une application prévu sur une tablette sur un smartphone ça risque d'être pénible a utiliser car il y aura trop de boutons sur une petite surface, donc il faut adapter l'UI, pareil dans l'autre sens: tes utilisateurs de tablettes trouveront une appli de smartphone "pauvre" car pas conçu pour un grand écran.

Dans l'articles des Inrocks il y a "Un bon administrateur réseau, quand il se prend une attaque comme ça [DDOS], n’a besoin que de quelques minutes pour réagir" et là je trouve ça très curieux comme phrase: certes si le déni de services est fait en faisant consommer des ressources à un serveur, ce n'est pas toujours trop compliquer de réagir (encore que ça dépend assez de l'attaque), mais si la bande passante de ton accès est saturé là ça peut devenir très compliquer!

OK, j'y suis peut-être aller un peu fort. Mais bon la doc de "référence" ne parle pas du sujet (quand même assez fondamental) alors j'ai quelque excuse non?

Tiens une dépêche qui parle d'ADA ?

Bah non: je doute que Rust arrive à la cheville d'Ada sur bien des sujets, un exemple: dans leur doc de "référence", ils ne parlent même pas de ce qui se passe en cas de débordement entier, je suppose que la sémantique du C/C++ est tellement imprimé chez eux qu'ils n'envisagent même pas d'avoir un autre comportement..
Pourtant avoir des entiers avec un comportement sain (big int ou exception en cas d'overflow par défaut, débrayable pour les cas ou il faut 100% des perfs du CPU) dans un langage conçu au 21ème siècle ça ne serait pas un mal..

Si je suis d'accord avec toi en gros, je pense que les GPUs ont des gros problèmes, même en local à cause de leur histoire: au départ il s'agissait d'accelerer une application (une appli de CAD ou bien un jeu), passer d'une application a plusieurs est très compliqué (surtout que ça n'est pas un gros argument pour les ventes donc la priorité est secondaire pour les vendeurs) donc même maintenant ça n'est pas terrible: je ne pense pas qu'utiliser un GPU soit compatible avec des garanties temps réels par exemple.

Bref, la 3D a l'heure actuelle c'est loin d'être mur, alors quand on rajoute du distant la dessus forcément ça ne peut qu'exacerber les problèmes..