Developper sur Rail

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bonjour, je voulais savoir si comme pour d’autre langage (php par
exemple), les developpeurs ruby francais sont nombreux ?

En fait c’est pour le cas d’un demarrage d’un nouveau projet, j’ai
besoin de savoir plusieurs choses :

    • Nombres de talenteux developpeurs sur Rails (Ruby donc)
    • Robustesse du core ruby sur un projet consequent (version 1 et 2)
    • Stabilité du core
    • Gestion des bases de données
    • Gestion des add ons (genre cpan sur perl)

Je voudrais pas me retrouver sur un projet ou on ne trouve pas de
developpeur ou encore sur un projet tel que le core ruby se mette a
planter a tout va, ou observe des performances lamentables.

Bref, ce qui ont un peu de recul sur ce sublime langage, qu’en pensez
vous ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32) - WinPT 1.2.0

iD8DBQFFlAWMEg3iyspSWPARAoPOAJ4iB+1QJfm8FcA5EigwKjuviUS3ywCfQT5q
LIbsn0IN8QtHZvQSvMBv7J4=
=9rDQ
-----END PGP SIGNATURE-----

Salut Cypher S.,

Je comprends ton “inquietude” face a un nouveau framework. Bcp de gens
se
posent exactement les memes questions que toi. Tout ce que je peux te
dire,
c’est que:

  • 37signals (qui est la boite qui grosso modo sponsorise RoR a toutes
    ses
    applications en RoR et elles supportent de grosses grosses charges.
  • dernierement, dans la liste de diffusion, on va vu que le site de
    Madame
    Figaro tournait depuis pas longtemps avec RoR.
  • dans ma boite, on utilise depuis presque 2 ans cette techno et on a eu
    AUCUN probleme bloquant que cela soit au niveau de la stabilite d’une
    appli
    et ou bien sur les performances.
  • la liste de diffusion francaise est plutot active et on a rapidement
    une
    reponse (correcte). Meme chose apparemment pour la version anglophone
    (jamais teste en fait).

MAIS attention, comme l’a dit DHH (le papa de RoR) dans une de ses
interviews, le developpeur doit s’adapter a RoR et non le contraire (il
n’a
pas dit exactement cela mais c’etait l’esprit). Il veut dire que RoR est
puissant car il fournit toute une methodologie pour la creation
d’applications qui va a la fois te faire gagner un temps pas possible
(je le
verifie a chaque projet que je demarre) et d’autre part te permettre
d’avoir
un appli plus robuste et facilement maintenable.

Ceci etant dit, je te conseillerai te prendre plutot des developpeurs
qui
ont deja une experience dans ce domaine (Ruby ou RoR) ou qui ont un
background technique assez consistent. Parce qu’a force de dire que RoR
est
facile, bcp de personnes le prennent au pied de la lettre et on
rencontre
alors des droles de choses. Dans ma boite, on a recupere une appli RoR
debutee par un gars et je peux te dire que c’etait totalement infernal a
lire et a decoder, le gars reinventait la roue la plupart du temps, le
code
etait brouillon (DRY, connaissait pas), bref c’etait pire que tout. En
gros,
RoR ne te transformera pas un developpeur moyen en un super developpeur
de
la mort :slight_smile:

Donc pour resumer rapidement, RoR oui mais avec cela depend des
contraintes
sur ton projet (ie: degre de liberte) et surtout avoir un developpeur
RoR
senior (genre en tant que responsable technique).

J’espere que cela t’aidera. Bonnes fetes de fin d’annee.

Did

2006/12/28, Cypher S. [email protected]:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, merci pour les precisions.

En fait le degre de liberte est assez consequent, ce qui est pratique,
par contre le manque de developpeurs est ennuyeux.

En fait on a deja un projet assez gros ecris en perl, qui date d’il y a
4 ans, et on a un probleme pour trouver des developpeurs perl jeune, et
assez doue pour ne pas faire de cochonerie.

Comme on demarre un nouveau projet, on pensais choisir un langage
pratique, efficace, elegant, qui obligerait a bien faire, et dans lequel
on aurait pas de soucis a trouver des developpeurs, quitte a les obliger
a bien faire …

Le seul sur lequel on s’oriente pour l’instant c’est le php … mais
j’aimes pas des masses. On va trouver certes des developpeurs en
pagaille mais bonjour le panache … On en aura plein qui sauront faire
n’importe quoi …
Enfin on peut les obliger a bien coder.

Pour ruby, faut deja trouver des developpeurs, et apres … faut voir
s’il code bien.

Bref … a reflechir. Mais j’ai grace a vous et via la mailing-list, des
elements de reflexions maintenant.

Merci
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32) - WinPT 1.0.1

iD8DBQFFllC8Eg3iyspSWPARAiRbAJsGzckd4g2KGY16YNrxy5NwHs348wCbB6Ul
+SG5EMzUzugRGW37HdlgrbE=
=x8Xb
-----END PGP SIGNATURE-----

Nombres de talenteux developpeurs sur Rails (Ruby donc)

C’est clair y’a pas, faudra les former.

Par contre RoR est un bonheur à apprendre pour quiconque est à l’aise
avec
l’objet.

Je partirais donc avec des gens familiers de Java ou .NET (BTW, je fais
partie des derniers et j’adooore RoR).

PHP a une longue tradition de bordel organisé et d’OO mal compris, sauf
pour
l’aspect scripting, il ne prépare sans doute pas au mieux pour Ruby.

C’est clair que Ruby on Rails est un framework récent, donc tu trouveras
beaucoup moins de devs Ruby que PHP.

Mais récent ne veut pas dire jeune ou instable : il est stable depuis
déjà quelques temps et basé sur un langage de script 100% objet qui a
une dizaine d’année, donc bien éprouvé depuis.

Vers quelles solutions techniques penches tu ? PHP 5 de base et Ruby on
Rails ?
Personnellement, aucun framework PHP ne m’a donné pleine satisfaction,
pas autant que le couple Ruby & Ruby on Rails.

Entre du PHP 5 nu et Ruby on Rails, je choisirais personnellement RoR.
L’apprentissage et l’utilisation de Ruby on Rails pour des développeurs
qui ont déjà de l’expérience Web avec un langage/framework objet (.NET,
J2EE) se fait vraiment rapidement.

J’ai lu de nombreux retours d’expériences sur des blogs de développeurs
qui se sont lancés dans un projet RoR avec des développeurs .NET/Java et
au final certains ont même gagné du temps, malgré la phase
d’apprentissage.

En résumé, si tu n’as pas de contrainte pour l’hébergement de ton
application (serveurs dédiés avec Sysadmin Unix compétent) et des
développeurs qui ont déjà une expérience Web objet, RoR est clairement
une solution à envisager.

Nicolas.

Cypher S. wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bonjour, je voulais savoir si comme pour d’autre langage (php par
exemple), les developpeurs ruby francais sont nombreux ?

En fait c’est pour le cas d’un demarrage d’un nouveau projet, j’ai
besoin de savoir plusieurs choses :

    • Nombres de talenteux developpeurs sur Rails (Ruby donc)
    • Robustesse du core ruby sur un projet consequent (version 1 et 2)
    • Stabilité du core
    • Gestion des bases de données
    • Gestion des add ons (genre cpan sur perl)

Je voudrais pas me retrouver sur un projet ou on ne trouve pas de
developpeur ou encore sur un projet tel que le core ruby se mette a
planter a tout va, ou observe des performances lamentables.

Bref, ce qui ont un peu de recul sur ce sublime langage, qu’en pensez
vous ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32) - WinPT 1.2.0

iD8DBQFFlAWMEg3iyspSWPARAoPOAJ4iB+1QJfm8FcA5EigwKjuviUS3ywCfQT5q
LIbsn0IN8QtHZvQSvMBv7J4=
=9rDQ
-----END PGP SIGNATURE-----

Ce qui est sur aussi c’est que nombreux développeur Ruby on abordé
ruby (et/ou RoR) dans une démarche personnel, et n’ont pas eu encore
l’occassion de le pratiquer en entreprise, et donc ne peuvent pas
avoir de référence sur leur CV.

Personnellement, mon CV reflère plutot un profil Java, mais cela fait
plus d’un an que je tate du ruby @home … Je ne pense pas être le
seul dans ce cas.

Après de la à dire que je (nous) suis(sommes) talentueux… c’est
aller un peu vite en besogne, comment savoir quand on a pas taté un
vrai projet…

Enfin, ça ne t’avance peut-être pas beaucoup mon intervention, si
peut-être juste pour te signaler qu’il y a des développeurs Ruby, mais
certains sont caché sous d’autre profil :slight_smile:

2007/1/3, philippe lachaise [email protected]:

Philippe:

Par contre RoR est un bonheur à apprendre pour quiconque est à l’aise
avec l’objet.

Je partirais donc avec des gens familiers de Java ou .NET (BTW, je fais
partie des derniers et j’adooore RoR).

Je ne comprends pas très bien l’enchaînement logique entre ces
2 phrases.

PHP a une longue tradition de bordel organisé

Je ne vois pas le problème. Une appli Rails est naturellement
structurée,
donc ça “structure” aussi le développeur.

et d’OO mal compris, sauf pour l’aspect scripting, il ne prépare
sans doute pas au mieux pour Ruby.

Et si ledit développeur a travaillé sur une appli Web correctement OO
(et ne me dites pas qu’il y en a pas en PHP !) qui s’avérait peut-être
un logiciel libre (culture open source), qui a des compétences (X)HTML,
CSS, JavaScript (voire même Prototype), a déployé sous LAMP
(culture Linux, Apache, MySQL), il n’aurait pas suffisamment de
prédispositions pour Rails ??

Je ne dis pas non plus que les développeurs PHP sont les plus
prédisposés mais je ne suis pas convaincu par l’argumentaire ci-dessus.

-- Jean-François.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oui je comprends bien.

Quand je me mettrais a chercher des developpeurs, je passerais par ce
forum :slight_smile:

C’est sur que ca aide, si la personne a deja fait un peu de ruby et a un
profil java correcte :slight_smile:

bref, a voir
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32) - WinPT 1.0.1

iD8DBQFFm4FHEg3iyspSWPARAiQ6AJ4k8a15oRLwTlLjajtMVRaiwOS2dgCfW3b4
pTNfelMGGN121vyPWVXaEyY=
=3/sD
-----END PGP SIGNATURE-----

Le Mar 9 janvier 2007 16:58, Jean-Francois a écrit :

Philippe:

Je partirais donc avec des gens familiers de Java ou .NET (BTW, je fais
partie des derniers et j’adooore RoR).
[…]
PHP a une longue tradition de bordel organisé
[…]
et d’OO mal compris, sauf pour l’aspect scripting, il ne prépare
sans doute pas au mieux pour Ruby.

Je ne dis pas non plus que les développeurs PHP sont les plus
prédisposés mais je ne suis pas convaincu par l’argumentaire ci-dessus.

Chouette alors je vais jouer à ta place, parce que moi je le dis : les
développeurs PHP me semble nettement plus aptes à passer à Ruby que des
développeurs Java.

Le coté complexe du passage à ruby ce n’est pas l’objet. Une bonne remise
à plat de la philosophie objet ça prend au plus une journée. Le coté
complexe d’un changement de langage c’est la perte de ses habitudes et
du
dogme qu’on construit en s’habituant à un langage.

Les développeurs Java que je vois autour de moi ont de très grosses
difficultés vis à vis d’au moins trois points :

  • le coté dynamique (absence de déclaration statique, absence de
    contrôled’un compilateur, classes ouvertes modifiables)
  • l’organisation des bibliothèques (le mode “tout dans la classe de base”
    de ruby et l’absence de completion évolué dans les éditeurs à cause du
    manque de typage statique)
  • toute notion objet qui ne colle pas à 110% avec la vision objet de Java

Ca n’a l’air de rien mais pour les développeurs un minimum colorés “Java”
autour de moi, ça risque d’être un pas énorme. J’en ai justement
discutésavec certains dans le cadre d’une présentation à Ruby que je prépare.
le coté dynamique (pas de déclaration statique)

A l’inverse, le développeur PHP il a une philosophie objet qui est bien
plus proche de ruby. Son objet est encore à moitié statique par rapport à
ruby, son code n’est souvent qu’à moitié objet à cause du langage, mais la
façon de manipuler les objets n’est pas si lointaine (principalement du
fait du typage dynamique).
Certes notre développeur PHP aura un cadre plus rigoureux que son
habitude, mais pas énormément. Il va même gagner des joujous 20 fois moins
rigoureux que ce qu’il a jamais espéré (genre redéfinition des types de
base ou des opérateurs).

Pour moi la proximité est beaucoup plus proche avec PHP qu’avec Java. Et
surtout, un développeur PHP est de mon expérience beaucoup plus souple
qu’un développeur Java. Ces derniers ont souvent beaucoup de mal avec tout
ce qui sort de leur vision habituelle.


Éric Daspet
http://eric.daspet.name/

On 1/9/07, Eric D. [email protected] wrote:

Chouette alors je vais jouer à ta place, parce que moi je le dis : les
développeurs PHP me semble nettement plus aptes à passer à Ruby que des
développeurs Java.

En tant que développeur Java en train d’apprendre Ruby et Rails, je
suis d’accord.

Les développeurs Java que je vois autour de moi ont de très grosses
difficultés vis à vis d’au moins trois points :

  • le coté dynamique (absence de déclaration statique, absence de contrôle
    d’un compilateur, classes ouvertes modifiables)

Ca, pour moi, ça n’est pas un problème majeur, puisque c’est
précisément ce qui manque le plus à Java (voir là
http://nicolas-delsaux.is-a-geek.net/wordpress/index.php/archives/2007/un-module-pour-similar_text/
ce que j’ai rajouté à String)

  • l’organisation des bibliothèques (le mode “tout dans la classe de base”
    de ruby et l’absence de completion évolué dans les éditeurs à cause du
    manque de typage statique)

C’est vrai que l’absence de complétion et surtout de refactoring est
un frein puissant, je trouve. Mais on s’y fait, au bout d’un moment
(et c’est là que j’apprécie d’avoir commencé le Java avec un éditeur
de texte basique et Ant).

  • toute notion objet qui ne colle pas à 110% avec la vision objet de Java

Si tu parles des modules et mixins, je dirais non.

Moi, ce qui m’em***de le plus avec Ruby, ce sont les syntactic sugar
et autres trucs bizarres.
Typiquement, hier, je jouais avec un bout du projet sur lequel je
bosse, et j’ai bien mis 1/2 heure à comprendre que la méthode
retournait bien argument, parce que le coup de “la valeur de retour
d’une méthode est sa dernière ligne”, je trouve ça lourd. Surtout
couplé avec un
ma_variable = if toto==titi
toto+tatat
else
titi-tata
end
Et je ne parle pas des 4 façons différentes de créer une chaïne …
qui me donnent carrément la migraine

Ca n’a l’air de rien mais pour les développeurs un minimum colorés “Java”
autour de moi, ça risque d’être un pas énorme. J’en ai justement discutés
avec certains dans le cadre d’une présentation à Ruby que je prépare.
le coté dynamique (pas de déclaration statique)

C’est vrai que pouvoir connaître le type des arguments d’une méthode,
par exemple, ça aide. Je ne sais pas comment font les développeurs PHP
mais je sais que, déja en Javascript, ça fout un beau bazar. Il va
donc falloir revenir aux notations hongroises et autres
odieusetés(mega-beurk) ? ou alors commenter le codde d’une façon correcte (ce
qui me conduit à une question annexe : comment faire en RDoc
l’équivalent de la javadoc et des @param ?).

Pour moi la proximité est beaucoup plus proche avec PHP qu’avec Java. Et
surtout, un développeur PHP est de mon expérience beaucoup plus souple
qu’un développeur Java. Ces derniers ont souvent beaucoup de mal avec tout
ce qui sort de leur vision habituelle.

Les développeurs Java de bas étage, alors. Parce que ceux d’un peu
nplus haut ont déja joué avec des décorateurs de bytecode, AOP, …
des trucs aussi puissants que ce que permet Ruby, mais en 20 fois plus
de lignes :wink:


Nicolas D.
N’imprimez ce mail que si vous ne savez pas le lire sur l’écran : les
électrons se recyclent bien, le papier, beaucoup moins bien.

Éric :

Je ne dis pas non plus que les développeurs PHP sont les plus
prédisposés mais je ne suis pas convaincu par l’argumentaire ci-dessus.

Chouette alors je vais jouer à ta place, parce que moi je le dis : les
développeurs PHP me semble nettement plus aptes à passer à Ruby
que des développeurs Java.

J’utilisais le superlatif car je voulais sortir du triumvirat Ruby, PHP,
Java.

Je pense que les dévs Perl ou Python passent assez facilement Ã
Ruby. Et je crois que les plus prédisposés à Ruby sont les développeurs
Smalltalk. Pour eux, c’est les doigts dans le nez !

Le coté complexe du passage à ruby ce n’est pas l’objet. Une bonne
remise à plat de la philosophie objet ça prend au plus une journée. Le
coté complexe d’un changement de langage c’est la perte de ses
habitudes et du dogme qu’on construit en s’habituant à un langage.

Oui, ou on cherche l’équivalent en Ruby de concept existant dans son
langage. L’exemple qui me vient en tête, est les interfaces en Java.

Sinon plutôt d’accord avec tes arguments.

-- Jean-François.

“la valeur de retour d’une méthode est sa dernière ligne”, je trouve ça
lourd.

C’est vrai que ça fait partie des non-dits (*) déroutants.

Un autre générateur de brouillard, par exemple, est l’usage dans RoR de
“yield” en lieu et place de “content_for_layout”, c’est très branché
mais si
on est pas dans le secret on se demande bien ce que ça fait là .

D’un autre côté la soupless de création de DLS hyper puissantes est à ce
prix.

Ma conclusion : RoR demande d’intégrer une vaste culture (plus que de la
technique) avant d’être à l’aise et très productif. Ceci dit, ça en vaut
la
peine.

(*) Le fait d’être documenté n’empèche pas d’être un non-dit lorsque
c’est
très éloigné des habitudes les plus répandues.

Le Mer 10 janvier 2007 08:28, Nicolas D. a écrit :

  • toute notion objet qui ne colle pas à 110% avec la vision objet de
    Java

Si tu parles des modules et mixins, je dirais non.

Je pensais plus à la notion d’interface et aux
visibilitéspublic/privé/protégé, à la surcharge des méthode, et globalement aux
architecture à 600 couches avec à chaque fois un moteur, une
implémentation, une interface, etc. L’exemple simple que j’ai en tête
c’est la différence pour les itérateurs. En Java on a une classe dédié à
l’itération qu’on instancie et qu’après on utilise pour le parcours. En
Ruby ou en PHP on utilise(rait) une méthode directement dans la classe à
parcourir.

Surtout couplé avec un
ma_variable = if toto==titi
toto+tatat
else
titi-tata
end

Ca je te rassure comme construction c’est bien horrible. A la base c’est
illisible en langage naturel donc ça devrait être
évité.

C’est vrai que pouvoir connaître le type des arguments d’une méthode,
par exemple, ça aide. Je ne sais pas comment font les développeurs PHP

En caricaturant : à quoi ça sert ?
Ce qui m’intéresse quand je code c’est le rôle des données et ce que
représentent les variables, pas leur type.
Pour passer dans le concret, tu n’as probablement jamais tenté d’ouvrir
une porte avec une fleur : tu utilises une clé. Quand tu reviens du
fleuriste avec un bouquet de fleur pour ta maman, ce qui te retient de
l’utiliser ce n’est pas son type (le fait que ce soit une “fleur” et que
la serrure attend des “clé” en paramètre), c’est son rôle et ce qu’elle
représente (le fait que c’est un cadeau prévu comme tel et pas un
trousseau prévu pour ouvrir les portes).
La preuve c’est que si tu achètes en réalité un trousseau à ta mère pour
son anniversaire, et que tu dans ta poche le trousseau de la porte
d’entrée et celui de ta cave : tu ne tenteras pas d’ouvrir la porte avec
le trousseau de ta mère, par contre tu risques d’essayer avec celui de la
cave si tu ne fais pas attention. La distinction ne se fait pas sur le
type (ce sont tous les trois des trousseaux de clés) mais sur le rôle que
tu leur as
attribué.

Si tu as besoin du type c’est que le nommage de tes variables ou méthodes
ainsi que le contexte ne permettent pas de savoir à quoi sert la
donnéeque tu as sous les yeux. Et si ça arrive, tu as un problème bien plus
important que le manque de type.

(oui, je sais, je dérive, mais la question du typage et de comment le
typage dynamique est ressenti par les habitué de java m’intéresse
beaucoup)

mais je sais que, déja en Javascript, ça fout un beau bazar. Il va
donc falloir revenir aux notations hongroises et autres odieusetés
(mega-beurk) ?

Ah non ! pas de préfixage de type, pitié ! Le nom de la variable doit
suffire à savoir ce qu’elle représente (et donc ce qu’on peut faire avec),
peu importe son type.

Ces derniers ont souvent beaucoup de mal avec
tout ce qui sort de leur vision habituelle.

Les développeurs Java de bas étage, alors. Parce que ceux d’un peu
nplus haut ont déja joué avec des décorateurs de bytecode, AOP, …

En fait je pensais au contraire plus aux architecte et développeurs assez
poussés.

des trucs aussi puissants que ce que permet Ruby, mais en 20 fois plus
de lignes :wink:

C’est bien de la forme que je parle, la façon de faire les choses. Il est
bien évident que tout ce qui est faisable dans un langage est faisable
dans un autre. La problématique c’est changer sa façon de faire et les
habitudes/attendus/réflexes qui viennent avec.


Éric Daspet
http://eric.daspet.name/

Le Mer 10 janvier 2007 14:26, Nicolas D. a écrit :

On 1/10/07, Eric D. [email protected] wrote:
Pour moi, la seule chose qui me manque vraiment, c’est de pouvoir
savoir ce que je peux faire avec mon paramètre. Si je reprend mon
exemple précédent (ce module de similar_text), la méthode principale
s’appelle get_lcs et a cette tête :
get_lcs(s1, s2, verbose)
En lisant ça, est-ce que tu sais comment manipuler s1 et s2 ?
Est-ce que tu arriveras facilement à modifier le code de la méthode ?
Pas moi (enfin, dans ce cas très précis, si, mais dans le cas général,
non).

Je sais, c’est facile et je parle toujours dans mon monde idéal, mais
d’après moi ce qui pose problème là ce n’est pas l’absence du type, c’est
le mauvais nommage de la méthode et des paramètres. Au lieu de se
contraindre à expliciter les types des données, il vaut mieux se
contraindre à expliciter les actions menées et les données manipulées
elles mêmes. C’est sûr que si on ne fait aucun des deux et qu’en plus ce
n’est pas commenté, ça ne fonctionnera pas ;).

Pour prendre un exemple à PHP, si je te dit strpos(a, b) (recherche d’une
chaîne de caractère dans un texte). J’ai beau te donner les types (les
deux sont des chaînes de caractères), ça ne t’explicitera pas vraiment
quel est la chaîne à rechercher et quelle est la chaîne dans laquelle
rechercher.

Si je sais ce que représente quelque chose je peux tenter de voir ce que
je vais faire avec et les méthodes dont je dispose (donc de quelle classe
c’est). Par contre si j’ai la classe mais que je ne sais pas ce que
çareprésente, de toutes façons je ne pourrais rien faire avec.

Enfin bon, je me rend compte que j’ai encore dérivé à n’en plus finir,
toutes mes excuses.


Éric Daspet
http://eric.daspet.name/

On 1/10/07, Eric D. [email protected] wrote:

Je pensais plus à la notion d’interface et aux visibilités
public/privé/protégé,

Ben ça, (par ça, je parle de la visibilité), ça va.

à la surcharge des méthode, et globalement aux
architecture à 600 couches avec à chaque fois un moteur, une
implémentation, une interface, etc. L’exemple simple que j’ai en tête
c’est la différence pour les itérateurs. En Java on a une classe dédié à
l’itération qu’on instancie et qu’après on utilise pour le parcours. En
Ruby ou en PHP on utilise(rait) une méthode directement dans la classe à
parcourir.

Oui, enfin bon, prendre comme exemple l’itérateur, c’est un peu bas,
puisque c’est le truc le plus typique de Java dans ce domaine.

Surtout couplé avec un
ma_variable = if toto==titi
toto+tatat
else
titi-tata
end

Ca je te rassure comme construction c’est bien horrible. A la base c’est
illisible en langage naturel donc ça devrait être évité.

Ouais, enfin bon, le codeur de pimki ne s’embarasse pas de ces
considérations, manifestement :slight_smile:

En caricaturant : à quoi ça sert ?

A sauter facilement jusqu’à la doc pour lister les méthodes,
plutôtqu’en faisant mon_objet.methods.sort*“\n”

Ce qui m’intéresse quand je code c’est le rôle des données et ce que
représentent les variables, pas leur type.
type (ce sont tous les trois des trousseaux de clés) mais sur le rôle que
tu leur as attribué.

Ouais, enfin bon, pour suivre cette métaphore, je dirais qu’il faut
quand même être sûr que tu as une clé dans la main, et non une
décoration de porte-clé en forme de gorille (ou de tête parlante, pour
les vieux fans de Christophe Lambert).

Si tu as besoin du type c’est que le nommage de tes variables ou méthodes
ainsi que le contexte ne permettent pas de savoir à quoi sert la donnée
que tu as sous les yeux. Et si ça arrive, tu as un problème bien plus
important que le manque de type.

Je ne suis pas d’accord, tout au moins dans mon cas.
Comme tu as pu t’en douter, je participe (un peu) au codage de Pimki.
Et, dans ce cadre, je vais de temps en temps toucher à des objets que
je connais bien moins que mes servlets, et pour lesquels je ne connais
malheureusement pas le type des arguments. Du coup, si je modifie le
code, je ne sais pas trop comment modifier ces paramètres.

(oui, je sais, je dérive, mais la question du typage et de comment le
typage dynamique est ressenti par les habitué de java m’intéresse
beaucoup)

Tu m’étonne.
Pour moi, la seule chose qui me manque vraiment, c’est de pouvoir
savoir ce que je peux faire avec mon paramètre. Si je reprend mon
exemple précédent (ce module de similar_text), la méthode principale
s’appelle get_lcs et a cette tête :
get_lcs(s1, s2, verbose)
En lisant ça, est-ce que tu sais comment manipuler s1 et s2 ? Est-ce
que tu arriveras facilement à modifier le code de la méthode ?
Pas moi (enfin, dans ce cas très précis, si, mais dans le cas général, non).
Et c’est difficile en partie parce que les béquilles ddu monde Java me
manquent (la complétion, la javadoc qui s’affiche automatiquement sous
mon objet, …).
Tiens, par exemple, je suis toujours à la recherche de l’outil magique
qui me permettra d’afficher depuis mon éditeur de texte la doc d’une
méthode, genre “collect” que j’ai sélectionnée (j’avais commencé comme
ça en Java, avec Textpad et la javadoc au format Winhelp).

Ah non ! pas de préfixage de type, pitié ! Le nom de la variable doit
suffire à savoir ce qu’elle représente (et donc ce qu’on peut faire avec),
peu importe son type.

Ca risque fort de pas être
gagné.>

Les développeurs Java de bas étage, alors. Parce que ceux d’un peu
nplus haut ont déja joué avec des décorateurs de bytecode, AOP, …

En fait je pensais au contraire plus aux architecte et développeurs assez
poussés.

Tu veux dire les mecs comme moi ?

La problématique c’est changer sa façon de faire et les
habitudes/attendus/réflexes qui viennent avec.

Il est vrai que, quand je vois à quel point mes collègues sont
fermésaux autres langages, je me dis qu’ils auront nettement plus de mal que
moi à s’y mettre.


Nicolas D.
N’imprimez ce mail que si vous ne savez pas le lire sur l’écran : les
électrons se recyclent bien, le papier, beaucoup moins bien.

On 1/11/07, Eric D. [email protected] wrote:

Pour prendre un exemple à PHP, si je te dit strpos(a, b) (recherche d’une
chaîne de caractère dans un texte). J’ai beau te donner les types (les
deux sont des chaînes de caractères), ça ne t’explicitera pas vraiment
quel est la chaîne à rechercher et quelle est la chaîne dans laquelle
rechercher.

D’un autre côté, un exemple en PHP, c’est presque toujours un
contre-exemple, non ? :wink:

Si je sais ce que représente quelque chose je peux tenter de voir ce que
je vais faire avec et les méthodes dont je dispose (donc de quelle classe
c’est).

Autrement dit, donner des noms signifiants aux arguments.

Par contre si j’ai la classe mais que je ne sais pas ce que ça
représente, de toutes façons je ne pourrais rien faire avec.

Si, tu sauras facilement quelles méthodes appeler.
Finallement, j’ai l’impression que le top, c’est de donner aux
arguments un nom qui me permette de savoir rapidement de quelle classe
ils doivent être (ou documenter ça correctement) et, par ailleurs,
leur donner un nom qui corresponde à leur rôle dans la méthode. Coup
de bol, c’est déja ce que je fais en Java.

Enfin bon, je me rend compte que j’ai encore dérivé à n’en plus finir,
toutes mes excuses.

Pas la peine de t’excuser (au moins pour moi), c’était exactement le
genre de discussion que j’attendais. D’un autre côté, elle aurait
peut-être été plus à sa place sur la liste Ruby …


Nicolas D.
N’imprimez ce mail que si vous ne savez pas le lire sur l’écran : les
électrons se recyclent bien, le papier, beaucoup moins bien.

discussion…D’un autre côté, elle aurait peut-être été plus à sa place
sur la liste Ruby

Vu l’importance du nommage dans RoR ça ne me parait pas du tout déplacé
ici.

Il y a un parrallèle avec l’écriture (littéraire) : la recherche du mot
juste.

Un texte efficace utilise des mots et des tournures qui vont droit au
but.
La souplesse de Ruby permet cette forme d’expressivité, qui est hors de
porté des langages classiques.

Ce que les écrivains on découvert bien avant le programmeurs c’est qu’un
bon
style fatigue moins le cerveau (en écriture autant qu’en lecture) ce qui
permet de manipuler plus de sens avec moins de symboles, sans perdre le
fil
en route.