zul a écrit 443 commentaires

De fait, elles le sont. Mais la syntaxe est restée très homogène. Regarde la syntaxe lambda de C++, où la complexité de certaines définitions quand on commence à manipuler des functor, on est plus dans le même monde.

Je ne veux pas défendre C++ parce que je trouve que c'est langage assez moche, mais malheuresement relativement utile (en terme de ratio efficacité / abstraction / communauté). Pour les lambda, la syntaxe est relativement moche en C++ mais au moins on peut faire des choses avec (tandis que les lambda en python sont quand même ultra limités). Pour les functors, je ne vois pas de difficultés particulières. Vu les affres du passage de python2 à python3, la syntaxe a beau être "homogène" (pour autant que ça veuille dire quelquechose d'objectif), ce n'est pas facile de "changer" de versions. (ce n'est pas si difficile que ça sur des projets relativement petits toutefois).

une API C cassé n-fois
Moui, on sort un peu du langage cependant.

C'est pas comme si on avait une spec de ce qu'était Python. Après CPython, sans son interface C (i.e. qu'avec du code Python pur), ça serait surement beaucoup moins utile (et utilisé). Donc il faut le prendre en considération.

J'ai appris le C++ quand tout ce fratras de C++11 n'existait pas (je crois même pas qu'on osait lever une exception à l'époque) et Python en version 1.5.2 . En quelques heures, je me suis mis à niveau en Python. Pour C++, j'ai l'impression que je vais galérer beaucoup beaucoup plus.

Probablement. C++ est un langage difficile, personne ne le niera. Je pense toutefois que ça va globalement dans le bon sens, i.e écrire du code C++11 correct est plus facile qu'écrire du code C++ 03 correct (quasiement pas besoin de pointeurs nues, quasiment pas besoin d'itérateurs, des conteneurs plus souples, …). Evidemment, il faut oublier C++ = C avec Classes qui est faux depuis bien longtemps.

Si je regarde Python, au niveau de la construction du le langage, il s'en sort pas mal. Il y a eu pas mal de nouvelles constructions par rapport à la version 1.5.2 que j'avais apprise, mais elles s'intègrent syntaxiquement de façon assez fluide dans le langage: itérateurs, générateurs, yield from, string unicode, décorateurs, gestionnaires de contextes. Tout ça a ouvert vraiment la voie à un style de programmation plus évolué, tout en restant dans la simplicité initiale et la syntaxe du langage.

Je ne suis pas sûr que Python soit vraiment un langage référence de ce point de vue là. C'est certes moins verbeux, mais les différences entre python 1.5 et python 3.3 sont quand même gigantesques. En plus de ce que tu as cité, tu as aussi:
- old-class vs new-class
- compréhension liste, et autres extensions de syntaxes pour les dictionnaires et les ensembles
- une API C cassé n-fois
- nouvelle syntaxe pour le formatage
- print() \o/

Et quand on parle de python, on parle de python2 ou de python3 ? (je ne parle pas du code qui fonctionne en 2.7, en 3.3 mais pas en 3.2). Et on oubliera tous les trucs qui datent encore de la préhistoire de python (pourquoi len(), dir(), … ne sont pas des méthodes …).

Quand tu vois qu'en Python, il y a à peu près 0 protections sur l'accès aux méthodes et qu'on arrive quand même à écrire des programmes, ça fait réfléchir.

En assembleur, on arrive aussi à écrire des programmes :) Cet argument ne vaut pas grand chose. La question est la maintenabilité sur le long-terme, par des équipes diverses.

En quoi le nommage C++ est horrible ? Qu'est qui est choquand dans std::enable_shared_from_this ?

Indicateur de disponibilité

ce n'est pas d'une grand fiabilité. Entre les gens toujours dispos, et ceux qui ne le sont jamais …

Message "texte"

Dans tous les cas, tu prend une notification (pop up + bruit) i.e. ton attention est détournée. Tu peux l'ignorer comme tu peux ignorer ton téléphone (en appuyant sur la touche idoine pour qu'il arrête de sonner).

Surtout quand tu es sur des fuseaux horaires de -9 à +9, tu vas pas réveiller en oubliant le décalage horaire

Dans un bureau, si il n'est pas là, il n'est pas là. À moins que tu dorme dans ton bureau.

Il y a encore des gens qui acceptent d'être dérangés en devant répondre dans les 10 secondes?

Je ne vois pas en quoi la téléphonie / visio-conférence via lync change la donne.

Ce n'est pas très sympa pour nos potentiels amis extra-terrestres :D

Non, pas encore, mais cette dépêche m'a donné envie de le découvrir ! Donc la dépêche aurait été utile au moins à une personne. Si le but était de lancer Zenitram dans un troll de compétition sur les services des libraires français, alors là, en plus bingo :D

Tu n'a pas vraiment répondu à la question. Ok, la boîte ne décide rien. C'est la donnée qui décide. Mais comment ? Par rapport à quoi ?

Cas 1: donnée qui se 'ressemble', peux-tu préciser ? Considère tu 'un type' ? Comment deux données peuvent elle se comparer in fine ? Est-ce que 12 secondes de temps à parler ressemble à 12 sec de temps à attendre ? (en prenant un example venant du #UseCase 1 Hotline).
Cas 2: Un chat qui décide, je peux comprendre, une donnée (le temps passé à attendre par exemple), bah je ne vois définitivement pas. Est-ce que tu peux préciser ?

Je ne vois toujours pas le rapport avec les réseaux Bayésiens. Le mot important dans réseaux Bayésiens, c'est Bayésiens, i.e. des probabilités (conditionnels) et de l'inférence. Si c'est juste pour sortir la notion de DAG, pas la peine de sortir l'artillerie lourde ;).

Concernant la présentation, il y'a plusieurs occurence de 'sateless' (en particulier dans le titre), c'est un peu génant.

La question auquel tu n'a toujours pas répondu, c'est que tu clame 'les connections se font en fonction du quoi, quand et où', mais:
- aucun example ne démontre cette fonctionnalité (je ne vois que des graphes classiques fixes)
- tu ne décris nul part les mécanisme sous-jacent (comment se fait la décision dynamique ?)

Tu devrais arrêter de t'enfoncer :D

Tu est en train de nous expliquer que tu as développé un langage de haut-niveau vachement trop cool, que tu es incapable de définir, mais que en même temps, tu aime bien savoir ce que fait exactement le code. Tu n'a même pas défini de sémantique claire à ton langage …

Ensuite, si on continue dans la régression, printf c'est une fonction de haut niveau. Tu devrais utiliser directement write(2), comme ça tu sais directement ce qui est envoyé au noyal. Tu ne risque pas de rencontrer un bug dans la libc. L'overflow, il est dans l'usage incontrôlé de sprintf :D On va inventer snprintf depuis 15 maintenant (sauf évidemment pour les gens condamnés à compiler avec vc++).

C'est plutôt l'inverse, quoi que de nos jours, sur des cpus modernes, c'est un peu kif kif. Sur le pc maintenant un peu ancien dont tu parlais, le calcul en float est très probablement plus rapide que le calcul en double (mais évidemment la précision peut être un problème (je t'aide au cas où tu ne saurai que répondre)).

Normalement, quand l'ensemble des permissions nécessaires changent, la mise à jour ne se fait pas de manière automatique, il faut valider manuellement pour confirmer que tu accepte les "nouveaux" besoins de l'application.

De toute façon, les gens ne lisent pas les permissions :) Et même quand tu fais l'effort de les lire, soit c'est trop opaque pour savoir ce que ça fait, soit tu n'installe rien :)

Tu me demande une réponse, je t'en donne une. Le code C++ pour faire ça est probablement plus court et type-safe.
Écrire un container avec un paramètre template, ça n'a rien de bien compliqué.

Évidemment, on peut faire des choses très compliqué avec des templates, mais on peut aussi faire des choses relativement simples (sûrement plus que le container_of trick) et qui simplifient la vie (et la correction du code dans ce cas là).

Une variante du void*.

L'idée c'est un truc du genre

struct my_custom {
   struct rb_node rbnode;
   ...
   // other fields
};

On insère les rbnode dans l'arbre avec un rb_insert. Et on utilise la macro magique container_of pour récupérer l'adresse de my_custom en faisant un truc du genre

container_of(ptr, struct my_custom, rbnode);

Évidemment, à ce moment, si quelqu'un a introduit un truc qui n'est pas de type my_custom dans le rbtree, ça va faire n'importe quoi. Et il n'y a rien qui l'empêche (à par la vigilance des reviewers).

Pour info, container_of, c'est

#define container_of(ptr, type, member) ({          \
      const typeof( ((type *)0)->member ) *__mptr = (ptr);  \
       (type *)( (char *)__mptr - offsetof(type,member) );})

Je n'irai pas jusqu'à dire que c'est une solution simple :) Élégante peut être pour une certaine définition de l'élégance. Mais clairement pas type-safe là ou on pourrait "sans problème" avoir une solution type-safe en C++.

Classiquement, implémenter une liste générique.

Soit tu te retrouve avec une sys/queue.h plein de macros dégeux,
soit tu retrouve avec une API plein de void* (genre g_slist) et là tu peux mettre un peu n'importe quoi dedans
soit enfin, tu reimplémente un template de pauvre en écrivant des macros qui vont générer des fonctions avec dedans le nom du type qui va bien et les bons paramètres.

L'autre truc intéressant possiblement du C++, c'est d'éviter de reimplémenter n fois des vtables de pauvre (genre le vfs, le dispatcher de paquets, et un tas d'autres auxquels je ne pense pas).

Les namespace ne seraient certainement pas une mauvaise chose à priori dans le noyau, plutôt que de préfixer tout par le namespace en question.

Du côté de NetBSD, tu peux utiliser http://pkgsrc.se/sysutils/sysupgrade pour mettre à jour facilement. Même si tu ne veux pas utiliser ce script, des archives sont générées et disponibles sur les mirroirs habituels, tu n'a donc pas besoin de compiler le monde. Le fichier install.* rappelle les différentes méthodes pour mettre à jour.

Du côté de FreeBSD, pkgng devrait permettre de mettre à jour facilement tes paquets. Ça sera le défaut dans 10.x, mais c'est déjà utilisé dans 9.x. Bapt t'en dira plus si nécessaire :).

Mais NetBSD c'est mieux (même le jeudi).

L'un des gros avantages des références par rapport aux pointeurs, ça reste la garantie de non-nullité. On peut toujours arriver à avoir des danglings références dans du code un peu poilu (genre avec des callback), mais ça reste une sécurité non négligeable.

Oui tu as raison, pas de using namespace globaux est plus juste. P

Personnellement, je préfére éviter les using namespace en général, quitte à avoir du code un peu plus long ou utiliser un alias local. Ça permet de savoir toujours quoi tu appelle rien qu'en lisant le code, sans aller chercher loin d'où vient ce vector (std::, boost::container::, my_cool_implementation:: , qt quand ils auront compris les namespace :D).

J'ai jeté un coup d'oeil au code (très vite) et voici quelques retours:

• JAMAIS de using namespace xxx dans un header, JAMAIS, JAMAIS! Ça casse l'intérêt principal d'avoir des namespace
• L'encapsulation est brisée un peu partout via des getter (non constant) renvoyant des pointers sur des choses internes de tes classes. À quoi ça sert de faire de l'encapsulation si tu renvoie un pointeur nue que n'importe qui peut modifier et briser ainsi tous les invariants ? Pour la grande majorité, ces getters devraient être marqués const.
• De manière plus générale, ton API manque beaucoup de modifiers const.
• Les pointeurs nus, c'est souvent mal. On préfère utiliser au maximum les références quand c'est possible, ou un pointeur intelligent à défaut.
• Le pattern singleton, c'est un peu le pattern sur-utilisé et presque toujours mal. Cf http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons pour une discussion sur les singletons.
• Il faut utiliser les listes d'initialisation dans les constructeurs
• Les objets "un peu gros" doivent (en général) être passé par référence constante plutôt que par valeur
• Quand tu manipule des pointeurs, gare aux constructeurs par copie, et n'oublie pas d'avoir un destructeur qui libère correctement les ressources (bon évidemment pour l'instant, il n'y a quasiment que des singletons).

Beaucoup d'autres choses à dire encore, mais il faudrait que je regarde de plus prêt.

Sinon, y'a UDF http://en.wikipedia.org/wiki/Universal_Disk_Format, avec des spécs et sans brevet. Après, il a ses problèmes aussi (pas de journal entre autre).

Que le blog du Monde soit un brin tapageur, soit c'est un média grand public, on ne peut pas attendre trop d'un média généraliste. Par contre, sur LinuxFr, je m'attend à un peu moins de sensationnalisme et un peu plus de fond. Bref, le problème ce n'est pas l'Iphone qui consomme plus qu'un frigo, mais une certaine utilisation qui en est fait, en considérant les coûts associés cachés du Cloud. Donc, ça vaut pour tous les téléphones intelligents.

L'article original est relativement intéressant et se trouve ici http://www.tech-pundit.com/wp-content/uploads/2013/07/Cloud_Begins_With_Coal.pdf?c761ac pour ceux qui n'auraient pas le courage de lire le blabla du Monde autour.

Tu peux ouvrir un livre sinon, tu sais le truc physique fait avec des arbres où il y'a des petites lettres imprimées, et où il faut tourner les pages physiquement. Les sujets traités sont divers, et tes yeux te remercieront d'ici 10 ans :).

Sinon, si on veut des trucs un peu plus chiadé, il y'a tikz http://www.texample.net/tikz/examples/, mais ça ne rentre pas dans le cahier des charges (i.e. il y'a une courbe d'apprentissage assez importante).

Sinon, personne n'a évoqué inkscape (http://inkscape.org/), ce n'est pas son but premier, mais il peut faire ce genre de chose assez bien, d'après mon expérience.

Perso, je n'ai pas été impressionné par la réactivité de la chose, je trouve ça un peu laggy encore, même sur une machine relativement puissante.

Oui, même si la nouvelle version a de nouveaux bugs bloquants pour son utilisation ou des features supprimées :)

La bonne façon de faire avec cmake c'est d'utiliser la variable CMAKE_DL_LIBS, qui contient ce qu'il faut selon la plateforme (rien, dl, …).