J'ajoute simplement qu'apparemment, pour celui qui a parlé de cette différence entre compilé et interprété, lorsqu'on dev en un langage interprété, on met forcément n'importe quoi en prod, et, qu'en plus, le fait qu'il y ait pas de compilation (qui est évidement faux) devait générer des problèmes (et des sueurs froides aux dev)
Je rectifiait simplement ces postulats, tous évidement faux... soit :
- un langage interprété va être, de toute manières, compilé avant exécution
- on ne balance pas n'imp sur un serveur de prod, de la même manière qu'on n'envoie pas un soft qui a seulement été compilé (et pas testé, et dont les retours du compilo n'ont pas été analysés) au client
- qu'on dispose de pas mal d'outils d'audit de code qui sont plus efficaces qu'une sortie de compilo combinée à des heures d'arrachage de tifs pour comprendre où optimiser le code et comment.
Je n'ai *pas* dit que :
- ça protégeait d'une quelconque faille : c'est logique
- ça permettait d'avoir *forcément* un meilleur code : là encore, c'est logique
Après, c'est certain, tout dépend du gus qui code : on peut tout faire, tout voir....
[^] # Re: d'un autre coté ...
Posté par jeffcom . En réponse au journal N'installez pas PHP 5.2.7 !. Évalué à 2.
Je rectifiait simplement ces postulats, tous évidement faux... soit :
- un langage interprété va être, de toute manières, compilé avant exécution
- on ne balance pas n'imp sur un serveur de prod, de la même manière qu'on n'envoie pas un soft qui a seulement été compilé (et pas testé, et dont les retours du compilo n'ont pas été analysés) au client
- qu'on dispose de pas mal d'outils d'audit de code qui sont plus efficaces qu'une sortie de compilo combinée à des heures d'arrachage de tifs pour comprendre où optimiser le code et comment.
Je n'ai *pas* dit que :
- ça protégeait d'une quelconque faille : c'est logique
- ça permettait d'avoir *forcément* un meilleur code : là encore, c'est logique
Après, c'est certain, tout dépend du gus qui code : on peut tout faire, tout voir....