Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Juste ce que j'ai vu ces derniers jours...
Juste ce que j'ai vu ces derniers jours...
Juste ce que j'ai vu ces derniers jours...
Le 17/06/2011 22:16, JKB a écrit :Avec java ? La maintenance ou l'évolutivité est au contraire moindre
parce que c'est du code écrit à la va-vite lorsque ce n'est pas à la
va-comme-je-te-pousse !
Là tu parles du dev, pas du langage…
Le problème est le même en Java ou en C++.
Par ailleurs, la programmation
abjecte^Wobjet est la pire des choses parce qu'on n'a jamais le bon
objet sous la main lorsqu'on a un programme un tant soit peu
complexe.
Ce qui dénote plus un problème d'architecture qu'un problème de langage.
Une architecture 3-tiers couplée à du MVC pour les clients, un soupçon
d'IoC pour coupler tout ça ensemble et éviter le problème sus-mentionné,
et basta.
Une archi totalement classique mais ô combien complexe à mettre en œuvre
en C++ et très rarement appliquée…
Alors qu'en Java, Maven, Hibernate ou autre Spring te prémache
totalement le travail, sans risque d'erreur.
100 lignes de codes et je suis connecté à une base de données avec tout
mon schéma de données et mes requêtes opérationnels et plus qu'à remplir
les trous côté 3-tiers et MVC, le tout totalement modulable et évolutif
sans aucun tricks de code à la con.
Tente d'en faire autant avec du C++…
Et le jour où je ne veux plus un client lourd mais un client/serveur
voire un site web, la couche 3-tiers est fully reusable sans changer la
moindre ligne de code.
La puissance de Java ne vient pas de son langage, mais de ses outils, de
sa communauté et de ses méthodes et standards de travail totalement
intégrés et respectés par l'ensemble de ses projets.
Le 17/06/2011 22:16, JKB a écrit :
Avec java ? La maintenance ou l'évolutivité est au contraire moindre
parce que c'est du code écrit à la va-vite lorsque ce n'est pas à la
va-comme-je-te-pousse !
Là tu parles du dev, pas du langage…
Le problème est le même en Java ou en C++.
Par ailleurs, la programmation
abjecte^Wobjet est la pire des choses parce qu'on n'a jamais le bon
objet sous la main lorsqu'on a un programme un tant soit peu
complexe.
Ce qui dénote plus un problème d'architecture qu'un problème de langage.
Une architecture 3-tiers couplée à du MVC pour les clients, un soupçon
d'IoC pour coupler tout ça ensemble et éviter le problème sus-mentionné,
et basta.
Une archi totalement classique mais ô combien complexe à mettre en œuvre
en C++ et très rarement appliquée…
Alors qu'en Java, Maven, Hibernate ou autre Spring te prémache
totalement le travail, sans risque d'erreur.
100 lignes de codes et je suis connecté à une base de données avec tout
mon schéma de données et mes requêtes opérationnels et plus qu'à remplir
les trous côté 3-tiers et MVC, le tout totalement modulable et évolutif
sans aucun tricks de code à la con.
Tente d'en faire autant avec du C++…
Et le jour où je ne veux plus un client lourd mais un client/serveur
voire un site web, la couche 3-tiers est fully reusable sans changer la
moindre ligne de code.
La puissance de Java ne vient pas de son langage, mais de ses outils, de
sa communauté et de ses méthodes et standards de travail totalement
intégrés et respectés par l'ensemble de ses projets.
Le 17/06/2011 22:16, JKB a écrit :Avec java ? La maintenance ou l'évolutivité est au contraire moindre
parce que c'est du code écrit à la va-vite lorsque ce n'est pas à la
va-comme-je-te-pousse !
Là tu parles du dev, pas du langage…
Le problème est le même en Java ou en C++.
Par ailleurs, la programmation
abjecte^Wobjet est la pire des choses parce qu'on n'a jamais le bon
objet sous la main lorsqu'on a un programme un tant soit peu
complexe.
Ce qui dénote plus un problème d'architecture qu'un problème de langage.
Une architecture 3-tiers couplée à du MVC pour les clients, un soupçon
d'IoC pour coupler tout ça ensemble et éviter le problème sus-mentionné,
et basta.
Une archi totalement classique mais ô combien complexe à mettre en œuvre
en C++ et très rarement appliquée…
Alors qu'en Java, Maven, Hibernate ou autre Spring te prémache
totalement le travail, sans risque d'erreur.
100 lignes de codes et je suis connecté à une base de données avec tout
mon schéma de données et mes requêtes opérationnels et plus qu'à remplir
les trous côté 3-tiers et MVC, le tout totalement modulable et évolutif
sans aucun tricks de code à la con.
Tente d'en faire autant avec du C++…
Et le jour où je ne veux plus un client lourd mais un client/serveur
voire un site web, la couche 3-tiers est fully reusable sans changer la
moindre ligne de code.
La puissance de Java ne vient pas de son langage, mais de ses outils, de
sa communauté et de ses méthodes et standards de travail totalement
intégrés et respectés par l'ensemble de ses projets.
Et niveau maintenance et évolutivité, Eclipse est quand même un des IDE
Et niveau maintenance et évolutivité, Eclipse est quand même un des IDE
Et niveau maintenance et évolutivité, Eclipse est quand même un des IDE
Le 17/06/2011 23:49, Tonton Th a écrit :Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Ajoute C ou ASM si tu le souhaites, cela ne change rien.
C'est même encore pire, avec des tricks comme les variables globales ou
que tout est accessible à la simple connaissance du .h…
Et j'oublie aussi la croix et la bannière pour gérer proprement la
compilation sans passer par des abérations comme les autotools ou le
bordel sans nom des inclusions croisées de .h…
Le 17/06/2011 23:49, Tonton Th a écrit :
Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Ajoute C ou ASM si tu le souhaites, cela ne change rien.
C'est même encore pire, avec des tricks comme les variables globales ou
que tout est accessible à la simple connaissance du .h…
Et j'oublie aussi la croix et la bannière pour gérer proprement la
compilation sans passer par des abérations comme les autotools ou le
bordel sans nom des inclusions croisées de .h…
Le 17/06/2011 23:49, Tonton Th a écrit :Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Ajoute C ou ASM si tu le souhaites, cela ne change rien.
C'est même encore pire, avec des tricks comme les variables globales ou
que tout est accessible à la simple connaissance du .h…
Et j'oublie aussi la croix et la bannière pour gérer proprement la
compilation sans passer par des abérations comme les autotools ou le
bordel sans nom des inclusions croisées de .h…
Le 17/06/2011 23:14, Tonton Th a écrit :Ou sur la facilité de maintenance et l'évolutivité accrue.
J'ai juste un peu lolé...
Justification ?
Java est connu pour ses outils permettant d'éviter tous les trucs
totalement bloated qu'on trouve régulièrement dans la plupart des autres
langages.
Et niveau maintenance et évolutivité, Eclipse est quand même un des IDE
les plus aboutis ne serait-ce que pour ses fonctionnalités de
refactoring très évoluées et par sa modularité (plugins).
Après, je te concède que pour parvenir à un niveau correct de
maintenance et d'évolutivité, il faut aussi avoir des développeurs
compétents et souvent un architecte logiciel (en tout cas au démarrage
du projet).
Le 17/06/2011 23:14, Tonton Th a écrit :
Ou sur la facilité de maintenance et l'évolutivité accrue.
J'ai juste un peu lolé...
Justification ?
Java est connu pour ses outils permettant d'éviter tous les trucs
totalement bloated qu'on trouve régulièrement dans la plupart des autres
langages.
Et niveau maintenance et évolutivité, Eclipse est quand même un des IDE
les plus aboutis ne serait-ce que pour ses fonctionnalités de
refactoring très évoluées et par sa modularité (plugins).
Après, je te concède que pour parvenir à un niveau correct de
maintenance et d'évolutivité, il faut aussi avoir des développeurs
compétents et souvent un architecte logiciel (en tout cas au démarrage
du projet).
Le 17/06/2011 23:14, Tonton Th a écrit :Ou sur la facilité de maintenance et l'évolutivité accrue.
J'ai juste un peu lolé...
Justification ?
Java est connu pour ses outils permettant d'éviter tous les trucs
totalement bloated qu'on trouve régulièrement dans la plupart des autres
langages.
Et niveau maintenance et évolutivité, Eclipse est quand même un des IDE
les plus aboutis ne serait-ce que pour ses fonctionnalités de
refactoring très évoluées et par sa modularité (plugins).
Après, je te concède que pour parvenir à un niveau correct de
maintenance et d'évolutivité, il faut aussi avoir des développeurs
compétents et souvent un architecte logiciel (en tout cas au démarrage
du projet).
Le 17/06/2011 23:51, Tonton Th a écrit :Juste ce que j'ai vu ces derniers jours...
On ne doit pas voir la même chose alors…
Côté Java je vois des trucs pas parfait certes, mais relativement
propres et bien conçus.
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.
Et je peux les intégrer en 4 lignes de XML à mon propre projet.
Toujours du côté des standards, la plupart des méthodes de travail ont
été standardisées et sont respectées par tout projet de ce nom, aussi
bien la partie organisation du code (convention de nommage) que celui de
la SCM (nommage des versions, emplacement des tags), des méthodes de
gestion de projet (tests unitaires, site web) ou des architectures
(n-tiers, IoC, MVC).
Quand je regarde un projet en C ou C⁺⁺, je tombe invariablement sur plus
de bordel pour gérer la compilation (makefile démentiel,
autotools/autoconf inmaintenable, #ifdef/#define à la con pour éviter
les boucles d'inclusion…) que pour gérer le code métier lui-même.
La compilation passe invariablement par la polution de mon système avec
des tonnes de librairies que je dois gérer à la main, des options de
compilation à faire palir la sortie d'un man…
Et niveau homogénéité, chaque projet fait des siennes, avec du code
souvent digne du siècle dernier (singletons, factories, god objects,
variables globales…).
Je vais te donner un exemple tout bête :
https://bitbucket.org/aeris/openpki/src
Même sans avoir fait de Java voire même de programmation objet ou de
programmation tout court, tu es presque en mesure de comprendre ce code.
En à peine 2.000 lignes de code (1.954 pour être tout à fait exact), je
gère :
— Une base de données complète, création automatique et requètes
incluses, indépendante du moteur de base derrière (MySQL, PostgreSQL,
SQL Server, H2, Oracle…)
— Un site web complet
— Une architecture 3-tiers (service, dao, domain) totalement séparée
pour la partie serveur
— Une architecture MVC (séparation accès base de données / affichage)
pour la partie cliente
— L'intégralité de la gestion d'une PKI (génération CA, génération
certificat, signature certificat, export x509/PKCS12/PEM, révocation et
prochainement CRL et OCSP)
— Les tests unitaires de l'application
Avec Maven, je suis aussi capable de te générer :
— le site du projet
— sa Javadoc
— ses rapports de tests U
— ses rapports de couverture de code
– ses rapports de normes de codage, de duplication de code ou de
mauvaises pratiques de programmation
– son changelog
— ses statistiques de code (nombre de classes, taille des
classes/méthodes, les hot spots à améliorer…)
— …
Et tu es capables de le compiler et de le déployer sur ta machine sans y
installer quoi que ce soit (hormis Maven) et sur n'importe quelle
architecture (Windows, Linux, Mac, x86, amd64…) avec juste un « mvn
install ».
Tu peux même le lancer immédiatement sans le moindre prérequis, juste
avec un « mvn org.mortbay.jetty:jetty-maven-plugin:run ».
Et tout ça en à peine 2.000 lignes de code Java et 400 lignes de
configuration, je le rappelle !
Tu m'en fais de même en C ou en C⁺⁺ ?
En si peu de code ?
En si peu de temps (un week-end) ?
Le 17/06/2011 23:51, Tonton Th a écrit :
Juste ce que j'ai vu ces derniers jours...
On ne doit pas voir la même chose alors…
Côté Java je vois des trucs pas parfait certes, mais relativement
propres et bien conçus.
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.
Et je peux les intégrer en 4 lignes de XML à mon propre projet.
Toujours du côté des standards, la plupart des méthodes de travail ont
été standardisées et sont respectées par tout projet de ce nom, aussi
bien la partie organisation du code (convention de nommage) que celui de
la SCM (nommage des versions, emplacement des tags), des méthodes de
gestion de projet (tests unitaires, site web) ou des architectures
(n-tiers, IoC, MVC).
Quand je regarde un projet en C ou C⁺⁺, je tombe invariablement sur plus
de bordel pour gérer la compilation (makefile démentiel,
autotools/autoconf inmaintenable, #ifdef/#define à la con pour éviter
les boucles d'inclusion…) que pour gérer le code métier lui-même.
La compilation passe invariablement par la polution de mon système avec
des tonnes de librairies que je dois gérer à la main, des options de
compilation à faire palir la sortie d'un man…
Et niveau homogénéité, chaque projet fait des siennes, avec du code
souvent digne du siècle dernier (singletons, factories, god objects,
variables globales…).
Je vais te donner un exemple tout bête :
https://bitbucket.org/aeris/openpki/src
Même sans avoir fait de Java voire même de programmation objet ou de
programmation tout court, tu es presque en mesure de comprendre ce code.
En à peine 2.000 lignes de code (1.954 pour être tout à fait exact), je
gère :
— Une base de données complète, création automatique et requètes
incluses, indépendante du moteur de base derrière (MySQL, PostgreSQL,
SQL Server, H2, Oracle…)
— Un site web complet
— Une architecture 3-tiers (service, dao, domain) totalement séparée
pour la partie serveur
— Une architecture MVC (séparation accès base de données / affichage)
pour la partie cliente
— L'intégralité de la gestion d'une PKI (génération CA, génération
certificat, signature certificat, export x509/PKCS12/PEM, révocation et
prochainement CRL et OCSP)
— Les tests unitaires de l'application
Avec Maven, je suis aussi capable de te générer :
— le site du projet
— sa Javadoc
— ses rapports de tests U
— ses rapports de couverture de code
– ses rapports de normes de codage, de duplication de code ou de
mauvaises pratiques de programmation
– son changelog
— ses statistiques de code (nombre de classes, taille des
classes/méthodes, les hot spots à améliorer…)
— …
Et tu es capables de le compiler et de le déployer sur ta machine sans y
installer quoi que ce soit (hormis Maven) et sur n'importe quelle
architecture (Windows, Linux, Mac, x86, amd64…) avec juste un « mvn
install ».
Tu peux même le lancer immédiatement sans le moindre prérequis, juste
avec un « mvn org.mortbay.jetty:jetty-maven-plugin:run ».
Et tout ça en à peine 2.000 lignes de code Java et 400 lignes de
configuration, je le rappelle !
Tu m'en fais de même en C ou en C⁺⁺ ?
En si peu de code ?
En si peu de temps (un week-end) ?
Le 17/06/2011 23:51, Tonton Th a écrit :Juste ce que j'ai vu ces derniers jours...
On ne doit pas voir la même chose alors…
Côté Java je vois des trucs pas parfait certes, mais relativement
propres et bien conçus.
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.
Et je peux les intégrer en 4 lignes de XML à mon propre projet.
Toujours du côté des standards, la plupart des méthodes de travail ont
été standardisées et sont respectées par tout projet de ce nom, aussi
bien la partie organisation du code (convention de nommage) que celui de
la SCM (nommage des versions, emplacement des tags), des méthodes de
gestion de projet (tests unitaires, site web) ou des architectures
(n-tiers, IoC, MVC).
Quand je regarde un projet en C ou C⁺⁺, je tombe invariablement sur plus
de bordel pour gérer la compilation (makefile démentiel,
autotools/autoconf inmaintenable, #ifdef/#define à la con pour éviter
les boucles d'inclusion…) que pour gérer le code métier lui-même.
La compilation passe invariablement par la polution de mon système avec
des tonnes de librairies que je dois gérer à la main, des options de
compilation à faire palir la sortie d'un man…
Et niveau homogénéité, chaque projet fait des siennes, avec du code
souvent digne du siècle dernier (singletons, factories, god objects,
variables globales…).
Je vais te donner un exemple tout bête :
https://bitbucket.org/aeris/openpki/src
Même sans avoir fait de Java voire même de programmation objet ou de
programmation tout court, tu es presque en mesure de comprendre ce code.
En à peine 2.000 lignes de code (1.954 pour être tout à fait exact), je
gère :
— Une base de données complète, création automatique et requètes
incluses, indépendante du moteur de base derrière (MySQL, PostgreSQL,
SQL Server, H2, Oracle…)
— Un site web complet
— Une architecture 3-tiers (service, dao, domain) totalement séparée
pour la partie serveur
— Une architecture MVC (séparation accès base de données / affichage)
pour la partie cliente
— L'intégralité de la gestion d'une PKI (génération CA, génération
certificat, signature certificat, export x509/PKCS12/PEM, révocation et
prochainement CRL et OCSP)
— Les tests unitaires de l'application
Avec Maven, je suis aussi capable de te générer :
— le site du projet
— sa Javadoc
— ses rapports de tests U
— ses rapports de couverture de code
– ses rapports de normes de codage, de duplication de code ou de
mauvaises pratiques de programmation
– son changelog
— ses statistiques de code (nombre de classes, taille des
classes/méthodes, les hot spots à améliorer…)
— …
Et tu es capables de le compiler et de le déployer sur ta machine sans y
installer quoi que ce soit (hormis Maven) et sur n'importe quelle
architecture (Windows, Linux, Mac, x86, amd64…) avec juste un « mvn
install ».
Tu peux même le lancer immédiatement sans le moindre prérequis, juste
avec un « mvn org.mortbay.jetty:jetty-maven-plugin:run ».
Et tout ça en à peine 2.000 lignes de code Java et 400 lignes de
configuration, je le rappelle !
Tu m'en fais de même en C ou en C⁺⁺ ?
En si peu de code ?
En si peu de temps (un week-end) ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/06/2011 23:49, Tonton Th a écrit :Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Ajoute C ou ASM si tu le souhaites, cela ne change rien.
C'est même encore pire, avec des tricks comme les variables globales ou
que tout est accessible à la simple connaissance du .h…
Et j'oublie aussi la croix et la bannière pour gérer proprement la
compilation sans passer par des abérations comme les autotools ou le
bordel sans nom des inclusions croisées de .h…
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/06/2011 23:49, Tonton Th a écrit :
Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Ajoute C ou ASM si tu le souhaites, cela ne change rien.
C'est même encore pire, avec des tricks comme les variables globales ou
que tout est accessible à la simple connaissance du .h…
Et j'oublie aussi la croix et la bannière pour gérer proprement la
compilation sans passer par des abérations comme les autotools ou le
bordel sans nom des inclusions croisées de .h…
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/06/2011 23:49, Tonton Th a écrit :Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Ajoute C ou ASM si tu le souhaites, cela ne change rien.
C'est même encore pire, avec des tricks comme les variables globales ou
que tout est accessible à la simple connaissance du .h…
Et j'oublie aussi la croix et la bannière pour gérer proprement la
compilation sans passer par des abérations comme les autotools ou le
bordel sans nom des inclusions croisées de .h…
machine. Et je peux les intégrer en 4 lignes de XML à mon propre projet.
machine. Et je peux les intégrer en 4 lignes de XML à mon propre projet.
machine. Et je peux les intégrer en 4 lignes de XML à mon propre projet.
On 06/17/2011 11:56 PM, Aéris wrote:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/06/2011 23:49, Tonton Th a écrit :Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Ajoute C ou ASM si tu le souhaites, cela ne change rien.
C'est même encore pire, avec des tricks comme les variables globales ou
que tout est accessible à la simple connaissance du .h…
En quoi l'utilisation raisonnable des variables globales
est-elle un "tricks" ?Et j'oublie aussi la croix et la bannière pour gérer proprement la
compilation sans passer par des abérations comme les autotools ou le
bordel sans nom des inclusions croisées de .h…
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.
On 06/17/2011 11:56 PM, Aéris wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/06/2011 23:49, Tonton Th a écrit :
Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Ajoute C ou ASM si tu le souhaites, cela ne change rien.
C'est même encore pire, avec des tricks comme les variables globales ou
que tout est accessible à la simple connaissance du .h…
En quoi l'utilisation raisonnable des variables globales
est-elle un "tricks" ?
Et j'oublie aussi la croix et la bannière pour gérer proprement la
compilation sans passer par des abérations comme les autotools ou le
bordel sans nom des inclusions croisées de .h…
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.
On 06/17/2011 11:56 PM, Aéris wrote:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/06/2011 23:49, Tonton Th a écrit :Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Ajoute C ou ASM si tu le souhaites, cela ne change rien.
C'est même encore pire, avec des tricks comme les variables globales ou
que tout est accessible à la simple connaissance du .h…
En quoi l'utilisation raisonnable des variables globales
est-elle un "tricks" ?Et j'oublie aussi la croix et la bannière pour gérer proprement la
compilation sans passer par des abérations comme les autotools ou le
bordel sans nom des inclusions croisées de .h…
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.