Andréas Livet a écrit 240 commentaires

C'est justement la raison d'être de l'association "Vélo Solaire Pour Tous".

Nous ne cherchons pas qu'à faire de la R&D collaborative, mais bien aussi de s'occuper de ces problèmes administratifs que bien des artisans ne veulent et ne peuvent pas s'occuper (à juste titre).

C'est une charge trop importante pour une petite structure et ça prend un temps fou.

A VSPT, comme on est nombreux et qu'on a des fonds pour (on a gagné l'eXtrême Défi l'an dernière, 30000€), on engage sereinement cette démarche.

Et puis qui (ou quelle structure) en assumera les coûts(*) et les responsabilités induites (allô le SAV, les assureurs, les juristes …).

L'idée c'est de s'assurer que le vhélio respecte bien tous les critères de la certification, puis d'en faire certifié un modèle par un laboratoire indépendant.

Ensuite, les entreprises qui voudront en fabriquer devront le faire en respectant les process et plans fournit par l'association.

Après, les questions d'assurances et de responsabilités sont complexes et bien souvent, un assureur va chercher à "diluer" la responsabilité sur plusieurs personnes/structures.

Mais, si on a des documents qui attestent qu'on a certifier le vhélio, on pourra plus difficilement se retourner contre l'association.

Pour moi, il y a vraiment un problème avec le décompte des morts. Tu écris :

Tu nous parles de virulence, mais tu ne nous donnes aucun chiffre. C'est pourtant pas bien compliqué, ils sont disponibles sur le site de Santé Publique France : le Covid, c'est 167642 décès en France au moment où je rédige ce journal.

Déjà, ce sont des chiffres pris sur plus d'une année. Normalement, quand on compte la mortalité, on le fait rarement de manière cumulative.

Après, le souci c'est justement ça :

Alors, certes, on peut contester la méthodologie de Santé Publique France : ils reçoivent tous les certificats de décès de France, et s'il y a indiqué "Covid-19" dans le champ "Cause du décès", c'est comptabilisé. C'est aussi comme ça qu'on compte les décès par cancer, par accident de la route, par maladie cardiovasculaire…

Dans le cas d'un cancer, d'un accident de la route ou autre, la cause du décès est évidente. Dans le cas du covid, elle a semble-t-il été mise de manière assez importante, même s'il n'y avait qu'une suspicion de covid.

Pierre Chaillot décrit en détail dans son livre, ses articles et ses vidéos, le problème du décompte, le fait que les hopitaux ont eu tendance à catégoriser les personnes "covid" simplement parce que c'était mieux remboursé (problème de la tarification à l'acte).

De plus, c'est vrai que dit comme ça, même 100 000 morts ça fait beaucoup et si on le compare aux 3-4000 morts sur les routes, on peut se dire :

Le Covid, c'est 15 fois plus, et on a un moyen simple de réduire drastiquement sa sévérité. Quel gouvernant responsable ne le saisirait pas ?

Le problème c'est que ce n'est pas comparable. Dans le cas du covid on a la plupart du temps affaire à des personnes en fin de vie ou dont la cause du décès est difficilement directement imputable au covid.

Enfin, même si tout le monde dit le contraire, je ne vois pas de moyen simple de "réduire drastiquement sa sévérité" (si on est dans l'hypothèse que c'est sévère)…

Il y a énormément de choses qui rendent malade et tuent des gens à travers le monde, la plupart sont liées aux activités humaines dont l'origine est bien connu (pollution de l'air, des sols, de l'eau etc.). Pourquoi avoir déployé tant d'efforts sur une cause de mortalité probable et pourquoi faire si peu pour les autres. Je crois que c'est cet élément qui m'a le plus choqué avec la crise du covid.

Il va y en avoir de plus en plus, donc y a des chances qu'un jour il y en ai un vers chez toi. Faut suivre la page du forum pointée à la fin de la dépêche ;).

Non ce n'est pas possible pour l'instant, vu que le vhélio n'est pas encore certifié.

Une entreprise qui le vendrait prendrait un grand risque, car en cas d'accident son assurance ne le couvrirait pas.

La certification est prévue pour la fin 2024, donc il y a des chances que l'on puisse en acheter un dès 2025 !

Merci pour le commentaire.
C'est vrai que je ne suis pas allé dans les caractéristiques techniques du vhélio et que je n'ai pas parlé du prix de revient (vu qu'on ne peut que se le monter soit-même aujourd'hui).

Tu pourra trouver tous les tarifs dans le document "Configuration et tarifs V1.0.0.pdf" qui se trouve sur cette page.

En gros ça va de 2600€ la version basique (sans moteur) à 7240€ la version intégrale.

Dans le fichier "3 - Liste des pièces et fournisseurs V1.0.0.xlsm" tu trouveras toutes les infos sur les pièces.

Je ne connaissais pas ce papier et je vais m'empresser de le lire, j'aime beaucoup l'approche pédagogique du constructionnisme, je m'en inspire beaucoup.

Cela m'intéresse d'autant plus que j'ai mis au point il y a quelques années un jeu de société plateau inspiré de Scratch. En gros, c'est une sorte de scratch mais version papier :).

Ça fait des années que je veux en parler sur linuxfr, je ferai peut-être un petit article dessus.

Merci pour la découverte, je ne connaissais pas ce langage !

alors qu'un langage supportant le RAII n'aurait libéré le lock que quand guard n'est effectivement plus référencé, c'est à dire à la fin de la fonction main !

Hum, oui mais en Zig tu ne l'aurai pas codé comme ça. Vu que Zig n'a pas de notion de destructeur, t'es obligé de mettre ton defer (et le unlock) dans le main (c'est d'ailleurs ce qu'il fait dans le post reddit que tu as cité).

Et puisque maintenant c'est Vendredi, je vous laisse avec la justification pour fermer l'issue pour faire du vrai RAII en Zig ;-)

La proposition du mot clé clean est intéressante, après je ne sais pas si ça rentre dans la philosophie du langage car ça masque le fait que ça va appeler une fonction, puis tu pourrai toujours oublié d'appeler clean.
Mais c'est moins verbeux que ce qui est pratiqué aujourd'hui.

Je comprends la volonté du/des créateurs de Zig d'être très conservateurs sur ce qui rentre ou pas dans le langage. Après, je trouve que cette gestion de la mémoire avec allocateur explicite est trop lourde dans bien des cas, c'est pourquoi je réserverai Zig pour de l'embarqué, de la programmation système ou des librairies qui ont besoin d'être très optimisées (genre librairie standard d'un langage, ce que fait Bun ou Roc).

Merci pour ce commentaire pertinent.

Je connais mal Rust (j'en ai fait un tout petit peu), mais je croyais qu'il contenait des mécanismes plus poussés pour le parallélisme.
Dans mon souvenir, un des auteurs de Rust disait l'avoir créer justement car c'était difficile d'écrire du code parallèle fiable en C++.

Si je comprends bien, avec Rust on a une garantie de fiabilité, mais pas plus d'outil que ça pour écrire facilement du code parallèle.

J'ai beaucoup entendu parlé de lib comme tokio et les retours que j'ai pu avoir c'est que c'est très puissant, mais difficile à appréhender.

L’installation (compilation) se poursuit sans problèmes et le temps dependent de la performance du système , j’ai essayé :

Il faut savoir que la compilation du binaire v se fait via gcc par défaut. En revanche la compilation des binaire issue de fichier écrit en v via la commande v ou v run se fait par défaut avec tcc et est extrêmement rapide. Le fait que tout le code se retrouve dans un fichier .c doit aider un peu je pense.

a.p.d. La version 0.4.0 les annotations sont balisées différemment ( par @[] )

Tu veux dire les attributs (genre [inline] etc.) non ?
Je viens de le voir dans la release note, dommage que la doc ne soit pas mise à jour en conséquence. Bon en même temps c'est en 0.4.1 qui est sortie la semaine dernière.

Je suis aussi assez enthousiaste par rapport à ce langage.

Par difference au C, les macros sont matérialisés par du code écrit en V, qui est interprété au pas de compilation.

C'est un des aspect du langage que je n'aborde pas dans la dépêche, mais il est en effet possible d'avoir du code qui s'exécute à la compilation, un peu à l'instar de comptime en Zig mais beaucoup moins générique. Ça reste néanmoins un outil de méta programmation assez puissant et un moyen de remplacer l'usage des maccros dans certains cas (cross compilation). La notion de file embedded est particulièrement intéressante je trouve. Voir la doc à ce sujet. Ce qui est marrant c'est que Zig a exclus cette possibilité dans comptime, car ce n'est pas cross platform.

le projet est financé

As-tu des informations la dessus ? J'ai l'impression que la situation est moins claire que pour d'autres projets qui sont sous l'égide de fondation par exemple.

Mais le projet se questionne sur ce qui semble une bonne idée pour créer de l'adoption mais pourrait les freiner dans le développement d'une toolchain plus efficace pour le langage lui-même.

Je ne savais pas qu'ils souhaitaient à long terme se défaire de LLVM. C'est un noble objectif et en même temps super ambitieux !
Ils ont l'air d'être déterminé et j'ai hâte de voir ce que ça peut donner.

Pour moi Rust est juste mieux quand on veut de la performance, il permet de tout optimiser:

Je ne comprend en quoi Rust est plus performant concernant l'allocation mémoire ?
Ni en quoi les macros de Rust sont plus efficaces que le comptime de Zig.

Pour moi, l'intérêt principal de Rust reste la garantie qu'il n'y aura pas de problème avec la mémoire (fuite etc.), mais niveau perf, ce sont deux langages qui permettent d'avoir des performances similaires.

Peut-être même que Zig encourage des façon de coder plus adaptés à la performance, comme le "Data Oriented Design", notamment avec des sucres syntaxiques pour pouvoir facilement boucler sur des structures de tableaux.

En tout cas, Zig est réputé pour permettre d'écrire du code extrêmement performant.

Zig a déjà des mécanismes permettant de détecter les fuites de mémoire (sauf en ReleaseFast), mais c'est vrai que le principe de RAII est intéressant.

ça s'implémente bien en C++ car il y a cette notion de destructeur. Dans un langage comme Zig, il faudrait trouver un moyen d'associer une fonction à une structure de donnée qu'on alloue.

Après, comme tu le dis, ça pourrait passé par une sorte de "super defer" ou peut-être justement par les allocateurs ?
Comme on passe l'allocateur, on pourrait peut-être préciser si la mémoire doit être libérée à la sortie du scope ? Bon dans tous les cas, tu pourrai oublié d'utiliser cet allocateur.

De ce que j'avais compris des premières présentation de Zig, Andrew semblait avoir des idées pour améliorer la gestion de la mémoire. Le langage est encore jeune, peut-être que ce genre de changement est encore possible ? Ça a peut-être été proposé (j'ai pas regardé) ?

Et bah voilà !

J'ai codé ça rapidement, j'utilise une petite bidouille avec le raw mode du module readline, mais ça fonctionne.

J'essaierai de voir si je peux pas faire plus simple au niveau de la récupération des inputs et du mode raw.

Pas encore pris le temps d'en faire un journal, mais ça va venir.

Merci pour cette dépêche !

Plus je lis sur Zig et plus j'aime ce langage.
Je ne l'utiliserai certainement pas pour tous les usages, mais quand on fait de l'embarqué ou du système, c'est vraiment chouette.

Le système de build intégré au langage est au début assez déroutant, mais l'idée de pouvoir tout faire dans le même langage et avec un seul binaire est vraiment séduisante.

J'apprécie aussi particulièrement la possibilité de pouvoir utiliser une bibliothèque C par un simple @cImport
J'adore ce petit exemple, qui montre que Zig est plus lisible que C même en appelant des bibliothèques C. Bref, c'est un meilleur C, comme le dit son auteur.

Le comptime aussi c'est juste magique, je n'ai pas encore trop joué avec, mais ça donne plein d'idées. J'avais été impressionné par le code de print présenté dans la doc. Ça vaut le coup de passer un peu de temps pour comprendre une telle fonction.
Ce qui est fou c'est que comptime permet de faire de la généricité sans rien ajouter au langage !

Il y a plein d'autres aspects à explorer comme la gestion "sécurisée" des pointeurs.

Il y a aussi plein de conf intéressantes à voir sur le sujet, notamment celle sur le recodage de la libC, malheureusement je n'arrive pas remettre la main dessus, peut-être que c'était pas ça le titre…

Bref, c'est un beau projet qui a de beaux jours devant lui.

En lisant un peu plus sur l'historique de Go, ça semble même venir du langage Newsqueak de Rob Pike

Merci pour la découverte (ou peut-être redécouverte je ne sais plus :)) de ce langage.
Souvent, les bonnes idées viennent de langages académiques qui n'ont pas percés (par exemple la notion de channel de Go vient de Limbo il me semble).

Ça donne du code plutôt verbeux j'en conviens, mais tout est explicite. Et le fait que ça ne soit pas une feature de la syntaxe du langage fait une feature de moins à apprendre.

Ce point est à mon avis important.

La force de Go est d'être épuré au maximum (je crois qu'il n'y a que 18 mots clés) et donc de reduire au maximum l'effort cognitif pour appréhender le langage : pas trop de nouveaux concepts (bon, les coroutines et les channels c'est déjà pas mal) et un syntaxe claire et explicite.

Là où V se démarque, c'est justement dans ces petits choix syntaxiques qui apportent beaucoup de fluidités à l'écriture. Alors c'est vrai, c'est pas toujours très explicite (les variables "magiques" it, err etc.), mais ça rend le code assez léger.

Il y a un aspect moins formel que l'on retrouve généralement plus dans des langages comme python et javascript. Je viens personnellement du C++ à la base et j'ai rapidement été écœuré par le côté ésotérique de la syntaxe et les lenteurs de compilation, puis après j'ai plus codé dans des langages de scripts et ce qui m'écœure aujourd'hui c'est le manque de compilation en amont, le typage faible.

V tente de continué dans la lancé de Go, tout en allant peut-être plus loin dans l’expressivité du code et j'aime bien le résultat.

Après, je code "peu" en V, je lis beaucoup dessus, suit son développement de près, mais ça reste au stade d'expérimentation. Je comprends à 100% que l'on ne veuille pas s'y mettre.

PS : je suis allé voir la gestion des erreurs en zig, c'est de l'implicite couplé à la gestion implicite des optional, ça me file la nausée ^

Ah c'est assez étonnant comme remarque, car Zig est justement connu pour être explicite. Dans ce sens où il n'y a pas d'appel de fonction caché, pas d'allocation implicite.
Je trouve le choix d'intégré la gestion d'erreur comme un élément de la syntaxe plutôt judicieux. Cela limite la verbosité du code et rend la gestion d'erreur plus confortable.

J'ai tout de même l'impression qu'avec ces notions de Optional/Result on arrive à une sorte de consensus (ou plutôt de convergence) où beaucoup de langages récents ont fait le choix de traiter les erreurs et les retours de fonction de cette manière.

Malheureusement j'ai l'impression après la lecture de cette dépêche qu'une bonne partie du langage est encore à l'état de promesses.

Oui, il y a un "déjà là" fonctionnelle et tout de même plutôt abouti, mais l'écart entre ce qui est annoncé et la réalité est assez important.
C'est pour moi la plus grosse erreur des concepteurs du langage : de mettre en avant certains aspects qui sont encore très très expérimentaux (gestion de la mémoire, ui etc.).

Non V a utilise aussi un ramasse miette. Il cherche aussi à développer d'autres méthodes de gestion automatique de la mémoire, mais ce n'est pas un langage où l'on est responsable de la mémoire.

Comment faire pour avoir un code plus long dans un map ? (Genre 2 lignes, ou assigner une variable externe lors de l'itération?).

Il est possible de passer aussi une fonction callback à map.

Après sinon je suis d'accord, ces "compile magic" sont déroutant et ça donne un côté très bidouille au langage, mais dans l'histoire des langages, c'est pas forcément les langages les mieux défini (ou les plus pures) qui ont eu les faveurs des programmeurs.

Dans le cas de V, les concurrents sont bien en place, je doute qu'il arrive un jour à devenir mainstream.

Quoiqu'il en soit, c'est une belle expérimentation, j'aime notamment l'idée de vsh. Poussé un peu plus loin, ça peut donner quelque chose de très séduisant.

Perso, je verrai bien une sorte de zx mais codé en V. J'avais commencé un truc, mais sans aller bien loin…

Ce n'est pas une killer feature, juste un choix de syntaxe issue de Go.

Disons que c'est plus cohérent, car l'exemple sans accolade ne fonctionne que si on a qu'une seule instruction.

Oui c'est cette approche minimaliste qui m'a plu dans V.
Après, la bibliothèque d'interface graphique n'est vraiment pas du tout au point.

J'ai essayé de faire un petit logiciel d'édition de sprite avec il y a quelques année et je m'étais bien cassé les dents.

Y a de bonnes idées, mais pas assez de réflexion sur la notion d'état de la vue, ce qui aujourd'hui est dommage quand on voit les apports de la programmation réactive.

Récemment j'ai découvert une mini lib Javascript qui permet de faire un peu la même chose que du React mais tellement plus simplement. J'adorerai voir ce genre de concept porté dans d'autres langages comme V par exemple.

c’est ainsi que la POO est présentée dans beaucoup trop de cas.

Oui, mais c'est aussi ainsi qu'elle est mise en pratique dans certains langages comme tu le dis bien dans ton billet.

Franchement, j'ai du défaire tout l'enseignement que j'ai eu à ce sujet, ça été douloureux, car j'y ai cru à toutes ces choses !

Je crois que le pire c'est les design pattern, j'ai essayé de m'y mettre ! J'y ai mis du cœur, mais dans bien des cas, je trouve que ça complexifie le code…