On 06/18/2011 12:35 AM, Aéris wrote:machine. Et je peux les intégrer en 4 lignes de XML à mon propre projet.
https://bitbucket.org/aeris/openpki/src/b97fbbff9598/pom.xml
Le XML c'est comme la violence : si ça ne marche pas,
c'est que tu n'en as pas utilisé assez.
On 06/18/2011 12:35 AM, Aéris wrote:
machine. Et je peux les intégrer en 4 lignes de XML à mon propre projet.
https://bitbucket.org/aeris/openpki/src/b97fbbff9598/pom.xml
Le XML c'est comme la violence : si ça ne marche pas,
c'est que tu n'en as pas utilisé assez.
On 06/18/2011 12:35 AM, Aéris wrote:machine. Et je peux les intégrer en 4 lignes de XML à mon propre projet.
https://bitbucket.org/aeris/openpki/src/b97fbbff9598/pom.xml
Le XML c'est comme la violence : si ça ne marche pas,
c'est que tu n'en as pas utilisé assez.
Gnî ? Et les #ifdef dans les .h, c'est fait pour les chiens ?
Quant aux variables globales, les seules fois où j'en utilise, c'est
uniquement pour gérer des choses dans des gestionnaires
d'interruption.
Euh... Mauvais .h, changer .h. Les autotools ne sont pas là pour
gérer ce genre de problèmes. Les trucs comme
autoconf/automake/autoheader sont là pour assurer l'inclusion des
bon fichiers d'en-tête sur des architectures bizarres en fonction
des bibliothèques installées. L'inclusion croisée des en-têtes ne
peut être réglée que par des primitives de préprocesseur dans ces
en-têtes.
JKB
Gnî ? Et les #ifdef dans les .h, c'est fait pour les chiens ?
Quant aux variables globales, les seules fois où j'en utilise, c'est
uniquement pour gérer des choses dans des gestionnaires
d'interruption.
Euh... Mauvais .h, changer .h. Les autotools ne sont pas là pour
gérer ce genre de problèmes. Les trucs comme
autoconf/automake/autoheader sont là pour assurer l'inclusion des
bon fichiers d'en-tête sur des architectures bizarres en fonction
des bibliothèques installées. L'inclusion croisée des en-têtes ne
peut être réglée que par des primitives de préprocesseur dans ces
en-têtes.
JKB
Gnî ? Et les #ifdef dans les .h, c'est fait pour les chiens ?
Quant aux variables globales, les seules fois où j'en utilise, c'est
uniquement pour gérer des choses dans des gestionnaires
d'interruption.
Euh... Mauvais .h, changer .h. Les autotools ne sont pas là pour
gérer ce genre de problèmes. Les trucs comme
autoconf/automake/autoheader sont là pour assurer l'inclusion des
bon fichiers d'en-tête sur des architectures bizarres en fonction
des bibliothèques installées. L'inclusion croisée des en-têtes ne
peut être réglée que par des primitives de préprocesseur dans ces
en-têtes.
JKB
En quoi l'utilisation raisonnable des variables globales
est-elle un "tricks" ?
Les autotools n'ont rien à voir avec le langage. Et non, sur
un projet bien construit, les inclusions "croisées" de .h
ne posent pas de problèmes.
En quoi l'utilisation raisonnable des variables globales
est-elle un "tricks" ?
Les autotools n'ont rien à voir avec le langage. Et non, sur
un projet bien construit, les inclusions "croisées" de .h
ne posent pas de problèmes.
En quoi l'utilisation raisonnable des variables globales
est-elle un "tricks" ?
Les autotools n'ont rien à voir avec le langage. Et non, sur
un projet bien construit, les inclusions "croisées" de .h
ne posent pas de problèmes.
Certes, je parle de développement objet en général. Pour avoir bien
réfléchi au problème, je crois de plus en plus que le concept objet
a été conçu pour avoir sur le marché des tas de développeurs
médiocres capables de faire des applications rapidement, le concept
d'objet étant un garde-fou.
Certainement. Sauf que depuis quelque temps, je trouve que les
développeurs qui codent en objet (et qui n'ont jamais vu que ça)
sont des branques et ne conçoivent pas correctement leurs soft.
Rajouter un bout de code dedans est trop souvent une gageure.
Déjà fait, et qui plus est assez modulaire pour être réutilisable.
Java, ce serait intéressant s'il n'y avait pas obligatoirement de
l'objet. C'est pour cela que le C++ lui sera toujours supérieur. En
C++, tu peux parfaitement faire de la programmation fonctionnelle
(qui est amha largement supérieure lorsqu'elle est correctement
faite à la programmation objet).
En Java, c'est beaucoup plus
difficile.
Quant à gérer efficacement les ressources comme la
mémoire ou les fils d'exécution, Java ne sait carrément pas faire.
Certes, je parle de développement objet en général. Pour avoir bien
réfléchi au problème, je crois de plus en plus que le concept objet
a été conçu pour avoir sur le marché des tas de développeurs
médiocres capables de faire des applications rapidement, le concept
d'objet étant un garde-fou.
Certainement. Sauf que depuis quelque temps, je trouve que les
développeurs qui codent en objet (et qui n'ont jamais vu que ça)
sont des branques et ne conçoivent pas correctement leurs soft.
Rajouter un bout de code dedans est trop souvent une gageure.
Déjà fait, et qui plus est assez modulaire pour être réutilisable.
Java, ce serait intéressant s'il n'y avait pas obligatoirement de
l'objet. C'est pour cela que le C++ lui sera toujours supérieur. En
C++, tu peux parfaitement faire de la programmation fonctionnelle
(qui est amha largement supérieure lorsqu'elle est correctement
faite à la programmation objet).
En Java, c'est beaucoup plus
difficile.
Quant à gérer efficacement les ressources comme la
mémoire ou les fils d'exécution, Java ne sait carrément pas faire.
Certes, je parle de développement objet en général. Pour avoir bien
réfléchi au problème, je crois de plus en plus que le concept objet
a été conçu pour avoir sur le marché des tas de développeurs
médiocres capables de faire des applications rapidement, le concept
d'objet étant un garde-fou.
Certainement. Sauf que depuis quelque temps, je trouve que les
développeurs qui codent en objet (et qui n'ont jamais vu que ça)
sont des branques et ne conçoivent pas correctement leurs soft.
Rajouter un bout de code dedans est trop souvent une gageure.
Déjà fait, et qui plus est assez modulaire pour être réutilisable.
Java, ce serait intéressant s'il n'y avait pas obligatoirement de
l'objet. C'est pour cela que le C++ lui sera toujours supérieur. En
C++, tu peux parfaitement faire de la programmation fonctionnelle
(qui est amha largement supérieure lorsqu'elle est correctement
faite à la programmation objet).
En Java, c'est beaucoup plus
difficile.
Quant à gérer efficacement les ressources comme la
mémoire ou les fils d'exécution, Java ne sait carrément pas faire.
Le 18/06/2011 09:56, JKB a écrit :Gnî ? Et les #ifdef dans les .h, c'est fait pour les chiens ?
Quant aux variables globales, les seules fois où j'en utilise, c'est
uniquement pour gérer des choses dans des gestionnaires
d'interruption.
Euh... Mauvais .h, changer .h. Les autotools ne sont pas là pour
gérer ce genre de problèmes. Les trucs comme
autoconf/automake/autoheader sont là pour assurer l'inclusion des
bon fichiers d'en-tête sur des architectures bizarres en fonction
des bibliothèques installées. L'inclusion croisée des en-têtes ne
peut être réglée que par des primitives de préprocesseur dans ces
en-têtes.
JKB
Et tu ne trouves pas génant d'avoir à gérer le compilateur dans ton code ?
On en arrive même souvent à devoir splitter (sans autre raison de «
conception » que le compilo nous emmerde) un fichier .h en 2 pour s'en
sortir, à galérer avec des early declarations pour les mêmes raisons, ou
même pire à casser une architecture propre pour faire plaisir au
compilateur…
Le 18/06/2011 09:56, JKB a écrit :
Gnî ? Et les #ifdef dans les .h, c'est fait pour les chiens ?
Quant aux variables globales, les seules fois où j'en utilise, c'est
uniquement pour gérer des choses dans des gestionnaires
d'interruption.
Euh... Mauvais .h, changer .h. Les autotools ne sont pas là pour
gérer ce genre de problèmes. Les trucs comme
autoconf/automake/autoheader sont là pour assurer l'inclusion des
bon fichiers d'en-tête sur des architectures bizarres en fonction
des bibliothèques installées. L'inclusion croisée des en-têtes ne
peut être réglée que par des primitives de préprocesseur dans ces
en-têtes.
JKB
Et tu ne trouves pas génant d'avoir à gérer le compilateur dans ton code ?
On en arrive même souvent à devoir splitter (sans autre raison de «
conception » que le compilo nous emmerde) un fichier .h en 2 pour s'en
sortir, à galérer avec des early declarations pour les mêmes raisons, ou
même pire à casser une architecture propre pour faire plaisir au
compilateur…
Le 18/06/2011 09:56, JKB a écrit :Gnî ? Et les #ifdef dans les .h, c'est fait pour les chiens ?
Quant aux variables globales, les seules fois où j'en utilise, c'est
uniquement pour gérer des choses dans des gestionnaires
d'interruption.
Euh... Mauvais .h, changer .h. Les autotools ne sont pas là pour
gérer ce genre de problèmes. Les trucs comme
autoconf/automake/autoheader sont là pour assurer l'inclusion des
bon fichiers d'en-tête sur des architectures bizarres en fonction
des bibliothèques installées. L'inclusion croisée des en-têtes ne
peut être réglée que par des primitives de préprocesseur dans ces
en-têtes.
JKB
Et tu ne trouves pas génant d'avoir à gérer le compilateur dans ton code ?
On en arrive même souvent à devoir splitter (sans autre raison de «
conception » que le compilo nous emmerde) un fichier .h en 2 pour s'en
sortir, à galérer avec des early declarations pour les mêmes raisons, ou
même pire à casser une architecture propre pour faire plaisir au
compilateur…
Le 18/06/2011 12:46, Tonton Th a écrit :En quoi l'utilisation raisonnable des variables globales
est-elle un "tricks" ?
Je n'ai que très peu d'exemples voire pas du tout où une variable
globale est réellement justifiable.
Et très souvent, commencer à mettre une varglo, c'est la porte ouverte à
voir la moitié du code en varglo à plus ou moins long terme.
Après je suis en partie d'accord que le problème viendra le plus souvent
du développeur, mais le langage n'aide pas à éviter ce genre de tricks.
Les autotools n'ont rien à voir avec le langage. Et non, sur
un projet bien construit, les inclusions "croisées" de .h
ne posent pas de problèmes.
Correction, les .h croisés ne sont *plus* un problème une fois le projet
fini.
Mais ne me fait pas croire que tu n'as jamais lutté avec ce genre de
problème.
D'autant plus que les #ifdef/#define n'ont aucune justification dans le
code et ne sont là que pour faire plaisir au compilateur.
Le 18/06/2011 12:46, Tonton Th a écrit :
En quoi l'utilisation raisonnable des variables globales
est-elle un "tricks" ?
Je n'ai que très peu d'exemples voire pas du tout où une variable
globale est réellement justifiable.
Et très souvent, commencer à mettre une varglo, c'est la porte ouverte à
voir la moitié du code en varglo à plus ou moins long terme.
Après je suis en partie d'accord que le problème viendra le plus souvent
du développeur, mais le langage n'aide pas à éviter ce genre de tricks.
Les autotools n'ont rien à voir avec le langage. Et non, sur
un projet bien construit, les inclusions "croisées" de .h
ne posent pas de problèmes.
Correction, les .h croisés ne sont *plus* un problème une fois le projet
fini.
Mais ne me fait pas croire que tu n'as jamais lutté avec ce genre de
problème.
D'autant plus que les #ifdef/#define n'ont aucune justification dans le
code et ne sont là que pour faire plaisir au compilateur.
Le 18/06/2011 12:46, Tonton Th a écrit :En quoi l'utilisation raisonnable des variables globales
est-elle un "tricks" ?
Je n'ai que très peu d'exemples voire pas du tout où une variable
globale est réellement justifiable.
Et très souvent, commencer à mettre une varglo, c'est la porte ouverte à
voir la moitié du code en varglo à plus ou moins long terme.
Après je suis en partie d'accord que le problème viendra le plus souvent
du développeur, mais le langage n'aide pas à éviter ce genre de tricks.
Les autotools n'ont rien à voir avec le langage. Et non, sur
un projet bien construit, les inclusions "croisées" de .h
ne posent pas de problèmes.
Correction, les .h croisés ne sont *plus* un problème une fois le projet
fini.
Mais ne me fait pas croire que tu n'as jamais lutté avec ce genre de
problème.
D'autant plus que les #ifdef/#define n'ont aucune justification dans le
code et ne sont là que pour faire plaisir au compilateur.
Avec des outils standardisés comme Graddle ou Maven, je peux recompiler
la plupart des projets Java du monde sans aucun prérequis sur ma
machine.
On fait la même chose avec tous les autres langage. Regarde un peu
pkgsrc sous NetBSD. Ce n'est pas une histoire de langage, mais de
protocole de compilation.
Je n'ai jamais compris pourquoi il fallait du XML dans des choses
comme ant ni pourquoi un makefile des familles ne fonctionne pas
pour compiler du Java.
Et ? C'est encore quelque chose qui n'est _pas_ intrisèque au
langage.
Dans ce cas, c'est que le type chargé d'écrire le makefile (ou la
version autoconf/automake) est un branque. Le makefile (ou le
configure) doit s'arrêter en signalant ce qu'il manque.
Généralement, ces bouts manquants sont disponibles dans les dépôts.
Je vais te donner un exemple tout bête :
https://bitbucket.org/aeris/openpki/src
Beuah... Déjà, lorsque je vois tous ces répertoires imbriqués les
uns dans les autres, j'ai envie de vomir.
Et ? Si j'avais le temps, je te ferais la même chose en C (quitte à
utiliser à fond cpp ou m4 et un patchwork de bibliohtèques bien senties).
Et pour ta gouverne, le nombre de lignes n'est pas un facteur discriminant.
Le nombre d'instructions le serait déjà un peu plus.
Portabilité limitée aux systèmes qui embarquent une JVM conforme. Ça
s'est considérablement amélioré ces derniers temps avec openjkd,
mais durant très longtemps, les seules cibles étaient celles qui
avaient une JVM Sun officielles. Avec C/C++/Fortran, ça compile
partout ou presque. Avec Java, j'ai eu des tas de problèmes avec
blackdown, J9, Superwaka et autres. La portabilité Java, c'est de la
poudre aux yeux, d'autant que lorsque tu commences à faires de
choses subtiles, il faut _aussi_ trouver les paquets à importer.
Tu m'en fais de même en C ou en C⁺⁺ ?
Oui si j'en avait le temps et l'envie.En si peu de code ?
À peu près.En si peu de temps (un week-end) ?
Certainement pas, mais ce serait réutilisable et portable.
Avec des outils standardisés comme Graddle ou Maven, je peux recompiler
la plupart des projets Java du monde sans aucun prérequis sur ma
machine.
On fait la même chose avec tous les autres langage. Regarde un peu
pkgsrc sous NetBSD. Ce n'est pas une histoire de langage, mais de
protocole de compilation.
Je n'ai jamais compris pourquoi il fallait du XML dans des choses
comme ant ni pourquoi un makefile des familles ne fonctionne pas
pour compiler du Java.
Et ? C'est encore quelque chose qui n'est _pas_ intrisèque au
langage.
Dans ce cas, c'est que le type chargé d'écrire le makefile (ou la
version autoconf/automake) est un branque. Le makefile (ou le
configure) doit s'arrêter en signalant ce qu'il manque.
Généralement, ces bouts manquants sont disponibles dans les dépôts.
Je vais te donner un exemple tout bête :
https://bitbucket.org/aeris/openpki/src
Beuah... Déjà, lorsque je vois tous ces répertoires imbriqués les
uns dans les autres, j'ai envie de vomir.
Et ? Si j'avais le temps, je te ferais la même chose en C (quitte à
utiliser à fond cpp ou m4 et un patchwork de bibliohtèques bien senties).
Et pour ta gouverne, le nombre de lignes n'est pas un facteur discriminant.
Le nombre d'instructions le serait déjà un peu plus.
Portabilité limitée aux systèmes qui embarquent une JVM conforme. Ça
s'est considérablement amélioré ces derniers temps avec openjkd,
mais durant très longtemps, les seules cibles étaient celles qui
avaient une JVM Sun officielles. Avec C/C++/Fortran, ça compile
partout ou presque. Avec Java, j'ai eu des tas de problèmes avec
blackdown, J9, Superwaka et autres. La portabilité Java, c'est de la
poudre aux yeux, d'autant que lorsque tu commences à faires de
choses subtiles, il faut _aussi_ trouver les paquets à importer.
Tu m'en fais de même en C ou en C⁺⁺ ?
Oui si j'en avait le temps et l'envie.
En si peu de code ?
À peu près.
En si peu de temps (un week-end) ?
Certainement pas, mais ce serait réutilisable et portable.
Avec des outils standardisés comme Graddle ou Maven, je peux recompiler
la plupart des projets Java du monde sans aucun prérequis sur ma
machine.
On fait la même chose avec tous les autres langage. Regarde un peu
pkgsrc sous NetBSD. Ce n'est pas une histoire de langage, mais de
protocole de compilation.
Je n'ai jamais compris pourquoi il fallait du XML dans des choses
comme ant ni pourquoi un makefile des familles ne fonctionne pas
pour compiler du Java.
Et ? C'est encore quelque chose qui n'est _pas_ intrisèque au
langage.
Dans ce cas, c'est que le type chargé d'écrire le makefile (ou la
version autoconf/automake) est un branque. Le makefile (ou le
configure) doit s'arrêter en signalant ce qu'il manque.
Généralement, ces bouts manquants sont disponibles dans les dépôts.
Je vais te donner un exemple tout bête :
https://bitbucket.org/aeris/openpki/src
Beuah... Déjà, lorsque je vois tous ces répertoires imbriqués les
uns dans les autres, j'ai envie de vomir.
Et ? Si j'avais le temps, je te ferais la même chose en C (quitte à
utiliser à fond cpp ou m4 et un patchwork de bibliohtèques bien senties).
Et pour ta gouverne, le nombre de lignes n'est pas un facteur discriminant.
Le nombre d'instructions le serait déjà un peu plus.
Portabilité limitée aux systèmes qui embarquent une JVM conforme. Ça
s'est considérablement amélioré ces derniers temps avec openjkd,
mais durant très longtemps, les seules cibles étaient celles qui
avaient une JVM Sun officielles. Avec C/C++/Fortran, ça compile
partout ou presque. Avec Java, j'ai eu des tas de problèmes avec
blackdown, J9, Superwaka et autres. La portabilité Java, c'est de la
poudre aux yeux, d'autant que lorsque tu commences à faires de
choses subtiles, il faut _aussi_ trouver les paquets à importer.
Tu m'en fais de même en C ou en C⁺⁺ ?
Oui si j'en avait le temps et l'envie.En si peu de code ?
À peu près.En si peu de temps (un week-end) ?
Certainement pas, mais ce serait réutilisable et portable.
Je vais aller vomir... Un makefile, c'est simpliste à côté...
Je vais aller vomir... Un makefile, c'est simpliste à côté...
Je vais aller vomir... Un makefile, c'est simpliste à côté...
Le rapport avec la choucroute ? Et si je préfère Netbeans ?
Et si au
contraire je suis un vimiste tendance fanatique ?
Un langage est bon
ou mauvais indépendamment de l'IDE utilisée. S'il faut un IDE, il y
a déjà AMHA un problème.
Pas seulement au démarrage. Avec java (et tous les trucs objets), il
te faut un architecte du début à la fin. Mon expérience de vieux con
me dit que :
1/ commencer un projet en fonctionnel est très dur, mais plus on
arrive à la fin et plus c'est facile ;
2/ terminer un projet en objet est très dur, plus on arrive à la fin
et plus les conneries du début entravent le développement.
Le rapport avec la choucroute ? Et si je préfère Netbeans ?
Et si au
contraire je suis un vimiste tendance fanatique ?
Un langage est bon
ou mauvais indépendamment de l'IDE utilisée. S'il faut un IDE, il y
a déjà AMHA un problème.
Pas seulement au démarrage. Avec java (et tous les trucs objets), il
te faut un architecte du début à la fin. Mon expérience de vieux con
me dit que :
1/ commencer un projet en fonctionnel est très dur, mais plus on
arrive à la fin et plus c'est facile ;
2/ terminer un projet en objet est très dur, plus on arrive à la fin
et plus les conneries du début entravent le développement.
Le rapport avec la choucroute ? Et si je préfère Netbeans ?
Et si au
contraire je suis un vimiste tendance fanatique ?
Un langage est bon
ou mauvais indépendamment de l'IDE utilisée. S'il faut un IDE, il y
a déjà AMHA un problème.
Pas seulement au démarrage. Avec java (et tous les trucs objets), il
te faut un architecte du début à la fin. Mon expérience de vieux con
me dit que :
1/ commencer un projet en fonctionnel est très dur, mais plus on
arrive à la fin et plus c'est facile ;
2/ terminer un projet en objet est très dur, plus on arrive à la fin
et plus les conneries du début entravent le développement.
Le 18/06/2011 09:53, JKB a écrit :Certes, je parle de développement objet en général. Pour avoir bien
réfléchi au problème, je crois de plus en plus que le concept objet
a été conçu pour avoir sur le marché des tas de développeurs
médiocres capables de faire des applications rapidement, le concept
d'objet étant un garde-fou.
Inventé non, mais mal maîtrisé je +1
Mais je persiste qu'un dev non compétent fera plus de connerie avec du C
et du C⁺⁺ (ne serait-ce que .h croisé ou gestion de la mémoire) qu'avec
du Java.
Certainement. Sauf que depuis quelque temps, je trouve que les
développeurs qui codent en objet (et qui n'ont jamais vu que ça)
sont des branques et ne conçoivent pas correctement leurs soft.
Rajouter un bout de code dedans est trop souvent une gageure.
Dans un code mal conçu, on ne s'en sortira pas effectivement.Déjà fait, et qui plus est assez modulaire pour être réutilisable.
J'ai pas dis que c'était impossible, juste que le ratio (temps passé +
taille du code) / (modularité + évolutivité) est largement meilleur en Java.
Java, ce serait intéressant s'il n'y avait pas obligatoirement de
l'objet. C'est pour cela que le C++ lui sera toujours supérieur. En
C++, tu peux parfaitement faire de la programmation fonctionnelle
(qui est amha largement supérieure lorsqu'elle est correctement
faite à la programmation objet).
La POO apporte quand même des notions extrèmement utiles comme
l'héritage et le polymorphisme.
Sans cela, tu vas devoir passer des heures et allonger ton code d'autant
pour parvenir au même résultat…
Foo {doIt() { code1 } }
Bar : Foo { doIt() { code2 } }
List<Foo> list = { new Foo(), new Bar() }
for ( Foo foo : list ) foo.doIt()
Rien que cela en programmation fonctionnel, c'est une usine-à-gaz
immonde, puisque la fonction « doIt » va se transformer en une platrée
de if en cascade et prendre un gros « object » en paramètre, afin de
gérer le comportement alternatif en fonction du « type »…
En Java, c'est beaucoup plus
difficile.
Au pire rien ne t'empèche de prendre les classes pour des namespaces et
de faire uniquement des méthodes statiques hein =)
Quant à gérer efficacement les ressources comme la
mémoire ou les fils d'exécution, Java ne sait carrément pas faire.
Ça c'est un problème de développeur, pas du langage.
Tu peux très bien gérer ça très proprement.
Le 18/06/2011 09:53, JKB a écrit :
Certes, je parle de développement objet en général. Pour avoir bien
réfléchi au problème, je crois de plus en plus que le concept objet
a été conçu pour avoir sur le marché des tas de développeurs
médiocres capables de faire des applications rapidement, le concept
d'objet étant un garde-fou.
Inventé non, mais mal maîtrisé je +1
Mais je persiste qu'un dev non compétent fera plus de connerie avec du C
et du C⁺⁺ (ne serait-ce que .h croisé ou gestion de la mémoire) qu'avec
du Java.
Certainement. Sauf que depuis quelque temps, je trouve que les
développeurs qui codent en objet (et qui n'ont jamais vu que ça)
sont des branques et ne conçoivent pas correctement leurs soft.
Rajouter un bout de code dedans est trop souvent une gageure.
Dans un code mal conçu, on ne s'en sortira pas effectivement.
Déjà fait, et qui plus est assez modulaire pour être réutilisable.
J'ai pas dis que c'était impossible, juste que le ratio (temps passé +
taille du code) / (modularité + évolutivité) est largement meilleur en Java.
Java, ce serait intéressant s'il n'y avait pas obligatoirement de
l'objet. C'est pour cela que le C++ lui sera toujours supérieur. En
C++, tu peux parfaitement faire de la programmation fonctionnelle
(qui est amha largement supérieure lorsqu'elle est correctement
faite à la programmation objet).
La POO apporte quand même des notions extrèmement utiles comme
l'héritage et le polymorphisme.
Sans cela, tu vas devoir passer des heures et allonger ton code d'autant
pour parvenir au même résultat…
Foo {doIt() { code1 } }
Bar : Foo { doIt() { code2 } }
List<Foo> list = { new Foo(), new Bar() }
for ( Foo foo : list ) foo.doIt()
Rien que cela en programmation fonctionnel, c'est une usine-à-gaz
immonde, puisque la fonction « doIt » va se transformer en une platrée
de if en cascade et prendre un gros « object » en paramètre, afin de
gérer le comportement alternatif en fonction du « type »…
En Java, c'est beaucoup plus
difficile.
Au pire rien ne t'empèche de prendre les classes pour des namespaces et
de faire uniquement des méthodes statiques hein =)
Quant à gérer efficacement les ressources comme la
mémoire ou les fils d'exécution, Java ne sait carrément pas faire.
Ça c'est un problème de développeur, pas du langage.
Tu peux très bien gérer ça très proprement.
Le 18/06/2011 09:53, JKB a écrit :Certes, je parle de développement objet en général. Pour avoir bien
réfléchi au problème, je crois de plus en plus que le concept objet
a été conçu pour avoir sur le marché des tas de développeurs
médiocres capables de faire des applications rapidement, le concept
d'objet étant un garde-fou.
Inventé non, mais mal maîtrisé je +1
Mais je persiste qu'un dev non compétent fera plus de connerie avec du C
et du C⁺⁺ (ne serait-ce que .h croisé ou gestion de la mémoire) qu'avec
du Java.
Certainement. Sauf que depuis quelque temps, je trouve que les
développeurs qui codent en objet (et qui n'ont jamais vu que ça)
sont des branques et ne conçoivent pas correctement leurs soft.
Rajouter un bout de code dedans est trop souvent une gageure.
Dans un code mal conçu, on ne s'en sortira pas effectivement.Déjà fait, et qui plus est assez modulaire pour être réutilisable.
J'ai pas dis que c'était impossible, juste que le ratio (temps passé +
taille du code) / (modularité + évolutivité) est largement meilleur en Java.
Java, ce serait intéressant s'il n'y avait pas obligatoirement de
l'objet. C'est pour cela que le C++ lui sera toujours supérieur. En
C++, tu peux parfaitement faire de la programmation fonctionnelle
(qui est amha largement supérieure lorsqu'elle est correctement
faite à la programmation objet).
La POO apporte quand même des notions extrèmement utiles comme
l'héritage et le polymorphisme.
Sans cela, tu vas devoir passer des heures et allonger ton code d'autant
pour parvenir au même résultat…
Foo {doIt() { code1 } }
Bar : Foo { doIt() { code2 } }
List<Foo> list = { new Foo(), new Bar() }
for ( Foo foo : list ) foo.doIt()
Rien que cela en programmation fonctionnel, c'est une usine-à-gaz
immonde, puisque la fonction « doIt » va se transformer en une platrée
de if en cascade et prendre un gros « object » en paramètre, afin de
gérer le comportement alternatif en fonction du « type »…
En Java, c'est beaucoup plus
difficile.
Au pire rien ne t'empèche de prendre les classes pour des namespaces et
de faire uniquement des méthodes statiques hein =)
Quant à gérer efficacement les ressources comme la
mémoire ou les fils d'exécution, Java ne sait carrément pas faire.
Ça c'est un problème de développeur, pas du langage.
Tu peux très bien gérer ça très proprement.