Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 127 sur 133 PremièrePremière ... 2777117119120121122123124125126127128129130131132133 DernièreDernière
Affichage des résultats 3 781 à 3 810 sur 3965
  1. #3781
    Inter-process oui, inter-threads moins.
    La std17 a rattrapé le gros de son retard sur Qt5 sur plein de points; il devient dès lors standard et concis d'instancier des threads et de les synchroniser avec les éléments les plus courants.

    Je plussoie pour les sockets et pipe, c'est ce qu'on m'a toujours rabâché et que j'ai vu utilisés intensivement.

    Par contre, j'entends bien les arguments de Nilsou: les étudiants peuvent être désespérants de crasse avec des choses simples, donc pour amener ce genre de choses il faut quand-même bien organiser le TP. Sachant que certains élèves risquent de ne pas décoller des premières questions...

  2. #3782
    Ouais ici on est pas au niveau des sockets avec nos élèves, déjà ouvrir des fichiers voila, mais d'un autre coté on veut quand même leur faire toucher un peu aux quelques problématiques types « mutex/semaphores » de la vrai vie. Même avec un truc aussi simple que les fichiers, honnêtement, beaucoup d’élève n'y arrive pas alors bon ...

  3. #3783
    Je rêve du jour où je comprendrai ce que vous dites

  4. #3784
    Citation Envoyé par Captain_Cowkill Voir le message
    Je rêve du jour où je comprendrai ce que vous dites
    Là c'est des mots compliqués alors que c'est simplement réguler l'accès (exclusif, ou pas) à une ressource. Pour éviter que tout se mélange, sinon c'est la cata assurée.

  5. #3785
    Je me suis plains récemment du Python qui permet d'ajouter des méthodes au runtime sur un objet.
    Bon déjà, comme l'a à juste titre mentionné un collègue, on peut faire plus vicieux, aussi : on peut remplacer une méthode par une autre implémentation.

    Mais surtout, on peut faire pire...


    Je suis tombé sur ça :




    Ma réaction :




    Donc le jour où A n'hérite plus de B, ça se foire.
    Le mec qui a codé ça a réussi à créer un couplage fort entre la classe C et... et les liens d'héritage de la classe A.


    C'est la pire des magouilles "objet" que j'ai jamais vue.
    Et croyez-moi j'en ai vu des trucs crades.

  6. #3786
    une balle, un imp (Newstuff #491, Edge, Duke it out in Doom, John Romero, DoomeD again)
    Canard zizique : q 4, c, d, c, g, n , t-s, l, d, s, r, t, d, s, c, jv, c, g, b, p, b, m, c, 8 b, a, a-g, b, BOF, BOJV, c, c, c, c, e, e 80, e b, é, e, f, f, f, h r, i, J, j, m-u, m, m s, n, o, p, p-r, p, r, r r, r, r p, s, s d, t, t
    Canard lecture

  7. #3787

  8. #3788
    Mais pourquoi faire des classes et de l'héritage dans un langage de script ?

  9. #3789
    Pour tromper l'ennemi.
    Baalimologue - Le topic du The Voice of the X-Factor Canard's Got Talent & autres Vocalises.
    Battle.net (Diablo 3) : Fbzn#2658 ----- / ----- / ----- Steam ID

  10. #3790
    Citation Envoyé par TwinBis Voir le message
    Mais pourquoi faire des classes et de l'héritage dans un langage de script ?
    Parce qu'ils sont jaloux des vrai langages qui se débarrassent de leur boilerplate tout en gardant toutes leurs forces.

  11. #3791
    Tout ça pour qu’on ne se foute pas de la gueule de leur Hello world
    une balle, un imp (Newstuff #491, Edge, Duke it out in Doom, John Romero, DoomeD again)
    Canard zizique : q 4, c, d, c, g, n , t-s, l, d, s, r, t, d, s, c, jv, c, g, b, p, b, m, c, 8 b, a, a-g, b, BOF, BOJV, c, c, c, c, e, e 80, e b, é, e, f, f, f, h r, i, J, j, m-u, m, m s, n, o, p, p-r, p, r, r r, r, r p, s, s d, t, t
    Canard lecture

  12. #3792
    Citation Envoyé par ducon Voir le message


    Pourquoi c'est moi qui hérite de ce tas d'immondices ?

    Citation Envoyé par GrandFather Voir le message
    Mais... Pourquoi ?
    Pour me pousser à ouvrir cette sandwicherie dont je parle chaque fois que je mets à déprimer devant ce vieux pipeline tout pourri.

    Citation Envoyé par TwinBis Voir le message
    Mais pourquoi faire des classes et de l'héritage dans un langage de script ?
    Hého hein. Monsieur le troll. Le python, typé "script" ou pas, interprété ou pas, c'est vendu comme un langage objet.
    Mais t'inquiète pas, j'ai grillé dès le départ que c'était un langage objet de merde.
    A l'instant précis où j'ai vu qu'il fallait passer le thi... pardon, le self en premier paramètre de chaque métho... euh fonction.

    Comme en ADA ou en C quoi. Putain. Et c'est vendu comme un langage objet et moderne.

  13. #3793
    Le python, c'est vraiment le truc dont je ne comprends pas l'engouement. J'admets que comme il pardonne plus d'erreur on code plus facilement en python pour un débutant, mais j'ai l'impression que c'est pas vraiment le cas pour quelqu'un de formé dans un autre langage et en python... et au final c'est a peu prés son seul avantage ...

    Nan vraiment, c'est incompréhensible.

  14. #3794
    Rien ne t’empêche de transformer ton code écrit en Python en C, par exemple.
    une balle, un imp (Newstuff #491, Edge, Duke it out in Doom, John Romero, DoomeD again)
    Canard zizique : q 4, c, d, c, g, n , t-s, l, d, s, r, t, d, s, c, jv, c, g, b, p, b, m, c, 8 b, a, a-g, b, BOF, BOJV, c, c, c, c, e, e 80, e b, é, e, f, f, f, h r, i, J, j, m-u, m, m s, n, o, p, p-r, p, r, r r, r, r p, s, s d, t, t
    Canard lecture

  15. #3795
    J'ai trouvé le Python très confortable pour faire de petits scripts utilitaires pour usage perso.
    De mémoire il m'a servi à faire du renommage par lot un peu chiadé, à créer un tool de backup qui rameute des fichiers via SCP et les conserve en local, ce genre de trucs.
    Il est très complet pour les manipulations de fichiers et, surtout, de chaînes de caractères.

    En comparaison, je ne comprends d'ailleurs toujours pas pourquoi la STD est si avare en services sur les std::string en C++.

    Par contre, ça m'a l'air d'être un choix vraiment naze pour bâtir un gros pipeline sur lequel vont bosser un large panel de personnes dans le temps.
    Comme tu peux faire n'importe quoi avec, bah... les gens font n'importe quoi avec.
    Et puis bordel... le typage faible et le typage dynamique c'est vraiment un fléau tu ne sais jamais ce que tu manipules.

    La raison pour laquelle on fait surtout du Python dans mon taf actuel, c'est je pense parce que la plupart des applis avec lesquelles on interagit supportent surtout/uniquement le Python.

  16. #3796
    De notre coté (start-up avec un bon pied dans le coté recherche/université) on vois surtout Python chez les chercheurs : car le on-boarding est simple (un éditeur text et tu peux te lancer) et probablement aussi que quand tu ne viens pas du domaine, un aspect "script" est moins intimidant qu'un aspect "application".

    Le problème c'est que ça s’entretient ensuite : les académiciens font des libs Python, donc les académiciens vont sur Python à cause ça. On a commencé à utiliser des algos avancés pour certains de nos besoins (pas de l'IA mais plus très loin) et.. on a commencé à mettre du Python dans notre stack à cause de ça.

  17. #3797
    Citation Envoyé par Taro Voir le message
    J'ai trouvé le Python très confortable pour faire de petits scripts utilitaires pour usage perso.
    De mémoire il m'a servi à faire du renommage par lot un peu chiadé, à créer un tool de backup qui rameute des fichiers via SCP et les conserve en local, ce genre de trucs.
    Il est très complet pour les manipulations de fichiers et, surtout, de chaînes de caractères.

    En comparaison, je ne comprends d'ailleurs toujours pas pourquoi la STD est si avare en services sur les std::string en C++.
    Pour les scripts sur les fichiers je suis tout à fait d'accord.
    Une autre utilité c'est en science en alternative à Matlab avec matplotlib.

    Mais c'est plus un remplacement de script et d'affichage qu'un véritable usage en tant que "langage" pour faire des applications dans ces deux cas.

    - - - Mise à jour - - -

    Citation Envoyé par Taro Voir le message
    La raison pour laquelle on fait surtout du Python dans mon taf actuel, c'est je pense parce que la plupart des applis avec lesquelles on interagit supportent surtout/uniquement le Python.
    Ouais mais c'est aussi la raison pour laquelle on l'enseigne. Et au final c'est quand même une sacré mauvaise raison

    - - - Mise à jour - - -

    Citation Envoyé par Dross Voir le message
    Le problème c'est que ça s’entretient ensuite : les académiciens font des libs Python, donc les académiciens vont sur Python à cause ça. On a commencé à utiliser des algos avancés pour certains de nos besoins (pas de l'IA mais plus très loin) et.. on a commencé à mettre du Python dans notre stack à cause de ça.
    Dans mon domaine c'est particulièrement drôle : toutes les librairies pour réseaux de neurones sont dispo principalement en ... Python mais écrites surtout ... en C...
    Et c'est un héritage d'autant plus stupide que dans ce domaine on est tous informaticien .

  18. #3798
    Dans le réseau aussi y'a plein de libs (cisco, junos, ipsec, etc) qui sont super en Python, et parfois uniquement dispo/maintenues sur cette plateforme. Et les libs sont très matures (tout l'inverse de certaines libs en JS/Node ou Kotlin par ex (même si Kotlin c'est la JVM et donc compatible Java, y'a plein de projets Kotlin qui sont encore trop limite, je trouve)).
    Puis, pour avoir participé à la migration d'un gros applicatif (réseau de FAI et plein de microservices) de Kotlin vers Python, l'équipe est unanime : Python > Kotlin. Python a des défauts, mais il est aussi souple, rapide à prendre en main, et même s'il permet de faire des conneries (comme TOUS les langages), rien n'empêche d'apprendre les bonnes pratiques et de verrouiller ça avec les bons linters et revues de code.
    Kotlin (et son écosystème) reste super, mais là, sur notre projet et dans notre environnement, Python a certains avantages et on en est très contents. Un an plus tôt, quand on s'est mis à Python, j'aurais jamais imaginé dire ça ^^.

    Si l'on reproche la mocheté du Python pondu par des chercheurs c'est, j'imagine, parce que l'on parle de matheux pour qui coder est une torture. Math != Informatique.

  19. #3799
    Oui c'est sur que tu peux toujours trouver moyen de faire n'importe quoi. Après tout en C/C++ avec des manips à base de pointeurs de fonctions on peut reproduire la méthode bar() qui appelle foo() comme sur mon schéma.

    Mais bon, quel que soit le langage, je ne peux revenir en arrière pour demander au type de ne pas faire ce genre de truc crade.
    Ni discipliner mes collègues.


    Vu la tronche du pipeline dont j'ai hérité, il est clair que les concepts SOLID n'entraient pas en ligne de compte dans sa conception.

  20. #3800
    Haha, c'est certain

    Du coup si vous avez laissé le type pondre cet étron, c'est qu'il n'y a pas d'étape de relecture ou validation ? Le soucis est peut être plutôt là.
    Si tu hérites du truc et qu'on ne te donne pas du temps pour le remettre dans un état convenable, c'est aussi un autre soucis.

  21. #3801
    J'ai une très mauvaise impression de Python, mais je l'utiliserais sans mal pour éviter de coder à nouveau en Matlab voire en bash (j'aimais bien, mais non, sérieux, c'est plus possible).
    Pour le reste, Python est massivement poussé par des gens qui ne peuvent travailler qu'avec ça, et ouais ça comprend de plus en plus de chercheurs. Raison pour laquelle on ne me reverra sans-doute plus jamais dans un labo.

  22. #3802
    Citation Envoyé par Taro Voir le message
    Je me suis plains récemment du Python qui permet d'ajouter des méthodes au runtime sur un objet.
    Bon déjà, comme l'a à juste titre mentionné un collègue, on peut faire plus vicieux, aussi : on peut remplacer une méthode par une autre implémentation.

    Mais surtout, on peut faire pire...


    Je suis tombé sur ça :

    https://i.ibb.co/RQPQYzw/tcprinh.png


    Ma réaction :

    https://media.giphy.com/media/d2lcHJTG5Tscg/giphy.gif


    Donc le jour où A n'hérite plus de B, ça se foire.
    Le mec qui a codé ça a réussi à créer un couplage fort entre la classe C et... et les liens d'héritage de la classe A.


    C'est la pire des magouilles "objet" que j'ai jamais vue.
    Et croyez-moi j'en ai vu des trucs crades.
    Tu découvres le duck typing ?

  23. #3803
    Citation Envoyé par gros_bidule Voir le message
    Dans le réseau aussi y'a plein de libs (cisco, junos, ipsec, etc) qui sont super en Python, et parfois uniquement dispo/maintenues sur cette plateforme. Et les libs sont très matures (tout l'inverse de certaines libs en JS/Node ou Kotlin par ex (même si Kotlin c'est la JVM et donc compatible Java, y'a plein de projets Kotlin qui sont encore trop limite, je trouve)).
    Puis, pour avoir participé à la migration d'un gros applicatif (réseau de FAI et plein de microservices) de Kotlin vers Python, l'équipe est unanime : Python > Kotlin. Python a des défauts, mais il est aussi souple, rapide à prendre en main, et même s'il permet de faire des conneries (comme TOUS les langages), rien n'empêche d'apprendre les bonnes pratiques et de verrouiller ça avec les bons linters et revues de code.
    Kotlin (et son écosystème) reste super, mais là, sur notre projet et dans notre environnement, Python a certains avantages et on en est très contents. Un an plus tôt, quand on s'est mis à Python, j'aurais jamais imaginé dire ça ^^.

    Si l'on reproche la mocheté du Python pondu par des chercheurs c'est, j'imagine, parce que l'on parle de matheux pour qui coder est une torture. Math != Informatique.
    Nan mais on peut toujours trouver un langage plus pourris, c'est pas un vrai argument ça

    - - - Mise à jour - - -

    Citation Envoyé par vectra Voir le message
    J'ai une très mauvaise impression de Python, mais je l'utiliserais sans mal pour éviter de coder à nouveau en Matlab voire en bash (j'aimais bien, mais non, sérieux, c'est plus possible).
    Pour le reste, Python est massivement poussé par des gens qui ne peuvent travailler qu'avec ça, et ouais ça comprend de plus en plus de chercheurs. Raison pour laquelle on ne me reverra sans-doute plus jamais dans un labo.
    Perso ça me sort par les trous de nez, la plupart des chercheurs ont amplement les capacités pour apprendre d'autres langage bien plus sympa.

  24. #3804
    Concrètement quand je vois l'usage dans mon labo de physiciens je comprends l'engouement.

    En python pur c'est toute la partie lecture/Traitement de paramètres, préparation des données, enregistrement et post-proc. Pour le gros des calculs, tout est enfourné dans des grosses libs de calcul performantes.

    Du coup c'est rapide à mettre en place, pas trop foireux à maintenir et performant malgré tout... Si on tombe dans le cas d'usage c'est assez parfait.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  25. #3805
    Je fais du python en ce moment, pour du dev web et bah c'est franchement pas mal.
    J'utilise le framework Django, tu as vraiment une manière très logique d'organiser les choses. L'absence de type est gênante, mais moins que ce que j'imaginais. Notamment parce que avec le framework certaines codifications sont en place, et les arguments nommés aident pas mal aussi.

  26. #3806
    Citation Envoyé par Lazyjoe Voir le message
    Concrètement quand je vois l'usage dans mon labo de physiciens je comprends l'engouement.

    En python pur c'est toute la partie lecture/Traitement de paramètres, préparation des données, enregistrement et post-proc. Pour le gros des calculs, tout est enfourné dans des grosses libs de calcul performantes.

    Du coup c'est rapide à mettre en place, pas trop foireux à maintenir et performant malgré tout... Si on tombe dans le cas d'usage c'est assez parfait.
    Perso je trouve que, dans mon domaine du moins, ça fait de la mauvaise recherche : tu n'ira jamais mettre la main dans les-dites libs, et tu ne codera jamais vraiment tes calculs expérimentaux en python pur (souvent parce que tu a perdu l'habitude ou que ce serait moche et lent), le résultat c'est que tout le monde converge vers ... l'usage prévu par les libs.

    C'est très visible en recherche en IA par exemple : tout le monde utilise des libs déjà toutes faites, et tout les papiers se ressemblent.

    C'est bien simple : je venais d'un labo qui codait tout en C avec une API IA maison, c'était dur à prendre en main, mais le labo publiait sans arrêt des nouvelles IA ou tout était testé, tripatouillé, des nouveaux paradigmes était mis au banc d'essai très souvent. Puis je suis passé dans un labo ou tout le monde fait Python + librairie : et en gros ce n'est plus que de l'application de chose déjà faites, avec application sur un autre cas d'usage. (soit 99.9% des papiers d'IA moderne).

    Et pour moi, la méthode de travail est directement responsable : mes collègues actuel n'ont juste jamais vraiment codé un réseau de neurone eux même, leur connaissance du fonctionnement de la chose est de fait assez théorique... parce qu'ils se reposent sur un langage qui ne pousse pas à ça et qui utilise des bibliothèques ou personne ne va mettre les mains dedans.

    Donc oui, quand tu tombe dans le cas d'usage prévu par les libs, c'est OK, mais pour le reste ...

  27. #3807
    Vu à un autre niveau dans un autre domaine cette fois-ci utilisateur, effectivement les mecs rapportent qu'ils sont juste là pour pousser leurs données perso dans des moulinettes existantes qu'ils ne cherchent pas à comprendre.
    Retouche les scripts récupérés ci et là et papier.

    Vive la recherche (enfin, c'est pas partout pareil heureusement).

  28. #3808
    J'ai bossé dans un grand labo c'était C/C++/Python pour la "science" et Java pour la partie administrative.
    Un de mes collègues Java s'est fait débaucher pour 'industrialiser' le python des scientifiques: en effet chaque nouvel arrivant scientifique repartait de zéro car il ne comprenait pas (ou ne voulait pas comprendre) le travail fait par son prédécesseur.
    Ce collègue qui était bien content de quitter le monde Java était quand même déprimé par l'ampleur de la tâche: c'était un peu ses écuries d'Augias.

    Pour le Python j'ai quand même l'impression qu'il y a au moins deux usages très différents: le scientifique (avec les travers cité plus haut) et les développeurs en informatique administrative de "base". Ce créneau a été le royaume du Java pendant une vingtaine d'année,
    avec des trucs heureux et d'autres moins (EJB2?) et l'envie pour certains dev d'aller voir ailleurs (C#, Ruby, Python, Node, ...).

    J'ai l'impression qu'aujourd'hui Python devient LE langage des études d'informatique et remplace Java, et comme il est particulièrement bien taillé pour ce rôle, les étudiants doivent trouver ce langage génial et ne voient pas pourquoi ils auraient besoin d'apprendre autre chose.
    Du coup quand ils arrivent en entreprise et qu'on leur sert un vieux projet en Java ils doivent trouver ça bien merdique. Et ils vont rejoindre le troupeau des haters, font des blogs pour dire combien Java c'est de la merde... et finissent par trouver/démarrer un projet en Python.
    Avec un nouveau cycle d'imprévus à résoudre qui font voir les limites du langage.

    J'ai vécu ça avec Groovy: après 2 ans de maintenance d'un projet bancaire en EJB2/Swing qui m'avait amené aux portes de l'enfer, j'avais trouvé un nouveau poste (dans le labo cité plus haut), avec de la maintenance d'un vieux truc en Java web (bof) et surtout un nouveau gros projet en Groovy/Grails (groovy c'est une sorte de Ruby compatible Java à 100% et grails bha c'est rails avec Groovy). Au début c'est génial, et au bout de deux ans c'était horrible: le projet était infernal à maintenir car il y avait trop d'incertitudes à cause du manque de typage, il y avait des trucs de meta-programming (comme dans l'exemple de Taro) partout qui rendait très opaque la visibilité... En gros dès que nous sommes parti en prod ça a été le début des gros problèmes: faire un POC à 2 personnes c'est très grisant avec un langage dynamique; corriger les bugs en prod et faire évoluer le code avec une plus grande équipe ça à de grandes chances de devenir un gros cauchemar.
    Dernière modification par William Vaurien ; 17/04/2021 à 12h28.

  29. #3809
    This.
    Des outils différents pour des cas d'usage différents.

  30. #3810
    Citation Envoyé par gros_bidule Voir le message
    rien n'empêche d'apprendre les bonnes pratiques et de verrouiller ça avec les bons linters et revues de code.
    Clairement.
    La qualité d'un projet vient très peu de la "qualité" (hautement subjective) du langage mais bien plus de l'environnement et des process de dev.

    Citation Envoyé par gros_bidule Voir le message
    Si l'on reproche la mocheté du Python pondu par des chercheurs c'est, j'imagine, parce que l'on parle de matheux pour qui coder est une torture.
    Du code moche pondu par des chercheurs j'en ai vu dans tous les langages.
    Reprendre des algos dev au CEA ou DGA pour les optimiser et les intégrer dans des vraies applis c'est d'ailleurs un des créneau de ma boite actuelle.

    Citation Envoyé par Cwningen Voir le message
    Tu découvres le duck typing ?
    Pas besoin de duck typing pour faire ce genre d’horreur.
    C'est la faute à Arteis

Page 127 sur 133 PremièrePremière ... 2777117119120121122123124125126127128129130131132133 DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •