Discussion :

[GnuVince]

Ouin ben je pense pas passer plus de temps sur comment rendre le programme Python aussi rapide que celui en Haskell. Le fait que Haskell a du bon support pour le lazy evaluation lui donne un avantage que je peux pas répliquer en Python sans y mettre beaucoup de travail et comme on a parti ça pour parler de la vitesse de développement et de choisir le bon outil pour la bonne job, ça serait cave de ma part de me torturer avec ça plus longtemps. En plus, ya deux nouveaux trous dans le mur de ma chambre (calice de marde!)

[Luc Hermitte]

Je pratique intensément plusieurs langages et je maintiens ce que je dis. Je connais largement mieux le C++ que Python, et pourtant, mes algos de thèse sont maintenant en Python parce que c'est plus rapide à développer. C'est comme ça.

J'ai une expérience similaire.
J'ai une excellente connaissance du C++, et une médiocre du perl -- et une très bonne des expressions régulières à la vim. Pourtant à chaque fois que je dois faire des petits programmes utilitaires légers qui transforment des données texte, je pars sans hésiter sur du perl.

Une des différences tient à ce que ces langages m'offrent en natif (en particulier paramètres de programmes, et expressions régulières). Combien même je pourrai utiliser boost sur mes machines au boulot (compilo trop vieux), j'en resterai au perl pour la maintenance et le prototypage rapide.

[gorgonite]

J'ai déjà posé la question par ailleurs, en quoi par exemple Python est de plus haut niveau que C++ (pour C, j'ai des arguments en faveur de Python). Mais passons, le sujet mériterait un débat à lui tout seul.

j'ai parlé de C vs Python... je ne m'aventure pas trop sur les affirmations concernant le C++

dans le cas C++ vs Python, je dirais que Python évite la gestion de la mémoire.

en ce qui concerne le débat C++ vs tous les ordres langages non logiques (OCaml, Python, Java, etc), je pense que les résultats en surprendraient plus d'un
(perso, je me croyais assez bon en C++ il n'y a pas si longtemps, avant d'en apprendre énormement de la part de mon directeur de recherche... et je me suis rendu compte que je n'avais étudié qu'une seule de ces nombreuses facettes )

[Jean-Marc.Bourguet]

j'ai parlé de C vs Python... je ne m'aventure pas trop sur les affirmations concernant le C++

dans le cas C++ vs Python, je dirais que Python évite la gestion de la mémoire.

La presence d'un GC serait donc le critere determinant qui fait qu'un langage est de haut niveau ou pas?

[Matthieu Brucher]

La presence d'un GC serait donc le critere determinant qui fait qu'un langage est de haut niveau ou pas?

Non, de mon point de vue, c'est surtout un ensemble de choses (Java n'est pas un langage de plus haut niveau que le C++ pour moi), le GC peut en faire partie, tout comme le typage dynamique, la 'vitesse de développement' (le fait qu'on ait pas besoin de compiler, lier, ...).
Mais c'est une vision personnelle.

[Jean-Marc.Bourguet]

Non, de mon point de vue, c'est surtout un ensemble de choses (Java n'est pas un langage de plus haut niveau que le C++ pour moi), le GC peut en faire partie, tout comme le typage dynamique, la 'vitesse de développement' (le fait qu'on ait pas besoin de compiler, lier, ...).
Mais c'est une vision personnelle.

Moi qui pensait que c'etait une question de niveau d'abstraction manipulable

[souviron34]

Non, de mon point de vue, c'est surtout un ensemble de choses (Java n'est pas un langage de plus haut niveau que le C++ pour moi), le GC peut en faire partie, tout comme le typage dynamique, la 'vitesse de développement' (le fait qu'on ait pas besoin de compiler, lier, ...).
Mais c'est une vision personnelle.

Donc pour toi la vitesse de développement est liée au fait de compiler ou lier ???????????

[Matthieu Brucher]

Donc pour toi la vitesse de developpement est liee au fait de compiler ou lier ???????????

Eh oui, ça joue. Quand tu développes un outil, que tu te prends 10-15 minutes de compilation et qu'à côté, tu peux tester 10 fois des paramètres pendant ce temps, oui, c'est plus rapide.

[souviron34]

désolé moi j'appelle pas ça accélérer la vitesse de développement.

Pour moi une vitesse de développement c'est si au lieu de 2 ans de programmation tu mettais 2 mois....

Si tu fonctionnes par essai et erreur, c'est sûr que là tu prends en compte ce que tu dis.. Mais alors c'est que tu ne codes pas "professionnellement" (non non on ne va pas relancer le débat de l'autre thread)...

[Matthieu Brucher]

desole moi j'appelle pas ca accelerer la vitesse de developpement.

Pour moi une vitesse de developpement c'est si au lieu de 2 ans de programmation tu mettais 2 mois....

Si tu fonctionnes par essai et erreur, c'est sur que la tu prends en compte ce que tu dis.. Mais alors c'est que tu ne codes pas "professionnellement" (non non on ne va pas relancer le debat de l'autre thread)...

si tu trouves que fonctionner par essai/erreur est une mauvaise chose, je vais te dire que tu programmes vraisemblablement avec une approche à la française qui a démontrer tous ses défauts et que le monde entier critique dans son ensemble.

Si tu veux un programme qui fonctionne, tu le compiles régulièrement (pas plus tard qu'aujourd'hui, je le disais encore à mes élèves, même si c'est toutes les 2 lignes de code, on compile et on vérifie un peu moins fréquemment que les tests passent).

Si tu penses que ce n'est pas la bonne idée, va discuter avec des gens qui ont passé leur vie là-dessus et va enseigner ton approche à des élèves, tu verras bien le résultat.

[souviron34]

bon allez cool.. j'avais deja remarqué que tu etais susceptible, et j'ai fais un peu exprès de te provoquer

En ce qui me concerne, tout va bien : j'ai 27 ans d'expérience de programmation industrielle (et pas seulement française), et environ 7 millions de lignes de code qui tournent operationnellement sur des systèmes critiques...

J'ai travaillé dans des petites équipes (< 5 personnes) ou des grandes (> 60 personnes), sur des petits projets (<50 000 lignes) ou des très gros (>5 millions de lignes), des petits budgets (< 100 keuros) ou des gros (> 80 millions), avec des logiciels dont les prix sont petits (< 10 000 euros) ou gros (> 10 millions)...

Donc j'ai quand même une certaine expérience du développememt.... Et quand je dis que pour moi "accélérer le développement" ce n'est pas prendre en compte le temps de compil, c'est vrai... A l'heure actuelle je travaille sur un projet de 2 millions de lignes, je compile 1 fois toutes les 20/30 minutes en moyenne, et la compil prend < 30 secondes...

Pour moi, accélérer le temps de developpement, c'est utiliser un langage comme par exemple Motif ou Gtk ou Delphi pour faire une fenêtre, alors que la faire avec X11 ou les Windows API prendrait environ 100 fois le temps...

Ca oui c'est de l'accélération de développememt...

[Matthieu Brucher]

Pour moi, accelerer le temps de developpement, c'est utiliser un langage comme par exemple Motif ou Gtk ou Delphi pour faire une fenetre, alors que la faire avec X11 ou les Windows API prendrait environ 100 fois le temps...

C'est exactement le même processus qui fait qu'on dit qu'un langage tel que Python ou Perl sera plus rapide que le C. Maintenant, tu ne nous crois pas, tu es enfermé dans tes 27 années de pratique, c'est ton choix.

[Woufeil]

Allez, je donne ma petite contribution à 3 francs 6 sous (et oui, en plus de ne pas être chère, elle n'est pas à jour ).
J'ai lu quelque part que quelque soit le langage et à niveau égal dans tous les langages, on écrit autant de ligne par minute quelque soit le langage. Pour moi, ce n'est pas tout à fait vrai, mais il y a tout de même un bon fond de vérité. Et on ne peut pas nier que pour le même programme, on écrit moins de lignes en C qu'en Perl, donc le temps de développement est réduit d'autant.

[Thierry Chappuis]

Et on ne peut pas nier que pour le même programme, on écrit moins de lignes en C qu'en Perl, donc le temps de développement est réduit d'autant.

Tu es sûr que ce n'est pas le contraire que tu voulais dire?

Thierry

[souviron34]

si tu trouves que fonctionner par essai/erreur est une mauvaise chose, je vais te dire que tu programmes vraisemblablement avec une approche à la française qui a démontrer tous ses défauts et que le monde entier critique dans son ensemble.

ça ça devrait faire partie du bétisier....

Parce que tu trouves recommandable d'enseigner une technique d'essais/erreurs à des futurs informaticiens ?? Bonjour les futures équipes...

Ouch !!!!

Va faire un tour du côté des méthodologies, essaye de travailler sur un gros logiciel à créer avec ce genre de méthode, et on en reparlera... Heureusement que le développement des logiciels pilotant les TGV, les avions, les scanners, etc. ne fonctionne pas sur ton principe.......

Et en plus, tu sais quoi ?? ben c'est pas français... C'est mondial.. En ce moment je suis en Amérique du Nord, pour des logiciels de simulation d'avions et de tours de contrôle... Eh bien ça fonctionne sûrement pas par essais/erreurs....

Si tu veux un programme qui fonctionne, tu le compiles régulièrement (pas plus tard qu'aujourd'hui, je le disais encore à mes élèves, même si c'est toutes les 2 lignes de code, on compile et on vérifie un peu moins fréquemment que les tests passent).

Mais c'est qu'il le pense, le bougre !!! Et en plus il l'enseigne !!!!

Mamma mia... Pôv de nous...

Si tu penses que ce n'est pas la bonne idée, va discuter avec des gens qui ont passé leur vie là-dessus et va enseigner ton approche à des élèves, tu verras bien le résultat.

Ce que j'aime bien, c'est que quand quelqu'un qui justement a passé sa vie là-dessus te dit quelque chose avec lequel tu n'es pas d'accord, tu dis qu'il "s'accroche à ses habitudes", alors que c'est peut-être que justement l'expérience t'enseigne quelque chose....

Mettre des traces pour faire du debugging, oui.. Avoir comme philosophie de développement du "essai/erreur", alors là résolument non...


Pour en revenir au sujet :

C'est exactement le même processus qui fait qu'on dit qu'un langage tel que Python ou Perl sera plus rapide que le C.

Je n'ai jamais dit que Python par exemple, ou Netbeans, ou Delphi, ou.. n'était pas bien... J'ai juste dit que lorsqu'on est expert dans un langage, on ira 10 fois plus vite pour faire quelque chose avec ce langage qu'avec un autre..

Cela fait 19 ans que je fais du X11/Motif. Il est évident que j'irais beaucoup plus vite pour développer une interface avec ça (et mes milliers de lignes de biblios personnelles) que en essayant de le faire avec NetBeans ou autre, que je n'ai fait qu'effleurer...

Et donc j'en reviens à ce que je disais au début :

Si le PO est expert en C, il ira nettement plus vite à développer en C qu'en Python ou Perl...

C'est tout ...


Exemple :

je n'ai jamais pris de cours de Python ou de Perl, mais j'ai 19 ans de programmation C et X11/Motif, et j'ai fait 1 an de Delphi et 6 mois de VB.

Demain on me demande de faire une appli (ou même une démo) : une démo vide, je ferais sans doute en Delphi. Une vraie démo fonctionnelle, ou l'appli, je la ferais en Motif. Pourquoi ? Parce qu'en un jour ou une semaine je suis capable de la sortir à peu près fonctionnelle. Avec Python ou Perl, il faut d'abord que je lise les docs, savoir ce quon peut faire, comment s'appellent les types, quelle est la syntaxe, etc etc... (et là ma semaine est déjà passée) .... Et ça, ben pour moi ça fait partie du temps de développement. Ensuite que je fasse des essais, que je me heurte aux écueuils de tous les débutants... Encore du temps pris.... Et même quand j'aurais appris à les éviter, il est certain que je ne connaitrais pas toutes les subtilités qui pourrait m'être nécessaires pour la fabrication du logiciel... C'est de la formation, donc de l'argent/du temps immobilisé pendant que je suis improductif... , et donc, en termes de gestion du développement du logiciel, cela augmente d'autant le temps de développement... et donc aussi le délai et le prix...

Maintenant, si je le fais en X11/Motif, ou en C : je connais toutes les subtilités, les écueuils... j'ai du code déjà disponible.... Je connais la syntaxe par coeur... Résultat : pffff en moins de 2 j'ai sorti ce qu'il fallait...

Voilà c'est tout ce que je dis...

[Matthieu Brucher]

Va faire un tour du côté des méthodologies, essaye de travailler sur un gros logiciel à créer avec ce genre de méthode, et on en reparlera... Heureusement que le développement des logiciels pilotant les TGV, les avions, les scanners, etc. ne fonctionne pas sur ton principe.......

Je fais un tour régulièrement su côté des méthodologies, et c'est que je vois surtout c'est tester fréquemment. Mais en fait, j'ai surtout l'impressionq ue sur le coup, on s'est mal compris. Ce que j'appelle essai/erreur, c'est on a un système qui fonctionne, on ajoute des tests sur ce qu'on veut ajouter (les tests étant définis par un cahier des charges, naturellement), on vérifie que ça plante, et on code afin que ça passe. C'est une approche qui est utilisée dans TDD, UP, XP, ...
Il est certain que sur des systèmes critiques, on a vu mieux.

Enfin, je nsuis aussi d'accord avec toi que si tu ne connais pas le langage, sur le coup, la vitesse de développement sera moindre, c'est même logique. En revanche, une fois que tu as maîtrisé les rudiments, ça va plus vite, c'est aussi la raison pour laquelle tu utilises des bibliothèques de plus haut niveau, au début tu ne les maîtrises pas forcément, tu apprends leur fonctionnement, et après elles te font gagner du temps.

Il me semble que au moins sur certains points, notre point d'achoppement est plus sur une vue d'ensemble (je pars du principe qu'on connaît le langage, pas toi, et donc ça a des implications sur cette vitesse de développement), sur d'autres, je ne suis pas sûr que tu aies effectivement saisi ce que je sous-entendais, peut-être que je m'exprimes mal.

[souviron34]

Bon là on commence enfin à parle bon sens...

Effectivement il y a eu incompréhension, mais pas de ma part

Une autre raison, plus simple et plus probable encore, les gens qui travaillent chez ces compagnies connaissent mieux Python que Perl, tout simplement.

Et comme ça, on revient à notre discussion originale de choisir le bon langage pour la tâche: si la vitesse de développement est le facteur le plus important, le Python (ou Perl, ou Lisp, etc.) l'emporte, si la vitesse et la mémoire doivent être optimisé, C est l'outil à utiliser.

En quoi serait-ce plus rapide qu'en C ???
..
La vitesse de développement est plus rapide avec un langage que tu as appris. POINT FINAL. Si tu as appris le C, ce sera plus rapide en C. Si tu a appris l'assembleur, ce pourrait être plus rapide en assembleur, si tu as appris Java, ce sera plus rapide en Java,.. etc etc..


Mais donc cela n'a rien à voir avec quel est le meilleur langage pour faire quoi...

Faux. Je connais plusieurs langages et c'est largement plus rapide de développer avec Python qu'en C++ où c'est plus rapide qu'en C et idem pour l'assembleur. Pourtant c'est le C que j'ai appris en premier, puis l'assembleur, le C++ et enfin Python.

Bon on va plus se prendre le chou, vu que là on s'entend....

Je fais un tour régulièrement su côté des méthodologies, et c'est que je vois surtout c'est tester fréquemment. Mais en fait, j'ai surtout l'impressionq ue sur le coup, on s'est mal compris. Ce que j'appelle essai/erreur, c'est on a un système qui fonctionne, on ajoute des tests sur ce qu'on veut ajouter (les tests étant définis par un cahier des charges, naturellement), on vérifie que ça plante, et on code afin que ça passe. C'est une approche qui est utilisée dans TDD, UP, XP, ...
Il est certain que sur des systèmes critiques, on a vu mieux.

Alors effectivement ce que tu décris ne s'appelle pas essais/erreurs, mais cycle rapide de conception.

Mais par contre on ne fait jamais dans ce sens. y compris dans XP... On vérifie simplement que le logiciel passe les tests "systèmes" et d'acceptation utilisateur régulièrement, au lieu des méthodes traditionnelles qui ne le font qu'une seule fois, à la toute fin. Mais on ne "vérifie pas que ça plante".. On fait la même démarche qu'on ferait à la fin, "on vérifie que ça marche".... Et éventuellement on corrige les bugs...

Par contre, si tu enseignes, fais attention aux mots. Nous sommes dans un métier technique, et les mots ont un sens....

Essais/erreurs réfère à une "méthode" (ou plutôt une pratique) où on n'a pas de conception (pas de méthode), on ajoute une ligne pour voir si ça solutionne, .. Non ? bon ben on en essaye une autre...

[Matthieu Brucher]

Mais par contre on ne fait jamais dans ce sens. y compris dans XP... On vérifie simplement que le logiciel passe les tests "systèmes" et d'acceptation utilisateur régulièrement, au lieu des méthodes traditionnelles qui ne le font qu'une seule fois, à la toute fin. Mais on ne "vérifie pas que ça plante".. On fait la même démarche qu'on ferait à la fin, "on vérifie que ça marche".... Et éventuellement on corrige les bugs...

Oui, effectivement, on commence par écrire les tests (mais n'étant pas le professeur principal de la matière, si j'arrive déjà à leur faire comprendre qu'ils doivent tester tout le temps et non pas une fois qu'ils ont tout écrit, ce sera un miracle), mais dans certaines méthodologies, on écrit le test, on vérifie tout de même qu'on a une barre "rouge", puis on écrit le code pour que le test passe. Personnellement, je ne suis pas fan de ce principe.

Par contre, si tu enseignes, fais attention aux mots. Nous sommes dans un métier technique, et les mots ont un sens....

Essais/erreurs réfère à une "méthode" (ou plutôt une pratique) où on n'a pas de conception (pas de méthode), on ajoute une ligne pour voir si ça solutionne, .. Non ? bon ben on en essaye une autre...

Tu as raison, je me suis mal exprimé. Dans tous les cas, on leur dit d'avoir une liste de choses à implémenter, l'algo détaillé, ... et ensuite ils s'y collent. De toute manière, si on ne fait pas ça, ils n'y arrivent pas.

En revanche, dans mon code de recherche, je n'ai pas le choix, j'ai une conception qui tient la route, mais je dois tester des paramètres par essai/erreur parce que la chaîne des algorithmes est complexe et la recherche des paramètres optimaux pour chaque algorithme est plus une heuristique aléatoire qu'un calcul clair et définitif Et c'est la qu'on retombe sur mon message précédent par rapport à la vitesse de développement.

[souviron34]

donc je reviens à mon point de départ..

A la question "2008 et le choix d'un langage à tout faire", outre le fait qu'il n'y en a pas, il faut se poser les questions suivantes avant de décider du langage à utiliser :

1. C'est pour quoi faire ? (appli Web, GUI, BDD, outil de calcul, etc..)
2. Quels langages je connais ?
3. Quel est mon délai ?
4. De quel budget je dispose ?
5. Ai-je de l'expérience ?
6. Quels seraient les meilleurs langages pour créer cette application (par ordre décroissant d'adéquation avec le problème) ?
7. L'application rentre-t-elle dans le cadre d'un autre projet ?
8. L'application sera-t-elle maintenue par quelqu'un d'autre ?
9. Quelle est la durée de vie prévue de l'application ?

En fonction de la réponse à l'ensemble de ces questions, on pourra décider quel est le meilleur à utiliser pour ce cas de figure-là, cette personne-là, ce projet-là, ce budget-là, ces limites de temps là....


Il n'y a aucune réponse toute faite, et pour un même individu la réponse varie au cours du temps, en fonction de l'expérience, des projets, et des contraintes...

[GnuVince]

La méthode de construire des logiciels par essais est bonne seulement si tu as également des résultats prévus vérifiés par des tests automatisés; ceux qui écrivent leur code, compilent, regardent ce que ça donne et déterminent à ce moment si leur code fait ce qu'ils veulent sont condamnés à écrire du mauvais code.

Voici mon "flow" pour les applications que j'écris:

* Déterminer d'avance le comportement d'une fonction
* Écrire des tests pour vérifier cette fonction; les tests doivent couvrir des cas valides ainsi que des cas invalides
* J'écris ma fonction
* J'exécute mes tests
* Si mes tests ne passent pas, je retravaille ma fonction; s'ils passent, c'est fini, je passe à une autre fonction.

Je n'ai pas d'expérience dans la programmation de systèmes critiques, mais il me semble que cette méthodologie (ça s'approche du TDD il me semble) serait tout à fait appropriée. Les tests sont une spécification exécutables, il semble que ce serait une excellente façon de vérifier que le système fonctionne comme il se doit. Bonne façon aussi de blâmer l'analyste