[Masklinn]

Citation :

Provient du message de XhaK
je ne pense pas qu'on parle de langages open sources ... mais de langages standardisés
C et C++ sont standardisés car n'importe qui peut consulter la norme ANSI/OSI/autre de leur définition.

Je dirais que la standardisation est encore un autre niveau
Dans un langage Open Source, n'importe quel utilisateur peut creer et ajouter (ou tenter de faire ajouter par le "comite executif") de nouvelles fonctions, ou de nouveaux types de donnees (ce qui n'est bien sur possible que pour des langages de suffisament haut niveau), et tous les outils "de base" sont open source. enfin c'est comme ca que je le vois

Citation :

serait il possible de faire un processeur qui comprenne directement le byte code ?

Je ne pense pas, d'apres le peu que j'en sais un bytecode de langage interprete reste quelque chose de complexe, incompatible avec les fonctions de base beaucoup plus simples qu'on cable dans un proc, qu'il soit RISC ou CISC

[Eowin Da Evil]

Citation :

Provient du message de Masklinn
Je dirais que la standardisation est encore un autre niveau
Dans un langage Open Source, n'importe quel utilisateur peut creer et ajouter (ou tenter de faire ajouter par le "comite executif") de nouvelles fonctions, ou de nouveaux types de donnees (ce qui n'est bien sur possible que pour des langages de suffisament haut niveau), et tous les outils "de base" sont open source. enfin c'est comme ca que je le vois

humm... là je crois plutot que tu parles des librairies standards ( ou pas ! ) qui vont avec le langage, non ?

[Jade Ylis]

Citation :

Provient du message de XhaK
serait il possible de faire un processeur qui comprenne directement le byte code ?

C'était dans les projets de Sun au lancement de Java : faire une machine avec un proc qui exécute directement le byte-code, avec un OS full Java.

Citation :

Provient du message de Masklinn
Question a 2 francs: as tu comparé des programmes java avec des programmes equivalents dans d'autres langages interprétés et comparé les lourdeurs (en termes de ressources machines) des différents interpréteurs à l'exécution?

Oui, et ? Il y a des applications pour lesquelles il n'y a pas besoin de chercher gagner le moindre cycle d'horloge ou le moindre octet. J'estime gagner en confort de développement et en structuration ce que je perds en performances pures dans le cadre du dev perso. Et dans un cadre professionnel, on n'est pas forcément maître de la plateforme ou de l'environnement pour lequel on développe

Je ne nie pas que Java soit gourmand en ressources, ou qu'il ait des performances inférieures à d'autres langages pour des problématiques particulières. Je dis juste que JE ne le trouve pas lourd, et que JE pense qu'il apporte une certaine robustesse dans les développements sans pour autant demander des machines impossibles pour le faire tourner dans des conditions raisonnables, et que JE pense également que c'est un langage qui dispose d'un spectre d'utilisations assez étendu pour valoir le coup.

Ca n'est qu'un avis perso, et je ne cherche à convaincre personne

Citation :

Provient du message de Masklinn

Je n'en ai retenu qu'un, car tu me l'as imposé

et la semi-compilation est une notion un peu étrange, à la limite parler d'optimisation ou de pré-compilation (qui est également inexact, en fait il vaudrait mieux parler de pré-interprétation) pour désigner la génération des Bytecodes OK, mais semi-compilation je trouve personnellement que ca n'a pas réellement de sens

Moi y en a pas avoir compris ce que j'ai imposé

Quant à la semi-compilation, c'est sous ce terme là que l'on m'a appris ce type de langage, comportant 2 phases, une phase de transformation du source en pseudo-code, puis interprétation du pseudo-code. La théorie veut que ce type de langages permettent un portage plus facile vers différentes plate-formes, dans la mesure où seule la machine virtuelle est propre à la plate-forme et nécessite un nouveau développement. Dans la pratique, les performances brutes de ce type de langage sont inférieures à celles des langages compilés. Par exemple, le Pascal était un langage semi-compilé tel que définit par Niklaus Wirth, mais n'a commencé à rencontrer un succès - du moins en France - auprès des développeurs qu'à partir du moment où Borland a fourni un véritable compilateur et s'est donc passé de l'utilisation d'une machine virtuelle. De la même façon, Java est moins performant que C++ pour faire de la prog système ou PHP pour faire du Web (encore que pour PHP, y a bataille à mon avis ).

[Masklinn]

Citation :

Provient du message de Jade Ylis
Oui, et ? Il y a des applications pour lesquelles il n'y a pas besoin de chercher gagner le moindre cycle d'horloge ou le moindre octet. J'estime gagner en confort de développement et en structuration ce que je perds en performances pures dans le cadre du dev perso. Et dans un cadre professionnel, on n'est pas forcément maître de la plateforme ou de l'environnement pour lequel on développe

Raison pour laquelle j'ai parlé de comparaison avec d'autres langages interprétés, censés être de niveau équivalent et donc de "confort" équivalent en terme d'éloignement de la machine et de clarté du code

Citation :

Moi y en a pas avoir compris ce que j'ai imposé

Lis mon quote initial, tu réfutes l'utilisation du mot "interprété" et dit que pour toi il est "semi-compilé", tu n'as pas fait coexister les 2 termes, tu as donné un qualificatif unique au langage, j'ai fait de meme

Citation :

De la même façon, Java est moins performant que C++ pour faire de la prog système

On parle aussi de niveaux de langage
De même, théoriquement, coder en ASM pur est plus performant que de coder en C/C++...
si on arrive a faire un programme qui fonctionne de plus de 500 lignes


Pour ceux qui n'ont pas suivi: plus le niveau du langage monte plus il s'éloigne de la machine et plus il est facile de transcrire ses idées en code simple, mais moins le langage lui même est efficace
.
On parle de langage de haut ou bas niveau pour les comparer, le langage de plus bas niveau possible est le langage machine (donc l'assembleur en langage codable), le langage de plus haut niveau serait un langage humain "réel"

Citation :

PHP pour faire du Web (encore que pour PHP, y a bataille à mon avis ).

Surement parce que le PHP est un langage interprété au même titre que le Java, le Perl ou le Python

[Jade Ylis]

Citation :

Provient du message de Masklinn
Raison pour laquelle j'ai parlé de comparaison avec d'autres langages interprétés, censés être de niveau équivalent et donc de "confort" équivalent en terme d'éloignement de la machine et de clarté du code

Java présente à mes yeux des caractéristiques que n'ont pas ou plutôt que n'avaient pas ( ), ces langages interprétés : objets et typage fort notamment. En plus du fait d'être semi-compilé alors que certains de ces autres langages étaient interprétés. Depuis, les choses ont évolué, ces langages ont intégré des notions objet et font de plus en plus appel à une pré-compilation "cachée"

Tu vas me dire que je t'ennuie toujours avec ma notion de pré-compilation Et oui... parce que pour moi, sur un projet conséquent, une pré-compilation que l'on effectue de manière explicite présente l'avantage de faire une première vérification syntaxique du code Cela n'est certes pas une garantie de bon fonctionnement, je te l'accorde

Citation :

Provient du message de Masklinn
Lis mon quote initial, tu réfutes l'utilisation du mot "interprété" et dit que pour toi il est "semi-compilé", tu n'as pas fait coexister les 2 termes, tu as donné un qualificatif unique au langage, j'ai fait de meme

Parce que pour cette forme de langage, le terme semi-compilé est plus usité que celui de semi-interprété Peut-être parce que la phase de compilation en p-code était plus "visible" que la phase d'interprétation (du moins pour Pascal ou Java). Actuellement pour PHP 4 par exemple, il faudrait sans doute parler de langage semi-interprété (pas de compilation explicite, mais gestion par le moteur PHP de p-code permettant de ne pas faire une analyse syntaxique de chaque fichier à chaque utilisation).

[Masklinn]

Citation :

Provient du message de Jade Ylis
Tu vas me dire que je t'ennuie toujours avec ma notion de pré-compilation Et oui... parce que pour moi, sur un projet conséquent, une pré-compilation que l'on effectue de manière explicite présente l'avantage de faire une première vérification syntaxique du code Cela n'est certes pas une garantie de bon fonctionnement, je te l'accorde

?
La génération du bytecode en python est implicite et provoque quand meme une vérification syntaxique du code

Citation :

Parce que pour cette forme de langage, le terme semi-compilé est plus usité que celui de semi-interprété

La semi-interprétation n'existe pas, on est interprété ou on l'est pas, le Java est interprété, le C ne l'est pas point final

Citation :

Peut-être parce que la phase de compilation en p-code était plus "visible" que la phase d'interprétation (du moins pour Pascal ou Java).

Le propre d'une phrase d'interprétation est d'être la moins visible possible et de tourner en tâche de fond, non?
En plus on ne peut pas dire que celle du java soit peu visible

Citation :

Actuellement pour PHP 4 par exemple, il faudrait sans doute parler de langage semi-interprété (pas de compilation explicite, mais gestion par le moteur PHP de p-code permettant de ne pas faire une analyse syntaxique de chaque fichier à chaque utilisation).

Non, le PHP st un langage interprété, qu'ait lieu une génération de Bytecode (qui a lieu pour la quasi totalité des langages interprétés récents en vue de se rapprocher des performances des langages compilés tout en restant interprétés) n'y change rien, car ce bytecode est incapable de faire quoi que ce soit par lui même, il faut le faire passer par l'interpréteur de bytecode PHP

[Jade Ylis]

Citation :

Provient du message de Masklinn
?
La génération du bytecode en python est implicite et provoque quand meme une vérification syntaxique du code

Je me suis mal exprimé : la phase de compilation explicite permet une vérification rapide et directe de la syntaxe, sans avoir à exécuter l'ensemble du code pour effectuer une compilation implicite.

Pour le reste, dans la mesure où nous campons tous les deux sur nos positions, je pense que le débat est clos En tout cas en ce qui me concerne.

Pour qui n'a qu'un marteau, tous les problèmes ressemblent à des clous.

[Eldarendil]

Citation :

posté par Elrick de Marly
Je me permet juste d'ajouter qu'il faut bien faire attention a la différence entre Open Source et FreeSoftware

ce sont deux chose totalement différentes

opensource veut juste dire qu'on te donne les source avec mais tu peut payer pour ça

alors que freesoftware ...

Les freesoftwares aussi peuvent parfaitement être payants...

Citation :

posté par Jade Ylis
De la même façon, Java est moins performant que C++ pour faire de la prog système ou PHP pour faire du Web

C'est un des problèmes de java
Il permet de tout faire, mais dans chaque domaine il se fait battre par un langage mieux adapté
(Il n'y a qu'en ce qui concerne la programmation des puces, avec javacards je crois, où cette règle semble ne pas s'appliquer)

Citation :

posté par XhaK
C et C++ sont standardisés car n'importe qui peut consulter la norme ANSI/OSI/autre de leur définition.

Tu as oublié de préciser «en payant»...
(Oui, ce n'est pas incompatible avec leur standardisation et ne les empêche pas d'être open-source)

[Kathar - Alleria - Lango]

Citation :

Provient du message de Masklinn
La semi-interprétation n'existe pas, on est interprété ou on l'est pas, le Java est interprété, le C ne l'est pas point final

Non pas point final
Il est possible de compiler du java directement en exécutable.
De même il est possible d'interpréter du c. (il existe même des programmes qui synthétisent des puces directement à partir du code c... c'est de l'interprétation ou de la compilation ? )

Classer ce que l'on fait dans des cases, c'est bien. Mais il ne faut pas oublier que les limites entre les cases sont parfaitement arbitraires, et qu'elles n'ont aucune valeur.

[Masklinn]

Citation :

Provient du message de Lango
Non pas point final
Il est possible de compiler du java directement en exécutable.

Est-ce une vraie compilation, c'est à dire la génération de code machine à partir du code Java, ou comme en Python l'implémentation d'un mini-interpréteur python dans un exe? (genre py2exe qui inclut un mini-interpréteur python + le script dans un exe)

Et le C peut etre interprété, bien sur, tout langage peut être interprété (ce n'est jamais que ce que fait le compilateur, dans l'absolu, une interprétation simple et efficace sans fioriture), mais compiler un langage interprété de haut niveau doté d'un garbage collector?

[Kashrag]

Citation :

Provient du message de Jade Ylis
De la même façon, Java est moins performant que C++ pour faire de la prog système ou PHP pour faire du Web (encore que pour PHP, y a bataille à mon avis ).

Ca me semble un peu normal, Java ne permet pas aux développeurs de gérer directement la mémoire, au contraire de C++. Sinon on peut aussi parler de développer des CGI en C++

Les JSP enfoncent PHP de loin au niveau heu... à tous les niveaux en fait. Ca n'empêche que PHP reste un bon langage, un peu fouilli par moments, mais qui permet de faire rapidement et simplement pas mal de trucs.

Je serai ravi de voir des comparatifs de vitesse d'exécution Java/C++ avec une JVM récente (pas avec le JDK 1.1 sans JIT svp), à mon avis Java n'a pas à rougir de la comparaison (je parle de code propre, et un minimum optimisé hein).
Par contre au niveau occupation mémoire, ok il faut se coltiner la JVM, et Java sera forcément plus gourmand, mais ça ne veut pas dire plus lent. Par contre ce sera surement plus lent au démarrage de l'appli.

Mais un point fort de Java c'est surtout son API extremement riche et très orientée réseau/applications réparties. Tiens au fait Python permet-il la gestion de la persistence de données ?

[Kathar - Alleria - Lango]

Citation :

Provient du message de Masklinn
Est-ce une vraie compilation, c'est à dire la génération de code machine à partir du code Java, ou comme en Python l'implémentation d'un mini-interpréteur python dans un exe? (genre py2exe qui inclut un mini-interpréteur python + le script dans un exe)

quand je dis compiler c'est compiler au sens où tu l'entends.

Citation :

Et le C peut etre interprété, bien sur, tout langage peut être interprété (ce n'est jamais que ce que fait le compilateur, dans l'absolu, une interprétation simple et efficace sans fioriture), mais compiler un langage interprété de haut niveau doté d'un garbage collector?

quel est le problème du garbage collector ? Ce n'est rien de plus qu'une bibliothèque à laquelle on fait appel quand on alloue de la mémoire...

[- Caïn Abalham -]

Citation :

Provient du message de Kashrag
Je serai ravi de voir des comparatifs de vitesse d'exécution Java/C++ avec une JVM récente (pas avec le JDK 1.1 sans JIT svp), à mon avis Java n'a pas à rougir de la comparaison (je parle de code propre, et un minimum optimisé hein).
Par contre au niveau occupation mémoire, ok il faut se coltiner la JVM, et Java sera forcément plus gourmand, mais ça ne veut pas dire plus lent. Par contre ce sera surement plus lent au démarrage de l'appli.

Mais un point fort de Java c'est surtout son API extremement riche et très orientée réseau/applications réparties. Tiens au fait Python permet-il la gestion de la persistence de données ?

Cette année on a fait un assez gros projet, un compilateur MiniJaja (version light de Java, enfin le but du projet etait de comprendre le principe d'un compilateur, mais la n'est pas le problème).

On avait le choix entre Java et C++, et sur tous les comparatifs qu'on a fait entre nos différents compilateurs, C++ enfonce largement Java niveau rapidité, et ca c'est verifié les années précédentes avec les autres promos qui ont eu à faire le même projet.

Faudrai que je retrouve mes sources, mais C++ est considéré comme étant 10 à 20 fois plus rapide que Java.

A la rigueur quand tu fait un projet simple sans IHM (enfin une vraie IHM, pas un menu dans la console ), la différence s'atténue énormément.

Mais il faut quand même reconnaître que des que tu fait un minimum de graphique pour ton appli, ca sera un bon gros char qui aura des gros soucis à avancer

Mais bon Java a aussi ses avantages (les seuls qui me viennent en tête c'est la simplicité d'utilisation des sockets et le RMI), mais, personnellement, si on me propose encore le choix entre C++ et Java mon choix sera irrémédiablement C++, sans hésitations

[Masklinn]

Citation :

Tiens au fait Python permet-il la gestion de la persistence de données ?

Qu'appelles tu la persistance de donnees?

Citation :

quand je dis compiler c'est compiler au sens où tu l'entends.

Interessant, tu as un lien?

Citation :

quel est le problème du garbage collector ? Ce n'est rien de plus qu'une bibliothèque à laquelle on fait appel quand on alloue de la mémoire...

Et a quel moment s'effectue la desaloccation? sur quels criteres? il faut que ta lib soit capable de gerer dynamiquement les allocations et desallocations sans aucune indication de l'utilisateur, c'est quand meme pas rien

Citation :

Provient du message de - Sarga -
On avait le choix entre Java et C++, et sur tous les comparatifs qu'on a fait entre nos différents compilateurs, C++ enfonce largement Java niveau rapidité, et ca c'est verifié les années précédentes avec les autres promos qui ont eu à faire le même projet.

Oui mais ca personne a jamais dit le contraire, le C++ est un langage beaucoup plus bas niveau que le Java et il est compile, il est donc normal qu'il soit plus rapide, le contraire serait pour le moins inquietant.
L'avantage des langages de haut niveau est la facilite de codage et la rapidite de transcription d'une idee "humaine" en code, celui des langages de bas niveau d'etre beaucoup plus prets de la machine, donc d'offrir moins de garde fous (gestion memoire ) et d'etre en general plus difficiles a coder, mais de fournir des perfs d'un tout autre niveau.

Apres, certains langages de haut niveau permettent de developper des modules (libs) en C/C++ pour accelerer le traitement des taches "time critical"

[Kathar - Alleria - Lango]

Citation :

Provient du message de Masklinn
Interessant, tu as un lien?

pas sous la main hélas. J'édite si je retrouve ça.

Citation :

Et a quel moment s'effectue la desaloccation? sur quels criteres? il faut que ta lib soit capable de gerer dynamiquement les allocations et desallocations sans aucune indication de l'utilisateur, c'est quand meme pas rien

je te garantis pourtant que c'est tout à fait faisable. D'ailleurs pour t'en convaincre, caml le fait très bien.
La seule contrainte pour un langage qui possède un garbage collector, c'est qu'il ne peut pas offrir la notion de pointeur (sinon le garbage collector ne peut pas savoir s'il existe un pointeur sur un objet qu'il souhaite jeter...)

[quote]Oui mais ca personne a jamais dit le contraire, le C++ est un langage beaucoup plus bas niveau que le Java et il est compile, il est donc normal qu'il soit plus rapide, le contraire serait pour le moins inquiétant.
L'avantage des langages de haut niveau est la facilite de codage et la rapidite de transcription d'une idee "humaine" en code, celui des langages de bas niveau d'etre beaucoup plus près de la machine, donc d'offrir moins de garde fous (gestion memoire ) et d'etre en general plus difficiles a coder, mais de fournir des perfs d'un tout autre niveau.

Citation :

Caml est un langage de plus haut niveau que java (ordre supérieur, c'est-à-dire que les fonctions sont des objets comme les autres, système d'inférence de type, c'est-à-dire que c'est le compilateur qui analyse le type des expressions qu'on lui passe sans que le programmeur ait à le préciser, ...)

Et pourtant :

• caml peut se compiler soit en bytecode, soit en code natif
• caml a de très bonnes performances, à peu près comparables à c++
  

[Masklinn]

Citation :

Caml est un langage de plus haut niveau que java (ordre supérieur, c'est-à-dire que les fonctions sont des objets comme les autres, système d'inférence de type, c'est-à-dire que c'est le compilateur qui analyse le type des expressions qu'on lui passe sans que le programmeur ait à le préciser, ...)

Le fait que le typage soit implicite n'est pas reellement un probleme, ca demande juste des analyses un peu plus poussees quand on a besoin de compiler -_-
idem pour le fait que ce soit un langage tout objet (comprendre: un objet est un objet, une fonction est un objet, une lib est un objet, une varable [meme int ou string] est un objet)

Citation :

Et pourtant :

caml peut se compiler soit en bytecode, soit en code natif

caml a de très bonnes performances, à peu près comparables à c++

*va se renseigner sur le CAML*

[Kathar - Alleria - Lango]

Citation :

Provient du message de Masklinn
idem pour le fait que ce soit un langage tout objet (comprendre: un objet est un objet, une fonction est un objet, une lib est un objet, une varable [meme int ou string] est un objet)

Ce n'est pas ça l'ordre supérieur.

En caml, tu peux faire une fonction qui prend un paramètre quelconque et qui te construit une fonction à partir de ce paramètre.

[Masklinn]

Citation :

Provient du message de Lango
Ce n'est pas ça l'ordre supérieur.

En caml, tu peux faire une fonction qui prend un paramètre quelconque et qui te construit une fonction à partir de ce paramètre.

J'ai pas compris le principe

[Kathar - Alleria - Lango]

Citation :

Provient du message de Masklinn
J'ai pas compris le principe

Code:

let make_incr a = fun x -> x + a

déclare une fonction make_incr, qui prend un entier en paramètre, et te renvoie une nouvelle fonction.
La fonction renvoyée prend un entier en paramètre, et l'incrémente de a
par exemple :

Code:

let incr2 = make_incr 2
incr2 3;;
- : int = 5
let incr10 = make_incr 10
incr10 4;;
- : int = 14

[Masklinn]

Citation :

Provient du message de Lango

Code:

let make_incr a = fun x -> x + a

déclare une fonction make_incr, qui prend un entier en paramètre, et te renvoie une nouvelle fonction.
La fonction renvoyée prend un entier en paramètre, et l'incrémente de a
par exemple :

Code:

let incr2 = make_incr 2
incr2 3;;
- : int = 5
let incr10 = make_incr 10
incr10 4;;
- : int = 14

mouais...

pas tres interessant ca, ca marche aussi en python

Code:

def make_incr(a):
    def f(x):
        return x+a
    return f
>>> incr2 = make_incr(2)
>>> incr2(5)
7
>>> incr2(3)
5
>>> incr10 = make_incr(10)
>>> incr10(4)
14
>>>

[Kathar - Alleria - Lango]

Citation :

Provient du message de Masklinn
pas tres interessant ca, ca marche aussi en python

Je n'ai jamais dit que c'était une exclusivité de caml...
Tu peux aussi faire ça en lisp, haskell, et sûrement d'autres langages que je ne connais pas

Par contre tu ne peux pas le faire en c, ou dans d'autres langages bas-niveau.

[Masklinn]

Citation :

Provient du message de Lango
Je n'ai jamais dit que c'était une exclusivité de caml...
Tu peux aussi faire ça en lisp, haskell, et sûrement d'autres langages que je ne connais pas

Par contre tu ne peux pas le faire en c, ou dans d'autres langages bas-niveau.

Totalement d'accord, mais moi je pensais apprendre un nouveau truc super interessant et pas faisable sur les langages que je connais, ou alors en bidouillant mechant, donc j'etais triste

Mais spa grave, j'aime beaucoup cette petite discussion (par contre j'aime pas trop la sytaxe CAML, elle a une drole de tronche )

[Kashrag]

Citation :

Provient du message de - Sarga -
Faudrai que je retrouve mes sources, mais C++ est considéré comme étant 10 à 20 fois plus rapide que Java.

A la rigueur quand tu fait un projet simple sans IHM (enfin une vraie IHM, pas un menu dans la console ), la différence s'atténue énormément.

Non désolé, le facteur 20 me fait rire
J'aimerai savoir ce que vous avez testé exactement et comment. Si c'est à vue de nez la réactivité de l'IHM, ben...

L'API Java Swing est assez difficile à maîtriser. Elle a quelques bugs et limitations, mais surtout un aspect fouilli qui rend son apprentissage long et complexe (à mon avis).
Je ne sais pas à quoi ressemble SWT (autre API graphique créée par IBM à l'origine), mais à voir le résultat dans Eclipse, elle n'a rien à envier au C++ au point de vue réactivité des composants / rapidité.

De plus ça m'étonnerait énormément que les applis graphiques représentent la majorité du développement. L'IHM n'est que la partie hébergée de l'iceberg...
Pour toi un projet simple = projet sans IHM ? hmm

Il faudrait que je teste une IHM en Python un jour, ça a l'air assez sympa à faire.

Citation :

Provient du message de Masklinn
Qu'appelles tu la persistance de donnees?

EJB, JDO, Hibernate... enfin une représentation objet de tes données stockées dans ce que tu veux (fichier plat, SGBD, XML). Je ne crois pas que Python propose cela (bien sur du parsing XML il connait).

[- Caïn Abalham -]

Citation :

Provient du message de Kashrag
mais à voir le résultat dans Eclipse, elle n'a rien à envier au C++ au point de vue réactivité des composants / rapidité.

Excuses moi, mais Eclipse a beau être nettement plus rapide que la plupart des applis en Java de taille équivalente, il reste nettement plus lent que, pour prendre un exemple équivalent en C++, Visual studio.

Pour le facteur 20, certes c'était peut être abusé, et j'ai jamais fait de réel calcul sur un programme équivalent avec mon chrono pour voir les temps de réaction

Mais j'attends toujours qu'on me montre 2 applis équivalentes, une en Java, l'autre en C++ qui ont des temps de réaction comparables

Citation :

De plus ça m'étonnerait énormément que les applis graphiques représentent la majorité du développement. L'IHM n'est que la partie hébergée de l'iceberg...
Pour toi un projet simple = projet sans IHM ? hmm

Je me suis mal exprimé, je sait très bien qu'il y a des applis de bourrins sans IHM ...

Ce que je voulait dire c'est qu'une fois l'IHM virée, la différence C++/Java s'amoindrit énormément

Mais on ne m'ôtera pas de l'idée sans preuves concrètes que Java est plus lent.

Par contre pour Lango, un truc m'éttones dans ta syntaxe CaML.
J'ai fait un peu de CaML l'an dernier, et ca ressemblait pas du tout à ca (c'était plus proche du Scheme).
Il y a une syntaxe particulière pour CaML light ?

[Kashrag]

Citation :

Provient du message de - Sarga -
Mais on ne m'ôtera pas de l'idée sans preuves concrètes que Java est plus lent.

Soit...
http://www.aceshardware.com/read.jsp?id=153
For client-side Java programs (eg applets, desktop applications) start-up times are more important, but more time is spent in the graphics libraries anyway - these days Java developers complaining about speed will most likely be complaining about graphics performance, for which the libraries are mostly statically compiled.

A noter que ce ne sont que des tests de calculs mathématiques, donc vraiment pas des applications représentatives de la vie réelle. D'ailleurs je me demande comment on peut comparer deux applis utilisées (C++ / Java), à priori je n'utiliserai pas les deux langages pour faire la même chose (je mets de côté les IHM).