anaseto a écrit 2229 commentaires

Oui, oui, on est d'accord, c'est juste qu'entre langage au typage statique et langage dynamique il y a tout un gradient, tout comme il y a un gradient dans l'aberration :)

(3) est toujours autant une aberration que quand c'était fait en Java avec Object.

C'est pas rassurant, mais « aberration »… C'est ce qui est fait pour absolument tous les objets dans les langages dynamiques. Là tu le fais juste très rarement, tu es obligé d'écrire explicitement ton assertion de type dans le code, et dispose de la possibilité de faire un wrapper sûr autour : verbeux, je te l'accorde. Je t'accorde aussi que le risque existe que les programmeurs abusent de ceci et fassent du code aberrant, pour reprendre ton terme.

C'est une faute de ne pas le faire !

Une faute, une faute, je sais pas pourquoi il faut essayer de culpabiliser les autres ^^ Ils ont fait un truc qui correspondait plus ou moins à leurs besoins, aux besoins d'autres personnes aussi, faut pas chercher beaucoup plus loin : à la base le langage est pensé par trois personnes uniquement, pas tout Google. La faute, ça serait autant aux autres, d'avoir accepté le truc tel quel. Et bon, perso je suis bien content que ce langage existe, je l'utilise juste pour quelques projets sur mon temps libre, mais ça m'a permis de pas avoir à m'inquiéter de choses comme la sérialisation (sauvegarder une structure plus ou moins quelconque se fait en quelques lignes, alors que dans d'autres langages ce n'est pas trivial), les builds, etc. et quand je reviens plusieurs mois après sur mon projet, j'ai pas l'impression d'avoir oublié la moitié du langage (bonjour Haskell et ses lentilles et flèches). Je suis content aussi que d'autres langages existent et que de meilleurs langages soient développés (système de types évolué, super outils, builds rapides, etc.). On aura peut-être tout ça en même temps un jour :)

Go aurait pu être une occasion pour un nouveau public de découvrir, c'est une occasion manquée, c'est très dommage.

Bon, soyons plus optimiste, au moins ils ont eu les lambdas depuis le début, et ils sont assez populaires et faciles à utiliser, pas comme en Java :) Là le grand public apprend les lambdas, ça prépare le terrain pour les types somme dans la prochaine décennie ;)

Les types sommes pourraient être ajoutés, on est d'accord. Mais ce pour quoi ils sont utiles est déjà couvert (en moins bien si on veut) par les constantes (enums) et les interfaces (avec assertion de type) pour le reste. Ajouter maintenant les types somme signifierait que les programmeurs auraient maintenant deux façons différentes d'écrire certains programmes. Pour les fonctions renvoyant une erreur on aurait maintenant deux signatures : celles qui font comme maintenant, et celles qui renvoient un type option. Je comprends qu'étant donné l'actuel ça ne soit pas très cohérent de les ajouter. Tu vas me dire que c'est de la complexité accidentelle que d'utiliser constantes et interfaces pour faire des sommes (disjointes si on veut, il suffit d'implémenter une interface spécifique), mais personellement je me risquerais à parier que, dans ce cas, la complexité accidentelle est moindre que celle d'étendre le langage.

Le concept de l'interface typée vérifiée par des couples (type, valeur) (en interne) est peut-être pas satisfaisant en théorie des types, mais c'est quand même très flexible pour vraiment pas cher (réflection quasi-gratuite en prime), je trouve, et une avancée par rapport à un langage purement dynamique.

Les cas simples avec les type-class sont ok, c'est sans doute plus une question de savoir les présenter (donc pas propre au langage) : parmi les première que décrivent pas mal de tutos, c'est celle des monades ; et, il me semble (mais ça fait plusieurs années que je fais pas de Haskell), que pour des choses concrètes équivalentes au Writer et Reader de Go, il faut aller chercher dans les packages. Après, le fait qu'il soit possible de faire des classes sur des types plus complexes et des concepts plus avancés n'est pas intéressant pour un langage comme Go : un principe du langage c'est qu'au bout d'une semaine tu peux lire le code de n'importe qui sans barrière de compétence sur le langage. Du coup, au mieux, ils auraient pu viser un sous-ensemble de la solution à base de type-class ; est-ce qu'en pratique le résultat aurait changé beaucoup par rapport aux interfaces ?

le Gc est largement au niveau de celui de java

En fait, j'aurais dit que c'est justement là le point où Java gagne en performance : le Gc de Go est optimisé pour la latence, tandis que celui de Java pour les performances pures. Mais je suis pas un spécialiste…

on a obtenu un truc "comme C mais avec un modèle de concurrence raisonnable et avec GC parce que c'est plus pratique". C'est juste aussi de dire qu'ils n'ont visiblement pas vraiment pris le temps de regarder ce qui s'était fait dans les autres langages pour en reprendre les bonnes idées, et que ça se voit dans le langage.

À mon avis (ou alors c'est une coïncidence) ils ont aussi regardé du côté des langages dynamiques et ont copié le côté intégrer de façon ad hoc dans le langage les tableaux dynamiques et les tables de hachages, ce qui je pense rend le langage beaucoup plus accessible aux gens venant de ces langages.

Dans le même genre d'idées, ils ont mis des choses dans le langage comme la réflection qui, bien qu'imparfaits, sont en même temps une solution simple (d'un point de vue théorique) à des choses comme la sérialisation qui me semblent être des points délicats et demandant un traitement particulier dans les langages avec système de types plus évolués que j'ai utilisés (Haskell et OCaml), même s'il y a du progrès.

Les interfaces Go (qui sont le point central à la réflection en Go) sont un mécanisme simple qui permet de faire beaucoup, même si pas autant que d'autres systèmes. En pratique, l'avantage c'est que les gens les utilisent (contrairement au type class Haskell, qui sont pas pour les débutants, ou les modules et foncteurs en OCaml, ou certains systèmes objets plus compliqués). Et on retrouve ça partout dans la librairie standard: il suffit d'implémenter String() pour un type et on peut utiliser toutes les fonctions de formattage sytle printf après, et c'est seulement un exemple (la gestion de différent types de buffers et entrées sorties utilisant une même interface commune est aussi très agréable).

Leur sémantique de package, ainsi que la possibilité de répartir dans plusieurs fichiers les éléments d'un même module, est aussi plutôt bien trouvée, même si c'est un point à la limite du langage.

Bref, Go doit au minimum un certain nombre de traits aux langages dynamiques actuels (par accident ou non), ce qui le rend très différent de C. J'ai un peu l'impression de passer ce journal à défendre ce langage, mais il me semble qu'il y a des jugements un peu trop rapides à son sujet :)

Je suis d'accord que pour eux c'était quelque chose de secondaire (même si la première version stable date de 2011) et que leur approche à la création du langage donnait clairement priorité aux problèmes concrets qu'ils voulaient résoudre, dont éviter simplement (donc sans trop avoir à innover) la complexité. Pour le GC ils ont peu plus creusé la recherche, car c'était nécessaire pour leurs priorités. C'est juste que tel que c'est mentionné dans ce fil à plusieurs reprises, on dirait qu'ils font ça volontairement juste pour ignorer la recherche, comme s'ils avaient une dent contre la recherche :)

Mais c'est sans doute juste l'effet fil de discussion linuxfr qui part dans tous les sens ;)

Ah, je passe mon temps à râler sur les défauts et les manques de OCaml, il suffit de demander (dans un message à toplevel par contre, pas perdu au milieu d'un troll sur Go). J'essaie d'améliorer les choses aussi.

Je sais bien, je suis de temps en temps ce qui se fait sur OCaml, même si j'avoue être un peu à la traîne sur les dernières nouveautés :)

Ce qui est amusant, c'est qu'on dirait que les deux on aime bien OCaml, mais qu'on a réussi a apprécier Go aussi, et parfois ça surprend (en tous cas dans ma communauté). C'est plus typique les passages Python/Ruby/Perl vers Go.

Go ignore (volontairement) les développements en langages de programmation qui ne viennent pas de ses auteurs

Peut-être simplement qu'ils connaissent mal ces développements ou qu'ils n'étaient pas sûrs de comment les intégrer à leur langage et n'avaient pas le temps d'approfondir, qu'ils ont fait des compromis, etc. Car, pour autant que j'en sais, ils sont même ouverts à la programmation générique (à ce qu'ils disent), ils n'ont juste pas vu d'approche qui leur plaise intégrée à leur langage (un des développeurs du langage a écrit 4 propositions qu'il a lui-même rejetées, alors que ça a dû lui prendre bien du temps, car il n'arrivait pas à un truc satisfaisant). Donc si tu as un lien pour justifier ce « volontairement » comme philosophie déclarée du projet, ça m'intéresse. Qu'ils donnent volontairement une priorité secondaire à ces choses par rapport au reste semble déjà plus crédible.

(C'est quand même vraiment très con d'écrire (a, err) := foo(bar), en sachant que a n'est pas défini si err est nil !)

C'est moins satisfaisant qu'un type somme, en effet. Mais j'ai du mal à en faire tout un pâté inadmissible comme toi : en tous cas, j'ai codé en Go et OCaml, et (a, err) := m'a pas causé plus de soucis que les exceptions (invisibles dans la signature) en OCaml ; en fait moins : d'accord, c'est peut-être juste parce qu'on abuse des exceptions en OCaml, donc pas propre au langage, mais on trouve cela jusque dans la librairie standard.

Je remarque que parfois les programmeurs et programmeuses rechignent à admettre des défauts de leurs langages parce qu'il y a une dimension communautaire voire marketing au choix du langage : on a besoin que les langages qu'on utilise séduisent les gens pour avoir plus d'outils et de bibliothèques, donc il faut avoir un discours positif et ne pas insister sur ses points faibles. Je pense que cette forme de subjectivité est inévitable dans certains contextes, mais elle n'a pas sa place dans le contexte de discussions sur la recherche en langage de programmation, où il faut essayer de s'exprimer au maximum de façon réaliste et précise.

En effet, mais il me semble que tu prends la chose aussi un peu trop à cœur (ou du moins ta prose en donne l'impression) pour apparaître totalement objectif aussi, car en ayant une vision trop ancrée système de types, on finit par ne voir plus que cela dans le langage ; je vois ça dans ma communauté aussi (qui est similaire à la tienne), et même si je comprends et moi aussi j'apprécie les avancées dans le domaine, j'aimerais voir plus d'auto-critique sur certains langages : par exemple Haskell suit la voit de la complexité et des pragmas à tout va, OCaml de plus en plus aussi, avec tout plein d'annotations spéciales maintenant, qu'ils finissent par ressembler au C++ et ça fait peur ; surtout qu'OCaml est un langage que j'aime bien en dehors de quelques manques et fonctions dans la librairie standard et la syntaxe, plus la couche objet qui n'est pas rentable à mon avis, et la syntaxe limitée pour la programmation impérative avec des tableaux (qui a le mérite d'exister, contrairement au cas d'Haskell).

Non, c'est vrai. On peut faire des types sommes et du filtrage de motif en restant tout à fait dans le "budget complexité" de Go, regarde la façon (pas très compliquée) dont ils sont présentés dans OCaml ou Swift par exemple.

Sur ce point, tu as très probablement raison, encore que je ne suis pas sûr que ça s'harmonise parfaitement avec le reste du langage, au sens, ça demande d'introduire une nouvelle notion, pas de changer une notion existante (les constantes en go étant déjà utilisées comme enum, le cas particulier d'utilisation le plus courant). Mais que juste ceci donne droit aux « 40 années de recherche ignorées » me semble légèrement injuste et traduire une réaction à une difficulté à appréhender qu'est-ce qui attire d'autres personnes vers un langage auquel on ne trouve soi-même rien d'intéressant, et de se rassurer intuitivement en pensant que c'est dû uniquement aux outils.

travailler sur Go serait clairement le cas (a), personnellement j'ai plutôt tendance à m'inscrire dans l'approche (b)

Ça c'est quelque chose que je comprends parfaitement, j'ai tendance à penser pareil : autant poursuivre ses idéaux, peut-être que d'autres s'en inspireront après, plutôt que de faire face à des obstacles qu'on pense vraiment évitables.

Par ailleurs, indépendamment de Go, le langage, qui n'a aucun intérêt ou presque, il y a des choses intéressantes dans Go, en particulier l'idée que finalement on peut rendre un langage bof très agréable à utiliser si on met le paquet sur les outils. C'est hors du cadre discuté dans mon journal ci-dessus, et personellement je ne comprends pas encore très bien, scientifiquement, l'articulation entre un langage de programmation et les outils qui l'entourent.

Eh bien en pratique il me semble que c'est quand même un lien à ne pas négliger, même si scientifiquement on n'arrive pas à le définir facilement. Et, autant d'un point de vue théorique il n'y a rien ou presque d'innovant dans Go, d'un point de vue humain, les choix faits sont intéressants à mon avis : ce n'est pas qu'une question d'outils, le succès de ce langage, c'est aussi (et peut-être surtout) une question d'approche par la simplicité (au risque d'être simpliste parfois), optique qui n'est pas du tout à la mode et qui manquait visiblement à pas mal de monde ; je pense que des langages avec des systèmes de types plus évolués pourraient essayer de s'en inspirer un peu.

Je pense que ces choses font, au contraire, qu'avoir une sémantique formelle du langage serait probablement plus facile que pour d'autres langages avec plus de fonctionnalités, si on exclut la concurrence, justement.

Et je trouve simplificateur le typique « ignore complètement les 40 dernières années de recherche » dont est souvent victime Go : il se trouve juste que c'est un langage qui avait des objectifs assez précis et qu'ils pèsent vraiment le coût de l'accessibilité et simplicité pour les problèmes courants au moment d'introduire quelque chose dans le langage, et puis ils font la balance avec le reste ; que les choix faits ne plaisent pas à la communauté prisant les systèmes de types complexes et expressifs, avec le choix par exemple plutôt de leurs interfaces implémentées implicitement, approche relativement peu commune parmi les langages, c'est autre chose, mais pas de l'ignorance : tout choix a un coût.

Go attire les utilisateurs de langages dynamiques : accessible (typage simple), plus sûr (interface{} occasionnellement ça leur fait pas peur : dans un langage dynamique il n'y a que ça et c'est même pire, car Go au moins force à être explicite au moment de l'assertion de type), rapide (typage statique), builds rapides (permis par les choix au niveau langage), etc.

Et je dis tout ça en tant que personne qui s'amuse souvent à faire du Coq aussi.

En effet, une sémantique formelle simple et des preuves mécaniques simples ça ne veut pas forcément dire intuitives pour l'humain : il suffit d'avoir un peu utilisé un assistant de preuve comme Coq pour s'apercevoir que notre vision du simple et du compliqué est souvent en désacord avec celle de la machine. Ceci dit, je dirais quand même qu'en pratique, dans le doute, viser une sémantique formelle simple et adaptée raisonnements formels a des chances d'aider à obtenir un langage plus simple pour l'humain aussi (l'idéal étant d'avoir les deux); et puis je dirais rajouter des irrégularités que lorsqu'on a une bonne raison, comme par exemple viser à être moins général et utiliser une solution plus ad hoc lorsque c'est plus raisonnable d'un point de vue humain.

D'abord merci pour ce journal intéressant.

Par rapport aux qualités, un point peut-être à mentionner, c'est le cadre d'application d'un langage, qui doit donc être concis, clair, cohérent etc. pour ce quoi il est prévu, mais du coup ça peut beaucoup varier, et c'est parfois difficile d'avoir toutes ces qualités en même temps. Il faut donc faire des compromis qui dépendent du champ d'application du langage et du public visé.

Et par rapport à la co-évolution, je suis d'accord que c'est quelque chose qui est très souhaitable. J'y rajouterais aussi l'importance d'essayer d'avoir des retours par les potentiels utilisateurs en utilisant dans la mesure du possible un échantillon varié du public visé, avec différents degrés de compétence, parce que ça peut mettre en évidence des points obscurs qui autrement passent inaperçus. Je trouve par exemple intéressant l'approche incrémentale de rust, qui essaie à la fois d'attirer les formalisations et les programmeurs, tout en s'inquiétant de l'accessibilité (même si clairement il y a du progrès à faire encore sur certains points, par exemple concernant les temps de vie des variables, il me semble, mais j'ai pas beaucoup testé le langage).

Ça peut paraître surprenant, d'autant plus que, même si à peu près tout le monde est d'accord pour l'existence d'un embargo et essayer de prévenir les autres « gentils », c'est plus du tout le cas sur leur longueur, et le système n'est pas parfait.

Parce que plus l'embargo est long, plus il y a des chances qu'il y ait une fuite et que cette fuite puisse être mise à profit sur une longue durée. Et suivant les cas il y a probablement des acteurs qui ne seront pas prévenus parce que trop petits ou pas assez connus, donc la philosophie c'est de faire ce qui est mieux pour la majorité, au potentiel détriment des minorités, qui est une philosophie qui se défend, mais n'est pas universelle non plus.

Et clairement, en fonction des acteurs, un embargo plus ou moins long est plus ou moins pertinent. Pour des logiciels libres, il y a de bonnes chances que les correctifs soient prêts très rapidement et que donc un embargo tout petit suffise aux distributions et, moins de temps on laisse aux potentielles fuites après que les correctifs soient prêts à être distribués, mieux c'est, donc en général l'intérêt d'un embargo long, c'est plutôt pour les gros vendeurs qui, certes représentent beaucoup de clients. Et aussi pour les chercheurs, pour donner plus de médiatisation à leur découverte. Bref, l'intérêt d'un embargo long est varié et inégal et dépend aussi du type de faille, donc s'étonner de ces choses est pour le moins très compréhensible.

Plus de détails dans ce commentaire par un développeur. En gros, l'embargo a été étendu : OpenBSD a respecté le premier délai d'un mois, mais pas l'extension après mettre au courant CERT et donc (d'après le commentaire) les agences gouvernementales des US.

J'ai hâte de voir la gueule de la mobilité professionnelle quand une ville sera prise d'assaut par des spéculateurs immobilier.

C'est ce qui arrivera s'il devient possible d'acheter et vendre un bien immobilier sans frais.

Perso, j'ai jamais compris comment c'est possible qu'on en soit venu à ce que l'immobilier, un produit de nécessité dont il y a largement de l'offre, soit devenu un produit de luxe. Une taxe plus utile que les actuelles serait la suivante: personne ne paie d'impôts pour un premier logement, pour deux logements tu commences à payer une taxe, pour trois logements le double de cette taxe, pour quatre logements le double du double, etc. Comme ça les riches et les spéculateurs auraient grand max quelques logements, et pas des milliers voire dizaine de milliers comme c'est le cas aujourd'hui, ils ne risqueraient pas de réussir à spéculer de façon significative pour la société.

J'ai oublié de commenter ce point :

generation procedurale (choix qui permets la rejouabilite et un dev plus "simple", moins artistique) donc drops aleatoires et combats interessants trop peu frequents…

En fait, génération procédurale ne signifie pas aléatoire à 100% (ou alors, c'est mal fait). Dans Boohu, c'est semi-aléatoire pour les drops : dans toutes les parties, on trouvera presque toujours une armure légère, un chain mail, etc., à des niveaux similaires, avec un peu de variations pour épicer un peu la chose : ainsi des fois on est content (j'ai trouvé telle armure avant d'habitude !) ou triste (Rââh, quand est-ce que je trouve une bonne arme !), mais c'est contrôlé. Le nombre de périssables qui apparaissent a une variabilité contrôlée aussi, tout comme les bâtons magiques (pas plus de trois par partie, et en général vers la profondeur 9 on a trouvé les trois, sauf si on a dû fuir à un moment, et du coup on peut se retrouver avec moins et le challenge, c'est de survivre même si tout ne tourne pas rond).

Sans génération procédurale, le joueur chevronné connait par cœur les cartes et on perd le côté surprise et exploration.

D'ailleurs, une différence entre ToME4 et d'autres roguelikes comme DCSS et Boohu, c'est qu'en ToME4, ce qui est dangereux, c'est les boss, et le reste, c'est pour faire des pauses entre chaque boss. Dans Boohu il n'y a même pas le concept de boss (juste parfois certains groupes spéciaux de monstres normaux), et dans DCSS, bien qu'il y ait des uniques, ils sont moins dangereux que bien des monstres normaux du jeux.

A priori, le tiens sera plutot comme les autres… a verifier.

Si dans les autres il y a DCSS, alors oui, mais en plus simple vu que Boohu va plus à l'essentiel (car jeu court), en sacrifiant je dirais encore plus le scénario, mais en gagnant en accessibilité aussi, du coup. Si dans les autres il y a juste Nethack et des variantes, ou Angband, alors tu risques de trouver ça différent.

des tuiles, et pas juste des pâtés graphiques

Je te conseille de regarder l'art Unicode de Brogue, ou Cogmind (pas libre), pour voir que l'Unicode, c'est pas forcément moche, et on peut même faire des effets avec. Et dans tous les cas, ça restera plus élaboré qu'un simple jeu d'échecs à deux couleurs.

une vraie ihm post-80

DCSS, Brogue et beaucoup de roguelikes récents sont totalement utilisables à la souris. C'est pas le cas du jeune Boohu, par contre, parce que ça prend du temps ces trucs.

un background réel que l'on remarque des le debut du jeu, et qui s'etoffe quand on decouvre le jeu

J'en ai déjà parlé dans mon autre commentaire, mais oui, la plupart des roguelikes visent à offrir une expérience qui n'est pas ralentie par des scénarios élaborés (il y a quelques exceptions il me semble, mais c'est pas quelque chose qui m'attire, pour ça il y a les RPGs).

le systeme de potions et parchemins, qui existe en fait sous la forme des runes et infusions a cooldown, epargnant au joueur le grind.

Bien, j'en déduis qu'effectivement tu n'as pas dû jouer à DCSS. Dans DCSS, et Boohu hérite ceci, il y a des mécanismes pour éviter le grind, et plus évolués que dans ToME : c'est même très difficile de faire du grind d'XP dans DCSS (ou de quoi que ce soit), contrairement à ToME, où on a tout intérêt à visiter tous les coins avant d'aller vers les zones plus dangereuses. Boohu évite carrément ces problèmes par divers mécanismes : pas de nouveaux monstres ou objets après génération de la carte, pas d'escalier pour revenir à la carte précédente, plus quelques mécanismes anti-scumming qui empêchent de rester trop longtemps sans combattre ou explorer de nouvelles cases. La taverne de DCSS est une mine d'informations sur le design anti-scumming et l'art de faire un jeu amusant même pour le joueur optimal (je conseille d'ailleurs cette vidéo d'un des développeurs de DCSS sur le sujet), et sur laquelle j'ai passé beaucoup de temps à lire.

L'avantage, c'est qu'on conserve les choix stratégiques et tactiques du type « j'utilise la potion, ou bien je prends des risques ? », qui dans ToME4 ne sont pas présents (pas de stratégie, juste de la tactique, et ça finit avec un mécanisme de régénération pas très bien équilibré où tu passes tout ton combat en train de te souvenir qu'il faut le réactiver régulièrement). Dans ToME4 on ne fait que progresser, alors que dans DCSS et Boohu on utilise des ressources, avec le risque d'en venir à bout, donc pas 5 fois par combat, et à mon avis c'est quelque choses qui contribue beaucoup à l'immersion. Dans DCSS (et Boohu), il n'y a pas qu'un seul mécanisme, et chacun a des influences très différentes dans le gameplay : potions (à consommer une fois), magie dans Crawl (utilise le mana), abiletés dans Crawl (l'utilisation est limité de diverses façons suivant les cas de façon réfléchie), et bâtons magiques dans Boohu (limités à la fois par mana et un nombre de charges qui se recharge — partiellement aléatoirement, et c'est important — quand on descend un escalier).

La difficulté mal dosée: dur jusqu'au level 14, simple de 24 jusqu'a l'autre continent (hors dongeons de la forteresse). Je n'ai pas vraiment joue en normal, je m'y ennuye. Au final, pas mal de mes morts sont liées a l'ennui, pas assez de boss intéressants a combattre (MAIS j'aime bien me faire les dragons de la salle de la mort, j'avoue).

C'est bien mon impression aussi : 95% ou plus de combats sans danger, et de temps en temps faut se réveiller (d'où le risque de s'être un peu endormi, qui correspond aussi aux fois où je suis mort en jouant à ce jeu).

La principale difference de gameplay, c'est le temps reel.

Alors, oui, il y a souvent des débats sur ça, les amateurs de roguelikes classiques les appellent souvent des roguelikelike ou roguelites (il y en a plusieurs dans le graphe), les autres les appellent des roguelikes (souvent sans avoir jamais joué à un roguelike classique). Mais oui, un roguelike classique, c'est normalement un jeu au tour par tour. Mais bon, c'est pas très grave et, d'un certain côté, ça fait parfois découvrir les roguelikes au tour par tour à ceux qui ont uniquement joué à des roguelikes temps-réel.

Quant a ta definition… zut, on n'est plus dredi… elle confirme une impression que j'ai souvent eue: 90% des roguelikes se cachent derriere un elitisme (le joueur averti sait que l'@ est un dragon et non un rat, c'est parce qu'il est un vrai, celui qui ne sais pas est un neophyte, c'est pour ca qu'il n'aime pas ce jeu magnifique) pour expliquer l'absence totale de reflexion sur l'interface: on prend un jeu des annees 70 et on refait la meme, en changeant un peu les textes explicatifs.

Alors, déjà, il y a un peu d'humour dans la définition, je crois :) Et puis, je sais que tu trolles un peu exprès, mais tu simplifies un peu trop, en fait : l'interface a souvent beaucoup évolué depuis les années 70, et a fait l'objet de pas mal d'efforts dans beaucoup de roguelikes, même en dehors du simple ASCII vs Unicode vs tuiles. Par exemple, dans DCSS, l'interface est extrêmement pratique et fonctionnelle. On y trouve de l'exploration automatique avec sélection de zones à éviter, et d'ailleurs même Boohu aussi fait ça, en un peu plus simple pour le moment, alors qu'en jouant à ToME4 j'ai souvent été marqué par l'absence de ceci. Et dans DCSS tu as un mécanisme pour voyager rapidement dans n'importe quelle région visitée, chercher des objets, des shops, etc. avec des regexps. Et puis bon, DCSS est beaucoup plus qualitatif dans les stats etc, ça fait moins peur que les nombres en ToME4 et c'est plus facile à l'œil de décider si tel ou tel objet est meilleur. Et entre DCSS et ToME4, je trouve que les tuiles du second ont beau être un peu plus détaillées que celles du premier, elles sont moins fonctionnelles : j'ai plus de mal à distinguer les monstres, surtout que dans ToME4 chaque monstre a des variations énormes d'XP, etc, donc voir le monstre ne suffit pas à estimer sa dangerosité : même tuile pour des monstres au fond très différents.

Honnêtement, même le tout jeune Boohu, avec son interface Unicode sans tuiles qui peut faire peur, est au fond beaucoup plus accessible d'un point de vue UI que les premiers roguelikes. Le nombre de raccourcis est assez petit (rentre largement dans un seul écran sans scroller), on a de l'aide contextuelle à n'importe quel moment sur ceux-ci avec '?', et presque tout dans le jeu fait dans le qualitatif (pas comme ToME4) et dans la transparence d'informations (contrairement à Nethack). Il y a donc juste le minimum nécessaire de nombres, mais par contre on a par exemple un Critical HP Warning (calculé en fonction du monstre qui attaque) qui demande de presser espace et qui évite de mourir bêtement lorsque les points de vie deviennent trop bas, on a aussi une simplification de gestion d'inventaire (pas plus d'une arme à la fois), on a des informations simples sur les monstres, etc. Par contre, ce qui manque probablement a Boohu, c'est un petit guide de survie, parce que je pense qu'un débutant n'a pas les bonnes idées, il va approcher ça comme un RPG temps-réel plutôt qu'un jeu de réflexion par tour, et ça ne marche pas :)

Enfin, de manière générale, le débat Unicode vs graphisme moderne, c'est un peu comme faire un débat entre livre et films, ça n'a pas beaucoup de sens, c'est deux moyens de communication différents, l'un privilégiant l'imagination (d'où la définition du «@ D») et l'autre l'attrait visuel, mais les deux peuvent être fonctionnels.

Pour l'absence de scénario élaboré en général, il y a une raison : les roguelikes font partie de ces jeux qui en général sont faits par leur auteur pour s'amuser eux-même, pas seulement en le créant, mais en jouant ! Et un jeu qui dépend trop d'un scénario pour être amusant l'est plus difficilement si tu le connais déjà par cœur. Un roguelike qui va a l'essentiel, par contre, c'est un peu comme un jeu d'échecs, le go, etc., mais avec un côté plus sympathique (pour moi), une interface plus colorée — Boohu utilise 16 couleurs et pas 2 comme les échecs :) — et moins exact : il s'agit de savoir évaluer des situations et leur risque et de s'adapter quand ça tourne mal.

Joli arbre !

Pour ma part, mon roguelike préféré est sans conteste Pixel Dungeon, facile à prendre en main, équilibré, vraiment très prenant.

J'avais déjà lu quelque part que Pixel Dungeon était inspiré de Brogue, et ton arbre confirme, du coup, j'imagine bien que c'est sympa :) Maintenant que je vois qu'il y a une version libre (pas très à jour peut-être), ça me donne envie d'essayer. Par contre pas d'instructions d'installation, on dirait, va falloir regarder ça à tête reposée.

Cette idée m'a l'air pas mal !

Bon, finalement j'ai mis des '?' sur la limite (je sais pas si c'est idéal comme caractère, mais au moins on comprend :) ), et j'ai enlevé les caractères de bloc en dehors.

C'est parce que j'ai renversé le paradigme. J'ai laissé vide les endroits explorés et j'ai rempli tous ceux qui ne l'étaient pas. Je trouve que ça plus léger (plus facile à lire pour moi).

L'inconvénient c'est que les points, c'est quand même pratique pour estimer la distance à l'œil nu et calculer le nombre de tours avant qu'un monstre se retrouve à côté. Après, je suis pas totalement convaincu par le système où je fais les deux non plus, je vais tester pendant un temps pour voir.

Oui, la zone de limite d'exploration, ça montre les endroits où on est passé sans tout voir. Exemples avec Bold
(d'après mon expérience, la sortie réussit régulièrement se cacher derrière un trou, mais j'attire murphy)

Cette idée m'a l'air pas mal !