GuieA_7 a écrit 689 commentaires

En C++, pour commencer, je ne voudrais pas faire de trop grandes généralités sur des langages que je ne connais pas.

OK. Mais prenons Ada, qui est relativement proche de C++ (impératif, orienté objet, typage statique fort…), et qui est réputé pour être utilisé dans des systèmes critiques. Et bien il propose aussi des exceptions.

Et comme des tas d'autres langages sérieux (Ocaml, Haskell, Erlang…), en plus des langages plus mainstream (Java, C#, Python…), proposent aussi des exceptions, on peut quand même largement douter du fait que ça n'apporte rien aux codes d'erreurs classiques (voire des mécanisme plus sophistiqués comme le pattern matching).

Est-ce toujours possible de traiter dans les couches supérieures ?

Mauvaise question.
Si il est intelligent de traiter l'erreur 3 appels de fonctions en amont, alors les exceptions te permettent de faire ça avec peu de code boilerplate. Mais de la même manière que tu coopères avec la fonction qui te renvoie un code d'erreur (en traitant ce code), tu coopères avec du code qui peut soulever des exceptions (en mettant des handlers là où c'est pertinent). Les exceptions n'ont pas la prétention de régler le problème des erreurs, mais de permettre d'écrire (quand ça a du sens) du code plus simple/court/robuste.

Personne n'a dit que les exceptions étaient un outil magique qu'il fallait saupoudrer sur ton code, et hop ton code gère les erreurs correctement. Non c'est un outil avec des avantages et des défauts, et qui peut être mal utilisé comme tous les outils.

En quoi, au final, les exceptions apportent-elles quelque chose à la gestion d'erreur ?

En C++, ou bien en programmation de manière générale ?

Trimballer le contexte de l'erreur jusqu'au lieu de correction.

Avec les exceptions tu peux traiter tout de suite, comme avec les codes d'erreurs, lorsque c'est pertinent.
Tu peux aussi traiter plus loin (et regrouper les traitements d'erreur plutôt que les multiplier) lorsque c'est pertinent (et le 'trimballage' de contexte sera plus facile, car le langage t'aide).

y a-t-il d’autres types de vecteurs?

En mathématiques un vecteur est un élément d'un Espace vectoriel. Il se trouve que très souvent on utilise les cas particuliers que sont ℝ² ("couple de nombres") ou ℝ³ ("triplet de nombres"), mais tu peux tout à fait construire des espaces vectoriels où les éléments sont de nature différente, comme des fonctions par exemple.

Kore is an easy to use web application framework for writing scalable web APIs in C. Its main goals are security, scalability and allowing rapid development and deployment of such APIs.

https://github.com/jorisvink/kore

Pour quelqu'un qui s'y connaît si peu en programmation (et qui visiblement ne sait pas non plus se servir d'un moteur de recherche), tu es bien arrogant. Un peu d'humilité ne te ferait pas de mal…

Programmation Web pour les utilisateurs de Visual Basic 6.0: https://msdn.microsoft.com/fr-fr/library/k29zz13x(v=vs.90).aspx

Dans la mesure où VB n'est plus maintenu depuis 2008 (à moins que tu parles de VB.NET, mais là ne pas comprendre qu'on peut faire du web avec, faut le faire exprès) ça ne me semble pas un exemple très intéressant.

Oui: http://www.zend.com/en/solutions/mobile-app-development

Après je ne te conseillerai pas PHP. Pas parce qu'il ne rentre pas dans tous les 'types', mais parce que c'est un mauvais langage.

Les gens répondent le plus intelligemment possible. Si la réponse intelligente est "ta question" n'a pas de sens", alors c'est ce qu'ils répondront, ne t'en déplaise.

En l'occurrence le tableau que tu pointes est loin d'être pertinent. Par exemple selon lui Python ne permet pas de faire de l'embarqué, or j'ai bossé pendant 1 an dans une boite qui faisait du python en embarqué. Pareil, Python ne permettrait pas de faire du mobile, ce n'est pas ce que dit Kivy. Et on t'as globalement répondu que tous les langages permettaient en gros de tout faire, c'est marrant… Du coup tous les languages sont dans tous les 'types', et donc ta question n'a pas de sens (et c'est tout ce qui est clair dans ta question, désolé).

Alors libre à toi d'écouter ce joli tableau avec des jolis couleurs si ça te chante, et libre aux gens de te faire remarquer que ta question n'a pas de sens.

Malgré son nom, Tipeee ne se cache pas de vouloir être le Patreon français (et pour les créateurs français). Et le nom de Patreon est plus parlant quant aux ambitions de ces plateformes, soit faire des dons récurrents à un créateur que l'on apprécie, et souvent avec des contreparties.

Dans les modèles qui marchent (éventuellement) et que j'ai pu voir:

• Nota Bene qui s'était donné un certain nombre de mois (il était au chômage je crois) pour que les dons lui permettent de se verser un SMIC, sans quoi il devrait arrêter (il y est parvenu, et c'est cool).
• Le bien connu ici David Revoy, qui peut, au fur et à mesure que les dons pour Pepper & Carrot augmentent, privilégier ce dernier par rapport à son travail de freelance plus classique. P&C est libre, gratuit et accessible à tous, mais les donateurs sont cités dans les crédits, ce qui est une (bonne) contrepartie.
• Le modèle précédant est malheureusement (du point de vue d'un libriste tout du moins) une exception ; généralement les illustrateurs ne placent pas leur travail sous licence libre, et les donateurs reçoivent des contreparties du genre version HD des illustrations, croquis préparatoires ou bien vidéos du processus créatif (un exemple avec Kuvshinov Ilya.

Du coup avec ton approche, j'ai l'impression que tu n'expérimentes pas vraiment ces plateformes, dans la mesure où on est proche du bouton 'Faire un don' qu'on trouvait sur Sourceforge il y a 15 ans. Ce n'est pas un reproche, mais je serai très étonné qu'on observe un résultat différent (bien que j'espère me tromper).

en général python pour le web s'utilise comme des script qui se lancent a chaque requete

Non dans la façon classique/recommandée les scripts ne sont pas relancés à chaque requête. Selon ta configuration, ton app va être relancée toutes les X requêtes ou toutes les X minutes, mais tu peux même laisser vivre ton app ad-vitam. Il me semble que c'est possible en PHP depuis pas mal de temps aussi.

OK pour le reste.

Tu veux qu'on te pose des questions techniques pour faire avancer le débat, et quand on t'en pose tu ne te souviens plus des aspects rédhibitoires des autres bibliothèques (tips: ça aurait été cool de le noter dans les commentaires de code). Je n'ai jamais déprécié ton code, en revanche tu en fais une très mauvaise promotion ; je comprends que faire de la pub n'est pas ton fort (c'est aussi mon cas), mais en tant qu'outsider, si tu veux que les gens investissent du temps sur ton code (plutôt qu'utiliser les libs déjà éprouvées) il va falloir plus que des banalités du genre "développer rapidement des applications de qualités".

Il y a une contradiction dans tes propos de manière générale ; d'un côté tu expliques que tu ne pourrais pas être plus efficace avec les autres outils, et de l'autre tu avoues ne pas avoir beaucoup regardé ce qui se fait ailleurs.

Dans la mesure où il existe des tas de frameworks libres de qualité, éprouvés par des milliers de codeurs/applications depuis des années, qui eux aussi se vantent de permettre de faire des applications de qualités rapidement etc…, tu peux comprendre qu'aller se plonger dans ton code pour y trouver d'hypothétiques qualités parce que tu ne peux pas expliquer ce que ton framework apporte par rapport à la concurrence est plutôt rebutant.

Par exemple tu aurais pu en profiter pour expliquer quelles bibliothèques de dates tu as essayées et en quoi la tienne est meilleure.

Les 2 choix 'Faire une preuve de programme' & 'Faire des preuves en Coq' semblent faire un peu doublon, non ?

'Commenter le code de quelqu'un d'autre', ça veut dire rajouter des commentaires dans le code (d'un autre), ou bien faire une revue de code ?

Bref proteger le consommateur.

Oui entièrement d'accord avec ça ; difficile de ne pas être d'accord en même temps.

Non mais faire une loi pour forcer a ce que les format de donnees soient parfaitement specifiée et libre.

Toi aussi tu veux forcer des choses ; je suis sûr que des tas de gens (très influents) vont qualifier ta proposition de dictature. C'est très relatif tout ça.

Forcer la publication du mode du fonctionement du materiel afin qu'il appartienne vraiment a l'utilisateur…(je pense aux drivers…)

L'histoire (et les cartes graphiques) a montré que même avec les spécifications, il est parfois très difficile de développer des drivers. Et puis la frontière entre hardware et software n'est pas toujours évidente. Le diable se cache dans les détails.

Forcer qu'un logiciel qui n'a plus de mise a jour et comportant des bugs soit libéré.

Qui va décider que ce sont des bugs ? Si à chaque fois il faut une actions en justice, le code source sera libéré 15 ans trop tard (comme la sélection du navigateur dans Windows). Et forcer un logiciel développé par une entreprise étrangère qui a coulée risque d'être très complexe aussi par exemple.

Il suffit cependant de demander a l'etat de faire ce a quoi il est cense servir….

Conclusion, il ne 'suffit' pas, tout ceci est très complexe (ex: il suffit de réduire le chômage, il suffit de relancer la croissance…).

Je n'ai absolument rien proposé de tel (je ne suis pas pour), je demandais des précisions sur un commentaire bien vague.
Alors c'est bon tu peux te détendre et aller chasser les crypto-communiste plus loin :)

Un langage tel que Rust peut-il s'attaquer à ce genre de problématique avec son mode de gestion automatique ?

Je pense que oui, parce que la gestion est certes automatique, mais prédictible (en plus pour les applications vraiment temps réelle l'allocation dynamique est proscrite en générale, et Rust permet ça aussi grâce aux allocateurs personnalisés).

PHP ça date de 1995, et Java de 1996 ; il est clair que Java est un truc de jeunes qui doit encore faire ses preuves ; vu le peu d'entreprises qui l'utilise, dans 10 ans ça aura sûrement disparu (après tout ça ne fait que quelques décennies que Cobol devrait avoir disparu).

Y en a marre de tous ces langages de hipster, alors qu'au final ça fait tout pareil que le basic de mon amstrad. Parce qu'au bout de 20 ans, il faut en apprendre un nouveau et ça c'est intolérable. En gros pour avoir ses 40 annuités il faut changer une fois (voire 2 !) de langage de prédilection. Ça c'est encore un coup de notre gouvernement et sa flexibilité du travail !

Cela étant, au début de Rust il y avait un GC qu'ils ont abandonné

Alors quelques précisions:
- le GC qu'il y avait au début de Rust n'étant pas un vrai GC, mais du comptage de références (parce que le travail n'était pas terminé).
- l'utilisation du GC a toujours pensée comme optionnelle : en gros on déclarait une référence comme étant "garbage collectable" (le langage a bien changé mais c'était dfans mon journal sur Rust 0.7 ).
- même quand le GC était partie intégrante du langage, le but était de s'en servir le moins possible, et par exemple la bibliothèque standard a vite atteint l'objectif de 0 GC.
- avec le temps l'équipe s'est aperçu qu'elle pouvait aller plus loin que ce qu'ils pensaient au début, et que le système de typage permettait de sortir le GC et de le penser comme une dépendance externe, sans besoin d'une syntaxe dédiée.

mais l'idée de remettre de la gestion automatique est toujours présente, cela semble être néanmoins compliqué

La gestion est déjà automatique, via le système de référence que j'ai (mal) expliqué, mais un GC optionnel serait un confort pour certaines partie de code. Ce qui complique la tâche ce sont les prérogatives assez élevées qu'imposent les buts du langage ('You pay for what you use' entre autres), quand Haskell/Ocaml/Java/Python… n'ont pas à se soucier de tels problèmes (mais ils en ont d'autres évidemment).

Sinon quelle différence fais-tu entre un langage qui peut faire de la programmation système et un langage système ?

La différence peut être mince, comme tu le soulignes avec les unikernels, mais je dirais qu'un langage système permet de maîtriser suffisamment parfaitement le comportement du code pour pouvoir écrire du code temps-réel (au sens temps réel dur, pas au sens globalement performant).

c'est pas si mal et bien mieux que le 25.82 s du meilleur code OCaml du test. D'autant que, n'étant pas moi même programmeur (je suis mathématicien et logicien, pas informaticien), il est fort probable qu'un spécialiste du langage puisse encore améliorer cela.

C'est très gentil de t'être donné la peine d'écrire un commentaire aussi argumenté, mais tu prêches un convaincu :) . Je sais très bien que Haskell ou OCaml ont de très bonnes performances dans la majorité des cas. Mais justement le lien que j'ai donné explique bien que Haskell va donner de très bon débit, mais va avoir des problèmes de latences ; ton benchmarck au final est équivalent à tester un débit moyen, mais ne va pas du tout tester les problèmes de latences, parce que 1) c'est pénible à tester 2) ce n'est pas ton problème.

C'est un système de lock pour les problèmes d'accès concurrents ? […]

Non pas du tout. Alors n'étant (encore :) ) pas un spécialiste du langage, mon explication va être un peu légère. En gros tout est fait à la compilation (un lock serait fait au runtime), où le compilateur, via son borrow checker, vérifie plusieurs choses comme:
- les temps de vie des objets. Par exemple si on retourne une référence sur un attribut d'un objet, alors le temps de vie de cette référence ne peut excéder celui de l'objet lui-même. Le borrow checker peut donc détecter des cas où on essaye de stocker cette référence en dehors du scope de vie de l'objet lui-même (un cas de dangling pointer comme on peut en trouver en C/C++).
- lorsqu'on passe une référence mutable à une fonction, on lui délègue la responsabilité de cette référence, et on ne peut plus utiliser cette référence dans la suite du code.

En pratique cela oblige à écrire le code de manière à satisfaire le borrow checker (sachant qu'il est régulièrement amélioré pour être moins stupide—il y a des fois où il est évident pour l'humain qu'il n'y a pas de problème, mais ça ne l'est pas pour le borrow checker). L'écriture des structure de données classiques est donc tout un art (heureusement le boulot est déjà fait !).

Au final c'est un peu comme quand les langages fonctionnels, qui en promouvant l'immuabilité et l'abandon des variables globales par exemple (ce que Rust fait aussi), obligent à penser son code d'une manière naturellement plus robuste.

J'espère avoir été clair.

Et on peut aussi manipuler des références (mais là c'est sans garde-fou) et faire de la programmation système en OCaml (la seule limite actuelle, c'est le GC qui ne gère pas les accès concurrents sur la major heap ce qui pose problème pour le parallélisme, cf multicore OCaml).

Ocaml permet de faire de la programmation système (ce qui ne veut pas dire grand chose, mais disons qu'un langage compilé nativement, avec de bonnes performances, qui permet de manipuler threads/sockets…, rentre dans cette appellation), mais à l'instar de Go par exemple, il ne peut pas être qualifié de langage système à cause de la présence obligatoire du GC (attention je n'ai jamais dit que tu avais affirmé que c'était un langage système—mais la précision me tient à cœur), tandis que Rust peut se passer complètement de runtime. Ça n'en fait pas un meilleur langage, c'est juste qu'ils ont des desseins différents.

Au passage, un petit article, que j'ai lu récemment, sur les problèmes qu'un GC peut poser (ici en Haskell): https://blog.pusher.com/latency-working-set-ghc-gc-pick-two/

l'attribut est un peu mieux décorrélé (mais pas totalement) de l'argument

Oui c'est ce que je disais dans mon commentaire avec "si les objets contenus sont mutable ils pourraient être modifiés de l'extérieur malgré ça"

Je ne sais pas ce que sont les notions de propriétaires/temps de vie en Rust, mais je dirais pour ma part : comme quoi le fonctionnel pur (ou l'observationnellement immuable) ça a son intérêt ! :-)

Tout à fait, d'ailleurs en Rust les variables sont immuables par défaut. Mais comme c'est un langage système qui vise aussi les performances optimales, il y a moyen de déclarer explicitement des variables mutables. Et le système d'emprunt de références va tout de même garantir qu'un seul endroit du code a la responsabilité de modification à un instant T. Ce qu'on perd en souplesse (le compilateur est encore plus hargneux, puisqu'en plus des règles sur types, on doit respecter les règles sur les références—et le système de typage est moins puissant qu'en Haskell/OCaml), on le gagne en performance.

Dans ce cas particulier, j'aime bien aussi :

class Test:
    def __init__(self, items=()):
        self.items = list(items)

Défaut:
- il y a forcément une copie, même si elle est potentiellement inutile (et du coup ça illustre bien comment, par exemple, les notions de propriétaire/temps de vie de Rust sont intéressantes pour des projets gros et devant être performants).

Avantages:
- puisque la liste nous appartient on peut la modifier sans trop de crainte (évidemment si les objets contenus sont mutable ils pourraient être modifiés de l'extérieur malgré ça).
- la fonction accepte du coup n'importe quel objet itérable (comme un générateur par exemple). Dans ton code items doit posséder une méthode append().
- même si ça ne dispense pas d'un commentaire sur l'API, la signature est plus explicite.

Dans le cas où 'items' n'a pas vocation à être très long (et qu'on n'a pas un 2ème argument du même genre), on pourrait aussi faire:

class Test:
    def __init__(self, *items):
        self.items = list(items)

du coup l'appel à la fonction serait Test(1, 2, 3) plutôt que Test([1, 2, 3]).

Comme quoi le "one way to do it" c'est (heureusement) une intention plus qu'une réalité :)

[…] s'attaquer à la difficulté de fond afin de faire établir ces idées comme principe ?

C'est à dire ? Faire voter une loi pour obliger les gens à ne faire que du logiciel libre ?

J'imagine que je ne suis pas le seul ici à connaître plusieurs entreprises qui n'utilisent pas de SCM du tout (décentralisé ou pas), parce qu'elles ne savent pas que ça existe ou ne savent pas vraiment à quoi ça sert. Celles que je connais sont de petites boîtes faisant des logiciels propriétaires.

Ça me fait froid dans le dos rien que d'y repenser :)

probablement inspiré de Rust au passage

Oui sûrement. Les 2 communautés s'inspirent mutuellement et c'est très bien comme ça, et très intéressant à suivre.

La gestion mémoire de Rust n'a rien de jeune. Elle vient des techniques de RAII de C++, Ada our Vala qui ont plus de 10 ans.
La seule "nouveauté" de Rust, est de les rendre obligatoire par défaut.

Rust a repris plein de concepts existants/éprouvés dans d'autres langages (C++, Haskell, Erlang, Python…), mais pour le coup sa gestion des références est réellement unique, et va plus loin que du simple RAII habituel (c'est sûrement inspiré du RAII, mais c'est bien plus que du RAII obligatoire). Le borrow checker n'a pas d'équivalent (à ma connaissance) ailleurs ; de plus, intégrer les autres concepts avec cette gestion mémoire, pour obtenir un tout cohérent, est aussi un tour de force en soi.

Rust est plus résistant aux buffer overflow que la plupart des langages des script, pourtant sa gestion mémoire est manuel

Je ne suis pas d'accord sur le terme 'manuelle' ; pour moi la gestion mémoire de Rust est automatique, mais faite (en grande partie) à la compilation, et pas à l'exécution (comme avec les langages à GC). Mais comme c'est un peu un OVNI, il n'est pas étonnant que l'abus de langage 'automatique==à l'exécution' se soit installé.