Blackknight a écrit 1234 commentaires

  • [^] # Re: nosql embarqué ?

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 2.

    Rien de tout ça (il a bien bénéficié d'un effet réseau, mais n'est pas le précurseur du genre), il a eu la jouabilité qu'il fallait

    Je suis bien d'accord sur le fait que la jouabilité est bien plus importante que la beauté des graphismes. Il suffit de regarder Tetris bien avant Minecraft.
    Mais de là à dire que les perfos n'ont pas d'intérêt, il y a un sacré pas.
    En plus, les exemples à la Tetris ou Minecraft ne sont pas légion non plus !!

  • [^] # Re: nosql embarqué ?

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 2.

    La gestion des exception est très mauvaise. Certaines exceptions peuvent générer des fuites mémoires très difficiles à diagnostiquer.

    Certes mais ce problème est connu depuis des années et documenté dans de nombreux livres. Cela fait-il de C++ un mauvais langage ?
    Tous les langages ont leurs pièges et bonnes pratiques pour y échapper.

    Très souvent la raison d'utiliser C++, est « c'est plus performant! » Mais personne n'a besoin de cette performance. Je n'arrive pas à retrouver les messages de devnewton qui explique qu'en général le gain de performance est invisible pour l'utilisateur d'un logiciel.

    C'est sûr ! En termes de jeu, il suffit de regarder Minecraft et de le comparer à Doom3 pour se rendre compte que la perf, ça sert à rien ou alors, c'est juste pour faire joli (ce que n'est pas franchement Minecraft).
    D'ailleurs, il y a encore des gens que ça intéresse les perfs dans le domaine des jeux (cf. ce très bon document sur les pièges de la POO).

    Qui plus est, il est difficile de faire monter C++ à l'échelle comparé à Java ou Python. En revanche, pour ce qui est d'une application serveur qui va prendre 100 coup à la seconde, la performance est importante. Mais dans ce cas, il devient difficile de faire monter à l'échelle n'importe quelle application C++.

    Tu entends quoi par là ? Références ? Exemples ?
    Du coup, si je te comprends, si on veut des perfs pour notre serveur, il faut du C++ mais on ne pourra plus "monter" à l'échelle ? Il n'y a pas de solution alors ? On est condamnés à avoir des serveurs qui gèrent des milliers de connexions mais qui seront lents ?

  • [^] # Re: L'édition de documents, est une catastrophe.

    Posté par  (site web personnel, Mastodon) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 10.

    La vache, on sait plus lire les smileys sur LinuxFR ?
    Un peu que c'était de l'ironie !!!

  • [^] # Re: L'édition de documents, est une catastrophe.

    Posté par  (site web personnel, Mastodon) . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 9.

    J'entends beaucoup parler de LyX, ces derniers temps.

    C'est normal, ça vient juste de sortir :)

  • [^] # Re: ARM

    Posté par  (site web personnel, Mastodon) . En réponse au journal Power8 - OpenPower : l'hégémonie du x86 pourrait-elle être bousculée dans le monde serveur ?. Évalué à 3.

    tu es plus vieux que moi ;-)

    Digital allait bien alors tu vois, c'est peu dire :D

  • [^] # Re: ARM

    Posté par  (site web personnel, Mastodon) . En réponse au journal Power8 - OpenPower : l'hégémonie du x86 pourrait-elle être bousculée dans le monde serveur ?. Évalué à 3.

    Ca doit faire maintenant 20 ans que j'entends dire que le x86 est mort, qu'il est lent, qu'il ne monte pas en charge, qu'il va être remplacé par tel truc qui tue

    Ouais, y avait même les Alpha dont on disait qu'ils allaient être le successeur du bon vieux x86. Quand on voit ce que Compaq en a fait… :)

  • [^] # Re: ARM

    Posté par  (site web personnel, Mastodon) . En réponse au journal Power8 - OpenPower : l'hégémonie du x86 pourrait-elle être bousculée dans le monde serveur ?. Évalué à 6.

    avec des montres à plusieurs milliers d'€

    Des Rolex ?

  • [^] # Re: Ce qu'on demande à un développeur aujourd'hui...

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 1. Dernière modification le 24 juillet 2013 à 11:11.

    Mais pour tout le reste, ce qui correspond globalement a la grande majorite de l'informatique moderne, ta suite de test ne t'aidera pas pour chasser les bugs juste eviter que certains ne reviennent pas !

    Ben non, perdu ! Il suffit de regarder que 98% de la production de processeurs finit dans l'embarqué (source). Sachant que l'embarqué ne se cantonne pas à des plateformes lourdes type Linux, une partie non négligeable de l'informatique moderne se trouve donc dans les lave-linges, les lave-vaisselles, les téléviseurs et les fours micro-ondes (les autres m'excuseront de les avoir oublier) et n'a pas de multi-coeur, de multi-tâche et pour certains même pas d'OS (le petit lien pour ça).

  • [^] # Re: Les tests unitaires, c'est bon, mangez-en :-)

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 1.

    T'es sûr de ton coup ? Ou alors, on n'utilise pas le même vocabulaire ?
    Moi, je pensais couverture de branche comme le monsieur ici.

  • [^] # Re: La Freebox n'est pas à toi

    Posté par  (site web personnel, Mastodon) . En réponse au journal freebox et gpl. Évalué à 8.

    c'est décoléré de la GPL sur la Freebox

    Ouais moi aussi, ça me met en colère :)
    Je pense que tu voulais plutôt dire décorrelé.

  • [^] # Re: Troll

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Ametys, le CMS java open source français qui monte. Évalué à 6.

    C'est un poil tendancieux surtout quand le "compte" de Maeva Mongaillard, responsable de communication chez AmetysCMS, n'existe déjà plus…
    Il faudrait peut-être prévoir un truc sur le site pour mettre dans le coin haut droit, un logo publi-information.
    Mieux, une entrée spécifique comme pour les journaux et les dépêches serait la bienvenue, on l’appellerait ça la page de pubs.

  • [^] # Re: BSD

    Posté par  (site web personnel, Mastodon) . En réponse au journal [non-troll] Faire confiance à (N)S(A)ELinux ou aux *BSD ?. Évalué à 9.

    j'éviterais de prendre deux BSD différents, ça va te faire plus à « appréhender ».

    Les différences entre les deux ne sont pas insurmontables quand même. Passer de FreeBSD à OpenBSD se fait plus facilement que d'un Linux avec "Network Manager" à un Linux "interfaces.conf"-like :)
    J'ai évité de parler de init Sys V et de systemd pour éviter le troll… Hein ? C'était déjà fait ? :D

  • [^] # Re: Mmmh

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ada, langage et ressources. Évalué à 6. Dernière modification le 27 juin 2013 à 10:43.

    Ce n'est pas parce qu'on compare la manière d'implémenter quelque chose dans 2 langages différents que c'est du troll.

    Sauf que dans un cas, c'est à toi de faire l'implémentation et dans l'autre pas.

    C++ possède des mécanismes qui entre autre permettent de faire ça

    Non, C++ possède des mécanismes qui permettent de l'implémenter soi-même, ce n'est pas la même chose.
    Si on va dans ce sens, l'assembleur possède aussi les mécanismes qui permettent, entre autres, de le faire.

  • [^] # Re: Mmmh

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ada, langage et ressources. Évalué à 2.

    Note que je ne nie pas que le fait que ce soit intégré au langage soit une excellente chose; juste que à partir du moment où tu voudras utiliser des objets plus complexes, je ne suis pas certain que tu ne finiras pas, même en Ada, avec une solution usine à gaz potentiellement plus compliquée à mettre en œuvre que ma bête solution en C++.

    On est bien d'accord. Si le problème est compliqué, il y a peu de chances que sa solution soit très simple :)

    Et aussi, je tends à réduire l'utilisation des templates au minimum vital. Je n'y ai recours que lorsque les gains vont clairement outrepasser la chiantitude à implémenter et déboguer l'implém.

    Là aussi, je ne peux qu'aller dans ton sens parce que je ne garde pas que de bons souvenirs de mes templates C++ notamment sur le débogage :D
    Mais comme le disait Michel, c'est ultra-puissant donc il n'y a pas de mystère, ça peut devenir compliqué.

  • [^] # Re: Mmmh

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ada, langage et ressources. Évalué à 2.

    Les concepts manipulés en ADA pour faire la même chose sont surtout nettement plus simples (et moins puissant).

    Certes mais restons raisonnables. Là, on est en train de comparer la déclaration de type avec les templates. Si on parle de généricité alors parlons des generics en Ada.
    Et effectivement, les generics Ada ne permettent pas la méta-programmation (voir wikipedia) et possèdent d'autres limitations que le C++ n'a pas.

    Voilà, on n'aura donc pas réussi à éviter le troll des langages :-/

  • [^] # Re: Mmmh

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ada, langage et ressources. Évalué à 2.

    un peu de méta-programmation avec les templates permettra de régler le problème, un peu comme avec la solution d'utiliser les « static asserts » de Boost, Loki ou autres bibliothèques

    Et bien, il est là le problème. On part d'une solution à base d'un template et on continue en rajoutant un soupçon de meta-programming pour obtenir les mêmes résultats.
    Donc la déclaration d'un type en une ligne en Ada demande nettement plus de code en C++ mais encore une fois, je n'ai dit nulle part que c'était infaisable en C++.

    Soit on ne connaît pas la valeur de la variable à la compilation, et oui bien entendu il faudra évaluer à l'exécution

    Exact et le compilateur Ada ne dira effectivement rien.

  • [^] # Re: Que du bonheur (pour toi)

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ada, langage et ressources. Évalué à 3.

    Parce qu'on peut pas le hacker facilement :D
    En école d'ingé, on code et on voit après et du coup, c'est très lourd parce que le compilo n'arrête pas de brider la créativité du développeur.
    En vieillissant, on en a marre de corriger sans cesse les mêmes bugs cons et on préfère se poser pour réfléchir. L'impulsivité de la jeunesse contre la Sagesse quoi :D

  • [^] # Re: Mmmh

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ada, langage et ressources. Évalué à 2.

    Bon, j'ai trouvé ça et tu seras d'accord pour dire que c'est moins sexy :D
    En tout cas, ça marche en C++ et ça ne me choque pas du tout.
    La seule différence est que ce ne sera détecté qu'au runtime.

  • [^] # Re: où faire de l'ada

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ada, langage et ressources. Évalué à 1.

    Mais c'est quand même triste de voir que "les gens" ne veulent pas vraiment la qualité, que ce n'est pas à la mode.

    La qualité, ça coûte toujours trop et on préfère privilégier le time to market à la qualité quitte à passer des lustres à fournir des patchs.
    Le probèleme en Ada, c'est que le développement est nécessairement plus long car il faut d'emblée se poser les bonnes questions plutôt que de hacker un truc vite fait.

  • [^] # Re: Mmmh

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ada, langage et ressources. Évalué à 2.

    C'est vrai, c'est pas énorme mais il ne faudra pas oublier de gérer le wrap around et tous les problèmes qui vont avec.
    Mais sinon, pour ceux-là, ça marchera aussi ?

    type Proportion is digits 4 range 0.0 .. 1.0;
    type day is Lundi, Mardi, Mercredi, Jeudi, Vendredi, Samedi, Dimanche;
    subtype jour_de_la_semaine is day range Lundi..Vendredi

    Sans compter que sur les types énumérés, on peut maintenant faire des prédicats pour constituer des ensembles disjoints (voir cette gemme)

  • [^] # Re: Mmmh

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ada, langage et ressources. Évalué à 2.

    Sauf que tu vas devoir te le faire ton template ainsi que les opérations qui vont bien avec, c'est justement tout ça que tu n'as pas à faire en Ada et c'est le compilateur qui te génère les opérations de base et des assert qui vont bien dans ton code que tu peux retirer une fois le code en prod si tu es vraiment sûr de toi.

    Certes la syntaxe est peut-être moins sexy, mais le résultat (et surtout l'utilisation !) serait la même (une exception serait lancée si on tente d'affecter un nombre trop grand à un entier de type u16 par ex). Mon exemple montre même un cas qui serait sans doute résolu à la compil, comme en Ada.

    La syntaxe n'est pas moins sexy, elle s'arrête à la définition du type, c'est tout !!
    D'ailleurs, il n'a jamais été dit qu'on ne pouvait pas faire la même chose dans les autres langages. La différence réside dans le fait qu'il faut les faire :)

  • [^] # Re: où faire de l'ada

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ada, langage et ressources. Évalué à 1.

    A part l'embarqué et le temps réel on ne l'utilise pas / peu ? Pourtant le langage pourrait vraiment être intéressant pour aider a faire de meilleurs softs, non ?

    Ben ouais mais vas faire comprendre ça autour de toi et tu verras que c'est vraiment pas la mode.
    Pourtant on sait même faire du Web avec Ada, la preuve :D

    et après faut pas croire mais en java on peut aussi faire des gros trucs sympa, genre basé sur hadoop, du distribué, etc

    Oui mais ça non plus, c'est plus la mode. J'ai même entendu dire par un collègue :

    S'ils veulent se faire chier à faire un client en Swing, ça les regarde mais un portail avec des portlets, c'est quand même mieux

  • [^] # Re: où faire de l'ada

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ada, langage et ressources. Évalué à 1.

    Une question un poil annexe, mais vu qu'il y a du monde qui semble en faire : où faire de l'ada (professionnellement j'entends) ?

    Dans le spatial, l'aéronautique, la défense, le transport majoritairement que ce soit chez l'éditeur de logiciels ou en SSII.
    Par exemple :
    - Sur LinkedIn en étant connecté :)
    - Directement sur les sites concernés comme MBDA ou Sagem Défense (certes, sur celle-là, on demande de l'expérience compte tenu du domaine mais si tu as de l'expérience en C, tu peux déjà postuler)

    Mais bon, il ne faut pas se leurrer, le langage n'est pas à la mode (cf. ce post) donc les offres de boulot ne sont pas légion.

    Une transition depuis du web/js/java ça se fait facilement ?

    Le gros problème risque d'être lié au fait que dans beaucoup de cas, on trouve Ada dans des systèmes temps réel et/ou critiques où les problématiques sont assez éloignées du développement Web. Dans ce cas, ce n'est pas le langage qui risque de poser problème mais plutôt son environnement.
    Par contre, la transition vers Ada en tant qu'apprentissage d'une nouvelle techno ne pose pas de problème.

  • [^] # Re: Proust alors.

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ada, langage et ressources. Évalué à 1.

    Une "surcouche" genre vala pour le langage C ? Là ce serait intéressant.

    Justement, il s'agit non pas d'une surcouche mais d'un sous-ensemble avec annotation. En clair, Ada est un langage généraliste et possède donc des fonctionnalités qui ne sont pas utilisables en l'état pour des applications critiques d'où l'existence de Spark.
    C'est justement cela qui rend Spark intéressant pour ce domaine.

  • [^] # Re: Proust alors.

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ada, langage et ressources. Évalué à 2.

    c'est l'aspect programmation concurrente et fonctionnelle de ADA

    Autant pour concurrente, on est bien d'accord, c'est un point intéressant, autant pour fonctionnel, j'ai bien l'impression que l'on ne parle pas de la même chose. Ada n'est pas un langage fonctionnel et ne le sera jamais, il s'agit d'un langage impératif.
    En ayant l'esprit très ouvert, on pourrait peut-être assimiler les dernières avancées en termes de prédicat pour la vérification statique de code de programmation pseudo-fonctionnelle mais faut vraiment être très ouvert.

    Si personne ne peut en parler ce n'est pas grave.

    Ben, on peut toujours parler de LISP mais franchement, si je peux comprendre à peu près qu'on compare avec Ocaml qui est multi-paradigme, la comparaison avec LISP peut s'arrêter à : "Il y a plus de parenthèses en LISP".