PHP, vos astuces pour palier à ses défauts ?

[Sephi-Chan]

Que dire, ce n'est pas le genre de débat qui peut finir.

À chacun ses technologie de prédilections. S'il n'y a pas qu'un langage unique, c'est bien parce qu'on a tous des attentes différentes.

L'essentiel, c'est de choisir une technologie parce qu'elle nous plaît, et pas se retrouver à l'utiliser parce qu'on ne connaît rien d'autre. Beaucoup de débutants choisissent PHP parce que c'est le plus connu, c'est dommage.

Et l'autre point essentiel, c'est d'utiliser des frameworks.

[Hideaki]

Je suis d'accord c'est dommage que les débutants choisissent cependant il est plus accessible, plus de documentation, de tutoriel en français, ne demande pas vraiment de grande connaissance, est facile à aborder dans le sens où tu peux tout faire (et n'importe quoi) dans la même page, l'approche procédural est souvent plus facile à comprendre pour les débutants ...
Vu ton engouement pour ruby on rails, pourquoi ne fais-tu pas un site entièrement dédié à cette technologie en français, sans abordé les jeux web ? voir créer un sous domaine de jeuweb : ruby.jeuweb.org ne parlant que de ruby à l'instar de la partie wiki ?

[Sephi-Chan]

PHP n'est guère plus accessible que Sinatra, un micro-framework en Ruby qui permet déjà de faire les choses 100x plus clairement que PHP.

l'approche procédural est souvent plus facile à comprendre pour les débutants ...

Si PHP était tout objet, les gens ne se poseraient pas de questions. Le concept de base de l'objet est infiniment plus naturel que le procédural.

Vu ton engouement pour ruby on rails, pourquoi ne fais-tu pas un site entièrement dédié à cette technologie en français, sans abordé les jeux web ? voir créer un sous domaine de jeuweb : ruby.jeuweb.org ne parlant que de ruby à l'instar de la partie wiki ?

Pourquoi isolerais-je Ruby et pas PHP ? Si j'ai renommé JeuPHP en JeuWeb, c'est bien pour marquer la fin de cette segregation stérile.

Au moins, les gens qui viennent ici peuvent tomber sur des messages concernant Rails au hasard d'une discussion et se dire que c'est plus sympa que leur PHP from scratch. Ça fait des victimes de moins pour le-langage-qui-a-pour-seul-avantage-de-tourner-sur-tout-les-hébergements-mutualisés.

Quand on se met à développer un jeu par navigateur, il est temps d'opter pour des outils plus sérieux et donc d'utiliser un framework (quel que soit le langage). Après, quitte à réapprendre à coder, autant le faire avec un bon langage (que ce soit Java, Ruby, Python ou autre importe peu).

Grâce à ces messages, plusieurs personnes s'y sont mises et d'autres se mettent à comprendre les enjeux des frameworks. Je suis donc très content de faire ça ainsi et de briser le monopole de PHP.

Faire des ressources hors du contexte des jeux par navigateur ne m'intéresse pas : je déteste les tutoriels d'introduction qui apprennent à faire des CRUD. Je préfère intégrer de vraies problématiques, et les webgames en offrent une infinité.

[niahoo]

Le concept de base de l'objet est infiniment plus naturel que le procédural.

C'est faux !! (oui je sais j'argumente autant que toi)

[Sephi-Chan]

Inutile de tomber dans l'absurde. Cette caractéristique de l'objet est largement admise, que tu aimes ou non ce paradigme.

Dès l'enfance, un humain regarde ce qui l'entoure en le décrivant : il comprend rapidement la différence entre un être vivant et un véhicule, il déterme le type du véhicule par certaines attributs : la présence ou non de roues, leur nombre, etc. Puis il découvre ce que cette chose est capable de faire : accélérer, freiner, etc.
L'enfant découvre des similitudes entre les choses tout en parvenant à les distinguer : femme/homme, moto/voiture/vélo, etc.

C'est exactement ce que fait l'objet.

[niahoo]

C'est mieux déjà

Dès l'enfance, un humain regarde ce qui l'entoure en le décrivant

Je veux bien croire qu'en maternelle la programmation orientée objet soit plus facile à appréhender que la procédurale.
Mais alors il ne faut pas aller gratter sour la syntaxe (genre en CM1) parce qu'on se mange du procédural dans les dents, du coup ça me paraît pas naturel qu'un nombre entier ait des méthodes ...

(mais j'ai pas dit que ce n'était pas bien ou que ce n'était pas plus pratique)

[popayan]

+1 Sephi ^^

ah mon premier cours de java avec bluej

[Hideaki]

cela n'avait pas pour but d'isoler le langage mais juste pour créer une section du : "comment faire en ruby un jeu web " sans pour autant créer un forum, cela aurait servit plus de tuto qu'autres choses afin de fournir au personne des bases, après d'autres langages pourraient exister.

Pour l'objet et le procédural, je ne suis pas d'accord avec ton exemple en effet un enfant ce que peux faire un objet ou être animé en revanche dans la vie de tous les jours, on ne dit pas à son devoir de faire quelques choses, ni à une liste de course de se calculer, ni au frigo rempli toi ou donne moi cela, j'ai d'autres exemples plus ou moins valable mais la première chose que l'on apprend c'est de manipuler ce qui nous entour et non demander à celui-ci de se laisser manipuler. Je me doute bien que tu trouveras des exemples contraires.

La conception objet vient bien plus tard et n'est absolument pas naturel pour la majorité des personnes.

[Sephi-Chan]

Je n'ai pas besoin de prendre d'exemple contraire, seulement de mettre ton exemple dans le bon sens.

Comme tu le dis toi même, il n'est pas question d'un objet réfrigérateur qui se remplit tout seul mais d'avoir des acteurs capables de le manipuler.
Un réfrigérateur est un objet qu'on peut remplir (il implémente l'interface "fillable" !).
Ce sont d'autres objets (les humains, par exemple.) qui sont capable ou non de déposer/retirer des objets du réfrigérateur (ou autre conteneur).

Quoiqu'il en soit, je tenais à expliquer ça mais cette partie du débat ne m'intéresse absolument pas.

[niahoo]

fill(frigo, hamburgers) ça fait pas très objet (toujours dans le cadre d'une découverte du langage par un novice)
Bref je suis aussi d'accord pour dire que ce débat ne sert pas à grand chose (mais quand même, l'objet à de grands avantages, on oublie trop souvent d'en admettre aussi les quelques défauts)