Discussion :

[Woufeil]

la taille du code produit
le temps d"execution du programme produit
la mémoire utilisé par le programme pendant son execution
et
le temps de développement (évolution et maintenance )

Dans ce cas (et je vais je pense faire plaisir à l'un des participants, devinez lequel ) je trouve que OCamL fait un bien meilleur concurrent. En temps d'exécution, c'est comparable au C. Je suppose qu'en mémoire c'est pareil. Pour les autres critères, je suis loin d'être un expert mais OCaml, mais je crois bien (de par les exemples que j'ai lu) qu'il s'en tire très bien.
Et pourtant je doute que tu le considères comme un langage universel...

Et surtout, encore une fois, universel, ça ne veut rien dire du tout, du moins tant qu'on en a pas donné une définition qui convienne à tout le monde. Personnellement, ta définition ne me convient pas, et la mienne (langage universel = que l'on peut utiliser partout) ne te convient pas (et ne me convient pas vraiment non plus d'ailleurs).

Juste une dernière remarque, je n'ai absolument rien contre Smalltalk, j'ai même été tenté de l'apprendre plusieurs fois. Je dirais même que c'est un langage qui me plait.

[Jean-Marc.Bourguet]

j'aurais plutot dit d'un délire de spécialistes de la théorie des langages au fond de leur labo... donc très éloigné de tout ce que les industriels auraient pu vouloir

Les langages n'etaient si theorise que cela dans les annees 60-70, au moment ou la POO apparait (SIMULA 67, SmallTalk 74).

Oui, il y a une reflexion theorique, mais en vue de resoudre des problemes pratiques bien reels. Et ces problemes n'etaient pas tant lies a la maintenance que la realisation meme de programmes importants.

Apres oui, les theoriciens ont parfois delire...

[super_navide]

je sais bien, c'est aussi mon cas
ingénieur + master de recherche, recherche appliquée ou R&D, trop compliqué pour du consulting mais pas assez formel pour de la recherche académique...

Mois je me suis arrété a bac + 4 car faire de la théorie pour de la théorie sans aucune pratique ca me gonfle.
Mais dans l'entreprise on veut pas du tout de théorie ou faire un peut de recherche.
Si on en fait on a un chef a qui il faut justifier tous ce qu'on fait ce qui est pénible et un perte de temps.

Moi je rèverai de faire un bureau de recherche indépendant qui travail pour faire du blé et des application concrete pour financé de la recherche fondamental et nons pas des actionnaire ou un patrons.

Mais de toutes façon les meilleurs profil se sont ce qui sont entre les deux.

[Jean-Marc.Bourguet]

Il est étonant voir stupide de nier l'existance d'un langage universel pour tous les domaines.
Le langage Smalltalk me parait un bon candidat.

Il va falloir commencer par me convaincre qu'un langage type dynamiquement est un bon candidat pour les gros projets (avec ma definition de gros: ou une personne ne peut qu'avoir une vision tres partielle de l'ensemble).

[super_navide]

Dans ce cas (et je vais je pense faire plaisir à l'un des participants, devinez lequel ) je trouve que OCamL fait un bien meilleur concurrent. En temps d'exécution, c'est comparable au C. Je suppose qu'en mémoire c'est pareil. Pour les autres critères, je suis loin d'être un expert mais OCaml, mais je crois bien (de par les exemples que j'ai lu) qu'il s'en tire très bien.
Et pourtant je doute que tu le considères comme un langage universel...

Et surtout, encore une fois, universel, ça ne veut rien dire du tout, du moins tant qu'on en a pas donné une définition qui convienne à tout le monde. Personnellement, ta définition ne me convient pas, et la mienne (langage universel = que l'on peut utiliser partout) ne te convient pas (et ne me convient pas vraiment non plus d'ailleurs).

Juste une dernière remarque, je n'ai absolument rien contre Smalltalk, j'ai même été tenté de l'apprendre plusieurs fois. Je dirais même que c'est un langage qui me plait.

j'ai oublié une valeur qui caractérise un langage c'est une valeur qui n'est pas fixe c'est le nombre de frameworks qui existe dans ce langage.

ta définition de langage universel me plait, c'est un lanage qu'on peut utilisé partout et qui donne des résultats acceptable voir bon.

Moi le langage que je trouve universel est Java .
Ensuite a Smalltalk il lui manque des framework et une communauté comme java.
Moi j'utilise 4 langage C C++ java et smalltalk

Pourr OCamL , je dirais rien car je le connais pas mais je vais voir ce qu'on peut faire avec.

[super_navide]

Il va falloir commencer par me convaincre qu'un langage type dynamiquement est un bon candidat pour les gros projets (avec ma definition de gros: ou une personne ne peut qu'avoir une vision tres partielle de l'ensemble).

Et Ben il y a 2 entreprises que je ne citerai pas qui ont de très gros logiciel en Smalltalk.

un lanage type dynamiquement n'est pas un frein .
Si tu teste convenablement tu n'a pas de problème.
en java tu a le problème du NullPointerException et du ClassCastException
ca revien presque pareil ...
J'ai lontemps pensé ouais typé c'est mieux car il y a le compilateur qui detecte certaine erreurs.
Mais avec l'experience je me suis appercus que ca ne changeait rien du tout .
Il y a autant d'erreur possible dans un langage type que dans un langage non typé.

Le seul point faible de smalltalk et il est de taille ce sont les Float et les Double qui sont des objets
Mais cette faiblesse est supprimé pour les floats sur les architecture 64 bits
mais bon après il y a les vecteurs les matrices qui sont des objets mais la pour java c'est la même chose.
Il faudrait pouvoir créer des objet sur la pile d'execution ...
Mais même la je commence a avoir des doutes sur la réelle utilité d'une tel possibilité.
Car le gabage collector de java est une merveille de performance.
Même si il est très très complexe...

[HanLee]

Je crois que j'ai precise ma pensee dans un autre message. J'ai du mal a considerer que la technique consistant a passer explicitement l'etat et a le retourner soit de la programmation fonctionnelle. C'est une technique utile quand on programme dans un langage "pur", c'est meme une technique utile dans d'autres cas car elle permet de conserver des proprietes interessantes, mais c'est faire rentrer une conception fondamentallement non fonctionnelle dans un moule formellement fonctionnel.

Mais regarde, si l'on considère la STL, pour les conteneurs, std::vector, list.

100% POO, programmation impérative, mais sémantique de valeur. Et je crois que c'est le dernier point qui est important, car c'est typiquement un des champ d'application privilégiés de la programmation fonctionnelle en fait. Donc pour moi, dans ce cas de figure, je pense que c'est pertinent de considérer ça comme de la PF+POO.

D'où la tendance à considérer la POO comme quelque chose d'orthogonal à tous les autres.

Car le gabage collector de java est une merveille de performance.
Même si il est très très complexe...

Pour des applications single-threaded, il est très très loin derrière celui d'OCaml.

[Jean-Marc.Bourguet]

Et Ben il y a 2 entreprises que je ne citerai pas qui ont de très gros logiciel en Smalltalk.

Il y a des entreprises dont je peux te citer les noms qui ont des tres gros logiciels en assembleur. Ce n'est pas pour cela que je considere l'assembleur comme un langage adapte aux tres gros logiciels.

un lanage type dynamiquement n'est pas un frein .
Si tu teste convenablement tu n'a pas de problème.

Si. Decouvrir au test ce qui peut l'etre a la compilation coute.

Je travaille pour une entreprise qui a des gros logiciels (dizaines de millions de lignes de code sans qu'on n'ait pas acces a tout le code, centaine de programmeurs actifs simultanement, historique de l'ordre de 20 ans pour celui sur lequel je travaille -- c'est pas les plus gros que je connais mais ca rentre quand meme bien dans mon critere). Nous utilisons des langages d'extension dynamique (un dialecte de lisp dans mon cas). Nous considerons que nous avons trop de code dans ces langages dynamiques (de l'ordre d'un ou deux millions de lignes de code) parce qu'ils posent des problemes de maintenabilite: regulierement, des modifications dans ce code introduisent des problemes qui ne sont decouvert que tres tard (pas aux tests de pre-check in, pas aux tests journaliers de l'equipe, aux tests d'integration ou meme aux tests de qualification d'une release) alors qu'un typage dynamique aurait montrer le probleme immediatement. Et retrouver la cause une fois que le probleme a ete trouve n'est pas simple du tout non plus. Nous avons deja assez de problemes fondamentalement subtils a regler que pour apprecier perdre du temps a cause de fautes de frappe ou de l'ignorance de l'existence d'un client du code modifie.

Mais avec l'experience je me suis appercus que ca ne changeait rien du tout .
Il y a autant d'erreur possible dans un langage type que dans un langage non typé.

C'est vraiment pas mon experience.

[Jean-Marc.Bourguet]

Mais regarde, si l'on considère la STL, pour les conteneurs, std::vector, list.

100% POO,

Ca n'a strictement rien d'OO. La seule chose qui soit OO dans la bibliotheque standard du C++, c'est les IOStreams et les locales. A la rigueur il y a aussi les classes d'exception.

[super_navide]

Il y a des entreprises dont je peux te citer les noms qui ont des tres gros logiciels en assembleur. Ce n'est pas pour cela que je considere l'assembleur comme un langage adapte aux tres gros logiciels.



Si. Decouvrir au test ce qui peut l'etre a la compilation coute.

Je travaille pour une entreprise qui a des gros logiciels (dizaines de millions de lignes de code sans qu'on n'ait pas acces a tout le code, centaine de programmeurs actifs simultanement, historique de l'ordre de 20 ans pour celui sur lequel je travaille -- c'est pas les plus gros que je connais mais ca rentre quand meme bien dans mon critere). Nous utilisons des langages d'extension dynamique (un dialecte de lisp dans mon cas). Nous considerons que nous avons trop de code dans ces langages dynamiques (de l'ordre d'un ou deux millions de lignes de code) parce qu'ils posent des problemes de maintenabilite: regulierement, des modifications dans ce code introduisent des problemes qui ne sont decouvert que tres tard (pas aux tests de pre-check in, pas aux tests journaliers de l'equipe, aux tests d'integration ou meme aux tests de qualification d'une release) alors qu'un typage dynamique aurait montrer le probleme immediatement. Et retrouver la cause une fois que le probleme a ete trouve n'est pas simple du tout non plus. Nous avons deja assez de problemes fondamentalement subtils a regler que pour apprecier perdre du temps a cause de fautes de frappe ou de l'ignorance de l'existence d'un client du code modifie.
C'est vraiment pas mon experience.

Est ce que tu est un développeur ???
Vous utilisé des TestUnit pour la vérification du code ???

Je pense que tu a de mauvaise méthode de développement.

Il faut avoir de bon test unitaire et test d'assemblage ( ou d'intégration )
Il faut avoir des specs claire et complete


Moi J'essais souvent de développé de facon modulaire pour pouvoir faire des
TestUnit mais c'est pas facile je l'avoue mais c'est un habitude a prendre.

Quand on développe il faut penser aux Tests tous le temps et creer le code pour le rendre facilement testable

Ensuite pour certain code on peut utiliser la logique de Hoare

De plus pour un langage non typé tu peut créer des outils au dessus du compilateur qui permette detecter des erreurs d'envoi de message.

[souviron34]

je me permet de re-rentrer dans la discussion ici (malgré le fait que je n'ai toujours pas eu le temps de regarder les exemples de plus haut, et que j'aurais pas le temps avant la semaine prochaine ).

Je ne suis pas sûr que la discussion des 2 pages précédentes ait un rapport avec le sujet...

Je m'explique :

• La maintenance d'un code est principalement facilitée par sa conception, pas par le langage utilisé. Si c'est codé comme un porc, ce sera diffcile à maintenir , quel que soit le langage.
  
  
• La conception devrait être LOGIQUE, quel que soit les concepts utilisés. Toute conception illogique, même se basant sur de l'objet ou des langages objets, sera diffcile à maintenir.

Jean-Marc, je ne sais pas pour quel boîte tu bosses, mais effectivement les problèmes que tu décris semblent plus être des problèmes de conception. J'ai moi-même écrit ou participé a des projets de 2 à 5 millions de lignes, et un bon programmeur "standard" s'y retrouvait en 1 à 2 jours.

(une des raisons d'ailleurs pour lesquelles je suis résolument CONTRE une documentation détaillée générale. Sur un gros logiciel, je n'ai JAMAIS vu de ma vie quelqu'un passer 4 mois assis à lire de la doc avant d'aller fouiller dans les répertoires...)

Maintenant, ce que je conteste, c'est, pour répondre à la question originale, la nécessité.

De l'"orienté objet" comme j'en parle depuis le début (fonctionnel), oui, je suis d'accord, c'est nécessaire.

De l'objet tel que vous le concevez (avec notions "théoriques" d'héritage, polymorphisme, et autres TestUnit et termes techniques) , non, cela ne me parait pas nécessaire.

[Jean-Marc.Bourguet]

Vous utilisé des TestUnit pour la vérification du code ???

C'est une partie de ce que j'ai appele "tests de pre-checkin".

Je pense que tu a de mauvaise méthode de développement.

On peut vraissemblablement s'ameliorer, mais je ne pense pas que ce soit a l'origine de ce type de problemes.

On n'est averti que quand un test echoue. Si c'est nos tests de pre-checkin, ca fait 1 ou 2 heure apres qu'une erreur de compilation aurait signaler le probleme. Si c'est aux tests journaliers du groupe (en gros les tests de pre-checkin de tout ce dont on s'occupe), c'est le lendemain du jour ou on a fait le checkin. Si c'est les tests d'integration (qui comprennent les tests de pre-checkin de tous les groupes), ca fait au minimum un jour, souvent 2, parfois 3 ou 4 apres. Si c'est aux tests de qualification, ca peut faire plusieurs mois apres. Si on ecrivait des tests d'integration parfait, les tests de qualification passeraient toujours, mais nous sommes faillibles. Mais je ne vois pas du tout comment une meilleure methode de developpement pourrait detecter le genre de problemes que j'ai donne avant les tests d'integration; je vois tres bien comment faire avec un typage statique.

Moi J'essais souvent de développé de facon modulaire pour pouvoir faire des
TestUnit mais c'est pas facile je l'avoue mais c'est un habitude a prendre.

Quand il y a une centaine de developpeurs qui travaillent en equipes se trouvant reparties a travers le monde, ne pas travailler de maniere modulaire me semble difficile a organiser.

De plus pour un langage non typé tu peut créer des outils au dessus du compilateur qui permette detecter des erreurs d'envoi de message

.

Ah, tu veux dire faire des outils qui considerent ton langage non type comme un langage a typage implicite(*) et qui ensuite verifient les types. Pourquoi ne pas utiliser directement un langage type?

(*) Je n'ai aucune experience avec des langages a typages implicites sur de gros projets; il se peut qu'ils soient adequats ou non.

[Jean-Marc.Bourguet]

Est ce que tu est un développeur ???

Oui.

Puisqu'on en est aux questions qui denotent un manque de confiance... tu peux de dire la taille du plus gros projet surlequel tu as travaille (avec le meme genre de caracteristique que j'ai donne pour mon projet actuel: age, lignes de code, programmeurs simultanes)?

[super_navide]

nombre de Ligne de code 266169
nombre de développeur 7
age du logiciel 10 ans

quand un langage est non typé tu gagne du temps car tu n'a pas le nom du typa a préciser

[Jean-Marc.Bourguet]

Je m'explique :

• La maintenance d'un code est principalement facilitée par sa conception, pas par le langage utilisé. Si c'est codé comme un porc, ce sera diffcile à maintenir , quel que soit le langage.
  
  
• La conception devrait être LOGIQUE, quel que soit les concepts utilisés. Toute conception illogique, même se basant sur de l'objet ou des langages objets, sera diffcile à maintenir.

Nous sommes d'accord.

Jean-Marc, je ne sais pas pour quel boîte tu bosses,

C'est pas particulierement un secret: http://www.cadence.com (numero 17 ici: http://www.softwaretop100.org/list.php?page=1).

mais effectivement les problèmes que tu décris semblent plus être des problèmes de conception. J'ai moi-même écrit ou participé a des projets de 2 à 5 millions de lignes, et un bon programmeur "standard" s'y retrouvait en 1 à 2 jours.

Nous utilisons une structure de donnees dont l'implementation fait entre un et deux millions de lignes de code. En 1-2 jours un developpeur connaissant le domaine (ce qui n'est deja pas facile a trouver) peut se retrouver dans l'interface. Dans l'implementation, pas une chance. C'est pas qu'elle soit mauvaise, elle est intrinsequement complexe.

Maintenant, ce que je conteste, c'est, pour répondre à la question originale, la nécessité.

De l'"orienté objet" comme j'en parle depuis le début (fonctionnel), oui, je suis d'accord, c'est nécessaire.

Nous divergeons completement; mais je me demande si ce n'est pas parce qu'"oriente objet" a un sens different pour nous deux.

Sommairement pour moi, la programmation orientee objet, c'est l'utilisation d'objets ayant un etat, de variables pouvant contenir des objets de plusieurs types, d'un choix de routines effectues en fonction du type de l'objet passe. Un langage oriente objet est un langage permettant de faire ce genre de chose facilement. La conception orientee objet c'est des techniques de conception tendant a trouver les solutions a un probleme qui font usages de la programmation orientee objet.

L'oriente objet en tant que technique de conception n'est pas necessaire. Il y en a d'autres qui fonctionnent tres bien, meme pour de gros projets. Mais a mon avis plus le projet est gros, plus il y a des chances qu'une conception orientee objet soit avantageuse pour une partie ou pour organiser l'ensemble.

De l'objet tel que vous le concevez (avec notions "théoriques" d'héritage, polymorphisme, et autres TestUnit et termes techniques) , non, cela ne me parait pas nécessaire.

Et moi, il me semble que meme si on ne la pratique pas, avoir de l'oriente objet une idee plus precise que ce qu'on en a deduit de la presentation d'un marketteur est necessaire. Et donc une connaissance au moins sommaire du vocabulaire -- meme si je rale quand ceux qui l'emploie ont l'air d'ignorer que ce vocabulaire recouvre aussi un domaine plus large que l'utilisation faite dans ce cadre -- et de la theorie derriere.

[Jean-Marc.Bourguet]

nombre de Ligne de code 266169
nombre de développeur 7
age du logiciel 10 ans

quand un langage est non typé tu gagne du temps car tu n'a pas le nom du typa a préciser

Je suis au courant. Et je pense que ca reste dans la taille de projet ou un langage non type peut conserver son avantage.

Comme je l'ecrivais ci-dessus, nous avons plus de 50X plus de lignes de code au total, plus de 7X plus de lignes de code en langage non type. Et la, a notre avis le non type n'est plus gerable.

[super_navide]

Est ce que vous avez des développeur qui sont spécialisé sur un module ou dans un domaine ??

Géré vous plusieur versions en parallèle.
Des développement sont commencé sur une version alors qu'une autre version est en cours de dévoppement


je ne dis pas qu'un langage type a un avantage moi je pense que ca doît être pareil

et puis des langages comme python et smalltalk sont non typé
mais il sont totalement différent

je pense qu'un très gros projet en python n'est pas viable

pour Votre Logiciel vous avez une compilation incremental ???


Moi je pense qu'avec une conception en module indépendant qui communique avec des WEB Services bien spécifier tu peut avoir de très gros projet avec un langage non typé

après je pense en reflechissant
peut être que ce que tu gagne en temps de développement (compilation incremental , et pas besoin de spécifier le type ) tu le perd en temps de test mais globalement c'est la même chose.
le cout global est le même.

[Jean-Marc.Bourguet]

Moi je pense qu'avec une conception en module indépendant qui communique avec des WEB Services bien spécifier tu peut avoir de très gros projet avec un langage non typé

En utilisant du XML je suppose? Et puis quoi encore?

après je pense en reflechissant
peut être que ce que tu gagne en temps de développement (compilation incremental , et pas besoin de spécifier le type ) tu le perd en temps de test mais globalement c'est la même chose.
le cout global est le même.

Non.

[super_navide]

Des WEB Services en XML c'est mieux je pense
Et j'ai pas demandé c'est quoi le langage typé que vous utilisé ???

[Montaigne]

Il existe une solution permettant d'avoir la puissance de SmallTalk... avec les performances du C.
Il s'agit du langage
Lisaac.
En gros, Lisaac est un sur ensemble de SmallTalk, car orienté objet à prototype et non à classe.
La nouvelle version sort dans les jours qui viennent.

De plus, ce langage est typé, ce qui réconciliera tout le monde

Et Ben il y a 2 entreprises que je ne citerai pas qui ont de très gros logiciel en Smalltalk.


un lanage type dynamiquement n'est pas un frein .
Si tu teste convenablement tu n'a pas de problème.
en java tu a le problème du NullPointerException et du ClassCastException
ca revien presque pareil ...
J'ai lontemps pensé ouais typé c'est mieux car il y a le compilateur qui detecte certaine erreurs.
Mais avec l'experience je me suis appercus que ca ne changeait rien du tout .
Il y a autant d'erreur possible dans un langage type que dans un langage non typé.

Le seul point faible de smalltalk et il est de taille ce sont les Float et les Double qui sont des objets
Mais cette faiblesse est supprimé pour les floats sur les architecture 64 bits
mais bon après il y a les vecteurs les matrices qui sont des objets mais la pour java c'est la même chose.
Il faudrait pouvoir créer des objet sur la pile d'execution ...
Mais même la je commence a avoir des doutes sur la réelle utilité d'une tel possibilité.
Car le gabage collector de java est une merveille de performance.
Même si il est très très complexe...