reno a écrit 3886 commentaires

L'aspect innovant de ce point n'est pas remis en cause, je pense.

Non, mais l'utilisabilité de la chose est par contre encore en question, j'attends de voir une API de GUI en Rust..

Tu retardes l'affaire des bibliothèque standard est morte depuis longtemps.

Pourquoi le Rust plutôt que le D ? Le Rust est plus bas niveau et ne nécessite pas de ramasse-miettes

Toi tu as lu, mon message un peu vite: fait une recherche sur DasBetterC, mais bien sûr si tu utilise D sans le ramasse miette tu as les mêmes problèmes que le C/C++ au niveau gestion mémoire.

il a un système d'abstraction beaucoup plus riche, avec des "sum types", […] avec des abstractions plus agréables à utiliser.

Hum, quelle est la différence entre un "sum type" et un "Variant record" en Ada?
Pour les abstractions plus agréable a utiliser, je n'en suis pas si sûr: visiblement faire un GUI en Rust ça a l'air bien pénible.
Et je pense quand même que Rust a un ramp-up important: quand je regarde un programme Ada j'ai l'impression de comprendre tout, quand je regarde un programme Rust ça fait "soupe de caractères" bon pas autant que le Perl mais pas loin..

Mouai, c'est un peu court pourquoi Rust plutôt qu'Ada ou D?

Franchement la maturité d'Ada par rapport à celle de Rust..
Et D est probablement beaucoup + facile comme transition depuis le C++ que Rust, il y a même un mode DasBetterC qui évite d'utiliser le GC (mais qui diminue la sécurité comme le C++ et empèche l'utilisation de certaines librairies).

Je ne pense pas qu'on puisse dire que c'est un problème ARM, c'est un problème de l'embarqué "non-PC".
Si tu utilise un MIPS, un PPC, un RISC-V ou autre, tu as exactement le même problème..

Quand on pense au nombre de téléphone Android non sécurisé c'est vraiment surprenant qu'il n'y ai pas encore eu un malware qui ai affecté des millions de téléphones..

Cmake est un méta système de build donc quand tu as un problème il faut regarder les Makefile et remonter.

Si tu as besoin de la portabilité OK, mais au travail on utilise CMake alors qu'on est cible seulement Linux et là rajouter une couche supplémentaire je pense que ça complique plus la vie qu'autre chose.
En ce moment, je suis en train d'essayer de comprendre pourquoi les cibles sont compilés dans un ordre différent d'une compilation à l'autre, je galère..

Certes construire un bon GNU Makefile demande pas mal d'effort mais en partant d'un Makefile 'modèle' on y arrive (enfin il faut quand même trouver le 'bon' modèle).

Pour ce qui est de la critique "Par exemple, si j'ajoute une option qui concerne l'édition des liens, celle-ci ne sera pas refaite par défaut." et bien ajouter une dépendance qui dis que si le Makefile est + récent que les target tu refais tout ne me parait pas compliqué.

Je déteste cette mode "moderne", mais non ça n'était pas le cas: le script a remplacé les commentaires par des lignes blanches, donc il restait "l'empreinte" des commentaires..

Par "coïncidence", l'université qui a crée le projet vend du support..

Non, les 2 n'ont aucun rapport bien sûr..

Tu peux expliquer ce que tu entends par '"deforestation" quand les map/fold sont dans le langage (haskel),etc…'?

Je ne sais pas de quoi tu parles..

Il est si bien écrit qu'il m'a fait passer énormément de temps à lire les autres articles sur le blog..

Je n'utilise pas beaucoup python donc il est peu probable que je me serve de Trio mais nom de dieu qu'est ce que c'est bien conçu!
Les articles ou il explique les problèmes et les solutions possibles et celle qu'il a choisi sont vraiment intéressants..

Alors pourquoi est-ce un problème (et pourquoi le processus ferait-il comme ça plutôt que d'accéder directement à la mémoire) ? Tout simplement parce qu'un script tournant sur une VM (de type VM javascript) peut exploiter la faille pour lire n'importe où dans la mémoire du processus

Je pense que le problème n'est pas seulement pour un interpréteur: ça remet en cause la sécurité par capabilities non?

A mon avis, tes utilisateurs potentiels ne vont pas être très nombreux: les utilisateurs avancés des shells qui en ont marre des langages de shell actuels, et bien ils ont quand même leurs habitudes dans un/des langages impératifs (shells, Perl, Python) leur proposer un langage fonctionnel comme remplacement bof..

Quand je vois ton exemple avancé, tout ces 'in(' ça me pousse plutôt à être 'out'!

Ca n'est pas la première fois que je note ça, j'ai commencé à lire un livre sur OCaml et bien qu'OCaml soit sensé être un langage "mixte" fonctionnel OU impératif, l'auteur du livre ne s'intéressait qu'à l'aspect fonctionnel: je n'ai pas terminé le livre..

Désolé mais je n'ai pas gardé la référence.

Le but de la manœuvre étant de retenir le contenu des cartes et bien écrire les cartes aide à les mémoriser..

De la même manière qu'on s'est rendu compte que ceux qui écrivaient leurs notes de cours retenaient mieux le cours par rapport à ceux qui les tapaient sur un ordinateur.

Le contraire aurait été surprenant Eiffel étant un language de "haut niveau".

Je suis surpris, c'est le cas aussi en mode 'release', je m'attendais à ce que ça soit le cas uniquement en mode debug.

Quand tu vois du code avec 2 fonctions treatBCCH et treatBcch :-( :-(
Une notation qui ne fonctionne pas bien avec des acronymes est une notation de m..

Je ne sais pas pourquoi elle est si populaire.

La documentation de Nix est plutôt mal organisée donc dès qu'on sort de l'utilisation de base ça devient vite très compliqué donc bof: j'ai fini par me recompiler a la main le gcc dont j'avais besoin.

Le principe de Nix parait sympa mais l'implémentation bof: 1) la doc 2) le DSL.

GUIX parait intéressant pour résoudre (2), après est-ce que la doc est meilleure?

J'ai remplacé le HDD de mon portable par un SSD 128Go a l'époque ou ça coûtait cher la Flash et je le regrette rien que pour stocker les photos de mes enfants c'est juste.
Après Windows est + gourmand en place que Linux alors..

À ma connaissance, seuls les langages fonctionnels typés offrent cette possibilité de différencier des types structurellement identiques, autrement qu'en faisant des classes.

Hum, Ada?

1) La compatibilité avec l'historique.
2) Les MAJ qui se passent bien.

De ce point de vue là le monde Linux (sauf le noyau) n'est pas à la hauteur..

Pas avec Wayland: avec GNOME Wayland!
C'est une extension de GNOME au dessus de Wayland: si tu essaye d'utiliser ça sur un DE qui utilise un autre compositeur Wayland (KDE par exemple) ça ne marchera pas.

Oui, c'est(c'était?) le but de libweston dont je parle, mais pour autant que je sache ça n'est pas utilisé (ni par GNOME, ni par KDE).

Entre "rien n'empêche" et que dans les faits ça soit le cas..

Donc osfe a raison, ils font de l'argent en vendant les composants ET en vendant les outils de développement, curieux mélange..