Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Bidouille & Développement Informatique
Agrandir
Bidouille & Développement Informatique
Les Mains dans le Cambouis
Bidouille & Développement Informatique
Actu 1 1
Articles
Médias 33 33
Tutoriels
Forums 326 326

Sujet Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 122 802 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
701
Gremlins > aucune idée :D

Gabou > C'est vrai, il y a beaucoup de manière d'écrire la même chose en C++, et théoriquement Python essaie de limiter à une seule manière de faire qqch, mais sans vraiment y arriver. Peut-être avec Python 3 ? Plusieurs paradigmes différents = plusieurs manières de coder la même chose.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

702

Citation :
Peut-être avec Python 3 ? Plusieurs paradigmes différents = plusieurs manières de coder la même chose.



Different paradigme ne veut pas du tout dire coder la meme chose, ou alors tous les langages sont les memes du moment qu'ils sont turing complete, mais une fois que tu as dit ca... Il y a certains algos qui vont avoir une solution elegante avec un certain paradigme, d'autres avec un autre. Passer un argument par copie ou par reference, c'est un detail d'implementation, ca n'a aucune autre espece d'importance, et ce n'est pas une difference de paradigme pour moi. C'est comme virtual / non virtual, ce type de trucs. C'est un non sens d'avoir ce type de constructions dans un langage un tant soi peu "haut" niveau.

Le coup des strings, et des containeurs en general, c'est significatif du probleme en C++ pour moi: c'est le truc qui est vraiment plus facile dans tout langage en gros plus haut niveau que le C, sauf en C++. Et c'est lie au manque de GC; pour un langage comme le C, c'est normal, c'est le but de controler ce genre de choses. Mais pour un langage "haut" niveau, ne pas avoir ca, c'est vraiment chiant.

Tant que le C++ se cantonne a etre un C avec un peu de syntaxe autour, ok, c'est sympa. Une fois que ca devient du n'imp en utilisant une horreur type template pour faire de la meta programmation et faire des trucs a la boost::bind ou boost::lambda... La, non :surpris:
703

Citation : Le C++ propose plusieurs paradigmes de programmation, et Python aussi, entre la programmation fonctionnel ou objet, c'est tout de même assez différent


A la place de "fonctionnel" tu veux probablement dire "impératif" ? Car ni C++ ni Python ne sont fonctionnel ; sont fonctionnels : lisp, CAML et OCAML...

Citation : On peut faire du joli code en C++ (QT en est un exemple), apres, c'est sur, mais c'est super dur. Le langage est tellement enorme, que tout le monde utilise un "sous C++"... Du coup, c'est courant de voir du C++ completement incomprehensible parce que c'est tres different de ce dont tu as l'habitude.


Je ne pense pas que ce soit très dur de faire du code clair ; ou alors disons que ce n'est pas compliqué mais que c'est long et fastidieux. En plus il est difficile de résister à la tentation de faire des trucs "acrobatiques" (pour "faire objet" notamment), et c'est là que ça devient franchement impossible à maintenir.

Citation : Le coup des strings, et des containeurs en general, c'est significatif du probleme en C++ pour moi: c'est le truc qui est vraiment plus facile dans tout langage en gros plus haut niveau que le C, sauf en C++. Et c'est lie au manque de GC; pour un langage comme le C, c'est normal, c'est le but de controler ce genre de choses. Mais pour un langage "haut" niveau, ne pas avoir ca, c'est vraiment chiant.


En fait tout ça s'explique par des raisons historique et non par des choix bien réfléchis : C avait pour but de remplacer l'assembleur, donc il est à la fois volontairement bas niveau, et involontairement "pauvre / laborieux" parce-que ancien. C++ a essayé de l'enrichir, mais a perdu son homogénéité pour garder une compatibilité ascendante. L'histoire de Perl est encore pire ; tandis que Python devait être déjà assez complet dès sa première version.

Comme toujours la compatibilité ascendante est gage de succès commercial mais aussi d'un gros manque d'élégance / cohérence !

Citation : Pour ce type de trucs, je pense qu'il faut avant tout d'excellents programmeurs. Je sais pas si t'as lu cet article sur une des equipes qui programment pour la navette spatiale... Ils font du code sans bug, en gros.

http://www.fastcompany.com/online/06/writestuff.html


Ya plein de trucs que j'ai trouvés très intéressants dans cet article. Ironiquement ça défend exactement le contraire de la "programmation agile" et de la "méthode bazar" (opposée à cathédrale dans le fameux article de Eric Raymond).

Ca rejoint l'une des thèses du livre (excellent) "Mythical man-month" qui démarre par une citation de restaurant : "la bonne cuisine prend du temps, si on vous fait attendre c'est pour mieux vous satisfaire"...

Par contre il y a aussi beaucoup de points très discutables :
- les démarches de Sun, Microsoft et Netscape ne sont absolument pas comparables.
- la navette spatiale n'est pas un exemple si isolé : les commandes électriques des Airbus, le logiciel des centrales nucléaires sont aussi critiques et fiables (et le nombre de morts potentiels est beaucoup plus important)
- les langages utilisés et les outils peuvent jouer un rôle très important : les méthodes formelles, des outils comme ObjectGeode (programmation en SDL) ou comme Core pour la gestion d'exigences... font une différence énorme.
- l'article compare des choses pas comparables car cette méthode a un coût. Si on regarde le service rendu par rapport au temps passé, on s'aperçoit vite que dans la plupart des domaines il est impossible de se permettre un tel niveau de qualité. En fait en moyenne un développeur de soft "industriel classique" produit 25 lignes quand un développeur de code critique en produit 5 et seulement 1 ligne pour de "l'embarqué vital"...

Mais par contre le côté minutieux plutôt que "Cowboy coding" (voir http://c2.com/cgi/wiki?CowboyCoding , d' ailleurs il y a beaucoup de réflexions pertinentes sur ce site, accessoirement l'inventeur du wiki), pour les spécifications détaillées, pour les tests croisés, pour la stabilité des specs après les débuts de la réalisation... l'article dit beaucoup de choses vraies qu'on lit trop rarement (quand on écrit pas tout bonnement le contraire !)

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

704

Citation :
En fait tout ça s'explique par des raisons historique et non par des choix bien réfléchis : C avait pour but de remplacer l'assembleur, donc il est à la fois volontairement bas niveau, et involontairement "pauvre / laborieux" parce-que ancien. C++ a essayé de l'enrichir, mais a perdu son homogénéité pour garder une compatibilité ascendante. L'histoire de Perl est encore pire ; tandis que Python devait être déjà assez complet dès sa première version.



Je suis bien conscient de l'histoire du C++. Quand tu lis Stroustrup, tu peux voir qu'il y a une justification pour chaque truc.

Citation :
Ya plein de trucs que j'ai trouvés très intéressants dans cet article. Ironiquement ça défend exactement le contraire de la "programmation agile" et de la "méthode bazar" (opposée à cathédrale dans le fameux article de Eric Raymond).



Pas vraiment: tu developpes pas tout comme tu developpes l'exemple donne. Unix est ne tres rapidement, et aujourd'hui encore, c'est le modele de tous les OS.

Il est bien dit d'ailleurs que le cout est eleve, comme tu le dis toi meme. Il n'y a pas une methodes applicable a tout. Typiquement, l'open source a montre que pour faire un OS ou certains types d'applis, ca marche tres bien.
705
Dr Pouet > non, je sais ce qu'estimpératif, j'ai bien dit fonctionnel. Python a emprunté à Haskell certaines choses, on peut programmer de manière fonctionnelle.

La nouvelle norme du C++ va ajouter la possibilité d'avoir un GC et de l'activer si besoin, donc ça ira. Et Python a pas mal évolué depuis le début, je ne crois pas qu'il y ait de GC avec la version 2, mais c'est à revérifier.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

706

Citation :
Python a emprunté à Haskell certaines choses, on peut programmer de manière fonctionnelle.



Pas enormement non plus, et ca va d'ailleurs en diminuant (python 3000 devrait voir l'abandon de map, reduce, voire lambda); ce que python a pris de hasksell, c'est les list comprehension, ce genre de trucs, qui ne sont pas particulierement fonctionnels (c'est juste une jolie syntaxe pour faire des operations sur des containers).

Apres, ca depend de ce que l'on appelle functionnel, c'est comme objet, ca veut plus rien dire. Pour certains, ca veut juste dire qu'une fonction peut etre passee en argument, et a ce niveau la, tous les langages objets, y compris le C++, sont fonctionnels... Ca permet quelques trucs sympas du fonctionnel, mais sans plus le python a ce niveau la.

Pour moi, LE truc fondamental du fonctionnel, c'est de privilegier le "stateless", ce genre de choses. Et la syntaxe qui va avec pour rendre le truc lisible.

Citation :
Et Python a pas mal évolué depuis le début, je ne crois pas qu'il y ait de GC avec la version 2, mais c'est à revérifier.



Si, il y a un GC pour resoudre les cycles, qui ne peuvent pas etre resolus par le systeme de base de gestion memoire en python, a savoir le reference counting. Pypy est une implementation de python en python qui permet optionnelement de faire appel a un GC de maniere globale, par contre. Et evidemment, jython (implementation de python sur JVM) et ironpython (idem sur CLR) utilisent un GC.

En fait, avant, quand je parlais de GC, il fallait bien sur comprendre systeme de gestion de memoire automatique, et non GC en soi.
707

Citation : Pas vraiment: tu developpes pas tout comme tu developpes l'exemple donne.


Certes. Mais les promoteurs des méthodes Agile, XP, Bazar et compagnie oublient la plupart du temps de rappeler que leur méthode ne s'applique pas à tout. Je ne me rappelle pas qu'à un seul instant Eric Raymond décrit des cas où sa méthode bazar ne s'applique pas. Dans l'absolu la méthode cathédrale devrait donner à la fois les softs les mieux conçus et les moins coûteux.

Le problème c'est que dans la plupart des cas on ne sait pas exactement ce que l'on veut faire, donc on commence et on corrige au fur et à mesure ; c'est malheureusement souvent inévitable.

Citation : Unix est ne tres rapidement, et aujourd'hui encore, c'est le modele de tous les OS.


Je ne dirais pas qu'Unix est né très rapidement. Déjà, de par l'expérience de l'équipe qui l'a conçu, les OS précédents ont servi de bases, que ce soit Multics ou d'autres (VMS qu'ils devaient connaître également et qui avait très bonne réputation). D'après https://fr.wikipedia.org/wiki/UNIX et https://en.wikipedia.org/wiki/Unix les débuts datent de 69, mais c'est plus tard qu'il s'est popularisé : en 78 il n'y avait que 600 machines à l'utiliser.

Donc avec l'expérience de gusses comme Ken Thompson, additionnée au temps de maturation du bidule, ça colle effectivement bien avec l'idée qu'il faut prendre son temps pour faire les choses bien.

Citation : Pour moi, LE truc fondamental du fonctionnel, c'est de privilegier le "stateless", ce genre de choses. Et la syntaxe qui va avec pour rendre le truc lisible.


Je suis assez d'accord. Surtout que maintenant la quasi totalité des applications sont conçues de manière multi-thread, alors que peu de gens mesurent les difficultés qui en découlent.

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

708
:?!:
FX
709
Oups, pardon, je voulais dire avant la version 2, ce que je viens de revoir d'ailleurs.
map, reduce et filter ne vont pas disparaître, j'avais lu qu'ils seraient dans un module particulier, ce qui serait plus logique étant donné qu'ils travaillent sur des listes principalement et que par exemple pour NumPy, utiliser map ne fonctionne pas trop :)
Mais ça a peut-être évolué depuis, je pense que je vais aller m'abonner à la ML de développement... En fait, c'est surtout que j'ai beosin d'infos sur le futur de Python pour un projet.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

710

Citation :

Certes. Mais les promoteurs des méthodes Agile, XP, Bazar et compagnie oublient la plupart du temps de rappeler que leur méthode ne s'applique pas à tout. Je ne me rappelle pas qu'à un seul instant Eric Raymond décrit des cas où sa méthode bazar ne s'applique pas. Dans l'absolu la méthode cathédrale devrait donner à la fois les softs les mieux conçus et les moins coûteux.



Je mettrais pas agile et co et ce que dit E. Raymond dans le meme sac, le contexte et le but ne sont pas du tout le meme. De memoire, Raymond donne bien des exemples de trucs ou l'open source ne marche pas tres bien: jeux video par exemple; je pense pas que ce soit super adapate pour des programmes ou l'interface graphique est preponderante, aussi, a moins qu'il y ait de forst interets financiers: typiquement, un soft comme live! ou Reaktor, je crois qu'on n'en verra jamais en open source.

En fait, je ne crois pas du tout que l'open source soit la panacee (j'ai pas enormement d'experience non plus); par contre, il a prouve qu'il etait un puissant moteur pour faire bouger les choses dans une industrie qui beneficie quand meme de sa propre incompetence trop souvent. L'experience montre quand meme que l'open source marche bien avec un leadership tres fort (le noyau linux, Kde, Gnome, Firefox, Debian, Ubuntu). Un truc comme Debian, par exemple, c'est pas vraiment dans l'esprit de faire de la programmation XP: c'est au contraire assez contraignant, et c'est certainement le plus gros projet en lignes de code ayant jamais existe.

Globalement, pour tout ce qui est destine a des programmeurs, je trouve l'open source en general extremement superieur a ce que fournit sa contre partie proprietaire. Gnome, aujourd'hui, est la meilleure interface graphique, largement devant Mac OS X a mon avis pour la simplicite et la coherence.

Citation :
e ne dirais pas qu'Unix est né très rapidement. Déjà, de par l'expérience de l'équipe qui l'a conçu, les OS précédents ont servi de bases, que ce soit Multics ou d'autres (VMS qu'ils devaient connaître également et qui avait très bonne réputation). D'après https://fr.wikipedia.org/wiki/UNIX et https://en.wikipedia.org/wiki/Unix les débuts datent de 69, mais c'est plus tard qu'il s'est popularisé : en 78 il n'y avait que 600 machines à l'utiliser.



J'aurai du etre plus precis: les concepts fondamentaux d'UNIX ont ete crees en peu de temps, et sont restes les references jusqu'a maintenant. Au niveau API, ca reste la reference depuis 30 ans maintenant. Apres, c'est sur que l'Unix de 72 et un Unix d'aujourd'hui, c'est un peu different.

Il y a d'autres exemples de trucs fondamentaux qui ont ete inventes en peu de temps au moins dans le concept (LISP, typiquement). Apres, que ca mette du temps a murir, sur.

Citation :
map, reduce et filter ne vont pas disparaître, j'avais lu qu'ils seraient dans un module particulier, ce qui serait plus logique étant donné qu'ils travaillent sur des listes principalement et que par exemple pour NumPy, utiliser map ne fonctionne pas trop



S'ils sont dans un module particulier, ca veut bien dire que le langage en lui meme ne tend pas a supporter le fonctionnel comme paradigme. En fait, Guido l'explique bien :

https://www.artima.com/weblogs/viewpost.jsp?thread=98196

Citation : En fait, c'est surtout que j'ai beosin d'infos sur le futur de Python pour un projet.



A priori, python 3000 (la prochaine version qui s'autorise des changements incompatibles) ne changera pas fondamentalement les choses. Tu t'attends a quoi comme changements ?