Le tien est plus gros que le mien

[Pierre Kypréos]

Je me fais à nouveau l'écho de ma source préférée avec cet article,
sur le thème de la comparaison des langages de programmation, que
chacun d'entre nous devrait méditer...
A noter que pour ma part je suis en phase avec l'auteur. ( C'est
évident, sinon je n'aurais relayé le message ;-) )

"Il y a des langages qui permettent de faire plus de choses en moins
de lignes... mais finalement, est-ce le plus important ?
Bien écrit.

[Narcissistic IT, same old challenge, same old idiots] (Anglais)
http://www.application-servers.com/links.do?reqCode=showLink&lid=3548
"

Retrouvez cette news sur :
http://www.application-servers.com/comments.do?reqCode=readComments&sid=2007-02-20-23:41:21

[Benoit LAFFITTE]

Personnellement, Je ne suis que partiellement d'accord avec l'auteur.
Car le fait d'écrire les choses de manière plus concises a des bienfaits, je m'explique.

Je suis en phases avec l'auteur de l'article qd il dis qu'il vaut mieux un code que mon voisin a compris,
qu'un code illisible, et inmaintenable.
Par contre la ou je proteste c'est le cas ou mon voisin ne comprend mon
code car il n'as pas les connaissances pour le faire; surtout qd ce travail est le fruit d'une mure réflexion, et l'expérience de 5 a 10 ans de technique d'optimisation du langage dans lequel je programme. Dans ce cas de figure il y a, selon moi, 2 choses à faire :

1. commenter son code,
   
2. former le gars a coté de moi pour que lui aussi puisse lire, écrire et surtout maintenir le code.

Je ne suis pas d'accord avec ce que que sous-entends l'article (en clair pour schématise , vive le C-C++ et les cartes perforés...),
un retour au base de l'informatique est importantes certes, mais en quoi il est utiles de savoir implémenter une liste chaînée ?
Pour moi, a rien si ce n'est de comprendre les mécanismes d'un langage, et que c'est l'occasion de mettre en pratique des méthodes de développement (au sens méthodologie) en ce basant sur un sujet simple maîtrisé par tout informaticien chevronné.
Là ou je rejoins encore l'auteur de l'article, c'est sur les éternelles erreurs que nous faisons et refaisons, comme au temps des cartes perforées... mais la ou il invoque le langage de scripting a la mode qui détourne le programmer du droit chemin (c'est à dire écrire du code robuste, sans anomalies et maintenable), moi j'invoquerais le marché, la pressions, les commerciaux qui nous demande toujours plus, plus vite et moins cher (histoire de ne pas trop rogner sur leur commission... si si il y en a des comme ça et vous en connaissez sûrement !), souvent au détriment de la qualité, ou de la maintennabilité du produit.

Sur ce constat voila enfin mon point vu sur la concision d'un langage sur le code à produire avec nos pauvre mi-mines de développeur:

1. Ça limite les risque de syndrome du canal carpiens et les tendinites (c'est accessoire pour certains ? on en reparleras dans 15 ou 20 ans...)
   
2. A charge équivalente on a plus de temps pour réfléchir, appliquer les normes de dev, commenter son code, bref mieux faire son travail.
3. On réponds aux attentes des clients et du marché, et le commerciaux s'en foute plein les fouilles (et nous on nous fous la paix...  on peut rêver non ;) )
4. Et bien si les trois premiers arguments ne vous convainc pas, moi je sèche.

On peut aussi atteindre ces objectif avec des langages plus verbeux, et la recette est assez simple, c'est la capitalisation des composants logiciels d'un application. Il faut, dans la mesure ou c'est possible, capitalisez au maximum sur les composants d'une application et ce dés le début de la conception (voir de l'avant ventes ...).
Au bout de quelques projet sur un domaine particulier on obtient une bibliothèque de composants conséquente, ce qui nous ramènera fatalement à un "pseudo macro langage" (assister ou non de générateur) qui raccourcis le nombre de ligne a taper.
C'est certes un peu plus long mais on en reviens au 3 point précèdent (je vous fais grâce du 4éme).


Sinon pour le reste, je suis d'accord, et si vous n'etes pas d'accord avec mes propos et bien j'ai qu'une choses a dire:

AU NOM DE SPRING, JAVA ET DE RUBY ON RAILS, AMEN !

"Bon c'est tous ce que j'ai a dire sur ce sujet"
Benoit LAFFITTE

PS: 1000pt pour le premier qui trouve de qui est la citation !!

[David Andriana]

J'ai lu l'article en diagonale, pour chercher l'évocation de la
programmation fonctionnelle. Et je suis d'accord sur ce que l'auteur dit
des Lispeurs, mais...

À mon humble avis, ce qui est déterminant dans le gain marginal entre
les langages, c'est ce qui fait basculer vers un mode de pensée plus
proche de la solution du problème (voire un mode de pensée au-delà de la
solution du problème, mais c'est un autre débat ;-)

Ainsi, ce qui est radical avec Ruby on Rails, c'est le côté « déclaratif
dans le code ». Ce qui est radical avec JUnit, c'est le côté assertif
hors de tout mécanisme de lancement. Ce qui est radical avec Java, c'est
le côté garbage collecting et pointer-free. Puis le dynamisme autour de
la plateforme, qui est un aspect très particulier.

Pour en revenir aux langages, je considère qu'un des leviers les plus
importants que j'ai découverts ces dernières années concernant la
productivité logicielle, touche les tests automatisés. En fait tout gain
d'écriture dans les tests, est marginalement plus important pour moi que
le même gain d'écriture appliqué au code lui-même.

C'est ainsi que j'ai récemment appliqué pour certaines validations des
jeux de règles écrits avec JBoss Rules (ex-Drools), règles qui disposent
maintenant d'une syntaxe assez claire, sans XML dans tous les coins.

D'une part, moyennant bien sûr le bon effort initial du framework qui va
bien (mon modèle fonctionnel est spécifique. Pas vous ?), l'expressivité
des règles de validation est extrêmement forte.

D'autre part, on s'est aperçu que moyennant l'adoption de ce système de
validation, les règles, comme les tests JUnit du reste, étaient sans
contexte, et donc... parallélisables. Comme elles ne sont que
déclaratives et non compilées (la compilation se fait à la volée, avec
Janino. Demander des détails à Étienne), on arrive à les penser comme
des fichiers transportables un peu partout. C'est très important, de
savoir si un langage devra être compilé ou s'il pourra être interprété à
l'exécution. Mine de rien cela conditionne notre façon de penser son
déploiement.

Noter que les règles elles-mêmes peuvent créer un nouveau contexte, qui
lui-même peut être ensuite validé.

Donc au final, dans la balance, j'ai à comparer :

1. des classes JUnit que je dois compiler, qui me valident certains
aspects pré-déterminés de mon système, et qui s'arrêtent après.
Difficiles à paralléliser. En tout cas pas pensées pour.

2. des règles déclaratives, compréhensibles par tous, parallélisables,
et qui peuvent me créer une nouvelle « vue » du système, que je peux
également revalider par la suite.

La puissance du point 2. rend très éloignées les considérations sur le
choix du langage de développement lui-même. « Du moment que mes clusters
de tests valident votre programme, vous pouvez choisir la techno que
vous voulez ».

Qu'en pensez-vous ?

Et faites-vous confiance aux tests, ou à la maintenabilité ? (Vraie
question)

--
David

[thierry mazzotti]

je suis partiellement  d'accord avec chacun de vous.....

Le problème n'est pas une question de language, ou de processus de tests mais un problème humain, et en cela, je rejoins Benoit.

Chaque jour, je suis confronté :

- A des Développeurs inexpérimentés qui n'ont pas le recul necessaire pour "coder correctement"  ou implenter "un découpage clair" du besoin.
- A des développeurs expérimentés qui "se font plaisir" et qui tiennent pas compte de la maintenance de l'application.

Et ceci, quel que soit le language, les  procédures de tests... etcc...

voila!!!

[Pierre Kypréos]

Deux citations :

"L'expérience est le nom que chacun donne à ses erreurs." (Oscar Wilde)

"Il vaut mieux se tromper avec tout le monde que d'être intelligent
tout seul." (Marcel Achard)