Le concept lui-même de faire tourner une appli directement sur l'OS est une daube intellectuelle pour une application serveur.
Je suis une burne infoutue d'exploiter les finesses de fonctionnement d'une machine virtuelle, alors je perds mon temps à bacler des Makefile foireux histoire de compiler un embryon de code impossible à porter. Mais je suis une mûle et toute la communication entre mon programme et moi se résume à "Buffer overflow: core dumped (SIGV 11)" alors: pour les fonctionnalités, je charge la mûle avec toujours plus de bibliothèques nazes parce faisant double emploi avec celles de la première JVM venue et pour les performances, j'ai les boules parce que la vitesse acquise aggrave l'accident quand le programme se vautre. Remarque, on peut inventer un compilateur C capable de générer du byte code interprétable par la machine virtuelle. Pas con! Et hop, j'étais une couille molle génératrice de lenteurs en Java avec ma conception à la Basic, et maintenant je suis une baboule génératrice de lenteurs en C: la boucle est bouclée.
Franchement, le C, son satellite transgénique le C++ et autres COBOL appartiennent au passé et les derniers compétents tu les trouvensdans les bataillons de vieux cons qui sont pas foutus d'évoluer en dehors de leur informatique bancaire sur mainframe et qui cherchent désespérément à se caser sur un marché de l'emploi dynamique et jeune.
En plus, stop les bench débiles qui prétendent la machine virtuelle ralentie l'exécution du byte code. Il est clair que la réutilisabilité du code de la VM elle-même favorise sa stabilité et ses performances. Pourquoi sinon, autant de sociétés sérieuses adopteraient elles cette technologie, seraient tous des nul? Ca m'étonnerait.
Java et .Net provoquent l'une des révolutions conceptuelle les plus importante dans le domaine du développement aujourd'hui et même le secteur du temps réel commence à se pencher sur des solutions de bibliothèques de threads préemptif en Java.
PHP et autres langages de scripting offrent des possibilités intéressantes pour les sites personnels, mais les limites d'un langage intégré aux pages trouve ses limites lorsqu'entrent en jeu des notions de workflow avec des équipes graphistes, techniques et des rédacteurs qui doivent travailler sur le même support final. Difficile d'éviter que l'édition artistique d'une page ne détruise le code préalablement intégré.
[^] # Re: Hum... Voilà un point de vue tranché.
Posté par Anonyme . En réponse à la dépêche Java J2EE vs .Net. Évalué à 0.
Le concept lui-même de faire tourner une appli directement sur l'OS est une daube intellectuelle pour une application serveur.
Je suis une burne infoutue d'exploiter les finesses de fonctionnement d'une machine virtuelle, alors je perds mon temps à bacler des Makefile foireux histoire de compiler un embryon de code impossible à porter. Mais je suis une mûle et toute la communication entre mon programme et moi se résume à "Buffer overflow: core dumped (SIGV 11)" alors: pour les fonctionnalités, je charge la mûle avec toujours plus de bibliothèques nazes parce faisant double emploi avec celles de la première JVM venue et pour les performances, j'ai les boules parce que la vitesse acquise aggrave l'accident quand le programme se vautre. Remarque, on peut inventer un compilateur C capable de générer du byte code interprétable par la machine virtuelle. Pas con! Et hop, j'étais une couille molle génératrice de lenteurs en Java avec ma conception à la Basic, et maintenant je suis une baboule génératrice de lenteurs en C: la boucle est bouclée.
Franchement, le C, son satellite transgénique le C++ et autres COBOL appartiennent au passé et les derniers compétents tu les trouvensdans les bataillons de vieux cons qui sont pas foutus d'évoluer en dehors de leur informatique bancaire sur mainframe et qui cherchent désespérément à se caser sur un marché de l'emploi dynamique et jeune.
En plus, stop les bench débiles qui prétendent la machine virtuelle ralentie l'exécution du byte code. Il est clair que la réutilisabilité du code de la VM elle-même favorise sa stabilité et ses performances. Pourquoi sinon, autant de sociétés sérieuses adopteraient elles cette technologie, seraient tous des nul? Ca m'étonnerait.
Java et .Net provoquent l'une des révolutions conceptuelle les plus importante dans le domaine du développement aujourd'hui et même le secteur du temps réel commence à se pencher sur des solutions de bibliothèques de threads préemptif en Java.
PHP et autres langages de scripting offrent des possibilités intéressantes pour les sites personnels, mais les limites d'un langage intégré aux pages trouve ses limites lorsqu'entrent en jeu des notions de workflow avec des équipes graphistes, techniques et des rédacteurs qui doivent travailler sur le même support final. Difficile d'éviter que l'édition artistique d'une page ne détruise le code préalablement intégré.