Sujet Le pub des programmeurs
- 1 925 réponses
- 117 participants
- 119 468 vues
- 130 followers
y a des programeurs sur AF si oui vous bossez sous quoi ?
Pov Gabou
batman14
Dr Pouet
Citation : > Par exemple les trucs largement interprétés (au lieu de compilé) ça ne les choque pas, pourtant c'est beaucoup plus sujets aux bugs.
Ca, j'y crois pas une seconde. Tu te bases sur quoi pour dire ca ? En plus, la difference compile, interprete, elle est super vague. Java, c'est interprete, compile ? IronPython (implementation de python en bytecode .net), c'est interprete ? La tendance de tous les langages a utiliser de la memoire automatiquement, a avoir des structures de haut niveau, bref, l'oppose du C++, c'est une tendance hyper lourde, je pense.
Effectivement, j'aurais du écrire à typage statique, ou plutôt à typage fort. Par exemple en C++ un pointeur sur un type T c'est pas un pointeur sur autre chose, et l'erreur sera détectée dès la compilation. En java, jusqu'à récemment (les génériques), une liste d'objets était une liste, indépendamment du type des objets manipulés. De ce point de vue les templates sont plus rigoureux.
Les langages genre Perl, Python, php qui ne sont quasiment pas typés (juste la distinction scalaire / liste), sont très propices aux erreurs. Les langages dont on peut changer le type des objet en cours d'exécution (ça doit être le cas pour Eiffel, objective-C et d'autres), sont aussi propices aux erreurs. Par contre Ocaml semble à la fois souple (peu de déclarations de types par le programmeur) tout en étant très rigoureux (analyse de type très poussée par le compilo).
Citation : Il y a compatibilite avec le C; des nouveaux projets en C++, je pense pas qu'il y en ait beaucoup aujourd'hui.
Ben yen a. Dans les gros trucs critiques que je croise, en gros c'est un peu plus de la moitié en java, le reste en C++.
Citation : Le calcul scientifique, t'as de moins en moins de gens a utiliser du Fortran
Chez ceux qui utilisent des machines dédiées (genre supercalculateur Fujitsu), il n'est pas courant que le compilo et la librairie de caclul soit optimisés dans d'autres langages que le Fortran. A la limite le C démarre mais représente qu'une petite part de marché. Faut voir que pour ces machines si tu utilises pas les outils optimisés, tu perds l'essentiel de la puissance, vu le prix (et les objectifs qui justifient l'achat de la bête), ce serait dommage.
Citation : Ben non, parce que la librairie standart est ecrite avec le C++ en tete, donc les templates et autres saloperies. Deja que c'est pas super fourni a la base...
Tu peux très bien utiliser la STL, sans définir toi même des templates acrobatiques. Je l'ai fait longtemps, alors me dis pas qu'on ne peut pas !
Citation : Je sais pas, donne moi un exemple concret ou ca t'as pose probleme, parce que perso, je vois pas.
Ben je te l'ai déjà donné. Tu prends un source de pseudo C++ (avec des mots clés genre Qt, ou Ilog Broker ou autre) et tu essaies de passer dessus un outil comme Insure ou Purify, et ben c'est cuit. Et si jamais tu as besoin d'une autre librairie qui elle aussi a enrichi le langage, généralement c'est indémerdable. C'est pour ça que le mieux est que personne le fasse.
Citation : J'ai jamais dit le contraire, j'ai presque l'impression que tu sous entends que parce que je pense que le C++ est presque jamais approprie, je pense qu'un autre langage peut tout faire...
Meuh non, faut pas s'emporter comme ça ! Je pense juste qu'il y a pas mal de cas où le C++ est le moins mauvais compromis. Il est évident que ce sont des situations où il y a pas mal de contraintes externes ; mais c'est souvent le cas dans de gros projets industriels.
Citation : Par exemple, pour mes projets lies a ma these, j'ai choisi python non parce que c'est le meilleur langage, mais parce que justement il y a un bon compromis performance - popularite - communaute vivate - expressivite.
Ben quand tu fais un truc qui ne vient pas se brancher dans des tas de choses existantes, qui n'est pas censé être maintenu pendant 15 ans par 6 dévelopeurs différents, c'est certainement un très bon choix. Pas de doute là-dessus.
Citation : Il faut etre capable d'apprendre de nouveaux langages, je pense que c'est fondamental une fois un langage bien maitrise; parce que chaque nouveau langage suffisament different t'apprend vraiment qqch de different.
Complètement d'accord avec toi. Et tu fais même des progrès avec ceux que tu connais déjà, ça te donne des idées à ré-utiliser (genre le toString de java à implémenter en C++)
Citation : > je ne ferais pas confiance à des universitaires pour choisir un langage de programmation.
Je trouve cette remarque vraiment typique de l'état d'esprit français qui scinde aussi nettement les mondes industriels et universitaires. A l'étranger la frontière entre les deux mondes est poreuse. On a moins cette espece de condescendance d'un millieu envers l'autre. Ca me navre de voir à quel point chacun s'ignore dans le meilleur des cas, ou se méprise dans le pire des cas.
C'était un peu de la provoc hein !
Moi aussi je regrette que les deux mondes soit aussi séparés. Je me trouve côté industriel actuellement, et j'ai essayé plusieurs fois de proposer des problématiques industrielles à des universitaires proches ; mais généralement c'est trop "terre à terre" pour les intéresser. Je trouve que c'est pourtant intéressant pour une université ou une grande école de bosser sur des projets du type ACE / TAO : c'est plus proche de l'info des industriels, ça oblige à travailler en groupe, à faire des compromis, des plannings, et ça contribue au renom de l'école.
Mais souvent (et j'espère que ça peut changer) on préfère en France des trucs plus théoriques, typiquement on a Bertrand Meyer face à Douglas Schmidt ou Richard Stallman.
Citation : c'est qu'on peut avoir des langages qui sont plus elegants que le C++
Là je suis d'accord.
Citation : qui sont *souvent* plus appropries, et que j'ai du mal a comprendre comment on peut *aimer* le C++.
Ben c'est le souvent qui dépend du contexte. Souvent tu vas avoir le choix entre C et C++. Ben personnellement je préfère largement le C++, étant bien entendu que je vais l'utiliser d'une manière très simple, en visant perpétuellement un code le plus humainement compréhensible. Et là je suis d'accord avec Stroustrup sur "C++ is a better C". ;)
Croisement avec batman14, je vois que nous sommes d'accord sur pas mal de points
Pov Gabou
Citation :
Je pense qu'il y a énormément de domaines où la gestion fine de la mémoire est importante.
Ok, t'as des exemples precis ? Parce que sur ce point, je suis en desaccord absolu. La performance de l'allocation a la main, c'est vrai dans certains cas, mais dans la majorite, un systeme automatique sera plus performant, j'en suis persuade, et ke le constate dans la plupart du code que j'utilise/developpe.
Pour la partie DSP des plug ins, la gestion memoire, il y en a pas, c'est simple, ou alors super bas niveau (en utilisant des pools; mais tu utilises pas de malloc classiques en tout cas)
Citation :
Effectivement, j'aurais du écrire à typage statique, ou plutôt à typage fort. Par exemple en C++ un pointeur sur un type T c'est pas un pointeur sur autre chose, et l'erreur sera détectée dès la compilation. En java, jusqu'à récemment (les génériques), une liste d'objets était une liste, indépendamment du type des objets manipulés. De ce point de vue les templates sont plus rigoureux.
Mais ton raisonnement ne tient que si tout le reste est inchange, ce qui est evidemment faux. T'auras plus d'erreurs ou d'exceptions en python qu'en C++, oui; mais de l'autre cote, ca a aussi contribue a la souplesse du langage. Avec python, t'auras pas de segmentation fault, t'as pas de dangling pointer, t'as pas de problemes de chaines de caracteres sans charactere de fin, etc... T'as la rapidite de protypage qui est une consequence directe du duck typing, et qui te permet de te focaliser sur l'api plutot que sur des details d'implementations, et ca a de sacres consequences sur le nombre de bugs. Donc t'as quand de sacres avantages qui vont avec.
J'ai une question vraiment sans arriere pensee: t'as deja programme en python ? Parce que sur le papier, tu rates la plupart des trucs. C'est vraiment lorsque j'ai converti un projet matlab -> python que j'ai eu ma premiere "revelation" quant a la puissance du truc. Tu peux refactoriser du code, de maniere vraiment differente du C/C++/java.
Pov Gabou
Dr Pouet
Pov Gabou
Citation :
Chez ceux qui utilisent des machines dédiées (genre supercalculateur Fujitsu), il n'est pas courant que le compilo et la librairie de caclul soit optimisés dans d'autres langages que le Fortran. A la limite le C démarre mais représente qu'une petite part de marché. Faut voir que pour ces machines si tu utilises pas les outils optimisés, tu perds l'essentiel de la puissance, vu le prix (et les objectifs qui justifient l'achat de la bête), ce serait dommage.
Supercalculateurs, je connais pas vraiment, donc je vais rien dire. Mais par contre, python est utilise pour de tres tres gros projets scientifiques (au Cern, pyroot est utilise sur des donnees qui se chiffrent en tera octets), et aussi comme glue pour sur de gros clusters (rien que google
). Evidemment, le core algebre lineaire, c'est BLAS/LAPACK. c'est du fortran ou du C a la limite; et la, le C++ n'a rien a apporter. Mais il y a la aussi, d'apres ce que j'observe, une tendance lourde vers un environnement ou de plus en plus de glue est faite dans un langage haut niveau.Et dans ces cas, de plus en plus courants, le C++ est une horreur, car impossible a appeler depuis d'autres langages (au moins sous linux, qui est la aussi de plus en plus utilise sur de gros clusters en calcul scientifique).
Pov Gabou
Citation :
J'imagine que ce moc traduit le Qt en C++ ? Le problème c'est si tu as un autre outil qui a la même démarche, à ce moment là il faudrait que tu ajoutes les mots clés de l'autre outil à ce qui sort de moc... T'imagines le bordel ?
Oui, c'est ca, pour moc. Clair que c'est pas super lisible; mais ton machine insure, c'est la mort avec n'importe quel truc non trivial a base de template. Genre la STL, ca doit etre pire que QT, parce qu'a debugger, laisse tomber. La, c'est carrement les messages du compilo que tu comprends pas (quand c'est pas le compilateur qui crashe; me souviens de VS 6 qui crashait plus que souvent avec les templates; et g++ m'a plante plusieurs fois. J'ai jamais vu gcc planter en mode C, meme dans des configurations farfelues genre compiler du code binaire pour solaris ultra sparc sur linux powerpc
).En fait, tu me donnes des arguments contre le C++ ?
batman14
Dr Pouet
Citation : Mais ton raisonnement ne tient que si tout le reste est inchange, ce qui est evidemment faux. T'auras plus d'erreurs ou d'exceptions en python qu'en C++, oui; mais de l'autre cote, ca a aussi contribue a la souplesse du langage. Avec python, t'auras pas de segmentation fault, t'as pas de dangling pointer, t'as pas de problemes de chaines de caracteres sans charactere de fin, etc... T'as la rapidite de protypage qui est une consequence directe du duck typing, et qui te permet de te focaliser sur l'api plutot que sur des details d'implementations, et ca a de sacres consequences sur le nombre de bugs. Donc t'as quand de sacres avantages qui vont avec.
Pour les char* et pbs de pointeurs, il faut effectivement prendre des mesures pour s'en sortir (à commencer par utiliser la librairie string des STL), mais ce serait un point pour Python.
Que signifie "duck typing" ?
Pour la rapidité de prototypage, ben dans les gros softs ce n'est pas recherché, au contraire. On essaie de faire des .h complets et élégants, et après on en bouge le moins possible.
Citation : J'ai une question vraiment sans arriere pensee: t'as deja programme en python ? Parce que sur le papier, tu rates la plupart des trucs.
Python j'ai juste regardé. Par contre j'ai pratiqué php et Perl qui ont pas mal de caractéristiques communes (même si Python est plus élégant). En Perl j'ai fait des générateurs de code C++
Mais sur des gros softs que tu maintiens pendant des années, un typage fort est vraiment un plus, quand même. Le côté lourdingue des .h devient plutôt un avantage. Mais là-dessus, le Pascal de Borland (qui n'a pourtant jamais du percer des des gros systèmes) avait beaucoup de qualité ; et avec une vitesse de compilation fabuleuse. Les belles technos sont-elles toutes vouées à la poubelle ?
Citation : pour la reutilisablite, y a une grosse difference entre le C et le C++ (c'est quasiment impossible d'appeler du C++ a partir d'autres langages directement dans la majorite des langages
On peut appeler du C++ à partir de C (déjà fait d'ailleurs !), donc on s'en sort. C'est sûr que le C est un meilleur candidat au mélange de langages.
Citation : sans parler du probleme que le standart C++ ne definit rien sur les conventions de linkage, ce qui est la encore vraiment une plaie
Complètement d'accord.
Citation : quand c'est pas le compilateur qui crashe; me souviens de VS 6 qui crashait plus que souvent avec les templates; et g++ m'a plante plusieurs fois.
Ha oui, il était très facile (et peut-être encore maintenant) de trouver quelques lignes de codes faisant planter g++ (xlc était un peu plus costaud, mais pas des masses, et non standard pour les templates). Ca t'encourage à faire du code simple !
Citation : En fait, tu me donnes des arguments contre le C++ ?
Ouais en fait on se place généralement pas dans le même contexte, mais je crois que quand on parle de la même chose on est d'accord ! En fait c'est juste que quand on a pas encore connu le cas de projets de plusieurs centaines de milliers de lignes (voire quelques millions), avec maintenance sur au moins 10 ans, avec des équipes qui tournent, des produits imposés (outils, librairies), des contraintes externes (brancher tel soft sur tel autre, l'un en C++ sur PC 32 bits little endian l'autre en ADA sur DEC 64bits big endian, et encore c'est un cas facile)... on imagine pas toutes ces difficultés !
Le mot compromis prend alors tout son sens ;)
- < Liste des sujets
- Charte