[debat]Programmation : quel langage ? [Archives]

Gigathlon

18/01/2004, 01h28

Le langage que je préfère est le C++, pour plusieurs raisons:

- langage d'assez haut niveau (fonctions complexes d'origine)
- possibilité d'intégrer du code assembleur
- j'adore le fonctionnement des structures :whistle:

Par contre si on me parle de VB j'ai les cheveux qui se hérissent encore plus qu'en temps normal, ce langage est beaucoup trop complexe pour encore être qualifiable de "basic" et trop peu efficace tant du point de vue du débogage que de l'efficacité du code généré.

Java j'ai toujours pas testé, et les frangins PHP et ASP sont un peu trop restrictifs pour permettre un développement vraiment rapide.

Bref, je vote C++ pour tout ce que ce langage comporte, assez explicite, polyvalent, efficace... que demander de plus? :P

SiX-P4cK

18/01/2004, 01h59

Bon bien vous allez debloquer.

1er année de graduat en informatique (equivanlent bac +3 en belgique)

En premiere et 2eme en fait du cobol et du fortran.
en 2eme on a un peu de C egalement
et en 3eme du C++

Chelou comme programme non?

Sinon j'aime bien le C, et je risque de bien aimé le C++ (j'en ai pas encore fait)

Gigathlon

18/01/2004, 02h09

Sinon j'aime bien le C, et je risque de bien aimé le C++ (j'en ai pas encore fait)

Tu rajoute un peu d'abstrait dans le C et tu obtiens le C++, avec toutes ses structures aussi farfelues que pratiques, intégrant de tout et n'importe quoi, les void... :love: :whistle:

En fait c'est à mon avis le langage à tout faire, aussi bien de la gestion de bases de données (grâce aux structures c'est franchement simple), le calcul (assembleur, compilateurs efficaces), le développement d'un projet multimedia (via le SDK DirectX principalement, qui n'est autre qu'un amas de magnifiques structures assez moyennement définies...)

Par contre le coup du Cobol ça m'intéresserait d'avoir l'avis de ton prof sur l'intérêt de l'enseigner, ou plutôt de s'obstiner à l'utiliser dans le milieu de la gestion alors qu'il a déjà montré quelques défauts non négligeables (dont le codage de la date il n'y a pas si longtemps...) :heink:

SiX-P4cK

18/01/2004, 04h21

Ouais.

il dit que le cobol c plus facile pour apprendre. :lol:

Puis surtout se qui m'enerve c'est que au programme sur les 3 ans on a:
250h de cobol
200h de fortran
50h de C
50h de C++

Neo_13

18/01/2004, 11h12

Ouais.

il dit que le cobol c plus facile pour apprendre. :lol:

Puis surtout se qui m'enerve c'est que au programme sur les 3 ans on a:
250h de cobol
200h de fortran
50h de C
50h de C++Moi, je dis pourquoi pas faire un peu de cobol... c'est une sorte de point de départ... Mais 250h :ouch:

Filou

19/01/2004, 15h16

SiX-P4cK tu fais ton graduat où ça?

stephlouv

19/01/2004, 20h07

Moi j'ai fait du logo sur MO5 a la petite ecole .... leve tortue / pose tortue etc .... l'ancetre d'AUTOCAD peut-etre :lol: :lol:
Sinon apres j'ai fait du Basic 1.1 sur mon Amstrad CPC 6128 !!! ouah ...
Puis du turbo pascal au lycée, en option informatique, Vachement utile passe que je me suis mangé 19 points de retard au bac francais ....
Puis un peu de Visual Basic, juste un peu .... et puis du C, juste un peu aussi... du pur et dur sous HPUX avec le puissant editeur "vi"

lechenejb

19/01/2004, 21h29

moi aussi j'ai fait du logo en primaire :D

PeNNeR

19/01/2004, 21h59

Moi je fais un peu de programmation en assembleur, mais c'est essentiellement pour la programmation de puces implantées dans des systèmes industriels :wink:

J'ai aussi fait du turbo-pascal :lol:

ririck

20/01/2004, 00h45

alors, dans les souvenirs :
aussi du logo !!
Le basic sur CPC, j'y ai trouché un peu, mais depuis il a plus son lecteur de disquette
J'ai aussi fait de la progra au collège, avec un soft dos sur des 33MHz, fallait programmer une table tracente !

fennec

20/01/2004, 09h07

C++ c'est super puissant mais c'est facile de faire du code crade :)

C'est aussi facile de faire du code propre :sarcastic:
Enfin je comprends ce que tu veux dire, mais c'est pas lié au C++ mais au langage objet en général.
Le truc c'est souvent les gens qui font du C++ on fait du C avant, alors dès qu'ils ont un petit problème ils se remettent a faire du C. Tu te retrouve alors avec un objet avec une methode qui contient tout le code, ou des objets qui ne servent que de structures avancées.

De plus certaine se trouvent obligés de faire de la redéficnition d'opérateur et tu te retrouves avec des trucs du style: "userA += userB" ce qui n'est parlant que pour le programmeur.

Le C++ est a mon avis un des langages les plus puissant et les plus permissif mais aussi un langage ou il faut avoir le plus de rigeur pour faire du code propre et maintenable.

De plus, pour moi commencer pas apprendre le C++ n'a pas de sens ...

Neo_13

20/01/2004, 09h13

Moi, j'ai démarrer par le logo vers 4-5ans, puis Basic 512 sur Thomson TO8 puis TO9+ (512ko de ram et modem 14k!!!!!!!!!), puis un peu de turbopascal sur PC, puis le langage TI-92, puis Maple, puis C, puis un peu de PHP...

juliusr

20/01/2004, 14h16

oh bah presque pareil pour moi en fait, dans l'ordre chronologique je dirai

logo en primaire
Basic sur TO8D chez moi et a l'école
Basic puis Visual Basic sur PC
HTML (qui n'est pas en language de prog mais bon)
Langage TI83 puis TI89
PHP/Javascript
C++/C#

[taz]

20/01/2004, 15h43

un peu de basic sur amstrad, puis sur 386

a la fac, on a eu droit au scheme (trop relou...), o-caml (du caml objet...), asm 8086/8087, asm mips r3000, sh, VB sous exel (l'horreur...)

et du php pour se detendre apres les cours ;)

lechenejb

20/01/2004, 20h05

à votre avis, le fait de devoir utiliser le framework est un + ou - pour le developpement en C#, sachant que sa permet d'alléger les programmes (il n'y a plus de dll ...)

ajnag

21/01/2004, 12h02

pour moi c'est un -
ça charge le client :/

Neo_13

21/01/2004, 16h11

à votre avis, le fait de devoir utiliser le framework est un + ou - pour le developpement en C#, sachant que sa permet d'alléger les programmes (il n'y a plus de dll ...)SAns réelle opinion, puisque je ne suis pas confronté réellement au problème...

ça charge le client :/

Mais alors, c'est un -...

lechenejb

21/01/2004, 20h05

sa dépend, si t'installe une fois les 20 Mo du framework ou de la machine virtuelle java ... c'est uen économie au final, toutes les fonctions ne sont présentent qu'une foie sur l'ordinateur

Neo_13

21/01/2004, 21h40

Note que perso, je préfère que le maximum de chose soit éxécuté coté serveur que client... Mais c'est pas toujours possible... Surtout en C# (du moins je crois, puisque je connais que très très mal le C#)

lechenejb

21/01/2004, 22h05

attention, je parle d'application executé, pas d'application web ...

Neo_13

21/01/2004, 22h21

ouais...

Pas fan quand même

fennec

21/01/2004, 22h23

Pour le C# et le Java, les machines virtuelles sont vraiemnt un plus a mon avis. Avec les api très complètes qu'elle fournissent on est pas obligé de ré-inventer la roue dans tous les sens comme en C ou en C++.

Au niveau de la sécurité c'est vraiment top car dans les deux cas on peut vraiment tout controler et éviter les problèmes avant que quelqu'un y songe :) Sans parler des buffer overflow qui font quasiement partie du passé dans ce cas.

Pour répondre a ceux qui disent que c'est moins rapide que le C ou le C++, je répondrais: "oui mais" :D dans 99% du temps une attente est due a un acces aux ressources (Net, HDD, Mémoire) et les 1% au temps de calcul du CPU, donc les langages a VM ne seront pas plus lent. Le C# propose d'ailleur un aspect intéressant avec le code "un-managed" qui permet de nouveau (si l'utilisateur et la VM ont les droits suffisants) d'acceder aux joies des pointeurs et de l'acces direct aux ressources.

donc pour moi les applis a machine virtuelles c'est : +++ :D surtout dans le monde professionel

Filou

23/01/2004, 14h57

entre installer une VM (un Framework) et fournir tout un fatras de bibliothèques pour toutes les situations possibles d'OS avec l'application, je pense que ça revient +- au même...

Gigathlon

23/01/2004, 18h21

entre installer une VM (un Framework) et fournir tout un fatras de bibliothèques pour toutes les situations possibles d'OS avec l'application, je pense que ça revient +- au même...

A mon avis c'est même exactement pareil :D

Les bibliothèques (DLL, .o par exemple) permettent de stocker ce dont l'OS a besoin pour faire tourner une appli "standard" en théorie, même si M$ a eu la bonne idée de baser purement et simplement la prog sur l'utilisation de DLLs... :whistle:

lechenejb

25/01/2004, 12h23

fennec

25/01/2004, 12h52

entre installer une VM (un Framework) et fournir tout un fatras de bibliothèques pour toutes les situations possibles d'OS avec l'application, je pense que ça revient +- au même...la différence je dirais c'est que tu fourni qu'une fois toutes les fonctions à la différences des dll que chaque programme inclus ...

De plus quand c'est MS ou Sun qui s'occupe de la sécurité (buffer overflow, certificats, réseau, etc.) ça fait plus sérieux que trucsoft and co ;)

nruiz

29/01/2004, 11h00

à votre avis, le fait de devoir utiliser le framework est un + ou - pour le developpement en C#, sachant que sa permet d'alléger les programmes (il n'y a plus de dll ...)

Pour l'instant, c'est pas vraiment un avantage : mais en voyant sur le moyen terme, sachant que de toute façon, tous les Windows auront bientôt le Framework par défaut, ça va être génial. Et puis, t'as plus à te soucier des DLL, surtout si tu n'installes pas l'appli que tu déployes sur un poste non-Français (les DLL anglaises posent souci :( avec des progs codés avec des DLL françaises)

fennec

29/01/2004, 21h22

spacelo

01/02/2004, 22h19

Pour avoir testé le c++ (depuis VC6) et récemment le c#, pour moi, il n'y a pas photo, le c# est vraiment super pratique, tout comme les apis du framework .NET d'ailleurs.

Bon, le c++ reste nécessaire pour certaines fonctions critiques en temps d'exec. Pour toutes les autres, c# !

assrockss

04/02/2004, 14h37

programmation système Unix POSIX, C et C++

ZB37

17/02/2004, 13h36

Bonjour,

Pour ma part, c'est Perl.

Facile à programmer, portable Unix <=> Windows et autres.

Bref le rêve quoi .

@+

Neopheus

17/02/2004, 19h45

Bonjour à Tous,

Je vais vous dire ce que j'en pense.

Pour ma part, je programme pas mal d'application bureautique, et des fois des clients/serveurs. Bref des applications typiquement orienté objet.

Je trouve que le C++ (voir C# pour certaine d'entre elle) et le Delphi sont des bons outils de programmation pour ce genre d'applications.

J'ai cependant une préférence pour les outils de Borland que je trouve nettement mieux pensé que ceux de Microsoft. (question de gout : ça se discute pas, désolé :P )

Pour ce qui est programmation de robo ou programmation industrielle. C'est soit de la programmation Grafcet, Assembleur, et pour les robo et machines outils qui l'acceptent du C voir C++ pour certaines. Mais bon, tout dépend de ce que l'on fait.

Je ne pense pas qu'il y est un langage qui soit vraiment que tous les autres. Mais chacun est bon dans son domaine (sauf VB qui est de la grosse daube :P : pas très puissant et aussi lent que du java, j'exagère mais autant que ça ;))

PS : la dernière phrase c'est pour taquiner ceux qui aiment le VB :P

doum

18/02/2004, 10h51

Perso de ce qu'on a gouté a l'iut...je dirais que j'aime bien le C, le C++. Je hais le Java, me demandais pas pourquoi c'est vicerale, j'en ai jamais rien sorti de correct.

On a gouté cette année au C#, ca a l'air sympa, mais on a pas approfondi. Permet de faire des trucs cool relativement facilement apparement.

Mais bon perso la prog ca me lourde, je suis plutot admin, vive le shell.

pdf

27/02/2004, 22h31

basic et assembleur sur CPC,
pascal, assembleur et C/CPP sur PC
actuellement, delphi et assembleur sur PC
et je tente le CBASIC sur l'os dont on se sert.
J'aime pas le VB a cause de tout ce qu'il faut rajouter, alors qu'avec le delphi, c'est un simple exe.

Møgluglu

28/12/2009, 14h12

C'était ironique, mais ça n'empêche pas que j'aime beaucoup Ada. Le problème, c'est que je dois être le seul. :p
Ada est l'exemple typique du langage propre et bien défini construit sur des bases solides, conçu par un comité d'experts dans leurs domaines respectifs pour pouvoir être utilisé par tout le monde. Résultat : un langage de niche utilisé par 3 gus de l'aéronautique et 2 de la NASA...

Si on regarde les normes qui ont réussi, le processus est :
1. une implémentation ou un standard propriétaire s'impose,
2. on en fait une norme à la va-vite,
3. 20 ans après, on se rend compte que la norme est toute pourrite et on essaie de rectifier le tir avec une révision (qui est un vague compromis entre conservateurs et révolutionnaires et ne satisfait vraiment personne).

Exemples : IEEE-754, C, C++, Unicode/ISO-10646, OpenGL...
(Pour C et C++, la révision est seulement 10 ans après, mais il a fallu attendre 10 ans de plus pour avoir des compilo presque conformes. Pour Unicode et OpenGL on l'attend toujours...)

Sauf que si un comité avait dit à Kahan "tes modes d'arrondis dynamiques et tes traps ça va foutre la merde, change ça", ou à K&R "la sémantique de votre opérateur virgule c'est nimp", ou au consortium Unicode "le principe de vouloir associer un Han à un point de code c'est foireux, bande d'ethnocentristes", et bah on en serait pas là, hélas...

Mais il me semble quand-même défendable que pour x86 on commence à passer à la phase 2. :)

fefe

28/12/2009, 20h42

Møgluglu

28/12/2009, 21h17

Je sais pas quelle mauvaise expérience tu as eu avec Ada, mais c'est pas du tout la mienne. Bon, j'ai juste codé quelques trucs simple en Ada il y a quelques années et enseigné un semestre en première année plus récemment...

Mais j'ai trouvé que les premières années (info/math/physique/élec/bio...) se débrouillaient bien mieux en Ada et se prenaient nettement moins la tête avec des détails de syntaxe à la con que les 2e année en C (info/phy/élec) (ou même avec les options du compilo et les include :O).
Pour les erreurs de compil je trouve les messages d'erreur de gnat très clairs (pourvu qu'on ait vu en cours quelques mots du vocabulaire de la norme).
Et quand on me pose une question la réponse est beaucoup moins souvent "Parce qu'un mec a décidé comme ça dans les années 60, il devait être bourré ce jour-là, mais on peut plus changer maintenant."

Et puis surtout une fois qu'ils ont subi Ada en 1re année j'arrive à leur faire bouffer du VHDL en 3e sans qu'ils râlent trop. ;)

Enfin c'est vrai que les concepts les plus avancés qu'on aborde sont les boucles sur les tableaux et les appels de procédure avec paramètres in/out... Pas de package à generics, pas de types access tarabiscotés, idem pour C l'arithmétique-de-pointeurs-et-l'allocation-dynamique-vous-verrez-plus-tard...

Mais pour que tout le monde soit content, on fait du lobbying pour mettre du Python à la place dans la prochaine maquette (au moins ça leur apprendra à indenter :()

Sinon, ADA c'est un loueur de voiture ou une loi américaine sur l'accessibilité aux handicapés, le langage c'est Ada. :p

fefe

28/12/2009, 23h41

Je n'ai d'experience qu'avec le compilateur IBM sur RS6k, et c'etait infernal... Ma comparaison etait essentiellement entre enseigner Pascal et Ada (3 semestres d'Ada et 6 de Pascal), et pas avec C et autres. Pascal etait systematiquement plus pratique et tu passais plus de temps a enseigner l'algorithmique ou comment programmer que d'expliquer pourquoi le compilateur avait decide que tu ne pouvais pas affecter un int a un int :). Bref entre Pascal et Ada comme langage imperatif pour faire decouvrir la programmation, le choix etait vite fait: Pascal gagnait systematiquement :).

Cote interet futur dans la carriere du programmeur, les 2 etaient d'un interet assez limite je suis d'accord...

Bien entendu si tu dois apprendre Vhdl, etre passe par Ada aide pas mal :). Mais si tu enseignes system-C et Verilog ca n'aide pas vraiment ;).

newbie06

29/12/2009, 10h29

WTF!?! Scheme et rien d'autre.

fefe

29/12/2009, 19h24

Ouais bon c'est vrai j'ai aussi eu droit a Scheme et CAML. Mais ce ne sont pas des langages imperatifs :).

newbie06

29/12/2009, 19h36

Je m'insurge ! OCaml supporte l'impératif. Mais comme je ne l'ai jamais enseigné je ne sais pas trop ce que ça donne.

Dans mon souvenir, Pascal passait pas trop mal chez des débutants, tandis que C, même chez des gens qui avaient déjà fait du Pascal, ça ne passait pas. J'ai fait un tout petit peu de Scheme avec des débutants et ça passait pas mal (mais bon c'était des matheux aussi, donc le fonctionnel ça leur parlait).

Møgluglu

29/12/2009, 20h45

WTF!?! Scheme et rien d'autre.

Oui, c'est vrai qu'avec Pascal et Ada il reste encore un infime risque que ça leur serve à quelque chose plus tard. :p

Je m'insurge ! OCaml supporte l'impératif. Mais comme je ne l'ai jamais enseigné je ne sais pas trop ce que ça donne.

Pas si terrible (pas enseigné mais j'ai croisé pas mal de victimes)...
Caml est un merveilleux langage qui arrive à cumuler les défauts du fonctionnel avec ceux du C, avec un compilateur dont le répertoire des messages d'erreur va de "Syntax error at (1664, 51)." à "Cannot convert from [10 lignes] to [les 10 mêmes lignes avec une virgule qui change, ou même pas]".

Je trouve que c'est ni un bon langage fonctionnel ni encore moins un bon langage impératif... Pas pour les débutants sauf à les cadrer dans un style de programmation bien précis. Même problème que pour C++, sauf que C++ il sert dans la vie.

Dans mon souvenir, Pascal passait pas trop mal chez des débutants, tandis que C, même chez des gens qui avaient déjà fait du Pascal, ça ne passait pas. J'ai fait un tout petit peu de Scheme avec des débutants et ça passait pas mal (mais bon c'était des matheux aussi, donc le fonctionnel ça leur parlait).

Ouais mais j'aurai honte d'enseigner du Pascal en 2009, et va trouver un interpréteur/compilateur encore maintenu...
C devrait être interdit au moins de 20 ans, un langage hardcore comme ça, ça pourrait provoquer des profonds traumatismes.
L'inconvénient/avantage de Scheme c'est que ça décourage tout de suite les r0x0r du PHP qui forment la majorité des promos d'info...

fefe

29/12/2009, 21h21

Ca a un bon cote l'enseignement de langages exotiques inutilises, le jour ou tu te retrouves a programmer dans un langage a la con, tu as l'habitude des changements de syntaxe. Je ne connais la syntaxe de quasiment aucun (hormis quelques asm, mais ca ne compte pas), mais en 5 min je m'en sors en a peu pres n'importe quoi, et j'attribue ca au fait que j'ai appris la programmation avec des langages inutiles (et donc que quand j'ai eu besoin de programmer quelque chose d'utile, j'ai du m'adapter a de nouvelles syntaxes).
L'essentiel a mon avis est de comprendre les mechanismes de la programmation et l'algorithmique, pas l'apprentissage d'une syntaxe qui sera forcement inutile le jour ou l'etudiant sera face a un vrai probleme a resoudre dans un environement different de celui choisi par ses enseignants.

newbie06

30/12/2009, 00h26

Dans ma fac, ils avaient trouvé la solution pour Pascal : reverse engineering de Turbo Pascal 3, mise à la norme, et maintenance. Mais bon, c'était y'a 10 ans :)

Sinon je plussoie fefe. Il faut s'abstraire au maximum de la syntaxe et se concentrer sur les concepts fondamentaux de la programmation. C'est pour ça que je pense que les langages du type LISP/Scheme sont un bon choix, d'autant plus qu'ils sont aussi interprétés. (OK, j'avoue j'ai légèrement interprété les propos de fefe :p).

En parlant de langage à la con, le pire que j'ai connu c'est Prolog (même si Prolog 3 et son moteur de contraintes était un peu plus amusant). Quant au plus amusant, j'hésite entre Modula2, CommonLISP et CAML. A l'arrivée, je ne fais que du C ^_^ (et de l'assembleur, mais, désolé fefe, y'a pas de syntaxe là-dedans).

fefe

30/12/2009, 02h21

Et APL !!!???

newbie06

30/12/2009, 11h45

Et APL !!!???
J'ai jamais eu de clavier avec des lettres grecques :p Il m'a toujours intrigué ce langage...

Møgluglu

30/12/2009, 11h59

J'ai jamais eu de clavier avec des lettres grecques :p Il m'a toujours intrigué ce langage...

Dans le style mais plus récent, je suis fan de Fortress (http://en.wikipedia.org/wiki/Fortress_%28programming_language%29). Vous avez rêvé à d'un croisement entre Fortran et Haskell avec une syntaxe basée sur tout Unicode? Sun l'a fait. :O

Si vous voulez on ouvre un topic dans la section Software, histoire que les canards puissent participer. Ça fait longtemps qu'on a pas eu un bon vieux troll mon-langage-il-est-mieux-que-le-tien. ;)

newbie06

30/12/2009, 12h45

Ouai faut un sujet dédié, j'ai envie de troller sur cette grosse daube de Python, le langage pour les nuls qui a réintroduit ce fabuleux concept de blanc signifiant comme Fortran dans les années 50.

Møgluglu

30/12/2009, 13h32

Alexko

30/12/2009, 14h33

Moi j'ai écrit mes toutes toutes premières lignes de "code" en faisant des scripts sur Counter-Strike pour acheter mes armes plus vites. Après un peu de Basic : je m'amusais à dessiner des cercles partout avec un bout de code dans une boucle, le résultat ressemblait un peu à de la broderie, ça m'a occupé quelques heures.

Mais j'ai commencé à réellement apprendre avec OCaml, puis Delphi, puis le C... Apparemment certains ont eu une expérience traumatisante avec OCaml (et c'était le cas dans ma promo) mais moi j'aimais bien, je trouve ça assez élégant comme langage, quand c'est bien utilisé.

Grosnours

30/12/2009, 15h04

Le fonctionnel, c'est beau comme du Michel Ange ! :emo:

A coté l'impératif fait lourd et disgracieux (mais efficace, je sais). La programmation logique (en Prolog par exemple) est aussi quelque chose à essayer, six mois en maitrise m'ont bien marqué.

Sinon j'ai fait du BASIC (enfin les déclinaisons locales) sur MO7, Commodore 64, Casio 880 (:wub:), du RPN-based sur HP-48, du B, C, C++, Java, CafeObj, Corba, GTK+, OpenGL, HPF, Fortran, MPI, PVM, Promela, Xspin, Lex, Yacc, Caml, OCaml, SML, C#, F#, tout cela pour faire aujourd'hui une immense majorité de.... AS3. :o
Et le pire c'est que j'aime cela ! :p

unpierrot

30/12/2009, 16h06

Moi c'est le C et Java.

Le Java est un langage bien pratique pour coder un truc sous Mac, Unix et Windows avec un même bout de code.
Et quand on veut faire du spécifique avec une plateforme, on peut toujours passer par les appels natifs en JNI (en C ;) ).

edit : de manière anecdotique, j'ai fait du Clipper, du SQL, du C++, du Cobol, de l'assembleur ... quand je dis C et java, ce sont les deux langages que j'utilise quotidiennement.

Møgluglu

30/12/2009, 16h33

Le fonctionnel, c'est beau comme du Michel Ange ! :emo:

Il y a un truc que je concède à Caml (et ML en général), c'est que ça permet de voir la correspondance de Curry-Howard. Quand j'ai vu ça en cours et que j'ai enfin compris que la réponse était 42 (ou qu'il existait un isomorphisme entre les programmes du lambda-calcul simplement typé et les preuves en logique intuitionniste du premier ordre, je sais plus), ça a été une illumination. :emo:

Ça m'a donné envie de regarder un peu de logique et de théorie des catégories, puis ensuite je me suis enfui en hurlant. :o
C'est comme ça que j'ai décidé de faire de l'archi.

tenshu

30/12/2009, 16h50

Puisque c'est du topic archéologie qu'est partie la discussion...
http://forum.canardpc.com/showthread.php?t=38688#post2802702

...Je me permet de déterrer ce topic pour l'occasion à la demande générale de newbie06 pour qu'il puisse troller sur Python.

Pourquoi Python c'est cool comme langage.
Surtout qu'il ne se prétend pas comme le meilleur, le plus rapide et blabla.
C'est propre, super propre même, extremis accessible, on devrait à mon gout faire commencer les étudiants par python avant de leur faire boire la tasse avec du C.

Moi je fait du PHP objet B)

newbie06

30/12/2009, 17h27

Python c'est le BASIC de la nouvelle génération, avec une touche de Fortran (espaces significatifs).
Bref, c'est ptet bien mais y'a intérêt à s'en défaire le plus vite possible.

Quant à savoir si c'est mieux de commencer par ce langage plutôt qu'un langage plus consistent, pas d'accord. En revanche, commencer par C, ça c'est surement une mauvaise idée !

tenshu

30/12/2009, 17h38

Je te trouve super dur tout de même.

Depuis l'essor de python dans les distro linux, on voit apparaitre tout un tas d'outils codé dans ce langage. Avec tout un tas de contributeurs qui peuvent se mettre au niveau.

Et à coté de PHP c'est un rubis (hahaha ruby ... haeum) de cohérence et de simplicité.

newbie06

30/12/2009, 17h46

Je suis peut-être dur ouai. Mais un truc me fait fliper : quand un truc est trop accessible, le premier type venu se croit programmeur parce qu'il a codé un bidule en Python. Chuis surement un vieux con, mais pour vraiment apprendre, il faut faire des études, se taper plein de trucs apparemment stupides, voir beaucoup de langages, apprendre l'algo (hé ouai, ça veut aussi dire faire un minimum de math).

J'ai des collègues qui sont designers de CPU, il fallait voir leur code C++, une horreur. Et maintenant ils sont tous à se toucher le kiki parce qu'ils arrivent plus vite à faire des trucs en Python. Ont-ils progressé niveau programmation ? Pas du tout. Leurs programmes sont-ils plus efficaces ou plus réutilisables ? Surement pas. Mais ils développent plus rapidement de la merde, certes utile, mais de la merde tout de même.

PS - J'ai pas que Python dans le collimateur ; j'ai eu le même genre d'expérience avec PERL, il y a quelques années. J'adorais écouter des mecs clamer qu'ils faisaient de l'analyse syntaxique à coup d'expressions régulières :|

tenshu

30/12/2009, 17h48

Hey mais on est d'accord hein, tu dis ça à un "programmeur" php (lulz) :) .

Ce que je voulais dire c'est que c'est surement un formidable outil de vulgarisation.
On peut faire (très) vite et bien en python.

Ce qui est totalement indépendant du fait qu'un piètre programmeur pissera du code tout pourri dans tout les langages.

:enfoncelesportesouvertes:

newbie06

30/12/2009, 17h50

Ca va pas du tout : si on est d'accord, on ne va pas pouvoir troller ^_^

Møgluglu

30/12/2009, 17h53

avant de leur faire boire la tasse avec du C.

Et à coté de PHP c'est un rubis (hahaha ruby ... haeum) de cohérence et de simplicité.

Ouais enfin ça on savait. :p

Perl et Python, il faudra que j'apprenne sérieusement un jour, pour l'instant je m'en sert, mais en codant comme ça vient, rapidement de la merde comme dit Newbie.

tenshu

30/12/2009, 17h56

Si on peut troller sur PHP et ses noms de fonctions rigolos :rolleyes:

Underscore:
str_replace(), str_repeat(), str_shuffle()
ou pas
strlen(), strpos(), strtolower()

singulier:
array_diff_key(), $_COOKIE
ou pluriel
array_fill_keys(), $_FILES

to:
strtolower(), strtoupper()
ou 2
bin2hex(), nl2br()

Et plein d'autres trucs énervants comme l'ordre des options dans les fonctions ...

Møgluglu

30/12/2009, 18h21

Encore mieux, moi je connais un langage où les types de base sont nommé tels que y'en a pas 2 qui suivent la même règle.

Dans ce langage, "char" veut dire "entier (signé ou pas, ça dépend) dont la taille fait 1 byte",
"short" veut dire "un entier aussi, mais généralement un peu plus gros, et signé par défaut", et ça continue avec des noms aussi ridicules que "long long int" (genre on a un truc à compenser).

Mais le mieux reste les types virgule-flottante. Un long double, c'est une variante du triple grande latte de Starbucks? :rolleyes:

newbie06

30/12/2009, 18h26

Encore mieux, moi je connais un langage où les types de base sont nommé tels que y'en a pas 2 qui suivent la même règle.

Dans ce langage, "char" veut dire "entier (signé ou pas, ça dépend) dont la taille fait 1 byte",
Nan, c'est faux ça : ça doit faire au minimum un octet !

Pour le reste ouai, chuis d'accord c'est de la merde niveau typage le C.

Tramb

30/12/2009, 18h30

dont la taille fait 1 byte

...ce qui ne fait même pas obligatoirement 8 bits! :p

Le C est un lourd héritage.

Møgluglu

30/12/2009, 18h45

...ce qui ne fait même pas obligatoirement 8 bits! :p

Note que j'ai pas écrit 1 octet. ;)

Nan, c'est faux ça : ça doit faire au minimum un octet !

Bah ouais, 1 byte doit faire au minimum 1 octet (8 bits), je vois pas le problème. ^_^

Pour le reste ouai, chuis d'accord c'est de la merde niveau typage le C.

Si c'était que le seul niveau... :rolleyes:

newbie06

30/12/2009, 19h00

Bah ouais, 1 byte doit faire au minimum 1 octet (8 bits), je vois pas le problème. ^_^
Non plus, un byte peut faire moins de 8 bits. T'as tort, et c'est tout !

r_one

30/12/2009, 19h33

J'avais bien aimé faire de l'Haskell à la FAC. C'était bien rigolo ces structures de données infinies qui donnaient la migraine aux étroits d'esprit et la méthode d'évaluation des expressions.

Pi le fonctionnel c'est beau !

fefe

30/12/2009, 20h33

Pff l'autre il troll et se plaint de Python, et dire que cette semaine j'ai passe pas mal de mon temps a ecrire du VBA hein ! Faut arreter de se plaindre !

ylyad

30/12/2009, 20h43

J'ai appris l'info avec Pascal, et effectivement (les rares fois où j'en ai besoin), je galère à chaque fois que je dois écrire un code (dans un vrai langage utile), parce que je me prends la tête sur la syntaxe et je laisse tomber. Alors que pour débugguer (ou écrire des specs vraiment correctes...), je m'en sors carrément bien :) parce que comme ça, je me concentre sur l'algo et la logique

Neo_13

30/12/2009, 20h50

Je multiplussoie fefe... Je REVE de pouvoir faire python + SQL au taff, et je fais du excel + VBA. Maintenant imaginez tout ce qu'on peux faire avec les 2 premiers, tentez de transposer dans les 2 seconds et hop, la tête dans la cuvette... En cette saison, ça doit aider à rester svelte.

---------- Post ajouté à 20h50 ----------

Et je multiplussoie pour le fonctionnel, c'est beau comme du leonard de vinci...

D'ailleurs, j'avais trouvé l'erlang intéressant. Mais je suis pas programmeur, donc ce n'est qu'un avis de n00b autoformé sur le tas + quelques dizaines d'heures de C académique.

tenshu

30/12/2009, 21h24

:haha:

Plutôt chômeur que de bosser sur du Microsoft.

fefe

30/12/2009, 21h26

J'ai ecri un coeur de recuit-simule en VBA+XL ces derniers temps, et honnetement meme si on s'y habitue j'aurais prefere python+SQL ou a peu pres n'importe quoi d'autre :).

newbie06

30/12/2009, 21h48

Ha ouai, j'aimerais bien voir du recuit simulé en SQL moi :p

Ha et le fonctionnel... J'adore :)

xheyther

30/12/2009, 21h50

tenshu

30/12/2009, 21h59

Way, difficile de lui reprocher.
On finit quand même par aimer et a faire de la prog, comme on ferait de la prose.

La finalité disparait car ce n'est pas ce qui est intéressant quand on est de l'autre côté du décor.
Un peut comme un écrivain qui se focaliserait sur la forme d'un article de journal alors que le fond serait extrêmement juste.

Møgluglu

30/12/2009, 22h17

Ha et le fonctionnel... J'adore :)

Moi aussi, c'est pour ça que C++ est mon macro-assembleur préféré.

(la métaprogrammation çaylebien)

fefe

30/12/2009, 22h46

Ha ouai, j'aimerais bien voir du recuit simulé en SQL moi :p

Oui monsieur, je prefererais avoir mes donnees source dans une base SQL plutot que dans des tables XL ...

newbie06

30/12/2009, 22h47

Le problème de newbie c'est qu'il extrapole à un language le ou les défauts que certains ont quand ils en "font" un tout petit peu.
Je peux aussi dire que java c'est de la mayrde pour les mêmes raisons (trop accessible tout ça tout ça) ou pire pour le C (gogo aller voir les forum du site du zéros pour vous marrer).

Fin bon il faudrait juste qu'on (pas nous ni qui que ce soit en particulier) arrive a se débarasser de de l'idée que la programmation c'est élitiste et tout. Je trouve ça chiant.
C'est pas une question d'élitisme, c'est une question de niveau : Python c'est le tricyle des langages de prog, on te colle une 3ème roue pour tenir debout, mais le vrai truc il est pas là, faut passer à deux roues.

De toute façon, les vrais ils programmes à la bite et au couteau, en langage d'assemblage.

PS - Et je trolle, si je veux.

Neo_13

30/12/2009, 22h54

Voilà, j'ai fait un peu de fusion-acquisition...

---------- Post ajouté à 22h54 ----------

Et je suis d'accord, les vrais hommes codent en assembleur.

xheyther

30/12/2009, 23h12

C'est faux.

C'est en langage machine et en exploitant intelligemment les faiblesses de la machine. (http://rixstep.com/2/2/20071015,01.shtml)

Voilà, maintenant qu'on sorti les trolls et les bon vieux memes, on fait quoi ? (ça fini toujours comme ça ce topic).

tenshu

30/12/2009, 23h16

C'est pas une question d'élitisme, c'est une question de niveau : Python c'est le tricyle des langages de prog, on te colle une 3ème roue pour tenir debout, mais le vrai truc il est pas là, faut passer à deux roues.

De toute façon, les vrais ils programmes à la bite et au couteau, en langage d'assemblage.

PS - Et je trolle, si je veux.

Désolé mais c'est un peut des conneries.
La finalité de la pratique d'un langage c'est l'aboutissement du projet dans lequel on l'utilise.

Les considérations de maintenance, beauté du code, cohérence du langage c'est complétement annexe.

fefe

30/12/2009, 23h28

Tout a fait, mais la premiere chose que tu ecrits en code machine est un assembleur pour ne plus avoir a le faire :). Pour avoir a ecrire de temps en temps du x86 en hexa, je confirme que c'est effectivement la maniere la plus douloureuse de programmer, donc faite pour les vrais hommes masochistes et tout.

Mais la raison pour laquelle il y a des gens comme moi qui se paluchent ce genre de truc, c'est pour eviter au reste une perte de temps tout aussi ridicule qu'inutile :).

Et oui, il y a plein de combinaisons d'opcodes en x86 pour lesquels il est impossible d'utiliser un assembleur...

La finalite de la programmation est d'avoir quelque chose qui s'execute sur ton hard. Moins tu depenses d'argent pour arriver a tes fins, plus tu es riche. Le fait que pas mal de monde prefere etre riche et travailler moins encourage l'utilisation de methodes de developpement efficaces comme des langages de programmation evolues.

Si c'est laid, fait par une compagnie "evil" mais que ca permet d'arriver a tes fins avec un minimum d'effort, tant mieux :). Oui je me plaints de coder en VBA, mais honnetement meme si ca me donne moins l'impression d'etre un heros, je prefere ca a ecrire des lignes d'hexa!!!

newbie06

30/12/2009, 23h48

Désolé, la maintenance est souvent largement autant critique que le reste. Lis le lien de xheyther.
Ou alors tu bosses chez MS ptet ou ATI (ça c'est pour énerver gratuitement xheyther :p) ?

fefe

31/12/2009, 00h10

Ca depend si tu developpes du soft pour le vendre ou pour une utilisation ponctuelle et pour le jeter apres.

XWolverine

31/12/2009, 00h16

Il n'y a pas de mauvais langages, que de mauvais programmeurs :ninja:

newbie06

31/12/2009, 11h41

En fait oui, presque tous les langages sont intéressants à un titre ou un autre. Et c'est pour ça que ce genre de débat est assez stérile... Enfin pas tout à fait stérile, ça m'amuse de voir les réactions épidermiques des gens :p

Pour en revenir à l'exemple de Python que j'ai au boulot, j'ai défendu l'utilisation de Python parce que si certains sont plus à l'aise pour écrire leurs utilitaires avec, ça restera plus productif de toute façon, puisqu'on n'a pas assez de pros du dév pour les faire. Mais si j'avais dit ça depuis le début, ça aurait été moins drôle, hein xheyther ? ;)

Tramb

31/12/2009, 11h52

En fait si, il y'a des mauvais langages... pour écrire de gros programmes complexes et/ou performants.
C'est clair que pour écrire de petites moulinettes ou des applis simples, tout peut faire l'affaire.
(M'enfin quand même, VBA + Excel... ^_^)

Python, perso j'aime pas (typage dynamique, performance lamentable), enfin si, y'a un intérêt, c'est un bon langage de script portable.
Si jamais je chope quelqu'un en train d'écrire du code numérique en Python, je lui pète une rotule.

newbie06

31/12/2009, 11h58

Le code numérique c'est FORTRAN ou rien.

Alexko

31/12/2009, 12h06

Désolé mais c'est un peut des conneries.
La finalité de la pratique d'un langage c'est l'aboutissement du projet dans lequel on l'utilise.

Les considérations de maintenance, beauté du code, cohérence du langage c'est complétement annexe.

La maintenance c'est annexe ? Si ton programme fait tout parfaitement, sans bug et avec toutes les fonctions dont tu peux avoir besoin du premier coup, ouais, c'est annexe.

Tramb

31/12/2009, 12h19

Le code numérique c'est FORTRAN ou rien.

Bof, depuis que restrict est arrivé dans le monde du C/C++, plus beaucoup de (bonnes :p) raisons de programmer en FORTRAN.

newbie06

31/12/2009, 12h37

Tiens ça m'intéresserait des bench comparant FORTRAN et C/C++...

Minuteman

31/12/2009, 13h08

De toute manière il ne faut pas se voiler la face, avec la manière dont parlent les sales jeunes aujourd'hui on va arriver à ça: http://en.wikipedia.org/wiki/LOLCODE :D

Mitsuaki

31/12/2009, 13h44

Perl, je crois que c'est le language ou j'ai réussi à écrire les trucs les plus crades et les plus incompréhensibles B)

$ ls -lRa|perl -aple '/^total/?$x+=$F[1]:$x}{$_=$x' :wub:

Neo_13

31/12/2009, 13h52

En fait si, il y'a des mauvais langages... pour écrire de gros programmes complexes et/ou performants.

Si jamais je chope quelqu'un en train d'écrire du code numérique en Python, je lui pète une rotule.
/me planque ses rotules...

Et PHP > 4.

Même Rasmus annonçait que le php objet, c'est très con.

XWolverine

31/12/2009, 13h59

En fait si, il y'a des mauvais langages... pour écrire de gros programmes complexes et/ou performants.

Ben oui, donc non. Y'a pas de mauvais langages, dans le sens où on peut trouver un usage adapté à chacun. A part si le langage est buggué, bien sûr.

(M'enfin quand même, VBA + Excel... ^_^)

Même ça. C'est à prendre comme l'utilisation d'un langage pas top (VB) intégré dans un outil (le tableur), permettant d'utiliser ses fonctions de manière simple => C'est bien pratique pour étendre les capacités du truc, là où les formules atteignent leurs limites.
Mais bon, c'est pas vraiment un langage de programmation.

Après, au delà de l'utilisation (grosses applis, perf, modularité, calculs, temps réel, abstraction, ...), il y a la sensibilité de chacun. Pour certains, un langage très carré, peu permissif, sera un bon langage (parce qu'il est "propre", robuste, maintenable) alors que pour d'autres, il sera chiant (qui a dit ADA) et préfèrera un langage très permissif parce qu'il se sent plus libre et qu'il le maîtrise suffisamment pour éviter les écueils.

T'façon, le problème de nos jours n'est pas dans le langage lui même, mais dans l'algorithmique, car à part dans des domaines particuliers, les dévs d'aujourd'hui n'ont plus les notions ou s'en foutent parce que ça tournera de toute façon vu les machines cibles. Et là, même avec le meilleur langage du monde, on n'y peut rien :p

Tramb

31/12/2009, 14h34

Ben oui, donc non. Y'a pas de mauvais langages, dans le sens où on peut trouver un usage adapté à chacun. A part si le langage est buggué, bien sûr.

Il y'a quand même des langages qui sont obsolètes par rapport à d'autre.

Modula vs Pascal
Pascal vs Ada
C vs C++ (holy war potentielle)
etc...

Après, au delà de l'utilisation (grosses applis, perf, modularité, calculs, temps réel, abstraction, ...), il y a la sensibilité de chacun. Pour certains, un langage très carré, peu permissif, sera un bon langage (parce qu'il est "propre", robuste, maintenable) alors que pour d'autres, il sera chiant (qui a dit ADA) et préfèrera un langage très permissif parce qu'il se sent plus libre et qu'il le maîtrise suffisamment pour éviter les écueils.

En tout cas, c'est ce qu'il prétendra. Pour l'instant j'attends toujours de voir des mecs qui font du typage dynamique et qui ne font pas d'erreur débile.
Et si tu rajoutes le merge des VCS, alors là, c'est encore plus casse-gueule si t'as pas de compilateur derrière pour en valider la syntaxe.
(Même si je suis d'accord que dans du mission-critical ou du life-critical, c'est le testing et la construction qui assurent la correctness, pas le compilateur).

PS: On dit Ada et pas ADA, c'est une dame, pas un acronyme :)

xheyther

31/12/2009, 14h49

Pour en revenir à l'exemple de Python que j'ai au boulot, j'ai défendu l'utilisation de Python parce que si certains sont plus à l'aise pour écrire leurs utilitaires avec, ça restera plus productif de toute façon, puisqu'on n'a pas assez de pros du dév pour les faire. Mais si j'avais dit ça depuis le début, ça aurait été moins drôle, hein xheyther ? ;)

Oui ça aurait été moins drôle mais pour toi, puisque tu n'aurai pas pus troller à ton aise. Moi je m'en fous mes programme ne quitteront jamais le laboratoire dans lequel je bosse et je serai le seul à y mettre le nez. J'ai juste besoin de résultats pour les publications. Que sans doute très peu de gens lirons par ailleurs. (ça vous intéresse vous la modélisation dynamique multi-échelle adaptative des système de transport urbains routiers ?)

Donc c'est un peu pas du tout le même contexte.

Mais je maintiens que dire le python/php/langage-X c'est nul parce que les gens en font n'importe quoi avec, c'est comme de dire que le crayon à papier c'est pas bien parce pour le dessin que il y a des gens qui font des dessins super moches avec. C'est pointless ! (et ouais je fais du jcvd si je veux.)

Les outils (et l'informatique ce n'est jamais qu'un outil pour l'utilisateur) ne sont que ce qu'on en fait.

Sp1d3r

31/12/2009, 15h10

Le choix du langage dépend de ce qu'on recherche je pense.

Si je veux me faire un script pour moi, sans recherche de la performance en général je me tourne vers Python. Exemple récent, je voulais faire un code qui remplisse un formulaire à ma place. En gros connexion à un site, récupération des cookies de connexion et envoi d'une requète POST en HTTP avec le contenu du formulaire.
Aussi, quand je veux traiter des xml, des csv en général je choisis Python. Rapide, pas prises de tête.

Après si on cherche la performance, on va forcément aller sur un langage qui permet de faire de choix que d'autres langages imposent. C++ ?

Parfois on a besoin d'être sûr que ça tournera sur des machines d'architectures différentes quitte à sacrifier de la perf. Là, j'irai naturellement sur Java plutôt...

Après pour ce qui est de faire du web, le php est suffisamment supporté partout pour que je le considère comme un bon choix :p

Bref, tout est une question de contexte. Je ne comprends pas les gens qui ne jurent que par un langage, oui on peut ouvrir une boite de conserve avec un couteau. Mais c'est tellement plus pratique avec un ouvre-boîte :p.

Tramb

31/12/2009, 15h42

Oui ça aurait été moins drôle mais pour toi, puisque tu n'aurai pas pus troller à ton aise. Moi je m'en fous mes programme ne quitteront jamais le laboratoire dans lequel je bosse et je serai le seul à y mettre le nez. J'ai juste besoin de résultats pour les publications. Que sans doute très peu de gens lirons par ailleurs. (ça vous intéresse vous la modélisation dynamique multi-échelle adaptative des système de transport urbains routiers ?)

Il serait intéressant de connaître le taux de papiers faux (et viralement de papiers qui les citent) à cause de programmes buggués, de rand, et autres couillonneries :rolleyes:

XWolverine

31/12/2009, 16h05

PS: On dit Ada et pas ADA, c'est une dame, pas un acronyme :)
Désolé, de mon temps, on n'avait pas les minuscules :ninja:

Là, j'irai naturellement sur Java plutôt...

Ah ? Je pensais qu'aucun usage particulier ne conduisait naturellement vers le java :siffle:

xheyther

31/12/2009, 16h34

Il serait intéressant de connaître le taux de papiers faux (et viralement de papiers qui les citent) à cause de programmes buggués, de rand, et autres couillonneries :rolleyes:

En tout cas ce qui nous concerne, mes collègues et moi, l'usage et de coder ce qui a d'abord été élaboré en théorie quand il s'agit de modèles. Dans ces cas là, un programme daubé se remarque trés vite, puisque les résultats ne sont pas ceux que l'on attend (oui faut pas croire hein, on ne fait pas tourné un programme sans savoir à peu prés ce qu'on va avoir, puisqu'en principe on comprend ce que le code fait et donc on peut en déduire l'allure des sorties). Il arrive, mais c'est vraiment rare, que les sorties ne soient pas conformes et que le code ne soit pas daubé, mais alors soit il y a une erreur conceptuelle soit certaines hypothèses ou conditions ne sont pas aussi bien satisfaite que prévues et il faut revoir toute la démarche.

L'autre cas d'utilisation c'est l'exploitation de données (payes tes 365jours de données trafic à la minute pour 250 points de comptage). Dans ce cas, on sait en général tout de suite si les données ou le traitement est pourri puisque les systèmes que l'ont traite sont pratiquement toujours chaotiques au sens ou une petite déviation pourrie très vite énormément tout le reste.

Donc oui il doit avoir des papiers "corrompus" mais pas beaucoup. Il doit y avoir par contre plus de papiers où les données ont été trafiquées...

edit : et le rand ça se remarque trés vite (faut pas croire), j'ai deux ou trois exemples en tête où le modèle faisait n'importe quoi à cause d'une graine mal réinitialisée, ça se remarque aussi beaucoup.

Tramb

31/12/2009, 17h07

edit : et le rand ça se remarque trés vite (faut pas croire), j'ai deux ou trois exemples en tête où le modèle faisait n'importe quoi à cause d'une graine mal réinitialisée, ça se remarque aussi beaucoup.

Sur une intégration de MonteCarlo ça peut être assez subtil quand même.

Sp1d3r

01/01/2010, 12h25

Il me semblait maintenant qu'on avait des dispositifs externes pour générer de l'aléatoire basé sur la physique quantique.

Tramb

01/01/2010, 13h46

Il me semblait maintenant qu'on avait des dispositifs externes pour générer de l'aléatoire basé sur la physique quantique.

Ca se fait en effet.
Et il y'a des générateurs pseudo-random qui sont très aléatoires aussi, de toute façon.
Un exemple:http://www.schneier.com/paper-yarrow.html

newbie06

01/01/2010, 14h03

J'imagine que pour le genre de simus que fait xheyther, il faut un minimum de reproducibilité, donc ça implique du pseudo-aléatoire, non ?

ducon

01/01/2010, 14h48

Selon ce dont j'ai besoin, j’aime bien Perl, Python, le C, Scilab ou le shell.

Møgluglu

01/01/2010, 15h50

Et il y'a des générateurs pseudo-random qui sont très aléatoires aussi

Très bon!
J'hésite à le mettre en signature... :p

xheyther

01/01/2010, 16h05

Sur une intégration de MonteCarlo ça peut être assez subtil quand même.

Nan on en fait jamais ça :) pas avec les grandeur qu'on utilise il y a des moyen plus rapide et efficace de calculer les intégrales.

J'imagine que pour le genre de simus que fait xheyther, il faut un minimum de reproducibilité, donc ça implique du pseudo-aléatoire, non ?
Voui, et nos problèmes viennent plus souvent de la graine que du générateur. Et ça c'est l'interface chaise clavier qui le gère donc c'est assez langage-indépendant.

Neo_13

01/01/2010, 19h21

Il me semblait maintenant qu'on avait des dispositifs externes pour générer de l'aléatoire basé sur la physique quantique.
Et puis bientot, ce sera intégré au cpu façon via depuis 15ans !

Tramb

01/01/2010, 20h20

Très bon!
J'hésite à le mettre en signature... :p

Bah quoi aléatoire c'est pas un booléen :O
Je sais pas si y'a un mot pour dire exactement "randomness" en français d'ailleurs!

Alexko

01/01/2010, 21h48

Aléatoiritude © Ségolène Royal.

fefe

01/01/2010, 22h08

(M'enfin quand même, VBA + Excel... ^_^)

Sauf que quand tu developpes des outils qui sont senses etre manipulables par des nons-programmeurs, tu developpes des tables complexes avec des macros pour iterer dessus et interroger des applis externes. Tu arrives meme a avoir des types de marketing qui font des experiences avec ton outil et qui le modifient pour leurs besoins sans ecrire une ligne de code.

Un outil dans un langage "propre" aurait pu etre developpe, mais il aurait fallu specifier tout ce que ses utilisateurs voulaient faire avec pour les 5 prochaines annees (ce que meme eux ne savent pas), ou garder un dev a temps plein dessus ce qui est hors de question.

Au final tu as une spreadsheet qui est un objet utilisable par pas mal de monde, qui a des capacites tres au dela de ce qu'on associe a une spreadsheet en temps normal. Bref c'est un outil de visualisation et d'analyse complexe de donnees produites par un autre outil lui ecrit en C (et de quelques millions de lignes de code imbitable et inmodifiables meme pour le commun des programmeurs).

Garder l'interface de visualisation/analyse des donnees sous unix est generalement un frein a son utilisation par le haut de la chaine de management et les non techniques :). Avoir tout dans une spreadsheet est quelque chose qu'ils comprennent :).

Bref j'aime pas VBA+XL mais je comprends ;).

Le pire que j'ai vu est une MAS ecrite sous word avec du VBA qui synthetisait les circuits, mais la c'est du domaine d'Alice au pays des merveilles :).

newbie06

01/01/2010, 22h47

Clair pour le marketing c'est le top : ils prennent toutes les cellules, appliquent un gain de 20% partout, et roule, la concurrence est loin derrière.

Mes outils sont en C et génèrent du CSV, ça me suffit :p

ylyad

02/01/2010, 09h54

Un outil dans un langage "propre" aurait pu etre developpe, mais il aurait fallu specifier tout ce que ses utilisateurs voulaient faire avec pour les 5 prochaines annees (ce que meme eux ne savent pas), ou garder un dev a temps plein dessus ce qui est hors de question.

Entièrement d'accord. Bon, après, faut quand même expliquer à tes utilisateurs que ça ne s'applique pas dans tous les cas, et que parfois, développer un vrai outil (ou l'acheter) a aussi son intérêt ;)

Garder l'interface de visualisation/analyse des donnees sous unix est generalement un frein a son utilisation par le haut de la chaine de management et les non techniques :). Avoir tout dans une spreadsheet est quelque chose qu'ils comprennent :).

Bref j'aime pas VBA+XL mais je comprends ;).

Clair! Et si en plus, ça rentre dans un mail et c'est utilisable sur BlackBerry ou iPhone, c'est encore mieux :lol:

yuushiro

02/01/2010, 20h54

Je plussoie fortement le C/C++.
Le choix pour C/C++, ça oblige à coder propre (pas de GC, la joie d'avoir une segfault, des poiteurs fous...). Et c'est ça qui fait que c'est un langage qu'on apprécie.
Cependant je conchie fortement sur Java.

xheyther

03/01/2010, 00h06

Le java c'est trai bien !

Sur ma brique Mindstorm NXT :ninja:

Møgluglu

03/01/2010, 10h04

C/C++

Argh, vade retro! :O

Soit on fait du C, soit on fait du C++, mais programmer en C/C++ c'est juste le mal absolu. Y'a pas de pointeurs en C++ (ou alors ils sont smart et certainement pas fous), et y'a pas de casts explicites de types pointeurs en C.

Le java c'est trai bien !

Sur ma brique Mindstorm NXT :ninja:

Mouais, les bibliothèques fournies sont pas mal mais la réactivité est pas géniale. Py on a pas accès aux features bien bas niveau genre interruptions...

xheyther

03/01/2010, 13h39

Ouais fin moi ce qui m'intéresse c'est que mon machin il suive la ligne noire et basta. J'ai pas besoin/envie de faire des trucs très très fin. La robotique oui, la programmation au niveau le plus bas euh... non, ça a l'air chiant.

yuushiro

03/01/2010, 14h27

Soit on fait du C, soit on fait du C++, mais programmer en C/C++ c'est juste le mal absolu. Y'a pas de pointeurs en C++ (ou alors ils sont smart et certainement pas fous), et y'a pas de casts explicites de types pointeurs en C.

Tout à fait d'accord sur ce point. Par C/C++ je veux dire que j'utilise l'un OU l'autre.

newbie06

03/01/2010, 14h45

Y'a pas de pointeurs en C++ (ou alors ils sont smart et certainement pas fous),
Ca dépend du programmeur ça...

et y'a pas de casts explicites de types pointeurs en C.
Hein ? C'est quoi un cast explicite pour toi ?

Puisque j'ai tapé sur Python, je vais maintenant taper sur C++. C'est de la MAYRDE.

yuushiro

03/01/2010, 16h39

newbie06 tu as osé critiquer Python. Ce si beau langage....

Pour en revenir au cast explicite en de type pointeur en C c'est à toi de te demerder.

Si tu déclares un void* sur lequel tu vas vouloir faire pointer l'adresse d'un entier c'est à toi à la lecture à lui spécifier que c'est un int, sinon c'est le bordel.

Møgluglu

03/01/2010, 16h45

Ca dépend du programmeur ça...

Oui, les développeurs de la STL, de Boost et de bibliothèques utilisées en internes par les projets d'un million de lignes utilisent parfois des pointeurs dans 0,01% des cas.

Pour le reste, il y a les itérateurs et boost::shared_ptr.

Hein ? C'est quoi un cast explicite pour toi ?

Un cast comme dans : t = (int*)malloc(n * sizeof(t)).
C'est absolument immonde, et sur le moment c'est le seul avantage de C sur "C/C++" que j'ai trouvé.

Puisque j'ai tapé sur Python, je vais maintenant taper sur C++. C'est de la MAYRDE.

Développe, développe s'il te plait... :p

newbie06

03/01/2010, 17h32

Oui, les développeurs de la STL, de Boost et de bibliothèques utilisées en internes par les projets d'un million de lignes utilisent parfois des pointeurs dans 0,01% des cas.

Pour le reste, il y a les itérateurs et boost::shared_ptr.

Développe, développe s'il te plait... :p

Tu as parfaitement résumé : regarde les implémentations de boost et STL et viens m'expliquer comment un programmeur moyen pourrait faire un truc équivalent. Faire du C++ performant requiert beaucoup d'expérience.

Un cast comme dans : t = (int*)malloc(n * sizeof(t)).
C'est absolument immonde, et sur le moment c'est le seul avantage de C sur "C/C++" que j'ai trouvé.Ha je croyais que tu trouvais que c'était un pb de C (cf. ton post...).

Neo_13

03/01/2010, 18h10

Un cast comme dans : t = (int*)malloc(n * sizeof(t)).
T'as pensé à vérifier avant que n*sizeof(t) < 2^(CHARBIT*sizeof(size_t)) -1 ?

Y compris dans le cas où size_t n'est pas un entier non signé ?

Møgluglu

03/01/2010, 18h24

Tu as parfaitement résumé : regarde les implémentations de boost et STL et viens m'expliquer comment un programmeur moyen pourrait faire un truc équivalent.

Parce que c'est le principe d'une bibliothèque de faire les trucs durs une fois pour toutes pour que le programmeur moyen n'ait plus que les choses faciles à faire?

Ou regarde l'implémentation de la libm en C ou dans tout langage de ton choix et va m'expliquer comment le programmeur moyen ferait ça. ;)

Sérieusement, le C est encore pire de ce point de vue. Il faut soit tout faire soi-même et être un cador soit utiliser des bonnes bibliothèques...

Ha je croyais que tu trouvais que c'était un pb de C (cf. ton post...).

Je voulais dire "on n'a pas besoin de faire de casts explicites de pointeurs".

T'as pensé à vérifier avant que n*sizeof(t) < 2^(CHARBIT*sizeof(size_t)) -1 ?

Ah non mayrde. :o

newbie06

03/01/2010, 18h54

T'as pensé à vérifier avant que n*sizeof(t) < 2^(CHARBIT*sizeof(size_t)) -1 ?

Y compris dans le cas où size_t n'est pas un entier non signé ?
Toi t'as trop fait de BASIC récemment, ^ c'est xor en C :p

---------- Post ajouté à 18h54 ----------

Ou regarde l'implémentation de la libm en C ou dans tout langage de ton choix et va m'expliquer comment le programmeur moyen ferait ça. ;)
Là tu confonds problème d'algorithmique (mathématique en plus) et difficulté d'appréhension d'un langage, non ?
Je maintiens que le bon gros C++ utile (stl, boost) est illisible.

Mais sinon je plussoie le manque de libs en C et c'est bien pour ça que je me traine ma lib maison de structures de données depuis un moment :)

yuushiro

03/01/2010, 20h50

Là tu confonds problème d'algorithmique (mathématique en plus) et difficulté d'appréhension d'un langage, non ?
Je maintiens que le bon gros C++ utile (stl, boost) est illisible.

La lisibilité il y a tout de même 2 alternatives, le gars qui code salement (oui ça existe), on mets un peu tout n'importe où, puis le langage qui te force à jongler avec les pointeurs etc pour arriver à faire ce que tu veux.

newbie06

03/01/2010, 22h32

Je ne sais pas, mais je n'arrive pas à lire un langage qui autorise la surcharge des opérateurs par exemple. Et plus généralement les langages objets je n'aime pas (sauf CLOS, le couche objet de CommonLISP :)).

D'un autre côté je viens de prendre au pif des fichiers source de Boost, et j'ai trouvé ça plutôt lisible... Donc soit je vieillis mal, soit c'est vraiment bien écrit :p

yuushiro

03/01/2010, 23h07

En même temps la surchage d'opérateur tout dépend du domaine. Il est vrai que y'a aucun intéret à ajouter 2 camions entre eux.
Par contre dans le cas où l'on réécrit une classe "mathématique" celà devient intéressant.

xheyther

04/01/2010, 08h57

Là tu confonds problème d'algorithmique (mathématique en plus) et difficulté d'appréhension d'un langage, non ?
Je maintiens que le bon gros C++ utile (stl, boost) est illisible.

Il n'y a pas de difficulté en ce qui concerne les algo mathématique (et les autres bien conncus) dans la mesure où ils sont parfaitement documentés par de multiples sources (enfin j'ai jamais eu de soucis de ce coté là avec ceux que j'utilise et pourtant j'en ai utilisé des assez peu courant).
Par contre, on a eu de vrai problème pour les implémenter de manière propre. Et même pas proprement pour une industrialisation du code mais proprement dans le sens : ça fait ce qu'on veut sans se vautrer et dans un temps raisonnable.
Donc dans un langage compliquer (c'était du python moi) ça doit être la grosse grosse merde, même en maitrisant l'algo.

tenshu

04/01/2010, 09h14

Et plus généralement les langages objets je n'aime pas (sauf CLOS, le couche objet de CommonLISP :)).

Pourtant l'objet caylebien :o

xheyther

04/01/2010, 10h34

L'objet c'est le mode de fonctionnement humain surtout !

newbie06

04/01/2010, 12h01

Je n'ai jamais accroché à l'objet parce que bien souvent les débutants empilent des hiérarchies juste parce que c'est possible. Oui, c'est très humain comme comportement : pourquoi faire simple quand on peut faire compliqué :)

D'un autre côté, je veux bien admettre que c'est parfois bien pratique, mais c'est comme C++ : il vaut mieux avoir des gens compétents pour faire quelque chose d'assez performant et maintenable.

Un exemple où la conception objet pèche : le placement des champs dans une classe dérivée est impossible, donc on ne peut pas tuner l'utilisation des lignes de cache. Hum pas claire ma phrase, alors un exemple :

class A {
int a;
char name[128];
int b;
virtual void f() = 0;
};
class B : public A {
int c;
virtual void f();
};

Une instance de type B sera composée des champs a, name, b et c. Mais si tous les calculs se font sur les champs a, b et c, le champ c n'est pas sur la même ligne de cache que a et b. Cet exemple est évidemment idiot, mais c'est pour donner l'idée ;)

Ha un truc que j'aime bien en C++ : les templates c'est vraiment chouette, ça fait des macros typées !

rOut

04/01/2010, 12h37

Perso, je ne me souviens plus trop par quoi j'ai commencé, peut être du basic ou du php. En tout cas, j'ai fait pas mal de PHP quand j'étais jeune, pour m'amuser à faire des sites web. Après quoi, j'ai fait un peu de Scheme, de Fortran, puis de C, de C++, de Java, Lex/Yacc, de SQL, d'assembleur (en fait pas vraiment vu que ça me saoulait, je n'y allais pas), de C#, de HTML et cie, en école d'ingénieur. Et pour mon boulot, j'ai principalement fait du Java, mais j'envisage / aimerais bien repartir plutôt du coté du C++ que je considère comme bien plus interessant. Pour une utilisation perso, je fais un peu de scripts Bash, j'ai tâté du Python, et je m'amuse en C++ pour des projets persos qui n'aboutissent généralement pas :)

Pour ce qui est de mon opinion sur les différents languages, je place Java et C# au même niveau, celui des languages pratiques pour coder rapidement, relativement proprement (la propreté dépend effectivement du programmeur a mon avis), sans avoir à recoder la roue, notamment en entreprise, et ils bénéficient d'un très bon outillage, pour tout ce qui est industrialisation du développement.

Comme je le disais, je me suis un peu amusé en Python, et même si je le préfère au PHP pour sa rigueur syntaxique et sa "propreté" intrinsèque, je dois dire que finalement, j'utilise plus des scripts Bash pour faire des petits programmes rapides que Python ou PHP, même si c'est plus crade, finalement c'est bien plus rapide à faire. La plupart du temps je n'ai pas besoin du formalisme objet pour coder ce que je veux, et je perçoit Python comme un language objet, ce qui me perturbe plus qu'autre chose.

Finalement, seul le C++ me parait sortir du lot, quand bien même il est bourré de défauts, notamment au niveau du typage, sa puissance au niveau métaprogrammation me laisse rêveur. C'est également le language que je perçoit comme le plus élitiste, du fait de sa souplesse. Il est très facile de coder quelque chose d'horrible et d'inutilisable, alors que cela demande beaucoup d'experience et de reflexion pour en sortir quelque chose de propre. Et on a des exemples de merveilles d'ingénierie codées en C++ (la STL, et encore plus BOOST).

Pour les autres languages que j'ai pu voir, bah, rien de particulier à dire, la diversité permet de former un programmeur à s'adapter et à abstraire les algorithmes au delà de la syntaxe, mais également à clarifier son code, car pour chaque language, il va devoir écrire les choses proprement pour arriver à s'y retrouver, alors qu'une personne habituée à coder dans un seul language va vite prendre de mauvaises habitudes et faire de la merde (au niveau clareté).

D'un autre côté je viens de prendre au pif des fichiers source de Boost, et j'ai trouvé ça plutôt lisible... Donc soit je vieillis mal, soit c'est vraiment bien écrit :p
Je pencherai pour la deuxième option.

Tramb

04/01/2010, 12h38

Disons que l'objet est un peu surévalué.

En effet, l'objet c'est souvent super stateful et l'état en programmation, c'est souvent le mal (je me bats pour faire comprendre ça autour de moi au boulot) car il faut maintenir des invariants et la complexité explose. Et c'est là que les bugs attaquent (http://www.youtube.com/watch?v=1IWF3IsEPBE).

C'est là où le fonctionnel est vraiment intéressant, il encapsule les changements d'états à très peu d'endroits. Il faut en retenir les principes même dans un langage impératif/objet pour ne pas abuser des classes quand de simples free functions font l'affaire.
Même si l'absence de support pour les lamb(a)da functions (http://en.wikipedia.org/wiki/Lambda_calculus#First-class_functions) et les closures (http://en.wikipedia.org/wiki/Closure_(computer_science)) obligent à contourner avec des functors en C++ par exemple.

En plus l'objet est souvent maléfique pour la performance en mélangeant des données chaudes, et des données froides, et en impliquant très souvent beaucoup de pointer walking.

Donc je résume ma doctrine (pour le C++ mais c'est valable pour les langages similaires):
1) de l'objet pour encapsuler l'état à haut niveau
2) mais pas trop, il faut minimiser cet état, donc il faut essayer d'être pur (http://en.wikipedia.org/wiki/Referential_transparency_(computer_science)) dès que c'est possible
3) ne pas appliquer les règles précédentes quand y'a besoin de gratter de la perf :p

(PS: Et la STL souffre de deux défauts majeurs : sa gestion des allocateurs, et des streams)

rOut

04/01/2010, 12h40

Ha un truc que j'aime bien en C++ : les templates c'est vraiment chouette, ça fait des macros typées !
Plusun, les templates c'est juste mortel. Et pour faire de la méta programmation et des vérifications compile-time c'est le top. Bon, après ils leur manque quelques détails, mais ils devraient arriver dans la prochaine révision (template typedefs/aliases, etc)

Tramb

04/01/2010, 12h56

Plusun, les templates c'est juste mortel. Et pour faire de la méta programmation et des vérifications compile-time c'est le top. Bon, après ils leur manque quelques détails, mais ils devraient arriver dans la prochaine révision (template typedefs/aliases, etc)

Ouais enfin la syntaxe est quand même bien pénible pour faire des trucs compliqués, plus les problèmes de compat' entre g++ et msvc...
Mais ouais, c'est super expressif.
Par contre il faut toujours des tonnes de macro pour rendre ça vraiment utilisable dans du code client.

rOut

04/01/2010, 13h22

Ouais enfin la syntaxe est quand même bien pénible pour faire des trucs compliqués, plus les problèmes de compat' entre g++ et msvc...
Mais ouais, c'est super expressif.
Par contre il faut toujours des tonnes de macro pour rendre ça vraiment utilisable dans du code client.
Ca dépend ce que tu veux en faire. Là je m'amuse à coder une vérification à la compilation pour du code OpenGL, en utilisant des templates. Bah une fois le tout en place, c'est transparent pour l'utilisateur il a des messages d'erreur si son code OpenGL n'est pas correct, mais il n'utilisera que des structures simples en façade. Par contre, en interne je fais des macro pour pas avoir à écrire toutes les instanciations explicites de templates.
Bon, j'en suis toujours à un stade très "initial" dans mon implémentation et je vais peut être me rendre compte que ça déconne plus tard, mais pour le moment, je suis assez content parce que ça reste à peu près propre.

Pour le moment, le seul truc qui m'ait un peu géné, c'est l'impossibilité de simplifier une spécialisation de template en fixant un paramètre, mais comme je le disais, c'est officiellement reconnu comme un manque et c'est un objectif de la révision c++0x.

Finalement, si on regarde, boost et la stl, il y a assez peu de macro du point de vue client (sauf dans des parties spécifiquement orientées macro évidemment).

Tramb

04/01/2010, 13h31

tenshu

04/01/2010, 13h43

Disons que l'objet est un peu surévalué.

En effet, l'objet c'est souvent super stateful et l'état en programmation, c'est souvent le mal (je me bats pour faire comprendre ça autour de moi au boulot) car il faut maintenir des invariants et la complexité explose. Et c'est là que les bugs attaquent (http://www.youtube.com/watch?v=1IWF3IsEPBE).

C'est là où le fonctionnel est vraiment intéressant, il encapsule les changements d'états à très peu d'endroits. Il faut en retenir les principes même dans un langage impératif/objet pour ne pas abuser des classes quand de simples free functions font l'affaire.
Même si l'absence de support pour les lamb(a)da functions (http://en.wikipedia.org/wiki/Lambda_calculus#First-class_functions) et les closures (http://en.wikipedia.org/wiki/Closure_%28computer_science%29) obligent à contourner avec des functors en C++ par exemple.

En plus l'objet est souvent maléfique pour la performance en mélangeant des données chaudes, et des données froides, et en impliquant très souvent beaucoup de pointer walking.

Donc je résume ma doctrine (pour le C++ mais c'est valable pour les langages similaires):
1) de l'objet pour encapsuler l'état à haut niveau
2) mais pas trop, il faut minimiser cet état, donc il faut essayer d'être pur (http://en.wikipedia.org/wiki/Referential_transparency_%28computer_science%29) dès que c'est possible
3) ne pas appliquer les règles précédentes quand y'a besoin de gratter de la perf :p

(PS: Et la STL souffre de deux défauts majeurs : sa gestion des allocateurs, et des streams)

Tu vois certainement ça de ton oeuil, avec ton utilisation et la/les finalités qui vont avec.

J'ai lu des papier qui disaient tout le mal blabla stateful, blablabla vilaine méthode statique. Globalement on évite si on peut, mais quand on code un site web on se retrouve dans un cas de figure où l'on doit souvent avoir l'état sous la main.

Quand je regarde le framework php symfony qui me semble plutôt dans le haut du panier niveau programmation php. Je me dit que je doit avoir raison.

Et puis de toute façon le procédural .... qu'elle horreur!

rOut

04/01/2010, 14h08

Le problème est que si tu veux spécifier le paramètre de template n+1, tu es obligé de spécifier le paramètre de template n, et récursivement tous :)

Donc quand tu veux instancier ton super hash map qui prend KEY, VALUE, LESS, HASH, ALLOCATOR, tu te retouves à devoir spécifier std::less<int> et defaulthash<int> si tu veux juste faire varier l'allocateur.
Et ça fait des notations très très verbeuses (surtout que l'allocateur prend en paramètre de template le type à allouer).

Et vu que y'a pas de typedef template, tu te retrouves à faire des contorsions à base de classes dérivées spécialisées (yuck) ou de macros (yuck mais moins, finalement, pour moi).
C'est ce dont je parlais, et visiblement, des gens biens et biens placés veulent palier à ce genre de problème dans les specifications C++ à venir :
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1449.pdf

---------- Post ajouté à 14h08 ----------

Sinon, pour l'aspect stateful et tout, mis à part les bugs que cela peut apporter, c'est finalement un compromis à faire entre clarté / facilité de design (plus naturel de penser en terme d'objets, de composants, etc), et difficulté à prouver que tout tient la route. Tant qu'on y est, on peu dire que l'abstraction du C est source de bugs et de perte de performance également et qu'il vaut mieux coder en assembleur pour maitriser le code, c'est le même genre de raisonnement. Sauf que parfois, un bon design, utilisant le paradigme objet pour sa conception ira plus vite que la même chose codé "linéairement" en assembleur, parce que l'algo procédural n'est pas adapté au problème (en théorie).

Tramb

04/01/2010, 14h36

Non mais on peut faire de l'objet en C ou en ASM hein, plein de monde le fait ou l'a fait, y'a juste pas de facilités pour ça.
Note que je ne critique pas l'abstraction, juste que l'objet n'est pas la seule méthode d'abstraction.
Le passage de message à la erlang ou la composition fonctionnelle en sont d'autres.

Sinon, je maintiens ce que je dis sur l'état, mais c'est d'autant plus vrai que les programmes sont gros...

rOut

04/01/2010, 14h42

J'avoue que pour le coup, j'ai du mal à imaginer comment faire un "gros" programme (genre un IDE, eclipse par exemple), tout en stateless. Et comme ça, à priori, je ne suis pas non plus convaincu de la perte de performance liée à la programmation objet sur ce genre de gros truc. Mais bon, c'est juste un pressentiment.

Tramb

04/01/2010, 14h51

Evidemment qu'il y'a de l'état, mais il ne faut pas le distribuer partout.
Le pattern objet Model-View-Controller très utilisé dans la GUI isole justement l'état (le model) de sa view et de son controller.

Un truc que j'ai oublié de dire : quand tu fais de la programmation parallèle, l'état devient encore plus ton pire ennemi car c'est encore plus dur de prouver des invariants à travers plusieurs clients concurrents!

Sinon la perte de perf de l'objet, ça ne concerne que les parties hautes performances d'une application, l'exemple de newbie06 là-haut est très bon.
Si tu veux itérer sur 20000 objets de type "A" uniquement pour consulter leur "a", tu vas le payer bien plus cher en accès mémoire avec ce design et tu auras du mal à le vectoriser (SoA vs AoS : l'objet c'est AoS à donf, mais tu peux essorer plus de perf avec du SoA).

rOut

04/01/2010, 15h03

Tramb

04/01/2010, 15h09

Ha bah oui, mais après c'est plus une question de bonnes pratiques en programmation objet que la programmation objet elle même. Pareil, si tu as l'intention d'itérer sur les 20000 objets pour consulter un seul de leur attribut alors que chaque objet et un machin monstrueux, c'est peut être ton design objet qui est mauvais. Tu peux stocker tes "a" dans un conteneur statique dédié et y faire référence par les "A" ensuite (ou un truc du genre) au lieu de les stocker dans les objets eux même. Enfin c'est juste pour dire que c'est le design qui est en cause bien souvent, pas l'objet.

Ce que tu suggères une perversion du design objet au nom de la performance qui ferait hurler à la lune Bertrand Meyer, mais c'est pas grave car ma règle 3 nous autorise à le faire dès que c'est nécessaire :)

AoS et SoA signifiant ?

"Array of structures" et "Structure of arrays"

PS : Lisez le point de vue de Stepanov, un des pères de la STL:
http://en.wikipedia.org/wiki/Alexander_Stepanov

Eh oui, si il y'a la STL dans le C++ c'est avant tout parceque l'objet pur c'est trop limité et la programmation générique est un complément fort utile!
C'ets pour ça que le C++ est un merveilleux langage pragmatique car MULTI-PARADIGMES.

rOut

04/01/2010, 15h20

C'est vrai que ça peut paraitre être une aberration d'un point de vue objet pur, mais dans ce cas c'est que l'on pousse le vice jusqu'a encapsuler les données elles mêmes dans des objets stateful (ouais, je sais c'est déjà le cas en C#, et d'autres langages objets). Et je suis d'accord que là c'est certainement une aberration d'un point de vue performances.

Il faut peut être convenir d'un niveau d'abstraction à obtenir à l'aide de la programmation objet, et d'un niveau de données "brutes" à conserver pour éviter de surcharger le tout.

Prenons l'exemple d'un moteur 3D. Il est censé charger et afficher des models 3D composés de vertex, d'arêtes, formant des triangles. Il serait totalement aberrant de modéliser indépendamment les vertex et les arêtes sous forme d'instances de classes, sachant que l'on aura pas besoin de les manipuler indépendamment du model complet. Une api comme OpenGL par exemple, permet de charger un tableau d'octet contenant les coordonnées de tous les vertex d'un model, puis les triplets d'indices pour former les triangles du model. Quand bien même on adopte le paradigme objet pour manipuler notre model 3D, il est clair que l'on doit conserver à tout prix les coordonnées des vertex et les indices des triangles sous forme de blob, sinon, bonjour l'overhead.

Tramb

04/01/2010, 15h23

Exactement.

newbie06

04/01/2010, 15h39

Raaaaaaaaah je suis tombé amoureux de Stepanov :p

rOut

04/01/2010, 15h55

Le footballeur ? :tired:

fefe

06/01/2010, 19h55

Entièrement d'accord. Bon, après, faut quand même expliquer à tes utilisateurs que ça ne s'applique pas dans tous les cas, et que parfois, développer un vrai outil (ou l'acheter) a aussi son intérêt ;)

Developper un vrai outil est ce qui se passe pour le projet suivant au vu des resultats du precedent. Ce qui a ete utile dans l'outil precedent est generalement transfere a un vrai developpeur (quelqu'un dont le boulot est d'ecrire du software et qui fait ca proprement en theorie et le maintiendra) qui developpe un outil stable. Outil stable qui sera linke d'une maniere ou d'une autre a un tas immonde de spreadsheet et de VBA codant les nouvelles idees qui n'avaient aps ete developpees pour le projet precedent.

Pour le genre de chose sur lesquelles je bosse il est impossible d'acheter un outil externe parce que 1: ca n'existe pas, 2: meme si ca existait, ca se saurait et ca donnerait des infos sur ce qu'on fait a la concurrence...

Clair! Et si en plus, ça rentre dans un mail et c'est utilisable sur BlackBerry ou iPhone, c'est encore mieux :lol:
Surtout tu fais copier coller et t'as ton slide powerpoint ;).

Nilsou

06/01/2010, 20h37

Je n'ai pas lue l'ensemble du topic : mais moi personnellement je ne programme qu'avec le C++ après avoir tâté de beaucoup d'autre langage.

Ce langage est un peu plus compliqué que d'autre langage plus proche de l'utilisateur et plus facile.
Mais il a l'avantage d'être proche du fonctionnement de l'ordi, de permettre de tout créer par sois même, les débuts en C++ sont assez dur, mais une fois la base maitrisé le programmeur peut se faire ses propre fonctions de base .

Des fonctions présentent dans d'autres langages a la base, mais au moins la , c'est toi qui les a faites, et tu peut les modifier, les adapter.

Bref, je pense aussi qu'un logiciel bien codé en C++ permet d'atteindre des sommet niveau rapidité et optimisation en comparaison des autres langages.

C'est aussi un langages très utilisé, et avec le C, il existe un grand nombre de bibliothèque et de travaux réalisé par d'autre programmeur, un bien plus grand nombre que pour un autre langages.

Si c'est la programmation de jeux vidéos qui vous intéressent : je conseils C++ + OpenGl + SDK. Un trio qui vous permettra de tout réaliser avec de la patience et de la détermination.

fefe

06/01/2010, 21h43

Mais il a l'avantage d'être proche du fonctionnement de l'ordi,

Non :), le fonctionnement de l'ordi n'a rien d'oriente objet, meme si C est l'un des langages les plus proches du fonctionnement de l'ordinateur, C++ s'en eloigne considerablement (essentiellement chacune des differences de C++ avec C contribue a l'en eloigner).

Etre proche du hard n'est vraiment un argument positif que pour ce qui a besoin de controler du materiel (un driver), ou d'optimiser pour les derniers % de performance qu'un compilateur/interpreteur n'est pas capable d'extraire d'un code de haut niveau (mais dans ce cas une routine en assembleur au milieu de code de haut niveau est la bienvenue), donc ce n'est pas toujours une necessite.

Je ne critique pas C++, mais c'est une illusion de penser que C++ est proche du hard (bien entendu si on compare a du PHP ou Python, C++ est probablement plus proche du hard:), mais c'est essentiellement du a la proximite avec C que le cote ++).

rOut

06/01/2010, 22h03

Bah de toute façon c'est pas essentiellement la proximité du hard qui fait la performance... Avec la rapidité des procs de nos jours et la complexité des programmes, c'est avant tout le design et les algorithmes qui comptent, et puis "un peu" le langage ensuite (bon, dans certains cas, certains langage sont plus adaptés, allez faire des inversions de grosses matrices en assembleur :p).

Et pour ceux qui veulent se mesurer le zizi : http://shootout.alioth.debian.org/

Tramb

06/01/2010, 23h09

Non :), le fonctionnement de l'ordi n'a rien d'oriente objet, meme si C est l'un des langages les plus proches du fonctionnement de l'ordinateur, C++ s'en eloigne considerablement (essentiellement chacune des differences de C++ avec C contribue a l'en eloigner).

Rhololo le hardeux qui croit que C++ = orienté objet :p
C++ est aussi proche que tu veux du hard, surtout que toutes les suites de dev supportent des intrinsics peephole-optimisées et des assembleurs inline (sauf MSVC en 64teubs qui exige de linker des .obj assemblés à l'extérieur).

Je ne critique pas C++, mais c'est une illusion de penser que C++ est proche du hard (bien entendu si on compare a du PHP ou Python, C++ est probablement plus proche du hard:), mais c'est essentiellement du a la proximite avec C que le cote ++).
Exactement, le fait de pouvoir faire toutes les saloperies que tu fais en C en C++ fait que tu peux mixer facilement du code très haut niveau objet et/ou générique avec des routines qui accèdent des registres memory-mappés ou qui traitent des gros tableau en SIMD avec des prefetches. Dans le même projet. Avec le même langage.

Après, oui, tu peux pas écrire un bootsector en C++ :)

Signé : Al-Qaida section C++ ^_^

fefe

06/01/2010, 23h24

allez faire des inversions de grosses matrices en assembleur :p).

[/url]
Les librairies BLAS optimisees fournies par les constructeurs sont ecrites en assembleur, et representent l'essentiel des calculs matriciels faits sur PC... petites ou grosses matrices.
A propos du C++ je sais que tu peux descendre aussi bas niveau que tu veux, mais, mon point etait que c'etait son lien avec C qui le permettait plutot que le cote ++ :).
Dans un "vrai" language proche du hard tu n'utilises que des pointeurs non types pour addresser tes donnees :), ca sert a rien mais c'est comme ca que ca marche...

Je suis un integriste de rien, je n'aime pas programmer, quel que soit le langage :) (c'est probablement le resultat de 25 ans de trop passes a programmer en tout et n'importe quoi).

Grosnours

06/01/2010, 23h25

Et pour ceux qui veulent se mesurer le zizi : http://shootout.alioth.debian.org/

Ouch, pas encore parfaite, parfaite, l'implémentation du F# via Mono quand on voit les perfs :
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=fsharp&lang2=ocaml
:p

Tramb

06/01/2010, 23h29

A propos du C++ je sais que tu peux descendre aussi bas niveau que tu veux, mais, mon point etait que c'etait son lien avec C qui le permettait plutot que le cote ++ :).

Et c'est bien vrai!

Dans un "vrai" language proche du hard tu n'utilises que des pointeurs non types pour addresser tes donnees :).
Certes mais bon, les opcodes sont de plus en plus éloignés de leur implémentation sous-jacente depuis des dizaines d'années. Faudrait coder en uops. Mais moi l'abstraction, ça me va, je la vis bien :p

Je suis un integriste de rien, je n'aime pas programmer, quel que soit le langage :).

Moi si, je suis intégriste et j'aime programmer :)

Plam

06/01/2010, 23h32

Bon j'ai pas tout lu, mais je dirai que ça dépend des besoins :
- j'aime les langages qui peuvent être bidouillé avec l'outil qu'on veut (donc j'aime pas les trucs proprio fermé, genre .net, me parlez pas de mono merci). :(
- j'aime bien les applis web, j'en fais pas mal, même de manière assez propre. Croyez le ou non, on peut être propre en PHP et Javascript (bien séparer le PHP pour le controleur/model et vue en JS et html). Javascript c'est pas mal (bien avec un bon debugger) et des frameworks genre Jquery ou Prototype. Comme exemple je citerai mon "gros" projet actuel, "Xen Orchestra". :p
- le C pour le milieu industriel, compilateur gcc qui va bien, et n'importe éditeur de texte (sauf vi, troll pas caché ^_^ )
- j'aime moyen les "gros" IDE (plus gros que Geany c'est pour dire) : j'aime pas y'en a de partout c'est lourd c'est moche. :tired:

Par contre, et par dessus tout, je ne pourrai pas vivre sans git (gestionnaire de version) : c'est l'outil le plus puissant que j'ai croisé de l'année 2009 :wub::wub::wub: (je connaissais pas avant).

Voilà ;)

Tramb

06/01/2010, 23h37

Par contre, et par dessus tout, je ne pourrai pas vivre sans git (gestionnaire de version) : c'est l'outil le plus puissant que j'ai croisé de l'année 2009 :wub::wub::wub: (je connaissais pas avant).

Je partage ton amour, heureusement git est une grosse chaudasse et nous pouvons le partager! :wub:

newbie06

06/01/2010, 23h44

Certes mais bon, les opcodes sont de plus en plus éloignés de leur implémentation sous-jacente depuis des dizaines d'années. Faudrait coder en uops.
Toi t'as trop fait de x86, je te propose un camp de rééducation ARM où l'on te montrera la vraie vie d'un opcode :rolleyes:

---------- Post ajouté à 23h42 ----------

Je partage ton amour, heureusement git est une grosse chaudasse et nous pouvons le partager! :wub:
Pareil, git est la grosse claque de 2009 :)

---------- Post ajouté à 23h44 ----------

Pour le genre de chose sur lesquelles je bosse il est impossible d'acheter un outil externe parce que 1: ca n'existe pas, 2: meme si ca existait, ca se saurait et ca donnerait des infos sur ce qu'on fait a la concurrence...
Intéressant. Donc certaines boites font du VBA et de l'Excel... Remarque je viens de voir ça par chez nous aussi. J'ai hurlé à l'hérésie, j'aurais ptet pas du :tired:

rOut

06/01/2010, 23h55

Croyez le ou non, on peut être propre en PHP et Javascript
:haha: Non, quand même... PHP, admettons, mais Javascript, c'est clairement un des trucs les plus crades que j'ai jamais rencontré. Sans parler des navigateurs qui supportent chacun leur "version" de javascript, le langage est tellement mou (dans le sens souple, mais en péjoratif), qu'on ne peut quasiment rien structurer. Ouais, on peut faire de l'objet... mais voilà quoi, vive le cauchemard. Et pourtant, j'en ai fait des gros trucs, et je remercie les projets comme Prototype, Scriptaculous ou Mootools qui essaient d'apporter un peu de propre, même si c'est peine perdue.

- le C pour le milieu industriel, compilateur gcc qui va bien, et n'importe éditeur de texte (sauf vi, troll pas caché ^_^ )
Pour l'industriel au sens entreprise / prod et cie, le C est sacrément mal venu à mon avis. Je pense qu'il ne fait pas le poids niveau outillage / facilité de maintenance / rigeur face aux langages évolués comme Java ou C#. Après c'est sûr, si c'est industriel au sens perfo / bas niveau, ya pas trop d'alternative... et encore.

- j'aime moyen les "gros" IDE (plus gros que Geany c'est pour dire) : j'aime pas y'en a de partout c'est lourd c'est moche. :tired:
Je vais faire un peu de prosélytisme, parce que je pense que tu n'imagines même pas ce que tu rates. C'est peut être un peu gros, un peu lourd, moche sûrement pas, mais dans tous les cas, Eclipse me fait gagner tous les jours des heures entières de travail. Au taf, les deux touches les plus utilisées sur mon clavier sont Ctrl et Espace. C'est tout simplement hallucinant le gain de temps offert par cet IDE. les deux tiers du code écrit sont générés automatiquement avec ces deux touches, il ne reste plus qu'a se focaliser sur l'algorithme et c'est réglé.
Et ça, c'est juste pour du Java. A un moment, je continuais à utiliser windows pour coder sous visual studio pour l'aspect C/C++, mais depuis les dernières versions du plugin Eclipse correspondant, ils sont tout simplement arrivés à un niveau largement équivalent, et à peu près aussi pratique que pour le Java. D'ailleurs c'est vrai pour pas mal d'autres langages, c'est simple, je n'utilise plus qu'Eclipse. Même Git a un plugin intégré.

newbie06

07/01/2010, 00h09

Ouai emacs aussi a un plugin git, et il n'a pas besoin de 2 Go et d'un quad core pour tourner.
J'ai lancé Eclipse une fois, pas deux.

Haaaaaaa ça me manquait une guerre d'éditeurs/IDE :p

rOut

07/01/2010, 00h10

Ouais mais EMACS c'est moche et c'est vieux. :argumente: :ninja:

fefe

07/01/2010, 00h42

Ahahah maintenant il y en a qui developpent l'argument que Emacs c'est leger. Je me souviens des grands debats emacs-vi, et l'argument etait different ;).

Je me souviens encore de Eight Megabytes And Constanly Swapping (EMACS) :). Marrant comment 8MB ca ne fait plus vraiment swapper quoi que ce soit, meme un telephone portable :).

---------- Post ajouté à 01h42 ----------

Intéressant. Donc certaines boites font du VBA et de l'Excel... Remarque je viens de voir ça par chez nous aussi. J'ai hurlé à l'hérésie, j'aurais ptet pas du :tired:

En general, plus la boite est grosse pire c'est...

Sp1d3r

07/01/2010, 07h20

Je préfère celui là :

Emacs make a computer slow...

L'autre acronyme que j'aime bien pour rester dans les langages de programmation:

LISP : Lots of Irritating Single Parentheses

Tain le lisp c'est sympa mais quand on corrige un truc qu'on est en train d'écrire ça devient vite horrible :|.

newbie06

07/01/2010, 08h44

LISP : Lots of Irritating Single ParenthesesC'est pas plutot "Silly" ou "Spurious" ? Pfff je vieillis mal moi :|

---------- Post ajouté à 08h44 ----------

Ahahah maintenant il y en a qui developpent l'argument que Emacs c'est leger. Je me souviens des grands debats emacs-vi, et l'argument etait different ;).
Ca ne me rajeunit pas, mais c'est vrai : les deux arguments principaux etait que vi etait tres leger (normal, la version d'epoque [y'avait pas vim] etait depouillee au possible) et aussi qu'au moins vi tu le trouvais sur toutes les machines. Mais moi je m'en foutais, la premiere chose que je faisais etait d'installer emacs :p

Marrant comment 8MB ca ne fait plus vraiment swapper quoi que ce soit, meme un telephone portable :).Ouai on en est a 256MB ou 512MB de RAM sur les telephones un peu evolues, avec une puissance a faire rougir les premiers Alpha.

tenshu

07/01/2010, 09h28

:haha: Non, quand même... PHP, admettons, mais Javascript, c'est clairement un des trucs les plus crades que j'ai jamais rencontré. Sans parler des navigateurs qui supportent chacun leur "version" de javascript, le langage est tellement mou (dans le sens souple, mais en péjoratif), qu'on ne peut quasiment rien structurer. Ouais, on peut faire de l'objet... mais voilà quoi, vive le cauchemard. Et pourtant, j'en ai fait des gros trucs, et je remercie les projets comme Prototype, Scriptaculous ou Mootools qui essaient d'apporter un peu de propre, même si c'est peine perdue.

Je suis obligé de valider cette réponse :ninja:
Avec un framework on peut faire du PHP très ordonné. Ça devient juste un peut dangereux par ce qu'on fait ce que l'entreprise attend de nous on se repose a 95% sur les librairies et l'organisation du framework.
Finalement on peut très bien le maitriser sans avoir de grandes connaissances en objet (je parle plus ou moins en connaissance de cause).

Le Javascript ... bordel c'est immonde ce langage. Heureusement que les lib sont arrivées à la rescousse effectivement!.

Pour l'industriel au sens entreprise / prod et cie, le C est sacrément mal venu à mon avis. Je pense qu'il ne fait pas le poids niveau outillage / facilité de maintenance / rigeur face aux langages évolués comme Java ou C#. Après c'est sûr, si c'est industriel au sens perfo / bas niveau, ya pas trop d'alternative... et encore.

C# :vomit:

Je vais faire un peu de prosélytisme, parce que je pense que tu n'imagines même pas ce que tu rates. C'est peut être un peu gros, un peu lourd, moche sûrement pas, mais dans tous les cas, Eclipse me fait gagner tous les jours des heures entières de travail. Au taf, les deux touches les plus utilisées sur mon clavier sont Ctrl et Espace. C'est tout simplement hallucinant le gain de temps offert par cet IDE. les deux tiers du code écrit sont générés automatiquement avec ces deux touches, il ne reste plus qu'a se focaliser sur l'algorithme et c'est réglé.
Et ça, c'est juste pour du Java. A un moment, je continuais à utiliser windows pour coder sous visual studio pour l'aspect C/C++, mais depuis les dernières versions du plugin Eclipse correspondant, ils sont tout simplement arrivés à un niveau largement équivalent, et à peu près aussi pratique que pour le Java. D'ailleurs c'est vrai pour pas mal d'autres langages, c'est simple, je n'utilise plus qu'Eclipse. Même Git a un plugin intégré.

Eclipse = caca
Netbeans = lebienabsolu
:troll:

Tramb

07/01/2010, 10h07

C# :vomit:

Bah au moins dans le C# y'a 2/3 bonnes idées contrairement au Java :rolleyes:

tenshu

07/01/2010, 10h13

Bah au moins dans le C# y'a 2/3 bonnes idées contrairement au Java :rolleyes:

Han le troll des familles :o

J'avoue que j'ai jamais accroché au Java, je l'explique pas bien mais bon.

Tramb

07/01/2010, 10h17

Ce que je lui reproche c'ets d'être sorti sur le tard et d'avoir juste oublié 30 ans de travaux sur les langages de programmation et d'avoir des défauts qui sont excusables dans le C++ mais pas dans un nouveau produit :)
Ex : pas de closure. Whatwere They Finking?

Une espèce de masturbation tout-objet qui paraissait déjà naze à l'époque aux observateurs éclairés.
Et encore ils ont rajouté de la généricité depuis, avant c'était juste ignoblissime.

DaP

07/01/2010, 10h20

Bah au moins dans le C# y'a 2/3 bonnes idées contrairement au Java :rolleyes:

C'est surtout que Java a été bâclé dès le début, et n'arrête pas de s'enfoncer (generics ratés, et j'attends de voir la tronche des fermetures).
À côté C# est parti sur des assez bonnes bases (pas de trucs foireux genre checked exceptions, et l'opposition valeur/référence ressemble à quelque chose en pratique par exemple) et a eu des changements intéressants et utiles (get/set, générateurs, LINQ, ...).
Après je trouve que c'est dommage qu'on se coltine toujours des dérivés du C dans la programmation "mainstream" (heureusement Python devient de plus en plus populaire), mais C# est assez agréable et productif alors que Java n'arrête pas de se mettre dans le chemin du programmeur.

newbie06

07/01/2010, 10h21

Ce que je lui reproche c'ets d'être sorti sur le tard et d'avoir juste oublié 30 ans de travaux sur les langages de programmation
S'il y a bien un domaine dans lequel les gens passent a leur temps a reinventer la roue en moins bien, c'est l'informatique...
Exemple toujours sur Java : la VM n'avait strictement rien d'innovant.

Mais, meme si je n'aime pas Java (euphemisme), ils ont quand meme su faire un travail d'engineering decent.

rOut

07/01/2010, 10h48

Newbie il chie sur tous les langages qu'on lui propose :p

tenshu

07/01/2010, 11h25

Ex : pas de closure. Whatwere They Finking?

Ils ont implémenté les closure dans php 5.3 :cigare:

D'ailleurs PHP a le problème inverse de java, il inclut tout les trucs à la mode dans un putain de vrac sans cohérence.
Genre ok on aura des fonction lambda et des closure mais concrètement est ce que ça a été ajouté pour des raisons cruciales et pertinentes ?
J'en doute.

Tramb

07/01/2010, 11h38

Les fonctions lambda et les closures ne sont pas "à la mode", c'est juste un truc fondamental de la programmation fonctionnelle, et ce dès les années 70 :)

Après, effectivement, pas sûr que ça intéresse le programmeur web moyen...

Plam

07/01/2010, 12h07

Pour en revenir au Javascript, oui ya des trucs pas terrible, mais en m'y mettant "à fond" sur mon projet actuel, ya vraiment des bonnes idées !

Avec firebug, facile de debugger :) Et puis Prototype ou JQuery, et scriptaculous, wow.

Et c'est encore "propre", alors que je commence a avoir un "gros" fichier js.

Sinon pour le PHP, on peut aussi faire du propre sans framework : cf encore mon projet actuel. Bon, j'avoue, je me suis aidé d'un maniaque du dev qui est très propre (le genre de mec qui fait aussi son propre langage de prog : http://yaiff.isonoe.net/ ).

Au final, c'est beau le soft :wub:

Et aussi dans un autre registre, imaginez : faire un rapport en LaTex de manière collaborative avec git :wub::wub:

newbie06

07/01/2010, 12h24

Newbie il chie sur tous les langages qu'on lui propose :p
Je suis un vieux con aigri :'(

rOut

07/01/2010, 13h14

C'est surtout que Java a été bâclé dès le début, et n'arrête pas de s'enfoncer (generics ratés, et j'attends de voir la tronche des fermetures).
À côté C# est parti sur des assez bonnes bases (pas de trucs foireux genre checked exceptions, et l'opposition valeur/référence ressemble à quelque chose en pratique par exemple) et a eu des changements intéressants et utiles (get/set, générateurs, LINQ, ...).
Après je trouve que c'est dommage qu'on se coltine toujours des dérivés du C dans la programmation "mainstream" (heureusement Python devient de plus en plus populaire), mais C# est assez agréable et productif alors que Java n'arrête pas de se mettre dans le chemin du programmeur.
C'est quoi l'interêt des fermetures, concrètement ? Je veux dire, par rapport à la même chose réalisé avec une classe paramétrable (un genre de foncteur à la limite) ?

Sinon, les getter/setter sont bien gérés dans Java je trouve. Alors oui, c'est pas contraint par le langage, on peut faire n'importe quoi, mais si on s'efforce de suivre certaines règles de codage / specifications "officielles", comme les Java Beans par exemple, ça permet de faire des choses aussi bien que les properties en C#.

Sans parler des specs J2EE qui sont un travail assez impressionnant sur l'industrialisation des développements et sur l'architecture orientée composants / services. On peut faire des choses extrêmement propres grâce à ça, des applications modulaires que l'on pourra faire évoluer très facilement. Ya qu'a voir les possibilités offertes par des frameworks comme Spring. Ca demande juste une bonne architecture au préalable et de coder proprement le reste.

---------- Post ajouté à 13h14 ----------

Je suis un vieux con aigri :'(
Ca doit pas être rigolo tous les jours, tu bosses dans le développement ? :)

Tramb

07/01/2010, 13h24

C'est quoi l'interêt des fermetures, concrètement ? Je veux dire, par rapport à la même chose réalisé avec une classe paramétrable (un genre de foncteur à la limite) ?

L'expressivité et la concision, tu passes pas ton temps a écrire des functors pour faire de la glu et capturer l'environnement syntaxique (un workaround qui marche mais qui fait écrire des tonnes de code pas bien passionnant).

Partitionner tous les entiers inférieurs à une variable dans un tableau
Ex en C++ (en gros j'ai la flemme de faire un vrai truc) avec un functor (oui je connais bind1st et consorts :) ):

struct lessThan
{
int value;
lessThan(int v) { value = v; }
bool operator()(int v) { return v < value; }
};

void f(int* sequence, size_t size, int value)
{
std::partition(sequence, sequence+size, lessThan(value));
}

avec une lambda fonction (et la closure qui permet de capturer value) dans un C++ imaginaire ça donnerait un cool truc comme ça:

void f(int* sequence, size_t size, int value)
{
std::partition(sequence, sequence+size, lambda{ x -> x < value} );
}

rOut

07/01/2010, 13h30

Bah, en java, tu peux faire une implémentation anonyme d'une interface dont le rôle est de comparer la valeur des éléments d'une liste à une valeur donnée aussi.

Un truc dans le genre (même si ça n'existe pas tel quel, c'est l'esprit) :

void f(List<Integer> sequence, int value) {
sequence.partition(new Comparator<Integer>() {
boolean compare(Integer element) {
return element < value;
}
});
}

C'est aussi clair pour moi.

Ca existe par exemple pour les méthodes de tri des listes, auxquelles on peut fournir une implémentation de l'interface Comparator pour permettre de définir un ordre quelconque sur les éléments.

Tramb

07/01/2010, 13h52

Bah, en java, tu peux faire une implémentation anonyme d'une interface dont le rôle est de comparer la valeur des éléments d'une liste à une valeur donnée aussi.

Un truc dans le genre (même si ça n'existe pas tel quel, c'est l'esprit) :

void f(List<Integer> sequence, int value) {
sequence.partition(new Comparator<Integer>() {
boolean compare(Integer element) {
return element < value;
}
});
}

C'est possible ça en Java sans passer value au constructeur du Comparator?
Si oui c'est une closure.

C'est aussi clair pour moi.
:O

Edit: Ah non, il y'a une feinte:
http://fishbowl.pastiche.org/2003/05/16/closures_and_java_a_tutorial/

rOut

07/01/2010, 13h56

Oui c'est possible. De la même manière que des classes imbriquées peuvent accéder aux champs d'instances de leur classe parente. Il faut peut être mettre value en paramètre "final int", je suis plus trop sûr, mais pour ce que ça change...

Bah ouais, je trouve ça aussi clair. :o
Au moins on sait ce qu'est censée faire la fonction : C'est un comparateur. Alors que lambda, pardon, mais au niveau signification fonctionnelle c'est pas très parlant.

Edit : Corrigé, c'est pas static qu'il faut mettre comme attribut au paramètre mais final, histoire d'assurer qu'il ne changera pas dans le code de la fonction.

rOut

07/01/2010, 14h06

Edit: Ah non, il y'a une feinte:
http://fishbowl.pastiche.org/2003/05/16/closures_and_java_a_tutorial/
Ouais, d'accord, dans le sens inverse (modification d'une variable externe), pour un truc comme :

i = 1;
1.upto(100) { |num| i *= num; }
puts i;Ce n'est peut être pas possible en Java... du moins, pas avec des classes anonymes. Mais bon... c'est un petit peu de l'enculage de mouche là, il faudrait un exemple plus interessant d'algorithme ou il n'y a pas de solution aussi efficace sans closure. :tired:

Tramb

07/01/2010, 14h59

Mais bon... c'est un petit peu de l'enculage de mouche là, il faudrait un exemple plus interessant d'algorithme ou il n'y a pas de solution aussi efficace sans closure. :tired:

Ouais de l'enculage de mouche, comme le typage, le RTTI, le polymorphisme et toutes ces choses qu'on peut émuler avec des constructions plus verbeuses :rolleyes:

tenshu

07/01/2010, 15h20

Tient pendant qu'on y est vous auriez des bouquins à recommander genre ça :

http://ecx.images-amazon.com/images/I/518AatQCwhL._SS500_.jpg

Tramb

07/01/2010, 15h25

r_one

07/01/2010, 15h41

En bouquins j'aime bien les Head First chez O'Reilly. C'est tout en anglais mais c'est super didactique et franchement bien fait. En plus il y a tout un tas de ressources en ligne.

Par contre c'est très Java pour tout ce qui est techniques de programmation (POO, design patterns, etc...) donc ça peut ne pas convenir à tout le monde (m'enfin les concepts restent les mêmes).

Neo_13

07/01/2010, 15h45

http://www.eyrolles.com/Scan/MaxiScan/9782212110791.jpg

Nilsou

07/01/2010, 16h19

Pour le C et le C++, l'avantage est bien sur que le C++ inclus le C, ce qui laisse un panel très large au programmeur, mais aussi, que, contrairement aux exemples évoqué plus haut .

Ce langage a une logique, il a été conçue avec un but et un sens pour ajouter de nouveaux concepts aux C, et il s'y est tenu, on est loin du grand nawak de certains langauges qui ont copié collé toute les fonction "a la mode" justement pour permettre un peu de programmer dans un grand foutoir avec la philosophie: plus il y en a , plus on a de chance de rendre tout le monde content.

rOut

07/01/2010, 16h21

Bah non, le C++ n'inclus pas le C... si tu utilises le C++ pour faire du C, bah en fait tu codes en C... :tired:

Tramb

07/01/2010, 16h23

Bah non, le C++ n'inclus pas le C... si tu utilises le C++ pour faire du C, bah en fait tu codes en C... :tired:

Oui le C++ n'inclut pas exactement le C.
Non, tu peux faire du C++ et utiliser des constructs C aux endroits désirés (ça s'appelle le pragmatisme et c'est la pierre d'angle du C++).

rOut

07/01/2010, 16h25

Oui le C++ n'inclut pas exactement le C.
Non, tu peux faire du C++ et utiliser des constructs C aux endroits désirés (ça s'appelle le pragmatisme et c'est la pierre d'angle du C++).
Dans ce cas tu fais du C++, parce que le C ne permet pas ça... :imparable: :tired:

Tramb

07/01/2010, 16h28

Oui enfin dans un cas tu utilises C pour désigner des idiomes C++, et dans un autre cas tu désignes un langage.

Nilsou

07/01/2010, 16h28

Edit: faille temporelle, tout ça.

rOut

07/01/2010, 16h29

Nilsou est pris dans une faille temporelle.

Tramb

07/01/2010, 16h41

Abattez-le!

Nilsou

07/01/2010, 16h44

Bah non, le C++ n'inclus pas le C... si tu utilises le C++ pour faire du C, bah en fait tu codes en C... :tired:
Bah ouais , c'est ça le truc cool! Tu switch comme tu veut.

Je ne suis pas un intégriste du C++, j'ai un problème qui se présente, je le résout avec les classe parce que ça me facilite la vie, mais si j'en ai marre, que je m'emmêle les pinceaux, ou que le problème m'apparait plus simple a traiter sous l'angle C, ben je le programme en mode C, et j'adore ça, switcher entre différentes méthodes, avoir le choix.

Les intégristes du C++ vont me maudire, mais mes progs tournent parfaitement.

J'avais notamment programmer un moteur de jeux 2D (en simulant de la 2D avec opengl en mode 3D pour profiter du zoom), je me souviens avoir résolut des problèmes très simplement et avoir gagner pas mal de FPS grâce a ce switch entre les deux types de programmations... un délice.

Neo_13

07/01/2010, 16h54

Le C++ c'est mal :gnome:

elpaulo

07/01/2010, 17h31

En fait ce topic c'est une boucle infinie quoi :ninja:

tenshu

07/01/2010, 17h51

Honnêtement j'ai aucune idée de bons bouquins pour l'apprentissage, mais méfie-toi des bouquins français de programmation en général.
C'est pas du snobimse mais de l'expérience, en général c'est de la merde de prof qui veut se faire du pognac.

Celui que je cite est très bon en tout cas :q
Et les bouquins de feu O'Reilly France était quasiment tous au top.

Tramb

07/01/2010, 17h58

Celui que je cite est très bon en tout cas :q
Et les bouquins de feu O'Reilly France était quasiment tous au top.

Je dis pas le contraire c'est juste qu'il faut se méfier et se faire conseiller... ce que tu tentes de faire :)

newbie06

07/01/2010, 18h41

Ca doit pas être rigolo tous les jours, tu bosses dans le développement ? :)
Oui et non. Je développe des outils internes pour aider à la conception de CPU, d'architecture et de micro-architecture. Donc j'ai à peu près totale liberté dans mes choix et pas de support à faire. De toute façon, je programme en C sans bug, 2 trouvés sur 20k LOC B) Pour ça que le pignolage à la UML, les docs de design ça me fait marrer :p

fefe

07/01/2010, 19h42

Oui et non. Je développe des outils internes pour aider à la conception de CPU, d'architecture et de micro-architecture. Donc j'ai à peu près totale liberté dans mes choix et pas de support à faire. De toute façon, je programme en C sans bug, 2 trouvés sur 20k LOC B) Pour ça que le pignolage à la UML, les docs de design ça me fait marrer :p

Ahahah, nous on mesure l'etat du projet au nombre de bugs trouves par semaine dans le code C++/Verilog: plus il y en a, mieux le projet va ! Quand on n'en trouve pas assez on s'inquiete !!! Le plus dur c'est de trouver les bugs dans les .doc qui contiennent les specs (bugs de l'interface chaise-clavier).

Quant a la liberte, on en a enormement, tant qu'on ne pete pas les millions de lignes de code des outils existant developpes ces 15 dernieres annees et qu'on s'interface avec eux... Ouais, en gros l'oppose de Newbie quoi ;).

newbie06

07/01/2010, 23h13

En fait, je suis très inquiet sur la quasi-absence de bugs trouvés dans mon code. On ne peut pas pondre 20k LOC en 6 semaines avec si peu de problèmes, donc ouai je frime, mais en réalité je flippe :|

Quant à cette liberté quasi-totale que j'ai eue, j'ai eu du bol de tomber au bon moment avec la bonne infrastructure et les bons arguments :) Y'a plus qu'à assurer...

tenshu

08/01/2010, 11h36

20K lignes en 6 semaines :O

C'est quoi l'adresse de ton fournisseur de 'remontants' ?

xheyther

08/01/2010, 11h44

ça doit être ACG Inc. (Automatic Code Generation inc.)

Ou alors il compte les commentaire genre licence et tout :mauvaiselangue:

newbie06

08/01/2010, 12h01

Des commentaires ? Ca sert a rien, ca devient obsolete au fur et a mesure que le code change :p

rOut

08/01/2010, 12h17

Il saute des lignes :rolleyes:

ylyad

08/01/2010, 12h23

Suite à ce passionnant débat, j'ai commencé à regarder Python (j'en avais entendu parler, mais pas plus) et ça me plait. Utiliser l'indentation (pré-requis de tout code pour être lisible) comme convention syntaxique, c'est déjà une très bonne idée. Et le côté mix de script et d'objet aussi rappelle la flexibilité permise par le Javascript, mais en beaucoup plus propre.
Du coup, je vais me relancer dans mon exploration de tinyERP, ERP libre (et plutôt puissant) écrit en Python. Parce que dans mon boulot (informatique de gestion, ERP, etc.), les problèmes de performance ne sont pas dues (ou rarement) à la performance du language, mais 1. à des problèmes profonds de conception, 2. à de la base de données (gros volumes de données, perfs du SGBD, etc.). Par contre, les bugs et les lourdeurs sont clairement liés à la complexité du language, et quand je vois un code Python, je vois très bien le gain en maintenance/évolutivité à espérer sur un code Java...

Tramb

08/01/2010, 12h32

Python a quelques constructions intéressantes, mais attention, passer à un langage typé dynamiquement quand tu viens du typage statique, c'est casse-gueule :)

tenshu

08/01/2010, 12h37

Ce qui est marrant avec python c'ets qu'il est très peut verbeux.
Donc on lit les base du langage, pusi on se dit tient je vais coder tel truc, on le fait et puis on se dit 'Nan attend j'ai dut oublier un truc là'.
Mais en fait on a rien oublié :)

L'indentation c'est bien sauf quand on se retrouve a imbriquer beaucoup de condition boucle et autre.

---------- Post ajouté à 12h37 ----------

Python a quelques constructions intéressantes, mais attention, passer à un langage typé dynamiquement quand tu viens du typage statique, c'est casse-gueule :)

Oui et non.
En documentant bien son code on peut éviter de multiplier 'toto' par 4 ^_^

Tramb

08/01/2010, 12h39

Oui et non.
En documentant bien son code on peut éviter de multiplier 'toto' par 4 ^_^

Comme je le disais précedemment : "c'est ce qu'ils disent tous".
Et après tu bosses avec eux et tu vois la terrible réalité telle qu'elle est :O

tenshu

08/01/2010, 13h06

Comme je le disais précedemment : "c'est ce qu'ils disent tous".
Et après tu bosses avec eux et tu vois la terrible réalité telle qu'elle est :O

^_^ je me doute. D'où le 'peut'.

Tramb

08/01/2010, 13h07

^_^ je me doute. D'où le 'peut'.

Bien vu la précaution oratoire (par écrit ^_^)

xheyther

08/01/2010, 13h25

Python a quelques constructions intéressantes, mais attention, passer à un langage typé dynamiquement quand tu viens du typage statique, c'est casse-gueule :)

Enfin, c'est pas vraiment le piège de python...

Au niveau des variables, je dirai que le piège viens plus du fait qu'en Python le nom de variable, c'est juste un pointeur vers l'objet (tout est objet tout ça).

edit : une référence en faite, pas un pointeur.

Neo_13

08/01/2010, 13h27

rOut

08/01/2010, 13h28

Tramb

08/01/2010, 13h29

Bon ben suite à ce débat, et à une suggestion d'un site (amazon, peut etre, ou un autre), ça a déclencher ma curiosité et j'ai acheté la suggestion : "Calcul numérique avec un langage fonctionnel"...

Et puis faut que je me repenche sur erlang, je trouvais ça plutot élégant.

Y'a un bouquin que je trouve sympatoche c'est
"The Haskell School of Expression: Learning Functional Programming through Multimedia".

xheyther

08/01/2010, 13h50

Par contre, un truc qui me gave en Python, c'est que tu ne peux pas vraiment définir la structure des classes, au niveau des attributs. Il suffit d'écrire self.truc = 'machin' dans une méthode d'instance pour quel la classe / instance obtienne un nouvel attribut d'instance truc. Si tu définis des attributs dans la déclaration de la classe (après le class Truc:), ce ne sont que des attributs de classe. A moins qu'il y ai quelque chose qui m'ait échappé ?

Euh, je pense avoir compris mais je ne suis pas sûr :

class MyClassDTC:
attribut_de_classe = 'Je suis le plus beau'

def Methode(self):
self.attribut_d'_instance = 'rOut est pas bô'

C'est ça ? Si oui, alors rien ne t'as échappé. Mais je ne comprend pas pourquoi ça te gêne.

rOut

08/01/2010, 14h02

xheyther

08/01/2010, 15h01

J'utilise ce genre de cosntruction à profusion (et c'est pas forcement une bonne pratique mais bon...) et je n'ai que rarement eu ce soucis.

À la limite si tu utilises beacoup plus l'affectation que l'accès à un attribut oui peut être, mais comme en général dans une méthode sur je fait self.machin = 'truc' et que dans les autres je fais une_kikoo_fonction(self.machin) ça se voit assez vite une erreur comme celle que tu cites.

ylyad

08/01/2010, 15h01

Python a quelques constructions intéressantes, mais attention, passer à un langage typé dynamiquement quand tu viens du typage statique, c'est casse-gueule :)
J'en suis pas là, et je viens de nulle part en dév :) Je comprends bien les limites de Python, c'est disons "trop facile", et je comprends bien que tu ne peux pas optimiser autant ton code ou que pour faire des trucs super pointus, c'est pas le mieux.
Mais c'est pas ça qui m'intéresse. Je suis plus intéressé par un truc qui permet d'écrire du code lisible par un humain normal, et qui permette plus facilement de le modifier/adapter, parce que la syntaxe est évidente. Si je devais faire une analogie (oubliez le côté verbeux/non-verbeux), c'est comme pour un fichier de données entre le format plat en longueur fixe et l'XML.

Tramb

08/01/2010, 15h04

En fait, justement, Python est dur à refactorer car tu dois compter sur grep plutôt que sur des checks de compile pour assurer la correction de ton changement.
Ca nécessite une discipline de fer.

xheyther

08/01/2010, 15h06

En fait, justement, Python est dur à refactorer car tu dois compter sur grep plutôt que sur des checks de compile pour assurer la correction de ton changement.
Ca nécessite une discipline de fer.

Je pas comprendre affirmation.
Je jamais avoir soucis à "refactorer" avec tests adéquats.

Tramb

08/01/2010, 15h08

Je pas comprendre affirmation.

Bah "a.toto" si tu renommes toto en tata et que t'en oublies un quelque part, ça ne sera détecté qu'au runtime.
Ca c'est l'exemple de base mais tu peux en fabriquer d'arbitrairement compliqués avec le système de typage en changeant des héritages etc...

Je jamais avoir soucis à "refactorer" avec tests adéquats.

Tests adéquats pour un rendu 3D, un filtrage sonore, une IA de jeu vidéo ou une GUI complexe => dur dur!
Mais sinon t'as raison, si tes tests sont extensifs c'est pas un problème.

xheyther

08/01/2010, 15h17

en ce qui me concerne c'est typiquement le genre de truc que je capture avec des tests unitaires.
Il n'y a même pas besoin d'être exhaustif : tu vérifie si il n'y a pas d'erreur lors d'une exécution de ton test qui appelle la fonction et basta !
OK, il faut écrire un test correct, évidement, pas un où ta fonction est appelé dans un branchement et ou tu ne vérifies qu'une branche, et ça reste du boulot. Mais bon dans les autres languages, compilés ou interprétés aussi il faut des tests... Et si ta compilation dure 4 plombes,c 'est quand même domage d'attendre 2 h pour que ça plante à la fin.

Il y a aussi des outils comme pylint et pychecker qui analyse le code statiquement et qui sont susceptibles de trouver ce genre d'erreur.

Tramb

08/01/2010, 15h29

Ouais enfin c'est pas si simple, quand tu dois tester une machine à état complexe, par exemple.
Ou, autre exemple, tu dois tester une fonction qui renvoie des trucs qualitatifs...
Ou n'importe quel code très stateful, on en revient à ce que je disais il y'a quelques pages, le state c'est le mal.

(Effectivement on utilise pylint ici aussi)

xheyther

08/01/2010, 15h51

En fait, ce que je veux dire, c'est que je en vois pas d'inconvénient intrinsèque à python quand il s'agit d'effectuer une refactorisation légère ( restructuration et réorganisation en particulier : déménagement de méthode, de fichier, de classe, changement de nom etc...). Quand tu commence à vouloir toucher lourdement aux format des flux entre les différentes couches, aux retours des fonctions ça reste, à mon avis qui vaut ce qu'il vaut, aussi délicat que dans n'importe quel langage.

tenshu

08/01/2010, 18h48

Oui, c'est ça. Ca me gène parce que dans n'importe quelle méthode, tu peux écrire self.machin = truc, et jamais on ne va te dire que machin n'a pas été déclaré comme attribut d'instance. Du coup, tu n'as pas de définition centralisée de la structure d'une classe (sauf si tu te forces à tout initialiser dans __init__ et à t'y référer sans arrêt, mais bon...), et que la moindre faute de frappe risque faire merder le tout sans que ça ne se voie. Genre à un endroit tu utilises self.machin, et un peu plus loin, self.machn, ça se voit pas forcément et c'est super chiant à débugguer.

En même temps je vois pas de potentielle alternative.

Un IDE devrait pouvoir pointer l'oubli de déclaration ou la fote de tipo.

Bah "a.toto" si tu renommes toto en tata et que t'en oublies un quelque part, ça ne sera détecté qu'au runtime.
Ca c'est l'exemple de base mais tu peux en fabriquer d'arbitrairement compliqués avec le système de typage en changeant des héritages etc...

Spa un problème commun à tout les langages interprétés?