/* Topic des codeurs [7] */

The Uploader · Le 18/05/2012, à 13:37

ArkSeth a écrit :

Est-ce si dur à comprendre que si je ne réponds pas au contenu, c'est parce que je n'ai rien à redire dessus, que je l'ai accepté, mais que ce n'est pas lui qui suscite ma réaction ?

Ah. Ben c'était vraiment pas évident alors, quand tu prétends que PHP n'est pas le problème, et qu'il n'a pas plus de mauvais code que les autres langages, qu'il n'encourage pas de mauvaises pratiques, qu'un langage ne peut pas être objectivement meilleur qu'un autre...

Dernière modification par The Uploader (Le 18/05/2012, à 13:43)

tshirtman · Le 18/05/2012, à 13:50

grim7reaper a écrit :

Bah si, il y a de la syntaxe quand même. Ordre et valeur des opérandes, tu ne mets pas n’importe quoi n’importe où. Après, oui c’est minimaliste comme syntaxe mais ça en reste une.

J'ai pas dis qu'il y en avait pas, j'ai dit que les mots clés de l'ASM, c'était une bibliothèque d'instructions émanant directement du processeur.

ArkSeth a écrit :

Bah pareil, je n'dis pas que c'est nécessairement faux, mais faudrait juste expliquer un peu en quoi, en définissant d'abord quelles sont les « bonnes pratiques » (genre pour le point cité par grim, si c'est mauvais d'être pensé sans typage de variables, bah y a un bon paquet de langages mauvais à ce niveau, dont ton préféré Que le mécanisme de précision soit présent mais buggé, ç't'autre chose, en effet très curieux), puis en quoi PHP encouragerait à ne pas les utiliser.

Python est fortement typé, si tu additionne deux variables de types différents (et à moins que tu ais surclassé l'opérateur sur le premier des deux), il va te gueuler dessus, alors que PHP va tenter par tous les moyens de trouver une combinaison de valeurs qui marchent, pas forcément consistante suivant l'ordre, pas forcément ce à quoi s'attends le programmeur, mais surtout, il fera tout son possible pour ne pas le prévenir d'un potentiel problème, en effet, ce n'est pas le seul langage à faire ça, javascript le fait aussi, et ça pose aussi pleins de problèmes (WAT! https://www.destroyallsoftware.com/talks/wat), mais python ne fait clairement pas ça.

Ce n'est pas le seul soucis, bien sur, mais si tu veux une liste détaillé, tu lis le liens http://me.veekun.com/blog/2012/04/09/ph … ad-design/ et tu en a pour la soirée, juste à lire, quand à répondre - et toutes méritent une réponse argumenté - tu en a pour des semaines.

Je ne nie absoluement pas les quelques problèmes dont souffre python sur des points précis, mais on parle clairement pas du même nombre de problèmes.

Jusqu'à maintenant, le seul « encouragement » à coder d'une manière ou d'une autre, c'est Python qui « encourage » (impose, d'ailleurs, quoiqu'il serait peut-être possible de se débrouiller pour contourner en foutant des parenthèses partout) à indenter proprement le code.

La gestion des erreur par les exceptions bien plus consistante.
La gestion des namespaces bien plus utilisable et donc bien plus utilisée.
et d'autres, mais bon, le but n'est pas de faire une liste… si tu as besoin que je développe ces deux points, je pense que sois tu n'a pas fais assez de python, soit tu souffre d'un aveuglement total sur l'état de php.

Pour tout le reste, de mon humble opinion (parce que c'est super subjectif, tout ça), je n'vois pas en quoi les autres langages encouragent ou découragent certaines pratiques, la facilité à les mettre en place (sauf bug de ce genre, mais voir ma parenthèse du paragraphe du dessus) me semblant dépendre essentiellement de la personne qui code.

sauf que les bugs de ce genre, y'en a des dizaines, des centaines, et les développeurs de php trouvent toujours des excuses bidons pour dire que c'est voulu, sans se rendre compte que dire que c'est voulu, c'est vraiment admettre être des imbéciles.

Dernière modification par tshirtman (Le 18/05/2012, à 13:51)

Elzen · Le 18/05/2012, à 13:52

The Uploader a écrit :

Ah. Ben c'était vraiment pas évident alors, quand tu prétends que PHP n'est pas le problème, et qu'il n'a pas plus de mauvais code que les autres langages, qu'il n'encourage pas de mauvaises pratiques, qu'un langage ne peut pas être objectivement meilleur qu'un autre...

Bah c'est peut-être un tort (je n'sais pas, j'n'ai pas eu droit à plus d'explications de votre part), mais je distingue l'aspect théorique de l'aspect pratique. Dire qu'un truc est buggé, ça s'attache à une implémentation précise, et dans ce cas, ce n'est pas « PHP » (au sens du langage tel que pensé) le problème, mais « l'implémentation de la bibliothèque de base de PHP », ce qui est p't'être un peu plus long à dire, mais tu m'connais, je pinaille ^^
S'tu préfères, il me semble qu'il serait théoriquement possible de faire une implémentation de PHP qui n'ait pas les problèmes sus-cités. Donc ça ne me semble pas être pas PHP lui-même, dans l'absolu, qui pose ce problème, mais la façon dont il est mis en place.

Sur le fait d'encourager ou pas les mauvaises pratiques, j'n'ai pas dit que ce n'était pas le cas, juste que je voulais bien que vous m'expliquiez ce que vous vous entendez par là.
Pour ma part, à part un $ devant le nom des variables et un « <?php ?> » à la place du shebang, je ne vois pas ce que le code PHP que je produit est foncièrement différent du code Python que je produits : dans les deux cas, c'est indenté, avec des fonctions pas trop longues, des lignes de 80 caractères maximum, des noms de variables explicites, même si ces variables sont non typées, etc. Donc dans l'immédiat, je ne vois juste pas quelles sont ces « mauvaises pratiques » dont vous parlez ni en quoi PHP les encouragerait.

Sur les stats pour le mauvais code, j'ai dis en effet ça un peu au pif, sans aucun chiffre réel ni aucune source (mauvais troll pour répondre à du mauvais troll, comme je disais ). Ce que je voulais dire par là, c'est que du code mal foutu, on en trouve dans tous les langages, et que de ma modeste expérience, il me semble qu'une personne qui code mal ni va pas brusquement se mettre à bien codé parce qu'il a changé de langage, ni qu'une personne qui code bien ne vas se mettre à brusquement coder bien.
Il me semble, jusqu'à ce que la façon dont vous entendez cette notion de « mauvais code » ne soit mieux explicitée, que le mauvais code dépend plus de la personne qui code que du langage qu'elle utilise.

D'où, je reviens dessus, le fait que ce ne soit pas PHP le problème : le problème, c'est que vous parlez de trucs mal définis, et que quand on vous demande de leur donner une définition, vous ne réagissiez qu'en indiquant en quoi PHP est bourré de bugs : bah d'accord, mais ça ne définit pas ce que c'est qu'un vrai langage ou un mauvais code.

Edit @tshirtman : ça c'est un post critique construit et constructif (à part sur la dernière ligne, mais j't'en fais cadeau). Du coup, j'n'ai rien à y redire et je soutiens ce qu'il y a dedans.

Juste deux trucs : pour la gestion des namespaces, tu veux bien parler du fait que le import de Python te renvoie un objet module, alors que le include/require de PHP te balance tout en vrac dans ton code, comme si t'avais fait un from machin import * en Python ?
Et pour la gestion des exceptions, ça n'me choque pas non plus terriblement (disons, pas plus, et pour la même raison, que leur implémentation des concepts objets), parce que je ne considères pas PHP comme un langage à exceptions. Je m'en sers en Python et en Java, des exceptions, mais ç't'à peu près tout. On a déjà parlé de ça, d'ailleurs, c'est juste une manière différente de voir les choses.

Dernière modification par ArkSeth (Le 18/05/2012, à 14:02)

tshirtman · Le 18/05/2012, à 14:07

« PHP » (au sens du langage tel que pensé)

J'espère vraiment que personne ne "pense" ça…

Juste deux trucs : pour la gestion des namespaces, tu veux bien parler du fait que le import de Python te renvoie un objet module, alors que le include/require de PHP te balance tout en vrac dans ton code, comme si t'avais fait un from machin import * en Python ?

Oui, entre autre.

Et pour la gestion des exceptions, ça n'me choque pas non plus terriblement (disons, pas plus, et pour la même raison, que leur implémentation des concepts objets), parce que je ne considères pas PHP comme un langage à exceptions. Je m'en sers en Python et en Java, des exceptions, mais ç't'à peu près tout. On a déjà parlé de ça, d'ailleurs, c'est juste une manière différente de voir les choses.

Oui, mais en PHP, les erreurs sont parfois traités comme en C (d'ou on se demande pourquoi avoir un langage moderne si c'est pour faire comme en 1970), parfois par exception, mais on sais pas dans quels cas, si elles seront propagées ou pas, sans parler des nombreux cas qui font tout simplement crasher l'interpréteur.

Dernière modification par tshirtman (Le 18/05/2012, à 14:11)

The Uploader · Le 18/05/2012, à 14:15

PHP a une implémentation majeure utilisée partout ou presque, et ne semble pas avoir de standard ISO ou autre (et les specs ? Ben non plus on dirait).

Ce qui pose pas mal de problèmes de consistance..

tshirtman · Le 18/05/2012, à 14:32

Le problème de php, c'est que c'est un bricolage poussé beaucoup trop loin… sans jamais sortir de sa logique de bricolage…

The Uploader · Le 18/05/2012, à 14:33

'xactement.

Pylades · Le 18/05/2012, à 14:39

The Uploader a écrit :

Sans compter que ceux qui codent PHP posent aussi un problème d'amateurisme dangereux, et codent aussi avec les pieds.

Enfin bon, de la part de gens qui supportent l’octal par accident, ce n’est pas très étonnant.

ArkSeth a écrit :

Tiens, d'ailleurs, ç't'une vraie question, y a un mécanisme de ce genre-là, en Python ?

Pas vraiment, ce n’est clairement pas dans l’esprit de Python. Python part du principe que l’objet que tu lui fournis permet de faire ce que tu as prévu. Si ce n’est pas le cas, exception. Mais il n’y a pas de mécanisme a priori. Tu peux aussi tester le type de l’objet qui est passé, mais ce n’est pas un comportement très pythonique.

Elzen · Le 18/05/2012, à 14:46

tshirtman a écrit :

Oui, entre autre.

Bah j'me suis demandé ce que ça pouvait être d'autre, donc si t'as plus d'infos ^^

Mais c'est vrai que je trouve ça assez moche aussi, les from machin import truc (ç'n'est justifié que dans quelques cas, et ça n'aide pas la lisibilité du code, à plus forte raison quand le truc en question est *… pourtant, c'est utilisé comme ça dans la plupart des exemples de Python sur lesquels je tombe ><).

Pendant un moment, j'essayais de contourner ça, en PHP, en créant une « classe » juste pour lui mettre des méthodes statiques, histoire d'avoir un semblant de namespace… je n'sais pas si c'est mieux ou pire, en fait (d'autant que je ne savais pas utiliser le PHP objet, donc je ne faisais pas ça comme il fallait, d'où la tonne de warnings sur laquelle on tombe en allant sur mon ancien site depuis que l'hébergeur semble avoir activé l'affichage des warnings)

Yep en gros sur la partie des erreurs.

tshirtman a écrit :

Le problème de php, c'est que c'est un bricolage poussé beaucoup trop loin… sans jamais sortir de sa logique de bricolage…

D'accord avec ça, j'crois même que c'est le truc qui me plaît le plus en PHP

Mais c'est vrai que pour faire un projet sérieusement pré-conceptionné et tout, ç'n'est pas l'idéal (ce qui ne veut pas dire que les trucs où tu fais un bricolage clairement assumé comme tel soient nécessairement « pas propre » ou « mauvais », selon moi, ça dépend du champ d'application)

Πυλάδης a écrit :

Pas vraiment, ce n’est clairement pas dans l’esprit de Python. Python part du principe que l’objet que tu lui fournis permet de faire ce que tu as prévu. Si ce n’est pas le cas, exception. Mais il n’y a pas de mécanisme a priori. Tu peux aussi tester le type de l’objet qui est passé, mais ce n’est pas un comportement très pythonique.

Bah de la façon dont j'interprête PHP, c'est censé fonctionner de la même façon (sauf pour l'exception, plutôt une valeur de retour indiquant l'erreur). Ç'pour ça que l'existence d'un mécanisme pour gérer ça en PHP m'étonne plus que le fait que ce mécanisme soit buggé.

Dernière modification par ArkSeth (Le 18/05/2012, à 14:52)

Pylades · Le 18/05/2012, à 14:52

Faut pas être étonné par les incohérences de PHP.

C’est un faux langage, faut pas raisonner comme avec un vrai langage.

Elzen · Le 18/05/2012, à 14:54

goto le début de cette discussion : define « vrai langage » ? (Autrement que « tout sauf PHP », s'entend)

grim7reaper · Le 18/05/2012, à 14:57

tshirtman a écrit :

grim7reaper a écrit :
Bah si, il y a de la syntaxe quand même. Ordre et valeur des opérandes, tu ne mets pas n’importe quoi n’importe où. Après, oui c’est minimaliste comme syntaxe mais ça en reste une.
J'ai pas dis qu'il y en avait pas, j'ai dit que les mots clés de l'ASM, c'était une bibliothèque d'instructions émanant directement du processeur.

Ok, je t’avais mal compris

ArkSeth a écrit :

S'tu préfères, il me semble qu'il serait théoriquement possible de faire une implémentation de PHP qui n'ait pas les problèmes sus-cités. Donc ça ne me semble pas être pas PHP lui-même, dans l'absolu, qui pose ce problème, mais la façon dont il est mis en place.

Tu soulèves là un point intéressant. Ce que tu dis est vrai pour la majorité des langages qui ont un standard/spécification/document reconnu par la communauté qui décrit le langage (après, il y a généralement l’implémentation principale et d’autres qui voit le jour).
Le souci, c’est qu’il semblerait que PHP ne soit pas défini (rien que la grammaire ne l’est apparemment pas si j’en crois le lien de The Uploader). Partant de là, l’implémentation unique fait réfèrence, mais plus que ça : l’implémentation est PHP.
Du coup, quand ils disent que PHP à tous ces défauts ils ont raison car on ne peut pas dissocier PHP de son implémentation.
Pour citer un des post sur stackoverflow :

Jimmy R a écrit :

The language is precisely whatever the interpreter does.

sweetly · Le 18/05/2012, à 14:58

ArkSeth a écrit :

goto le début de cette discussion : define « vrai langage » ? (Autrement que « tout sauf PHP », s'entend)

Je trouvais que la définition dans le lien de tshirtman était pas mal :

I assert that the following qualities are important for making a language productive and useful, and PHP violates them with wild abandon. If you can’t agree that these are crucial, well, I can’t imagine how we’ll ever agree on much.
A language must be predictable. It’s a medium for expressing human ideas and having a computer execute them, so it’s critical that a human’s understanding of a program actually be correct.
A language must be consistent. Similar things should look similar, different things different. Knowing part of the language should aid in learning and understanding the rest.
A language must be concise. New languages exist to reduce the boilerplate inherent in old languages. (We could all write machine code.) A language must thus strive to avoid introducing new boilerplate of its own.
A language must be reliable. Languages are tools for solving problems; they should minimize any new problems they introduce. Any “gotchas” are massive distractions.
A language must be debuggable. When something goes wrong, the programmer has to fix it, and we need all the help we can get.

Elzen · Le 18/05/2012, à 15:06

grim7reaper a écrit :

Tu soulèves là un point intéressant. Ce que tu dis est vrai pour la majorité des langages qui ont un standard/spécification/document reconnu par la communauté qui décrit le langage (après, il y a généralement l’implémentation principale et d’autres qui voit le jour).
Le souci, c’est qu’il semblerait que PHP ne soit pas défini (rien que la grammaire ne l’est apparemment pas si j’en crois le lien de The Uploader). Partant de là, l’implémentation unique fait réfèrence, mais plus que ça : l’implémentation est PHP.
Du coup, quand ils disent que PHP à tous ces défauts ils ont raison car on ne peut pas dissocier PHP de son implémentation.

Hmm.

Et donc, du coup, ça justifierait peut-être le statut de « pas un vrai langage » en supposant que la définition de « vrai langage » implique un tel mécanisme et qu'il soit clairement vérifié que PHP ne le remplit absolument pas.

Ça mérite réflexion et vérification… mais c'est quand même triste que la définition n'ait pas été posée avant…

sweetly a écrit :

Je trouvais que la définition dans le lien de tshirtman était pas mal :

Ouaip, j'me suis fait la même réflexion, mais j'attendais que l'un de ceux qui utilisent cette notion indique explicitement que c'était celle-la (ou une autre) qu'ils utilisaient.

Edit : encore que ça me semble spécifier ce que c'est qu'un bon langage, et pas ce que c'est qu'un vrai langage. Pour la définition de vrai, je pencherais plus pour le point évoqué ci-dessus par grim.

Ceci dit, j'pourrais critiquer certains points de la définition (ou de la vérification ou non par PHP de ces points), mais ç'n'est pas le sujet.

En fait, ce qui est fun, c'est que le discours des gens qui trollent contre PHP a l'air de présenter exactement les défauts que ces gens reprochent à PHP ^^

Dernière modification par ArkSeth (Le 18/05/2012, à 15:15)

Pylades · Le 18/05/2012, à 15:08

ArkSeth a écrit :

goto le début de cette discussion : define « vrai langage » ? (Autrement que « tout sauf PHP », s'entend)

Je l’ai déjà lu, le début, justement.

Et j’approuve : PHP n’est pas un vrai langage.

Elzen · Le 18/05/2012, à 15:10

Okay, donc tu fais du troll-post « à la Pylade », comme d'hab, sans intérêt aucun.

(Ç'quand même dingue, ça. Quand la question est « c'est quoi XXX ? » et qu'on répond « YYY n'en est pas » sans plus de précision, bonjour la recevabilité du post, ou rien que sa crédibilité, quoi… même le premier mauvais trolleur venu fait mieux…)

Dernière modification par ArkSeth (Le 18/05/2012, à 15:13)

tshirtman · Le 18/05/2012, à 15:15

ArkSeth a écrit :

tshirtman a écrit :
Oui, entre autre.
Bah j'me suis demandé ce que ça pouvait être d'autre, donc si t'as plus d'infos ^^

Quand tu aura expié tes fautes et reconnus que PHP est fondamentalement mauvais

Mais c'est vrai que je trouve ça assez moche aussi, les from machin import truc (ç'n'est justifié que dans quelques cas, et ça n'aide pas la lisibilité du code, à plus forte raison quand le truc en question est *… pourtant, c'est utilisé comme ça dans la plupart des exemples de Python sur lesquels je tombe ><).

Non, là tu choisit de les mettres dans ton namespace, et en lisant le code, tu vois d'ou ils viennent, vu qu'ils sont importés explicitements, ce n'est pas très différent du import org.bar.foo.baz.Meh en java, qui te permet de faire "new Meh();" après, tu sais d'ou ça vient, tout va bien. le import * à les défaut de l'include php (et l'include C, vu que c'est la même chose), à moins de mettre en place des conventions de nommage par bibliothèque, tu ne sais pas d'ou vient un truc.

Yep en gros sur la partie des erreurs.
tshirtman a écrit :
Le problème de php, c'est que c'est un bricolage poussé beaucoup trop loin… sans jamais sortir de sa logique de bricolage…
D'accord avec ça, j'crois même que c'est le truc qui me plaît le plus en PHP

hm, quand je dis bricolage ici, c'est pas au beau sens du terme… moi aussi je pourrait m'y mettre aujourd'hui, sortir un langage de scripting de pages webs dans 3 mois, et je trouverais surement des gens assez fous pour l'utiliser, pourvus que ce soit pas trop difficile a installer, mais si je n'ai rien conçus, juste mis des trucs un peu dans tous les sens pour qu'on puisse faire des trucs avec, les gens qui vont utiliser le truc vont devoir bricoler dès qu'ils vont tomber dans des cas que j'ai pas prévus, et ce sera une horreur, un empilement de hacks fait par des gens qui répondent à leur besoin immédiat, par ce que c'est quand même possible… et dans 10 ans, on a un autre PHP, avec un peu de chance. Mais franchement, non merci, je trouverais un autre moyen de faire mon beurre, et puis, y'a de la concurrence maintenant, beaucoup plus qu'a l'époque ou PHP est sortis.

Mais c'est vrai que pour faire un projet sérieusement pré-conceptionné et tout, ç'n'est pas l'idéal (ce qui ne veut pas dire que les trucs où tu fais un bricolage clairement assumé comme tel soient nécessairement « pas propre » ou « mauvais », selon moi, ça dépend du champ d'application)

Libre à toi de penser que pour faire ta cabane dans les bois, un couteau suisse de fête foraine est plus adapté, mais moi, si j'ai une caisse à outil, je vais la prendre, par ce que ce sera quand même plus adapté, même pour un "petit" projet.

Πυλάδης a écrit :
Tu peux aussi tester le type de l’objet qui est passé, mais ce n’est pas un comportement très pythonique.
Bah de la façon dont j'interprête PHP, c'est censé fonctionner de la même façon (sauf pour l'exception, plutôt une valeur de retour indiquant l'erreur). Ç'pour ça que l'existence d'un mécanisme pour gérer ça en PHP m'étonne plus que le fait que ce mécanisme soit buggé.

Non oO, en php, la logique, c'est que toute opération doit avoir un résultat, qu'il ait un sens ou non…

Elzen · Le 18/05/2012, à 17:04

tshirtman a écrit :

Quand tu aura expié tes fautes et reconnus que PHP est fondamentalement mauvais

Mince alors

tshirtman a écrit :

Non, là tu choisit de les mettres dans ton namespace, et en lisant le code, tu vois d'ou ils viennent, vu qu'ils sont importés explicitements, ce n'est pas très différent du import org.bar.foo.baz.Meh en java, qui te permet de faire "new Meh();" après, tu sais d'ou ça vient, tout va bien. le import * à les défaut de l'include php (et l'include C, vu que c'est la même chose), à moins de mettre en place des conventions de nommage par bibliothèque, tu ne sais pas d'ou vient un truc.

D'accord pour la nuance entre le from machin import truc et le from machin import *.
N'empêche que même si l'information est accessible, c'est quand même moins lisible, surtout pour un exemple de code (Java a le même problème, en effet. Dans ce cas comme dans les autres, ça n'pose pas de problème à partir du moment où l'on utilise des trucs de la bibli de base (Pour Java, les packages java.lang et java.util) et que les noms sont suffisamment représentatifs (les « J » au début de chaque composant Swing aident pas mal ^^), mais dès qu'on commence à utiliser des trucs un peu )

(Ce qu'il manque à Java à ce niveau-là, c'est la possibilité de définir l'espace de nom de façon moins verbeuse, genre « import as ». Si je pouvais appeler les classes « awt.Rectangle » ou « dom.Node », je n'hésiterais pas à le faire).

tshirtman a écrit :

hm, quand je dis bricolage ici, c'est pas au beau sens du terme… moi aussi je pourrait m'y mettre aujourd'hui, sortir un langage de scripting de pages webs dans 3 mois, et je trouverais surement des gens assez fous pour l'utiliser, pourvus que ce soit pas trop difficile a installer, mais si je n'ai rien conçus, juste mis des trucs un peu dans tous les sens pour qu'on puisse faire des trucs avec, les gens qui vont utiliser le truc vont devoir bricoler dès qu'ils vont tomber dans des cas que j'ai pas prévus, et ce sera une horreur, un empilement de hacks fait par des gens qui répondent à leur besoin immédiat, par ce que c'est quand même possible… et dans 10 ans, on a un autre PHP, avec un peu de chance. Mais franchement, non merci, je trouverais un autre moyen de faire mon beurre, et puis, y'a de la concurrence maintenant, beaucoup plus qu'a l'époque ou PHP est sortis.

Yep, c'est surtout le manque de concurrence à l'époque qui a fait le succès encore actuel de PHP. Ça finira probablement par changer un jour, d'ailleurs, mais en attendant, ç'n'est pas en balançant des piques ou en ayant des réactions allergiques comme faisait The Uploader au début de la discussion qu'on va faire évoluer les chose.

tshirtman a écrit :

Libre à toi de penser que pour faire ta cabane dans les bois, un couteau suisse de fête foraine est plus adapté, mais moi, si j'ai une caisse à outil, je vais la prendre, par ce que ce sera quand même plus adapté, même pour un "petit" projet.

Baj j'suis peut-être un cas désespéré, mais les meilleures cabanes que j'me suis faites (meilleurs au sens des plus agréables à utiliser, et peut-être aussi des plus solides), c'était avec des bouts de bois ramassés par terre à côté et un peu de ficelle, rien de plus.

J'ai essayé, plusieurs fois, d'en faire une « sérieusement », en achetant des outils exprès, en faisant des plans à l'avance et tout, mais ça n'a jamais réussi correctement (et ça n'avait pas le même côté fun, surtout).

tshirtman a écrit :

Non oO, en php, la logique, c'est que toute opération doit avoir un résultat, qu'il ait un sens ou non…

Bah, ç't'à peu près ce que j'ai dit, non ?

Tu acceptes tout sans balancer d'erreur, seulement si les paramètres d'entrées n'étaient pas bon, le résultat renvoyé n'est pas celui attendu dans les conditions normales.

HP a écrit :

Il ne m'a pas semblé que la discussion était de définir ce qu'est un « vrai langage »

Bah en l'occurrence, si tu relis la page précédente, The Uploader a énoncé (en réponse à une vidéo postée par kamui57) « PHP n'est pas un vrai langage », tu as répondu « +1 », et moi, j'ai demandé, juste après « C'est quoi, un vrai langage ? » (en en rajoutant un peu juste après, mais c'est comme ça que débute mon post et c'était son objectif principal). C'est de ces trois messages-là qu'est partie la discussion actuelle. Donc si, il me semble que c'était un peu le sujet de base de la discussion…

Elzen · Le 18/05/2012, à 17:15

HP a écrit :

donc, si un bricolage peut être considéré comme étant un « vrai langage »

Bah c'est précisément ce « si » là qui manquait quelque part, tu vois : d'un côté, vous accusez PHP de ne pas être un truc que vous ne définissez pas, et de l'autre, quand on vous demande des précisions, vous n'arrivez à répondre qu'en détaillant « PHP », et absolument pas en définissant « vrai langage ».

Moi, ma position est simple : pour dire que PHP (ou n'importe quoi d'autre) est, ou n'est pas, un « vrai langage », il faut commencer par définir ce qu'est un vrai langage (voire même définir ce qu'est un langage tout court, puis expliciter en quoi ils peuvent être vrais ou faux), puis évaluer si PHP (ou n'importe quoi d'autre) répond, ou ne répond pas, à la définition posée.

Tant qu'il n'y aura aucune de ces deux étapes (la seconde ne pouvant arriver qu'après que la première ait été placée), bah ce genre de pique sera inutile et contre-productive.

Et pour le moment, le seul élément de définition de ce que serait un « vrai langage », c'est grim7reaper qui l'a avancé, et vous n'avez même pas donné votre avis dessus.

Elzen · Le 18/05/2012, à 19:09

Il n'y a pas besoin de définir « mammifère », parce que « mammifère » a déjà une définition clairement posée, unique (il n'y a pas plusieurs acceptations radicalement différentes du mot en fonction du contexte, comme il y a, par exemple, pour « libre ») et que donc, si quelqu'un arrive en disant des trucs qui n'y correspondent pas, il suffit de le renvoyer à n'importe quel bouquin traitant de la question.

Pour langage (et, encore plus, pour vrai langage), ce n'est pas si évident, à moins de se reporter à la définition du dictionnaire (genre ici), à laquelle PHP correspond.

Donc soit vous dites un truc faux, soit vous dites un truc à définir. Moi j'suis gentil avec vous : j'pars du principe que c'est à définir.

Dernière modification par ArkSeth (Le 18/05/2012, à 19:11)

HP · Le 18/05/2012, à 20:05

Bon, on va te faire plaisir, on dira donc que c'est un vrai langage de programmation pourri ; l’aspect pourri ayant suffisamment été défini, prouvé et argumenté.

Elzen · Le 18/05/2012, à 20:11

Ce sera toujours aussi contre-productif (dans le même ordre d'idée que de juste répéter que Windows est pourri n'aide pas à faire adopter GNU/Linux), mais ça aura au moins l'avantage d'être un peu plus recevable, ouais.

sweetly · Le 18/05/2012, à 20:39

ArkSeth a écrit :

Ce sera toujours aussi contre-productif (dans le même ordre d'idée que de juste répéter que Windows est pourri n'aide pas à faire adopter GNU/Linux), mais ça aura au moins l'avantage d'être un peu plus recevable, ouais.

Queued. Il est turing complet. C'est tout. C'est juste un mauvais langage. J'ai jamais dis que c'était un faux langage, pour ma part. Juste qu'il était mauvais. Point. Et dans le cas d'un outil, le vrai et l'utile se rejoignent sans hésitation.

tshirtman · Le 20/05/2012, à 02:42

On peut maintenant utiliser kivy interactivement, du coup j'ai fait une démo vidéo des possibilités de base…

http://www.youtube.com/watch?v=S2sFqFGD … e=youtu.be
(faut le temps que ça process, mais moi dodo maintenant)

Dr Le Rouge · Le 20/05/2012, à 10:44

@ tshirtman : comment tu fais pour avoir des couleurs et une auto-complétion dans ton prompt python ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#776 Le 18/05/2012, à 13:37

Re : /* Topic des codeurs [7] */

#777 Le 18/05/2012, à 13:50

Re : /* Topic des codeurs [7] */

#778 Le 18/05/2012, à 13:52

Re : /* Topic des codeurs [7] */

#779 Le 18/05/2012, à 14:07

Re : /* Topic des codeurs [7] */

#780 Le 18/05/2012, à 14:15

Re : /* Topic des codeurs [7] */

#781 Le 18/05/2012, à 14:32

Re : /* Topic des codeurs [7] */

#782 Le 18/05/2012, à 14:33

Re : /* Topic des codeurs [7] */

#783 Le 18/05/2012, à 14:39

Re : /* Topic des codeurs [7] */

#784 Le 18/05/2012, à 14:46

Re : /* Topic des codeurs [7] */

#785 Le 18/05/2012, à 14:52

Re : /* Topic des codeurs [7] */

#786 Le 18/05/2012, à 14:54

Re : /* Topic des codeurs [7] */

#787 Le 18/05/2012, à 14:57

Re : /* Topic des codeurs [7] */

#788 Le 18/05/2012, à 14:58

Re : /* Topic des codeurs [7] */

#789 Le 18/05/2012, à 15:06

Re : /* Topic des codeurs [7] */

#790 Le 18/05/2012, à 15:08

Re : /* Topic des codeurs [7] */

#791 Le 18/05/2012, à 15:10

Re : /* Topic des codeurs [7] */

#792 Le 18/05/2012, à 15:15

Re : /* Topic des codeurs [7] */

#793 Le 18/05/2012, à 17:04

Re : /* Topic des codeurs [7] */

#794 Le 18/05/2012, à 17:15

Re : /* Topic des codeurs [7] */

#795 Le 18/05/2012, à 19:09

Re : /* Topic des codeurs [7] */

#796 Le 18/05/2012, à 20:05

Re : /* Topic des codeurs [7] */

#797 Le 18/05/2012, à 20:11

Re : /* Topic des codeurs [7] */

#798 Le 18/05/2012, à 20:39

Re : /* Topic des codeurs [7] */

#799 Le 20/05/2012, à 02:42

Re : /* Topic des codeurs [7] */

#800 Le 20/05/2012, à 10:44

Re : /* Topic des codeurs [7] */

Pied de page des forums