[F] high-tech » PHP et autres langages - Page 2

(itoo, d'autant que les 3~4 fois où j'ai voulu foutre du python, meêm hello world ne marchait pas)

T'as pas du chercher bien longtemps alors de façon très originale un Hello World en Python ça donne ça :
print "Hello, World!"
(mais je parlais de sh en fait)

bah c'est un langage de script comme un autre, et niveau syntaxe il est ... particulier

Non, ce n'est pas un langage "comme un autre". Chaque langage a ses forces et ses faiblesses. Sa sémantique, ses abstractions, ses concepts, son environement, ses outils.

À partir du moment où tu dis "je peux faire la même chose donc c'est un langage comme un autre", c'est que tu n'as pas compris ce qu'est un langage de développement. À partir de là, finalement le brainfuck, l'assembleur, le C, le Prolog ou LISP sont des langages équivalents. Après tout, on peut faire la même chose avec.

Zeph (./32) :
T'as pas du chercher bien longtemps alors de façon très originale un Hello World en Python ça donne ça :
print "Hello, World!"
(mais je parlais de sh en fait)

c'est bien ce que je disais : ça ne marche pas. python plante quand on lui file un script aussi simple que ça...

je n'ai pas dis le contraire, mais ici on parle de langage de script, ce qu'il est, et j'estime personnellement que sa syntaxe est très particulière au premier abord

il à beau être dédié à scripter des commandes shell, il est loin d’être ouvert et permissif, il faut le connaitre sur le bout des doigts, bref à chaque fois pour faire 2 conneries je passe 90% du temps sur google ou des tuto sh, et par dessus le marché le report des erreurs est en bois d'ours

serieux :

if [ -d "/var/www" ]
then
    echo "le répertoire existe"
fi

est ok

if [ -d "/var/www" ]; then
    echo "le répertoire existe"
fi

est ok

if [ -d "/var/www" ] then
    echo "le répertoire existe"
fi

./test.sh: ligne5: Erreur de syntaxe près du symbole inattendu « fi » ./test.sh: ligne5: `fi'

wtf ?!

à chaque fois je persévère mais limite j'ai envis de tout jeter ... je perd du temps pour rien.

vince (./35) :
c'est bien ce que je disais : ça ne marche pas. python plante quand on lui file un script aussi simple que ça...

Je crois surtout que tu as téléchargé un virus au lieu de python



./36 : bah tu écris n'importe quoi et le parseur est perdu, c'est à peu près ce que fait chaque langage du monde non ? il y en a qui produisent des messages plus ou moins explicites, dans le cas de sh ou de php c'est assez pourri, dans le cas de perl c'est généralement bien plus verbeux, mais dans tous les cas ça ne pouvait pas faire autre chose que balancer une erreur...

vouloir mettre le then sur la même ligne que le if et sans les séparer par un ; est la première chose qui me viendrais à l'esprit, qu'importe le langage

Les trois quart des langages existants t'imposent de mettre une parenthèse ouvrante après le "if", et pourtant ça ne sert à rien non plus (d'ailleurs sh, python et d'autres n'en ont pas besoin). Pourtant si tu ne la mets pas, ça ne compilera pas.

La justification dans ce cas, c'est que le "if" doit être suivi d'une commande, et que cette commande peut être suivie d'un nombre quelconque d'arguments, comme n'importe quelle commande shell. Il faut bien un moyen de savoir où elle s'arrête, et le "then" n'est pas suffisant puisque tu pourrais très bien vouloir passer le mot "then" en paramètre à une commande, donc il faut un autre séparateur. Tu as le choix, c'est soit un retour à la ligne soit un ";", mais "rien" c'est syntaxiquement pas possible (ou alors ça introduirait une incohérente dans la syntaxe).

Zeph (./37) :
Je crois surtout que tu as téléchargé un virus au lieu de python

aptitude sous debian doit être un virus

(je déconne hein, j'imagine qu'il s'agit d'un conflit avec un autre paquet déjà installé ou encore une lib manquante toussa...)

Tu veux parier combien de bouteilles de coca ?

cross edit

Mouais, #branche#

robinHood (./36) :
if [ -d "/var/www" ] then echo "le répertoire existe" fi

Pour expliciter ce que dit Zeph : si l'interpéteur voit ça :
if test -d /var/www then
Il suppose, de manière tout ce qu'il y a de plus logique, que tu souhaites appeler la commande "test", avec les 3 paramètres "-d", "/var/www" et "then".
C'est une simple question de cohérence.

En passant, le caractère [ n'est pas un élément de la syntaxe du shell, mais le nom d'une commande, /usr/bin/[ qui renvoie 0 ou 1 selon le résultat d'un test sur ses arguments. Cette commande reconnaît "]" comme un paramêtre, ce qui permet au "if [ -z blablabla ]" de fonctionner.
Il n'y a absolument pas de difference du point de vue du shell entre "if [", "if /usr/bin/[", "if test" ou "if grep"

D'ailleurs, si tu trouves ça confusant, tu peux utiliser systématiquement le nom complet de la commande : test au lieu de [.
if test -d /var/www; then echo toto; fi
(pour être complet, il faut préciser que la commande [ est implémentée comme builtin par certains shells, dont bash, pour des raisons de performances)

vu comme ca c'est bien plus logique merci :- )

j'avoue que j'ai lu les tutos en diagonale mais je suis jamais tombé sur ces explications

Pour l'exemple que tu donnes, l'erreur n'est trouvée que ligne 5 parce que :
=> le then n'est pas détecté ligne 1 (considéré comme un paramêtre à la commande [
=> il est autorisé d'avoir une commande composée dans le if
=> c'est donc en voyant le fi qu'il se dit qu'il manque quelque chose.

bizarre parce queif commande 1 commande 2; commande 3; then echo truc; fiPour les commandes composées dans le if ça peut paraître ...n'a pas grand intérêt. Ça fait ce à quoi on s'attend, c'est à dire
=> exécuter commande 1; commande 2; commande 3
=> le résultat est donc celui de commande 3
=> exécuter le echo si le résultat du if est vrai (donc si commande3 est vraie)

Alors pourquoi autoriser les commandes composées ? Pour deux raisons :
=> Parce que au delà du ; on peut aussi composer les commandes avec && et ||, et là ça devient utile
=> Parce qu'il est dit qu'une commande composée est équivalente à une commande simple. Donc pour être cohérent, quand on accepte l'un il faut accepter l'autre.

Pour l'anecdote, on peut vraiment mettre n'importe quelle commande derrière un if. Exemple de truc inutile et très moche :

if test -d / &&
    while echo foo; test -d /; date +%S | grep -v 0$ >/dev/null
    do sleep 1
    done && test -d /
then echo toto
fi

Au final, je ne vois toujours pas l'intérêt du PHP par rapport à Python ou Ruby

vince (./35) :

Zeph (./32) :
T'as pas du chercher bien longtemps alors de façon très originale un Hello World en Python ça donne ça :
print "Hello, World!"
(mais je parlais de sh en fait)

c'est bien ce que je disais : ça ne marche pas. python plante quand on lui file un script aussi simple que ça...

Je suis curieux de voir ce que tu as fait avec ^^

./46 assez louche à lire mais intéressant en terme de possibilités il faut l'avouer

flanker (./47) :
Au final, je ne vois toujours pas l'intérêt du PHP par rapport à Python ou Ruby

vince (./35) :

Zeph (./32) :
T'as pas du chercher bien longtemps alors de façon très originale un Hello World en Python ça donne ça :
print "Hello, World!"
(mais je parlais de sh en fait)

c'est bien ce que je disais : ça ne marche pas. python plante quand on lui file un script aussi simple que ça...

Je suis curieux de voir ce que tu as fait avec ^^

Comme je le disais à zeph, j'ai testé un purge puis un install, il a foutu un composant qu'il n'avait pas désinstallé et ça a l'air de marcher (le hello world en tous cas)

J'ai une petite question. Je voualis tester 2 fonctions différents, et je trouvais les différences de vitesse étranges, donc j'ai testé ceci : $ids = array( ); $ids2 = array( ); $comments = $this->self_get("/comment/$userId/forUser"); reset($comments); $t2 = microtime(true); foreach ( $comments as $comment) { $ids2[] = $comment['id']; } $t2 = (microtime(true) - $t2) * 1000; reset($comments); $t = microtime(true); foreach ( $comments as $comment) { $ids[] = $comment['id']; } $t = (microtime(true) - $t) * 1000; reset($comments); return $t . ' --------------- ' . $t2;

Et quoi qu'il arrive, la fonction qui passe en second ($t ici) sera toujours plus rapide(en général au moins 2 fois), et j'avoue que je ne comprend pas pourquoi. J'ai mit ici car je faisais du PHP, mais peut-être est-ce juste une question de code.

Les deux sections de code étant rigoureusement identiques, il y a peut-être une construction d'index du tableau, ou je ne sais quel mécanisme de cache qui est effectué au moment où il y en a besoin la première fois, ça pourrait expliquer pourquoi le deuxième parcours qui en bénéficie est plus rapide que le premier. Chez moi la différence est assez minime en tout cas.

Par contre c'est un problème 100% PHP et ça aurait plus sa place dans le forum informatique, "j'ai rien à dire" n'est franchement pas la catégorie idéale

Mais en définitive, le langage PHP est-il pleinement fonctionnel (et complexe dans sa diversité) ou simplement mauvais ? en somme, l'usage d'un framework (j'ai fait un peu de PRADO, maintenant sous CakePHP) qui ne fait qu'exploiter PHP pour en rendre les tâches de développement avec ce langage plus simple est-il une bonne solution ou faut-il vraiment oublier PHP (et par ricochet, ses frameworks) et partir plutôt sur un langage comme Python ou Rails ?

Je ne comprends pas la question, que veux-tu savoir exactement ? S'il "faut" abandonner PHP parcequ'il n'est pas "assez bien" ? Ça dépend, quelles sont les raisons qui te feraient rester ou changer d'environnement, quelles sont tes contraintes, de quoi tu as besoin ? Techniquement, c'est un outil qui fonctionne et qui fait le boulot qu'on lui demande, il y a suffisamment de sites qui l'utilisent pour ne pas avoir trop de doutes à ce niveau. Il y a bien des reproches qu'on peut lui faire, que ce soit au niveau de sa conception, de ses limitations ou de ses performances (c'est très subjectif, mais disons que beaucoup de monde s'accorde à dire que PHP c'est quand même particulièrement mal foutu), mais s'il te convient pour ce que tu veux faire, que recherches-tu d'autre ?

Meow > Concrètement, le PHP souffre globalement (et sans troller) des mêmes problèmes de base que le C/C++ : ce sont deux langages qui ont été radicalement transformés entre leur première version et les versions actuelles. Contrairement au Java ou ("mieux" encore, en terme de réflexion initiale sur le langage) à la technologie .NET, qui ont été pensés dans une direction donnée et s'y sont maintenus, le PHP et le C sont des langages qu'on a voulu faire évoluer au maximum tout en les laissant au plus compatibles avec les versions précédentes. On a donc des technologies assez bâtardes, mais qui permettent de faire plein de choses à plein de niveaux (bon, avec le C, on a quand même des éléments structurants qu'on n'a pas en PHP, donc ça reste quand même un peu plus compliqué à appréhender que le PHP, sans compter tout ce qui est accès mémoire, typage, etc.).

en gros tu reproches l'arrivée de la refonte "objet" de php au lieu d'avoir scindé php / php++ ?

Je ne le lui reproche pas, ça a des côtés très pratiques quand on fait du dev Rache compliant. Mais parfois c'est à se tirer une balle (quand des méthodes impératives passent au format objet de façon un peu bizarre, par exemple).

Je comprends néanmoins les prises de tête quand un collègue dit à un autre d'utiliser strpos pour vérifier si un mot existe dans une phrase, et qu'à vérifier la fonction sur la doc il y a une fonction "strripos" pour exactement la même tâche, mais en version case-insensitive. Réécrire strpos avec un paramètre optionnel pour la gestion du case n'aurait pas été préférable ?

C'est ce qu'on (ici) appelle le dév golgotha : on empile des petites merdes patch par patch pour au final obtenir un truc monstrueux mais qui se tient à peu près... l'éternel dilemne apporté par la rétrocompatibilité...

Mais ici, il ne s'agit même pas d'un besoin de rétrocompatibilité : la fonction explode par exemple s'est vu ajoutée un paramètre optionnel en 4.0.1, et ce paramètre accepte les négatifs en 5.1.0. D'une part, on a pu ajouter un paramètre en cours de route, d'autre part on a pu changer la portée de ce paramètre, et de revoir mon exemple ci-dessus sur une fonction supplémentaire qui aurait pu simplement être évitée en surchargeant sa grande sœur. PHP a un grand nombre de fonctions quasi-jumelles comme celle-ci, pourquoi ce genre de réflexion dès l'intégration de ces nouvelles fonctions ?

+ pas, j'imagine ? parceque les développeurs de PHP sont de gros noeuds, je ne vois vraiment pas d'autre explication possible