Malheureusement, ce genre de message étant propice au "trolling", je me demande si l'on doit poursuivre.
Oui, malheureusement je partage aussi ton point de vue et il ne faut pas continuer ce thread...
Mais l'héritage multiple c'est mal ;-)
@-salutations
Michel Claveau
Wilk
"Do Re Mi chel La Si Do" writes:
Re
Une confrontation des différents points de vue pourrait être intéressante, et lancer une grande discussion.
Par exemple, si j'aime bien l'approche objet de Python, je reproche à la programmation orientée objet (et non la programmation objet), une atomisation du code, à tel point qu'il peut être très difficile de retrouver l'information. J'ai un petit logiciel, avec une vingtaine de classes, héritant les unes des autres (par héritage multiple), et avec surcharge de méthodes. Résultat : en lisant une routine, c'est vraiment très difficile de retrouver le code qui va s'appliquer.
C'est l'entropie de la programmation objet ;-)
En programmation objet on a tendance à vouloir tout réutiliser et le système final devient ingérable et inutilisable sur plusieurs projets, alors que le but était justement l'inverse !
A côté de ça, j'ai un gros logiciel, genre bibliothèque de fonctions, essentiellement en procédural. La multiplicité des fonctions ne nuit pas à la lisibilité, car chaque fonction a un usage bien précis, et les possibilités de Python permettent de bien limiter les besoins de surcharge, et la multiplicité des fonctions.
Amha il faut appliquer ce même principe en programmation objet. C'est à dire faire des objets certes, mais en limitant l'interdépendance. Tu aurais eu exactement le même problème avec des fonctions trop liés entre elles...
Mais il est vrai aussi que, pour certains scripts simples, j'apprécie la facilité apportée par les classes, et que j'ai souvent du mal à relire des fonctions réentrantes.
Le code "spaghetti", ce n'est pas lié ni à la programmation procédurale, ni à la programmation objet, mais plutôt à la façon de programmer du développeur.
C'est ce que je pense aussi. Pour ma part je n'hésite pas à mélanger les deux... (Python le permet d'une manière particulièrement élégante).
Malheureusement, ce genre de message étant propice au "trolling", je me demande si l'on doit poursuivre.
Je pense que oui... Ca peut éviter de tomber dans certains pièges. C'est dans une discussion trollesque sur les langages que je me suis rendu compte que j'avais mis au point un vrai bourbier à vouloir trop "d'objets" (ce que démontrait un anti-objet). Je suis donc revenu "en arrière" et ça a été concluant !
-- William http://wikipython.flibuste.net : wiki francophone sur python
"Do Re Mi chel La Si Do" <enleverlesO.OmcO@OmclaveauO.com> writes:
Re
Une confrontation des différents points de vue pourrait être intéressante,
et lancer une grande discussion.
Par exemple, si j'aime bien l'approche objet de Python, je reproche à la
programmation orientée objet (et non la programmation objet), une
atomisation du code, à tel point qu'il peut être très difficile de retrouver
l'information.
J'ai un petit logiciel, avec une vingtaine de classes, héritant les unes des
autres (par héritage multiple), et avec surcharge de méthodes. Résultat : en
lisant une routine, c'est vraiment très difficile de retrouver le code qui
va s'appliquer.
C'est l'entropie de la programmation objet ;-)
En programmation objet on a tendance à vouloir tout réutiliser et le
système final devient ingérable et inutilisable sur plusieurs projets,
alors que le but était justement l'inverse !
A côté de ça, j'ai un gros logiciel, genre bibliothèque de fonctions,
essentiellement en procédural. La multiplicité des fonctions ne nuit pas à
la lisibilité, car chaque fonction a un usage bien précis, et les
possibilités de Python permettent de bien limiter les besoins de surcharge,
et la multiplicité des fonctions.
Amha il faut appliquer ce même principe en programmation objet. C'est à
dire faire des objets certes, mais en limitant l'interdépendance. Tu
aurais eu exactement le même problème avec des fonctions trop liés entre
elles...
Mais il est vrai aussi que, pour certains scripts simples, j'apprécie la
facilité apportée par les classes, et que j'ai souvent du mal à relire des
fonctions réentrantes.
Le code "spaghetti", ce n'est pas lié ni à la programmation procédurale, ni
à la programmation objet, mais plutôt à la façon de programmer du
développeur.
C'est ce que je pense aussi. Pour ma part je n'hésite pas à mélanger
les deux... (Python le permet d'une manière particulièrement élégante).
Malheureusement, ce genre de message étant propice au "trolling", je me
demande si l'on doit poursuivre.
Je pense que oui... Ca peut éviter de tomber dans certains pièges. C'est
dans une discussion trollesque sur les langages que je me suis rendu
compte que j'avais mis au point un vrai bourbier à vouloir trop
"d'objets" (ce que démontrait un anti-objet). Je suis donc revenu "en
arrière" et ça a été concluant !
--
William
http://wikipython.flibuste.net : wiki francophone sur python
Une confrontation des différents points de vue pourrait être intéressante, et lancer une grande discussion.
Par exemple, si j'aime bien l'approche objet de Python, je reproche à la programmation orientée objet (et non la programmation objet), une atomisation du code, à tel point qu'il peut être très difficile de retrouver l'information. J'ai un petit logiciel, avec une vingtaine de classes, héritant les unes des autres (par héritage multiple), et avec surcharge de méthodes. Résultat : en lisant une routine, c'est vraiment très difficile de retrouver le code qui va s'appliquer.
C'est l'entropie de la programmation objet ;-)
En programmation objet on a tendance à vouloir tout réutiliser et le système final devient ingérable et inutilisable sur plusieurs projets, alors que le but était justement l'inverse !
A côté de ça, j'ai un gros logiciel, genre bibliothèque de fonctions, essentiellement en procédural. La multiplicité des fonctions ne nuit pas à la lisibilité, car chaque fonction a un usage bien précis, et les possibilités de Python permettent de bien limiter les besoins de surcharge, et la multiplicité des fonctions.
Amha il faut appliquer ce même principe en programmation objet. C'est à dire faire des objets certes, mais en limitant l'interdépendance. Tu aurais eu exactement le même problème avec des fonctions trop liés entre elles...
Mais il est vrai aussi que, pour certains scripts simples, j'apprécie la facilité apportée par les classes, et que j'ai souvent du mal à relire des fonctions réentrantes.
Le code "spaghetti", ce n'est pas lié ni à la programmation procédurale, ni à la programmation objet, mais plutôt à la façon de programmer du développeur.
C'est ce que je pense aussi. Pour ma part je n'hésite pas à mélanger les deux... (Python le permet d'une manière particulièrement élégante).
Malheureusement, ce genre de message étant propice au "trolling", je me demande si l'on doit poursuivre.
Je pense que oui... Ca peut éviter de tomber dans certains pièges. C'est dans une discussion trollesque sur les langages que je me suis rendu compte que j'avais mis au point un vrai bourbier à vouloir trop "d'objets" (ce que démontrait un anti-objet). Je suis donc revenu "en arrière" et ça a été concluant !
-- William http://wikipython.flibuste.net : wiki francophone sur python
bruno modulix
Sylvain Thenault wrote:
On Wed, 23 Mar 2005 11:49:29 +0100, Hervé Cauwelier wrote:
dans le cas de la programmation fonctionnelle avec le module string, je trouve personnellement que la version objet est beaucoup plus lisible :
Les fonctions « fonctionnelles » ont un sens dans un programme écrit en fonctionnel. Votre exemple montre l'intérêt de la programmation objet.
oui, c'était bien le but.
Je pense que le sous-entendu était qu'il ne montrait pas l'intérêt d'un style fonctionnel !-)
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Sylvain Thenault wrote:
On Wed, 23 Mar 2005 11:49:29 +0100, Hervé Cauwelier wrote:
dans le cas de la programmation fonctionnelle avec le module string, je
trouve personnellement que la version objet est beaucoup plus lisible :
Les fonctions « fonctionnelles » ont un sens dans un programme écrit en
fonctionnel. Votre exemple montre l'intérêt de la programmation objet.
oui, c'était bien le but.
Je pense que le sous-entendu était qu'il ne montrait pas l'intérêt d'un
style fonctionnel !-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
VS from string import replace escaped = replace(replace(replace(basestring, '&', '&'), '<', '<'), '>', '>')
beark.... du replace de replace de replace etc.... notation objet ou notation fonctionelle, ça reste du genre gourmand.
une ch'tite boucle avec les tests idoines plutôt et recréation de la chaine non ??
Eric
-- Gr> non. qui dit femme ne veut pas dire féminisme. Pas toujours, mais sans trop m'avancer, la question féministe serait quand même nettement plus simple s'il n'y a avait pas de femmes -+- HP in GNU : J'ai honte, mais ça doit être la saison qui veut ça -+-
Sylvain Thenault wrote:
On Wed, 23 Mar 2005 11:04:20 +0100, Do Re Mi chel La Si Do wrote:
Bonjour !
dans le cas de la programmation fonctionnelle avec le module string, je
trouve personnellement que la version objet est beaucoup plus lisible :
VS
from
string import replace
escaped = replace(replace(replace(basestring, '&', '&'), '<', '<'),
'>', '>')
beark....
du replace de replace de replace etc....
notation objet ou notation fonctionelle, ça reste du genre gourmand.
une ch'tite boucle avec les tests idoines plutôt et recréation de la
chaine non ??
Eric
--
Gr> non. qui dit femme ne veut pas dire féminisme.
Pas toujours, mais sans trop m'avancer, la question féministe serait
quand même nettement plus simple s'il n'y a avait pas de femmes
-+- HP in GNU : J'ai honte, mais ça doit être la saison qui veut ça -+-
VS from string import replace escaped = replace(replace(replace(basestring, '&', '&'), '<', '<'), '>', '>')
beark.... du replace de replace de replace etc.... notation objet ou notation fonctionelle, ça reste du genre gourmand.
une ch'tite boucle avec les tests idoines plutôt et recréation de la chaine non ??
Eric
-- Gr> non. qui dit femme ne veut pas dire féminisme. Pas toujours, mais sans trop m'avancer, la question féministe serait quand même nettement plus simple s'il n'y a avait pas de femmes -+- HP in GNU : J'ai honte, mais ça doit être la saison qui veut ça -+-
