Quand je lit des trucs pareils, je me dit que tu connais pas grand choses au langages... Ou alors que tu es un integriste de l'interprete.
et puis quand ça pète, soit ça "plante" (fatal error : ie ça s'exécute même pas), soit ça affiche des warnings (là ça s'exécute mais pas forcément bien) soit ça affiche rien (par défaut, l'utilisateur peut créer ses propres exceptions) et là charge au dev de voir si le soft fait bien ce qui était prévu...
Ok.
En somme, quand ca pete, soit ca fait qq chose, soit ca fait rien?
He be, ca c'est un bel avantage, faut croire que le code interprete qui pete le fait plus proprement que du compile.
Tant tous les cas, ca pete, donc bon, on s'en fout un peu que ca affiche des warnings ou que ca se bourre lamentablement.
L'interprété c'est comme le compilé, ça répond aux mêmes règles de développement ! (je vois pas bien pourquoi ça serait autrement d'ailleurs)
Non, le test du code doit etre bien plus exhaustif, car tu dois toi meme tester ce que le compilo teste.
Bref, oui, on peut avoir la meme qualite de code avec de l'interprete, mais c'est plus dur.
Et encore, faut etre super confiant dans ses tests.
la seule différence, c'est que l'interprété, on a pas à modifier le code en fonction de la plateforme (ou presque)
Ouch. Java, .Net, ca te parle?
Un code, un binaire et ca passe partout (modulo les libs pur MS pour .Net).
Le problemes de portabilite sont strictement les memes (link a lib native ou path pour un fichier).
Et du code portable, ca peut s'ecrire meme en c/c++ (ok, on parlait de code serveur la, donc je sort du sujet un peu).
ni à passer des heures de compilation pour s'apercevoir que l'appli merde
Eclipse fait de la compile a la volee. Le temps de compile de mon projet est donc quasi nul. Tous les interprete n'ayant pas forcement pas de cache de bytecode, je pense meme qu'au final, on perd moins de temps a recompiler sans cesse a l'executio. Dans les 2 cas, on ne le sent pas de toutes facons. : on peut tester les scripts un à un, ce qui améliore considérablement la qualité du travail.
Ca s'appelle un test unitaire, et pour qq1 qui donne des lecons sur la qualite du code, tu devrais savoir que c'est qq chose de tres tres fortement recomande pour tous les projets de toutes facons (et une condition necessaire mais non suffisante pour s'assurer de la qualite du produit).
[^] # Re: d'un autre coté ...
Posté par thedude . En réponse au journal N'installez pas PHP 5.2.7 !. Évalué à 3.
et puis quand ça pète, soit ça "plante" (fatal error : ie ça s'exécute même pas), soit ça affiche des warnings (là ça s'exécute mais pas forcément bien) soit ça affiche rien (par défaut, l'utilisateur peut créer ses propres exceptions) et là charge au dev de voir si le soft fait bien ce qui était prévu...
Ok.
En somme, quand ca pete, soit ca fait qq chose, soit ca fait rien?
He be, ca c'est un bel avantage, faut croire que le code interprete qui pete le fait plus proprement que du compile.
Tant tous les cas, ca pete, donc bon, on s'en fout un peu que ca affiche des warnings ou que ca se bourre lamentablement.
L'interprété c'est comme le compilé, ça répond aux mêmes règles de développement ! (je vois pas bien pourquoi ça serait autrement d'ailleurs)
Non, le test du code doit etre bien plus exhaustif, car tu dois toi meme tester ce que le compilo teste.
Bref, oui, on peut avoir la meme qualite de code avec de l'interprete, mais c'est plus dur.
Et encore, faut etre super confiant dans ses tests.
la seule différence, c'est que l'interprété, on a pas à modifier le code en fonction de la plateforme (ou presque)
Ouch. Java, .Net, ca te parle?
Un code, un binaire et ca passe partout (modulo les libs pur MS pour .Net).
Le problemes de portabilite sont strictement les memes (link a lib native ou path pour un fichier).
Et du code portable, ca peut s'ecrire meme en c/c++ (ok, on parlait de code serveur la, donc je sort du sujet un peu).
ni à passer des heures de compilation pour s'apercevoir que l'appli merde
Eclipse fait de la compile a la volee. Le temps de compile de mon projet est donc quasi nul. Tous les interprete n'ayant pas forcement pas de cache de bytecode, je pense meme qu'au final, on perd moins de temps a recompiler sans cesse a l'executio. Dans les 2 cas, on ne le sent pas de toutes facons.
: on peut tester les scripts un à un, ce qui améliore considérablement la qualité du travail.
Ca s'appelle un test unitaire, et pour qq1 qui donne des lecons sur la qualite du code, tu devrais savoir que c'est qq chose de tres tres fortement recomande pour tous les projets de toutes facons (et une condition necessaire mais non suffisante pour s'assurer de la qualite du produit).