Letho a écrit 308 commentaires

Autant j'utilise toujours dnf pour les rpms, autant pour les Flatpak je trouve que Gnome Logiciels s'est quand bien bien amélioré depuis quelques versions.

L'article détaillé en anglais : https://www.quantamagazine.org/computer-scientists-invent-an-efficient-new-way-to-count-20240516/

La note de Donald Knuth : https://www-cs-faculty.stanford.edu/~knuth/papers/cvm-note.pdf

Idem que les réponses précédentes, je ne mettrais pas Copilot entre les mains d'un débutant – et je le leur interdis d'ailleurs dans mon équipe. Nous avons eu trop de mauvaises expériences de code qui, dans le meilleur des cas, tombe en marche sans que le développeur ne comprenne ce qu'il a écrit, et dans le pire ne fonctionne pas sans que le développeur ne comprenne pourquoi.

Une sorte de cousin du syndrome StackOverflow.

Après, j'aime beaucoup l'outil, et je l'utilise au quotidien. Il me fait gagner un temps fou. Mais de façon générale, je ne pense vraiment pas qu'utiliser ces générateurs de texte en dehors de son champ de compétence, donc sans la capacité à déterminer si le texte produit est valide, soit une bonne idée.

et les chara-design des jeux Dragon Quest

Et n'oublions pas Chrono Trigger… Mon enfance vient d'en prendre un coup.
Pensée à Chrono, Marle, Lucas, Frog, et tous les autres.

Oh ! Oui, donc nous sommes parfaitement d'accord. Mea culpa.

J'ai dû mal comprendre alors, c'était directement les stacks de type Jakarta EE / Spring que tu visais ? Parce que là, oui, de la factory de factory, il y en a parfois. Bien que cela évolue dans le bon sens (coucou Quarkus). Après, je reconnais volontiers que dans le monde Java, certains peuvent parfois faire preuve de design-patternite aigüe. Il est même possible que je sois passé par là ;)

Les « complexités "intelligentes" inutiles » (suringéniérie) sont, de mon expérience, beaucoup plus rare et surtout en perte de vitesse (imaginez les classiques « Java pour Entreprise™ » avec des Factory et tout dans tous les sens).

On peut vouloir tendre vers des principe de clean / hexagonal / onion architecture, sans que cela soit nécessairement de l'overengineering, hein. Tout dépend de la taille du projet.

Et puis moi, je n'ai rien contre les factories. Et j'aime bien l'inversion / injection de dépendance aussi. Voilà. Non mais. Ho.

C'est la start-up Aware qui propose ce service: grâce à une IA, elle peut avoir accès à tous vos messages. Absolument tous.

J'ai le bullshitomètre qui s'affole quelque peu. Si un système de traitement a accès aux dits messages, ce n'est pas parce que « vos supérieurs ont trouvé un moyen de glisser dans votre messagerie privée » (sic) et que pif, paf, pouf, des chocapics, mais bien parce que cette messagerie n'a jamais été privée, et que celui qui avait les clefs les a transmises à Aware.

Mais il y a « IA » dedans, alors ça fait un peu magique. ;)

Une alternative open-source serait plus que bienvenue, mais le meilleur remplaçant que j'ai pu jusque-là trouver à Google c'est Kagi. Non-libre, et payant, mais vraiment très, très efficace. Je n'ai pas utilisé d'autre moteur de recherche depuis – alors que je revenais toujours à Google avec Qwant et DuckDuckGo.

https://kagi.com/

De l'implicite, oui, on peut penser par exemple à l'inférence de type, mais cela ne rend pas pour autant le code ambigu. Avais-tu un exemple particulier en tête ?

Je suis sincèrement émerveillé par la richesse des cours proposés.
Mille fois merci.

Ça me rappelle un peu NuShell, qui fonctionne autour de l'idée de data structurée :

https://www.nushell.sh/

la Saint Église du Gritche

Ah, non. Il faut dire « Église de l'Expiation Finale ».

https://news.blizzard.com/fr-fr/diablo4/24009153/diablo-iv-sera-disponible-sur-steam-le-17-octobre

Je suis d'accord sur le fond - bien que je soie plutôt content de pouvoir chaîner des .map sur un Optional depuis Java 8 :)

Dans le même ordre d'idée, j'adorerais un équivalent standard en Java du Result<T, E> de Rust. Peu probable au vu de la sacro-sainte rétro-compatibilité.

Si tu en as le temps, cela m'intéresserait.

J'ai utilisé Window Maker lors de mes premiers émois Linuxiens – ce qui doit remonter à une RedHat 5.2. J'en garde un super souvenir.

Sur un sujet proche, quelqu'un saurait-il ce que devient le projet GNUstep ? Étoilé donnait envie il y a quelques années, mais cela semble au point mort.

C'est clairement plus qu'un simple système de messagerie, mais il y a le module Talk de Nextcloud : https://nextcloud.com/talk/

Merci de la découverte, je viens d'acheter les 5 premiers tomes 🙂

Eh bien bravo, je viens encore de commander un livre. Je ne te remercie pas.

C'est à mon sens une excellente idée, qui me trotte également dans la tête depuis quelques temps. Et en tant que dev, je serai ravi de pouvoir participer.

Simple suggestion : je vois qu'il existe deux ressources distinctes pour les représentations JSON des factures et le téléchargement du PDF. Il s'agit pourtant conceptuellement de la même ressource. Ne serait-il pas plus simple de pouvoir préciser dans le header accept le format souhaité ?

# Liste des factures en JSON
GET {apiRoot}/invoices
Accept "application/json"

# Détail d'une facture en JSON
GET {apiRoot}/invoices/{idFacture}
Accept "application/json"

# Détail d'une facture en PDF
GET {apiRoot}/invoices/{idFacture}
Accept "application/pdf"

La norme Obapi pourrait dans ce cas préciser que proposer une représentation PDF de la facture est obligatoire.

C'est ce que j'avais cru comprendre en survolant un peu de documentation. En gros, l'opérateur new renvoie en C++ un raw pointer référençant le tas, et l'idée est de ne jamais utiliser de variable intermédiaire pour ce dernier mais par convention de le passer directement au « constructeur » de smart pointer qui lui sera sur la pile ?

var foobar = std::unique_ptr(new SomeFantasticClass());

(syntaxe sans doute très très approximative)

Le smart pointer est le seul à connaître le raw pointer, et je suppose qu'il libère la mémoire quand foobar sort du scope.

J'ai bon ?

Ça ressemblerait effectivement un peu aux types Box<T> et Rc<T> en Rust (ou Arc<T>, je ne sais pas si shared_ptr est thread-safe ?)

…
…

C'est malin, je vais devoir ajouter C++ à ma liste de langages à tester.

Question sans doute naïve, mais je suis curieux :)

J'ai pratiqué un peu de Rust, mais pas de C++. De ce que j'en comprends, le principe de borrowing via & en Rust permet de libérer la mémoire de façon déterministe au moment de la compilation. Ce n'est pas le cas quand on utilise par exemple le type Arc<T>, qui fonctionne avec un compteur de référence – et donc au runtime.

Les smart pointers de C++ semblent plus proches de ce dernier cas ?

Je me suis promis d'essayer Gleam un jour prochain.

Typage statique + VM Erlang + modèle acteur. Miam.

https://gleam.run/
https://github.com/gleam-lang/gleam

Je ne l'ai jamais essayé, mais j'ai trouvé ceci :

https://age.apache.org/

C'est une extension PostGres pour faire de l'orienté graphe. Et cela gère Cypher. Deux points plutôt positifs pour toi ;)

Un article en parlant : https://www.fabiomarini.net/going-multi-model-with-postgresql-and-apache-age-experimenting-with-graph-databases/