TImaniac a écrit 6420 commentaires

On me souffle à l'oreille que l'erreur est humaine et qu'on est pas des robots.

Et puisque t'as pas l'air d'y croire, je t'ai fait un petit screenshot plus explicite :
http://pascalfresnay.free.fr/pub/website.png

T'es vraiment un boulet.
tu postes des liens wikipedia qui prouve juste que t'y connais rien une fois de plus.
ASP, c'est vieux et révolu. Ta recherche google t'as induis en erreur, et la politique de nommage de Microsoft sans doute également.
dans .NET, la techno web s'appelle ASP.NET et n'a plus rien à voir techniquement avec ASP : http://fr.wikipedia.org/wiki/ASP.NET
T'aurais pris la peine de lire le lien que tu m'a pointé, c'était pourtant précisé à la fin.
Et j'en fais régulièrement au taf, alors t'es gentil tu vas pas me montrer ce que c'est. Et je peux te garantir qu'on écrit du C# pour faire du site web, et que je peux compiler mon bouzin avant de le mettre en prod.

Concernant java, c'est du jsp(/JavaServer_Pages), donc oui, le langage est le même, mais, pour le coup, est interprété...
Mais t'es vraiment trop marrant toi, tu me pointes un lien où c'est écrit noir sur blanc :
Les JSP sont compilées par un compilateur JSP pour devenir des servlets Java.
La référence à l'interprétation concerne le pseudo-code Java, autrement dit, le bytecode. Pour ta connaissance vu que tu n'y connais rien, y'a 2 étages de "traduction" :
fichier.java => compilation avec javac => java.class (bytecode).
Après ce bytecode peut être interprété ou compilé à la volée (technique JIT), la VM de Sun faisant plus ou moins un mix des 2 techniques.
Dans tous les cas le langage écrit par le développeur, c'est le .java, et lui est bel et bien compilé avec toutes les vérifications qui vont avec. Bref, on s'intéresse au premier étage.

m'enfin on conviendra facilement que c'est un peu tuer une mouche à coup de blaster laser
C'est pour ca que personne ne code de site web en C (ou presque), et que je ne comprends même pas pourquoi tu en parles.

Histoire d'être encore plus parlant :
phpnuke => http://www.dotnetnuke.com/
wordpress => http://www.umbraco.org/ http://www.mojoportal.com/
http://en.wikipedia.org/wiki/ASP.NET#Performance

T'es désespérant.
exemples .NET : myspace.com, dell.com, match.com, monster.com
exemples Java : ebay.com, linkedin.com, hi5.com
Comme quoi dis donc c'est fait pour faire des sites web, comme PHP !
Après de là en conclure que t'y connais rien dans ces technos en affirmant que les usages sont diamétralement opposés...

Sauf que la méthode, elle est exécuté par un humain. Et le compilo il est exécuté par une machine. Moi c'est bizzare, j'ai plus confiance dans un compilo que dans la méthode. Pour être sûr, j'utilises les 2, mais il me paraît délirant de faire confiance à la seule méthode.
L'erreur est humaine, t'as oublié ? Ben les bugs aussi dis donc ! Même avec toute la méthodologie du monde !

ou un code (plus ou moins) compilé ?
Faudra que t'écrives un interpréteur un jour, tu comprendras la différence. En gros y'a pas d'étape où tu traduis le code original en code machine : tu exécutes un code (qui est dans l'interpreteur) qui correspond à la sémantique du code original.

justement, c'est là qu'elles doivent apparaître les erreurs,..
tu te fou de moi ? On parlait d'un problème qui arrivait sur un serveur de prod parcque justement passé inaperçu...

Il n'y a pas que Java et C# dans la vie... perso quand je compile ffmpeg, ça prends souvent plus d'une heure...
Rattrapes toi aux branches. On parle de PHP et donc de ce qui est comparable. C# et Java sont 2 langages compilés qui visent (entre autre) le même types d'application web que PHP.
Donc laissons le C et ffmpeg de côté.

Sur la route, parfois il n'y a ni ligne continue au sol, ni flèches indiquant le sens de circulation, ni gendarme : c'est pas pour autant qu'il faut rouler à gauche à tombeau ouvert avec 3g.
Quand t'es pressé, c'est tentant de dépasser les limites de vitesse. Quand ta voiture est bridé, c'est quand même plus difficile.

Tu as aussi le choix d'ignorer les warnings du compilateur et même de ne pas faire de tests unitaires sur ton code compilé... et de balancer en prod...
Tu réponds à côté de la plaque. Je disais justement que l'avantage d'un langage compilé, c'est qu'il y a un "gendarme", dans tous les cas. Ta remarques s'appliques très bien à PHP de la même manière et ne répond pas à ma remarque.

ça appelait une réponse ?
ben je sais pas, t'as l'air de croire qu'il est super facile de tester avec des tests U tout ce que peut vérifier un compilateur...

développer, ça s'improvise pas... (même si on peut improviser) c'est clair que si tu pisses du code, tu va avoir pas mal de travail pour l'auditer alors que si, dès le départ, tu réfléchis à ce que tu fais, que tu découpes ton code en modules fonctionnels, que tu le commentes, etc... il devient plutôt facile de faire quelque chose de très (plus) facilement auditable.
Mais ca n'empêche que le développeur il est pas infaillible, il peut faire une erreur, ou tu peux avoir besoin de faire du refactoring, et étant donné que t'as pas une couverture à 100% de ton code en test U, tu peux laisser une erreur ou 2 par ci par là, bref, tu peux faire tous les audits que tu veux, ca remplacera jamais ton compilateur qui comme dirait vient comme une sécurité "gratuite" supplémentaire. Continuer à prétendre que cette sécurité gratuite est totalement remplacable par des méthodes (audit, testU & co) est vraiment malhonnête quand tout le monde sait que les 2 sont complémentaires et non redondant.

si je pisse du code oui, c'est certain, mais c'est pareil avec un langage compilé...
Raaaah mais le compilo il va quand même éviter un certain nombre de conneries !
a = null
a.test()
moi mon compilo il va direct gueuler. Toi tu vas devoir écrire un test U pour ca, tu vas devoir faire un audit, sans aucune garantie au passage que tu vas effectivement tester ce cas. Quel est le plus coûteux ?

Le compilo c'est un automate, relativement fiable, qui coûte quasiment rien, pourquoi s'en passer je te le demande ?

Enfin, encore une fois, je ne m'amuse pas à faire de la compression vidéo en php, et je ne m'amuse pas à faire un forum en C#... ça n'est pas vraiment comparable
Tu avoues ton ignorance total de C# : c'est un langage qui dès le début à été conçu pour être entre utilisé pour réaliser des applis web dynamique, et qui est utilisé pour dans la réalité.

Envoyez des sioux. A l'ARC.

De plus, comme je le disais plus haut (ou ailleurs je sais plus) : c'est compilé, si non comment l'exécuter ?
En l'interprétant ! C'est la 2ème façon d'exécuter du code dis donc :)

our php, par exemple, au pire t'auras un warning, dans python t'auras un beau message d'erreur de compilation... ah... comme avec un "vrai" compilateur dis donc ! c'est fou quand même !
Oué bah je préfères avoir l'erreur sur un poste de développeur ou un serveur de build.

sauf qu'il n'y a *jamais* besoin de toucher au code pour prendre en charge telle ou telle archi.
Comme .NET et Java, qui sont compilés et font abstraction de l'architecture matérielle/OS sous jacent.

et, oui : java, .Net (beurk), etc. ça me parle...
On dirait pas puisque tu comprends pas.

Tout le monde n'utilise/ne peut pas utiliser Eclipse...
Ceux qui font du Java utilise Eclipse, ceux qui font du C# utilisent Visual, dans tous les cas le temps de compilation est anecdotique, donc le temps de compilation n'est PAS un problème.

PHP saimal parce que c'est permissif et que l'interprété saipareil parce que c'est pas compilé
C'est pas tout à fait exact. Ce qu'il faudrait plutôt dire : les langages dynamiques à la sémantique laxistes saimal. Après le fait est que ces langages sont généralement non compilés car non compilable.
On est pas du tout d'accord. On peut tout à fait produire du code de qualité en PHP. Seulement le coût est bien plus important qu'avec un langage à la sémantique plus strict, au typage statique, avec vérifications de tout ca à la compilation.
Après dire que beaucoup de développeurs professionnels sont contraints de faire un choix entre "temps" et "qualité", il n'y a qu'un pas... L'avantage du langage compilé avec typage statique et strict, c'est que c'est un passage obligé avant la mise en prod, alors qu'en PHP t'as toujours le choix de pas faire suffisament de tests...

Sérieusement t'as déjà fait des stats de couverture de code de tests U ? T'as déjà obtenu plus de 90% de code ? Le boulot pour arriver à une telle couverture de code est énorme, quelque part tu avoues qu'une partie du code n'est pas testé, alors t'imagine sans langage typé statiquement et vérifié par un compilo les dégâts potentiels...

Une grosse différence, c'est que le cloudcomputing a un modèle commercial derrière :)
Sinon à mon avis faut qu'on lutte contre tout ca, parcque ca va centraliser le contrôle de l'information sur quelques acteurs du marché, et ca c'est dangeureux.

Oué c'est du cloudcomputing quoi. Donc si je comprends bien Google est en retard là dessus ? Bon bah va falloir qu'ils se bougent le cul :)

Si Google sort un OS, c'est pour faire du CloudComputing : un OS pas pour la machine de monsieur tout le monde, mais un OS pour abstraire les ressources matériels de ses datacenters.
Bref ils ont déjà sûrement plus ou moins ca en interne, on voit seulement les applis pour le moment, c'est pas encore ouvert sur l'extérieur mais ca va sûrement pas tarder, surtout que Amazon le fait déjà, Microsoft a annoncé la même chose avec tambour et trompette, IBM planche sur le sujet, bref c'est tout vu.
Par contre je penses pas qu'on va voir quelque chose qui ressemble à un OS côté client : leur intérêt est juste d'exploiter à fond le naviguateur qui reste le dénominateur commun de tous les périphériques et sert donc de "client" idéal pour leurs applis.
Après leur truc NativeClient, je vois pas très bien l'intérêt, c'est quand même très fortement couplé à un type particulier de machine (x86), et au final ca revient à sandboxer un ActiveX.
A moins que leur idée ce soit de faire du cloudcomputing en se servant de l'univers comme datacenter :-D

- un langage interprété va être, de toute manières, compilé avant exécution
Alors je vais moi aussi jouer sur les mots, ton postulat est faux.
Un langage interprété n'est pas compilé.
http://fr.wikipedia.org/wiki/Interpr%C3%A8te_(informatique)
Il y a bien au final exécution de code machine, mais le processus n'est pas le même, et les opérations de compilation et interprétation désigne bien 2 processus différents pour arriver au même résultat.

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é
Ce qu'à juste voulu dire le monsieur, c'est qu'un compilo effectue un grand nombre de vérification qu'il est irréaliste d'effectuer avec des tests unitaires. Donc si tu prends 2 programmes écrits dans 2 langages "proches" (voir identique) dont l'un est interprété et l'autre compilé, avec le même niveau de couverture de code niveau tests U, celui qui est compilé reste plus "sûr".

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.
N'importe quoi. C'est pas plus ou moins efficace. C'est complémentaire. Et les avantages des 2 s'additionnent. Se passer de l'un des 2 va forcement avoir des implications.

moué, évidemment qu'un compilo ne protège pas dans l'absolu des failles de sécurités et des problèmes.
Cela dit c'est un outil qui permet d'éviter un grand nombre de problème, c'est un outil comme un autre qui aide à l'amélioration de la qualité d'un soft.
Evidemment qu'il n'est pas une garantie, qu'on peut coder crade avec un compilo et coder propre avec un interpréteur, mais le compilo reste tout de même un garde fou qui participe à la qualité du code produit.
La grammaire et la sémantique d'un langage va souvent de pair et constitue également un autre élément aidant à produire du code de meilleur qualité (là encore y'a pas de garantie).

les langages interpretés en règlent certains mais en apportent d'autres.
M'étonnerait que ca apporte des merdes niveau qualité du code pondu, ce dont on parle.

T'es sérieux là ? comment il va s'exécuter ton code s'il est pas compilé ? :)
Je penses qu'il parlait de compilation "statique", tu sais quand ca pète sur le poste du dev plutôt que sur le serveur de prod.

Et pourquoi en python on ne pourrait pas réindenter avec un éditeur comme c'est fait pour c, java, etc ?
Parcqu'en C, java & co l'éditeur peut se baser justement sur les {} pour faire l'indentation, en Python, y'a aucun indice pour lui dire comment indenter au risque de péter la sémantique...

Le risque est ailleur et ne se trouve pas au niveau de l'utilisateur final (qui aura toujours autant de risque à confier ses données à un tiers, mais ca c'est déjà le cas avec le web 2.0) mais se trouve au niveau du client du nuage : il devient fortement dépendant d'une plateforme, surtout qu'à l'heure d'aujourd'hui c'est essentiellement proprio.
Bref le libre a intérêt à réagir rapidement pour proposer une alternative pour les fournisseurs de services.
Evidemment ca n'empêche pas de faire du lobbying en // pour que les gens arrête de mettre leurs données partout (mais là c'est plus de la lutte contre le web 2.0 que contre le cloud computing en soit).

Bref le cloud computing en lui même n'a quasiment aucun intérêt pour l'utilisateur final
Evidemment puisque c'est un service de bas niveau pour d'autres fournisseurs de services.

il me semble que c'est bien le but à peine caché pour dynamiser encore plus les publicités sur le web sous prétexte d'innovation
Ca ca dépend uniquement de celui qui fourni les services à l'utilisateur final. Que celui-ci utilises une plateforme de Cloud computing comme support pour son application, ca n'a pas grand chose à voir avec la choucroute.

Bah imagines que tu veuilles faire une application qui "risque" de consommer des ressources, style une appli qui fait du calcul intensif ou plus bêtement un un portail web communautaire 2.0 qui gère beaucoup de données/utiliateurs. Tu vas te poser la question des ressources matériels : nombre de serveurs, bande passante, base de données, toussa. Tu vas également devoir te préocuper de configurer tout le bouzin (os, bdd)
Ben une plateforme de cloud computing te propose de faire abstraction de ces problèmes et de les déléguer à un fournisseur de services qui va héberger pour toi tes applis. Tu vas payer en fonction de la consommation réelle de ton appli et le fournisseur va se démerder pour que son datacenter derrière suive à tous les niveaux : os, bdd, serveurs, bande passante, etc.
L'intérêt côté client, c'est de ne pas se préocuper de ces problématiques de ressources et de ne payer que ce qui est réellement utilisé. Côté fournisseur, l'intérêt est de mutualiser les ressources entre tous les clients pour mieux gérer/répartir la charge.

Oué bah justement, je vois absolument pas le rapport d'un point de vu services rendus, tu peux élaborer ?

Euh, c'est quoi le rapport entre héberger des données chez soit et proposer une plateforme de Cloud Computing ?

Dans ce cas là, un routeur c'est pareil, t'as une interface (les prises ethernet) et voilà... ou même un lecteur dvd (prise peritel).
Tout à fait ! Et ca te viendrait pas à l'idée de venir demander à Free les sources des routeurs qui se trouvent dans leurs locaux, et qui pourtant routent TES paquets.

Surtout que c'est quand même ce qui caractérise un plugin d'une bibliothèque classique...

Oué bref, même s'ils ne font que du routage, ca change rien, le fait est que la box à des interfaces externes (ethernet, téléphonie analogique, péritel vidéo, etc.) qui te permettent d'accéder à des services (fournitures de contenus vidéo, routage de paquets, etc.)
Bref, c'est comme un serveur distant qui a aussi des interfaces et te fourni des services par ce biais.

Oué bah l'amendement est passé à la poubelle. prochaine étape : sa réintégration lors de la prochaine session parlementaire sur le texte.