Le tree classique affiche la sortie en temps réel en parcourant en DFS, mais avec eza comme avec celui-ci, c’est pénible de devoir terminer toute l’exploration avant d’obtenir l’affichage.

Quand il y a parfois un répertoire plus profond que prévu, il faut annuler puis ajouter une option d’exclusion, mais si l’affichage n’arrive qu’une fois l’exploration terminée, il faut aller chercher ce répertoire un par un..

Le format d’affichage me semble aussi meilleur sur eza… Sous Windows, c’est quand même un peu plus rapide que eza.

 

Il semblerait que les investisseurs puissent aussi apporter ce type de soutien
C'est assez surprenant

 

Apple M lol
C’est juste du RISC, non ?
Un article clairement orienté

 

L’original était

> Ask HN: Why hasn't x86 caught up with Apple M series?

mais le contenu a fini par ressembler à un résumé d’un billet de blog.

 

Qu'est-ce que vous voulez que j'en fasse...

 

J’ai lu plusieurs fois le code d’express.js après être tombé sur une interview où Evan You (créateur de Vue.js et Vite) disait que TJ Holowaychuk l’avait conçu de façon propre et élégante. Je n’ai pas réussi à en saisir toute l’architecture d’ensemble, mais j’ai eu l’impression générale que le code n’était pas complexe et qu’il ne contenait que la logique strictement nécessaire, de manière très nette.

Les commentaires sont aussi bien rédigés, donc même si le code a 10 ans, c’était pratique pour comprendre l’inférence de types ou le format des DTO.

 

J’utilise CalDAV task et ntfy pour bien organiser les notifications selon leur importance et traiter le travail accumulé en vérifiant souvent la boîte de réception des notifications, et jusqu’à présent cela fonctionne bien.

 

Si je dois upgrader la RAM du M4, autant acheter un x86 avec cet argent...

 

Apple n’oblige-t-il pas davantage les développeurs à migrer vers un environnement où ses puces fonctionnent bien, ce qui donne encore plus l’impression que les performances sont meilleures ?

 

Nos investisseurs (!) ont créé le SDK JS de notre application

Excités, nous, nous

 

Je n’aime pas mélanger deux systèmes d’exploitation. On ne sait pas quels effets de bord cela peut avoir. Je pense que chaque OS devrait être isolé dans un sandbox ou occuper à lui seul un serveur physique. En plus, j’ai déjà eu par le passé une expérience où WSL se comportait de façon étrange.

 

Le code source de Yanderedev... mdr

 

J’aimerais que vous lisiez les consignes et laissiez un commentaire en lien avec le sujet.

 

Croyez en Jésus.
L’intelligence artificielle est essentiellement une conscience artificielle.
Comme on ne sait pas pourquoi l’intelligence est de l’intelligence ni pourquoi la conscience est de la conscience, on ne peut pas la comprendre.
Si l’on savait déjà ce qui fait qu’une compréhension est une compréhension, on saurait déjà tout depuis longtemps.

 

N’offre une haute efficacité que lors de tâches spécifiques.

 

Honnêtement, je n’ai pas vraiment ressenti un écart écrasant comme le laissent entendre les benchmarks.
À l’usage, j’ai plutôt l’impression que c’est juste « un peu mieux », sans différence vraiment flagrante.
Au contraire, comme les performances des modèles se sont globalement nivelées vers le haut, j’ai aussi l’impression que les gens les comparent de manière plus stricte haha.
Au final, je pense que l’essentiel dépend du contexte d’utilisation.

Gemini a une fenêtre de contexte tellement grande qu’il semble bien adapté aux bases de code volumineuses ou au maintien d’un long contexte, tandis que Claude a pour point fort une précision de codage stable ; il suffit donc de choisir selon l’usage.

 

Y a-t-il un modèle qui, en usage réel plutôt qu’à travers des scores de benchmark en IA, offre de meilleures performances en programmation que Claude ?

 

Est-ce que je pourrais vous demander, avec précaution, pourquoi vous ne l’aimez pas ?

 

Les humains se disputent, mais les programmes non, et ils sont rationnels..