jeanas a écrit 129 commentaires

  • [^] # Re: Port GTK vers Qt

    Posté par  (site web personnel, Mastodon) . En réponse au journal Subsurface : un autre logiciel de Linus Torvalds. Évalué à 2.

    Une deuxième vidéo d'un autre développeur du projet l'explique :

    https://m.youtube.com/watch?v=ON0A1dsQOV0&pp=ygUUU3Vic3VyZmFjZSBndGsgdG8gcXQ%3D

    Il critique le manque de documentation de GTK et le fait que selon lui, les développeurs, lorsqu'on leur pose une question, réagissent en disant que ce n'est de toute façon pas comme cela qu'il faut faire. D'après lui, GTK paraît entièrement tourné vers GNOME et peu adapté aux autres applications qui voudraient l'utiliser à leur sauce (notamment sous macOS et Windows où les widgets n'ont pas une apparence native).

  • [^] # Re: AsciiDoc est le vrai nouveau LateX

    Posté par  (site web personnel, Mastodon) . En réponse au journal typst est le nouveau LaTeX. Évalué à -1.

    s/AsciiDoc/Sphinx :-)

    </troll gentil>

  • # Et Frescobaldi ?

    Posté par  (site web personnel, Mastodon) . En réponse au journal Lilypond + Frescobaldi + … (aka «En avant la musique !»). Évalué à 10.

    C'est super d'entendre parler de LilyPond sur ce site !

    (Pour info, je suis développeur actif de LilyPond.)

    Par curiosité : j'imagine que vous avez dû essayer aussi la fonction d'entrée MIDI proposée par Frescobaldi, en quoi était-elle insuffisante ? Qu'est-ce qui vous a poussé à créer cet outil perso ?

  • # Au sujet du « Ça marche du premier coup »

    Posté par  (site web personnel, Mastodon) . En réponse au journal Intégration d'une fenêtre de debug live en Rust 🦀. Évalué à 9.

    J'avoue être un peu sceptique sur le « Ça marche du premier coup », du moins si son intérêt est vu en terme de temps de débogage gagné. Car il n'y a pas de secret, pour que le programme marche du premier coup, Rust utilise des règles très strictes à la compilation, qui font que les cas oubliés potentiels ne sont pas possibles, et respecter ces règles demande un effort au moment du dialogue avec le compilateur qui consiste à lui faire comprendre que le code est valide. De ce point de vue, par rapport à un langage interprété laxiste du type de Python, on transfère simplement le temps de test et débogage initial des erreurs triviales vers du temps de développement où on « débogue » les erreurs de compilation (variables non définies ou pas encore initialisées, pas du bon type, etc.) Si on veut trouver les avantages potentiels d'un langage compilé au typage fort par rapport à un langage interprété laxiste au typage faible du type de Python, ils ne sont pas tant dans la facilité ou rapidité du développement en lui-même que dans le fait que des restrictions fortes peuvent faciliter la conservation d'un code maintenable lorsqu'il est écrit à plusieurs, et éviter les bugs triviaux qui ne se manifestent pas parce qu'on a oublié un cas dans les tests. À chacun de juger si les restrictions en question en valent la peine.

    S'il suffisait d'un typage fort et riche pour avoir un langage qui fait soudainement rêver le monde entier, on le saurait déjà, puisque c'est le cas de la famille des langages ML, avec des fonctionnalités similaires (les enums Rust sont appelées ailleurs types algébriques, les traits ressemblent aux classes de type de Haskell ou autre, etc.).

    Pour moi, le vrai intérêt de Rust est dans le fait que le langage combine des caractéristiques de langage agréable (par exemple une excellente portabilité, et une simplicité de distribution et réutilisation des modules qui me fait baver en tant que personne qui vient de passer plusieurs jours à se battre contre des build systems C++) avec des caractéristiques de langage sûr (soundness) et de langage de bas niveau adapté aux applications où la performance compte. Ce qui le rend unique, ce n'est pas tant chacune de ces caractéristiques prise isolément que leur réunion dans un même langage.