sedenion writes:Le C++ marche très bien, le java est inutile (comment ce truc a fait
pour percer ?), et les autres sont des trucs plus spécialisés. Les
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'une plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matériel
par leur architecture lourde et mal optimisée histoire de justifier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
- Le C++ est lourd et complexe. Cependant, c'est un langage amusant
qu'il faut essayer.
- Le Java est déclaré comme un langage jouet par son développeur
initiale. De plus ça VM est horriblement spécifié, ça grammaire est
mal spécifié.
- Le C♯ est entre le Java et le C++, mais un langage dépendant d'un os,
ne peut pas être un bon langage.
Après l'idée de compile-once run-everywhere n'est pas une mauvaise idée
en soi… si un compilateur natif n'était inclus dans la VM. Du coup,
aucun n'intérêt de perdre tu temps lors de l'execution pour compiler
vers du natif.
Un débutant (plus de 2 mois) sur un langage avec garbage collector est
un hérésie. On arrive à avoir des développeur qui ne connaissent pas la
gestion de la mémoire, ni comment fonctionne un µprocesseur. Au final
ils tentent d'optimiser du code Java alors que c'est bien une chose à ne
pas faire en Java car on ne recherche pas d'efficience dans ces types de
langages.
Et puis commencer sur un langage procédural : je n'en pense aucun bien.
sedenion <root@sedenion.42> writes:
Le C++ marche très bien, le java est inutile (comment ce truc a fait
pour percer ?), et les autres sont des trucs plus spécialisés. Les
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'une plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matériel
par leur architecture lourde et mal optimisée histoire de justifier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
- Le C++ est lourd et complexe. Cependant, c'est un langage amusant
qu'il faut essayer.
- Le Java est déclaré comme un langage jouet par son développeur
initiale. De plus ça VM est horriblement spécifié, ça grammaire est
mal spécifié.
- Le C♯ est entre le Java et le C++, mais un langage dépendant d'un os,
ne peut pas être un bon langage.
Après l'idée de compile-once run-everywhere n'est pas une mauvaise idée
en soi… si un compilateur natif n'était inclus dans la VM. Du coup,
aucun n'intérêt de perdre tu temps lors de l'execution pour compiler
vers du natif.
Un débutant (plus de 2 mois) sur un langage avec garbage collector est
un hérésie. On arrive à avoir des développeur qui ne connaissent pas la
gestion de la mémoire, ni comment fonctionne un µprocesseur. Au final
ils tentent d'optimiser du code Java alors que c'est bien une chose à ne
pas faire en Java car on ne recherche pas d'efficience dans ces types de
langages.
Et puis commencer sur un langage procédural : je n'en pense aucun bien.
sedenion writes:Le C++ marche très bien, le java est inutile (comment ce truc a fait
pour percer ?), et les autres sont des trucs plus spécialisés. Les
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'une plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matériel
par leur architecture lourde et mal optimisée histoire de justifier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
- Le C++ est lourd et complexe. Cependant, c'est un langage amusant
qu'il faut essayer.
- Le Java est déclaré comme un langage jouet par son développeur
initiale. De plus ça VM est horriblement spécifié, ça grammaire est
mal spécifié.
- Le C♯ est entre le Java et le C++, mais un langage dépendant d'un os,
ne peut pas être un bon langage.
Après l'idée de compile-once run-everywhere n'est pas une mauvaise idée
en soi… si un compilateur natif n'était inclus dans la VM. Du coup,
aucun n'intérêt de perdre tu temps lors de l'execution pour compiler
vers du natif.
Un débutant (plus de 2 mois) sur un langage avec garbage collector est
un hérésie. On arrive à avoir des développeur qui ne connaissent pas la
gestion de la mémoire, ni comment fonctionne un µprocesseur. Au final
ils tentent d'optimiser du code Java alors que c'est bien une chose à ne
pas faire en Java car on ne recherche pas d'efficience dans ces types de
langages.
Et puis commencer sur un langage procédural : je n'en pense aucun bien.
On 2014-01-01, Moreira David wrote:Tout ce que tu dis est vrai. Mais il reste un noyau monolithique. Et
pour le coup impose des limitations assez forte sur la planification des
taÌches, du montages, etc.
[snip]Pour faire des accès mémoire sur des périphériques o ui. En revanche la
planification taÌches n'a pas réellement besoin d'eÌtre e n ring0. Et comme
Je me suis bien creusé la tête, et je ne vois vraiment pas le
rapport entre la planification des tâches et le noyau Linux.
à moins que tu ne parles de l'ordonnanceur (le scheduler, quoi),
et pas du planificateur (le cron, quoi). Auquel cas, il faudrait
que tu précises tes griefs à son égard.
On 2014-01-01, Moreira David <vash2593@myopera.com> wrote:
Tout ce que tu dis est vrai. Mais il reste un noyau monolithique. Et
pour le coup impose des limitations assez forte sur la planification des
taÌches, du montages, etc.
[snip]
Pour faire des accès mémoire sur des périphériques o ui. En revanche la
planification taÌches n'a pas réellement besoin d'eÌtre e n ring0. Et comme
Je me suis bien creusé la tête, et je ne vois vraiment pas le
rapport entre la planification des tâches et le noyau Linux.
à moins que tu ne parles de l'ordonnanceur (le scheduler, quoi),
et pas du planificateur (le cron, quoi). Auquel cas, il faudrait
que tu précises tes griefs à son égard.
On 2014-01-01, Moreira David wrote:Tout ce que tu dis est vrai. Mais il reste un noyau monolithique. Et
pour le coup impose des limitations assez forte sur la planification des
taÌches, du montages, etc.
[snip]Pour faire des accès mémoire sur des périphériques o ui. En revanche la
planification taÌches n'a pas réellement besoin d'eÌtre e n ring0. Et comme
Je me suis bien creusé la tête, et je ne vois vraiment pas le
rapport entre la planification des tâches et le noyau Linux.
à moins que tu ne parles de l'ordonnanceur (le scheduler, quoi),
et pas du planificateur (le cron, quoi). Auquel cas, il faudrait
que tu précises tes griefs à son égard.
Le 01/01/2014 10:30, Moreira David a écrit :Toxico Nimbus writes:[...]merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'u ne plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matà ©riel
par leur architecture lourde et mal optimisée histoire de justifi er
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
Tu ne peux pas être à la fois indépendant de la platefor me matériel et
optimisé. Les bytecodes existaient déjà sur les machines bien plus
limitées d'il y a quelques dizaines d'années.
le lisp par exemple sur du PDP-7 (ou 9). Donc dans les années 70. S auf
qu'ici, il parle de la plateforme logiciel, dans ce cas MS Windows. Sauf
si Mono (c'est bien Mono ?) a évolué depuis le temps, le C⠯ est sous MS
Windows, et cela uniquement.
Le C# n'est pas présent que sous Windows. Mono est un /framework/
libre concurrent de .net.
Le 01/01/2014 10:30, Moreira David a écrit :
Toxico Nimbus <toxn@free.fr> writes:
[...]
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'u ne plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matà ©riel
par leur architecture lourde et mal optimisée histoire de justifi er
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
Tu ne peux pas être à la fois indépendant de la platefor me matériel et
optimisé. Les bytecodes existaient déjà sur les machines bien plus
limitées d'il y a quelques dizaines d'années.
le lisp par exemple sur du PDP-7 (ou 9). Donc dans les années 70. S auf
qu'ici, il parle de la plateforme logiciel, dans ce cas MS Windows. Sauf
si Mono (c'est bien Mono ?) a évolué depuis le temps, le C⠯ est sous MS
Windows, et cela uniquement.
Le C# n'est pas présent que sous Windows. Mono est un /framework/
libre concurrent de .net.
Le 01/01/2014 10:30, Moreira David a écrit :Toxico Nimbus writes:[...]merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'u ne plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matà ©riel
par leur architecture lourde et mal optimisée histoire de justifi er
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
Tu ne peux pas être à la fois indépendant de la platefor me matériel et
optimisé. Les bytecodes existaient déjà sur les machines bien plus
limitées d'il y a quelques dizaines d'années.
le lisp par exemple sur du PDP-7 (ou 9). Donc dans les années 70. S auf
qu'ici, il parle de la plateforme logiciel, dans ce cas MS Windows. Sauf
si Mono (c'est bien Mono ?) a évolué depuis le temps, le C⠯ est sous MS
Windows, et cela uniquement.
Le C# n'est pas présent que sous Windows. Mono est un /framework/
libre concurrent de .net.
Le 01/01/2014 10:25, Moreira David a écrit :sedenion writes:Le C++ marche très bien, le java est inutile (comment ce truc a fa it
pour percer ?), et les autres sont des trucs plus spécialisés . Les
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'un e plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du maté riel
par leur architecture lourde et mal optimisée histoire de justifier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
- Le C++ est lourd et complexe. Cependant, c'est un langage amusant
qu'il faut essayer.
Je ne vois vraiment pas ce qu'il y a de récréatif dans le C++. S'il y
a un langage qu'il vaut mieux aborder avec rigueur, c'est surement
celui-là .
- Le Java est déclaré comme un langage jouet par son déve loppeur
initiale. De plus ça VM est horriblement spécifié, c ̧a grammaire est
mal spécifié.
La grande majorité des langages ont démarré un jour comme des projets
"pour le fun", ça ne veut pas dire qu'ils gardent ce caractère. En
lâoccurrence, Java permet de mettre au point des projets tout à fait
sérieux.
- Le C⯠est entre le Java et le C++, mais un langage dépend ant d'un os,
ne peut pas eÌtre un bon langage.
Cela tombe bien puisque C# (et tout les langages ".net") tout comme
Java ont justement été créés pour s'affranchir de l'O S, en remplaçant
l'API de l'OS par un framework.
Après l'idée de compile-once run-everywhere n'est pas une mauv aise idée
en soi⦠si un compilateur natif n'était inclus dans la VM. Du coup,
aucun n'intéreÌt de perdre tu temps lors de l'execution pour c ompiler
vers du natif.
Pour tout ce qui est transactionnel, un langage à VM+JIT s'exéc ute
aussi vite que du code compilé. L'avantage est que ton code compil é
est distribuable partout, avec une compatibilité ascendante
quasi-parfaite, et ce en gardant le code fermé.
Un débutant (plus de 2 mois) sur un langage avec garbage collector est
un hérésie. On arrive à avoir des développeur qui ne connaissent pas la
gestion de la mémoire, ni comment fonctionne un µprocesseur. A u final
ils tentent d'optimiser du code Java alors que c'est bien une chose à ne
pas faire en Java car on ne recherche pas d'efficience dans ces types de
langages.
Un débutant, où que ce soit, doit être gérer correcte ment. Si tu le
laisse bosser tout seul, tu auras forcément n'importe quoi à la
clé. La première chose que j'enseigne à n'importe quel d ébutant en
dev, c'est de ne jamais optimiser le code. On n'optimise que le algo
et encore, pas dans n'importe quelle phase de développement.
Et puis commencer sur un langage procédural : je n'en pense aucun b ien.
Y'a-t-il une raison à cela ?
Le 01/01/2014 10:25, Moreira David a écrit :
sedenion <root@sedenion.42> writes:
Le C++ marche très bien, le java est inutile (comment ce truc a fa it
pour percer ?), et les autres sont des trucs plus spécialisés . Les
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'un e plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du maté riel
par leur architecture lourde et mal optimisée histoire de justifier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
- Le C++ est lourd et complexe. Cependant, c'est un langage amusant
qu'il faut essayer.
Je ne vois vraiment pas ce qu'il y a de récréatif dans le C++. S'il y
a un langage qu'il vaut mieux aborder avec rigueur, c'est surement
celui-là .
- Le Java est déclaré comme un langage jouet par son déve loppeur
initiale. De plus ça VM est horriblement spécifié, c ̧a grammaire est
mal spécifié.
La grande majorité des langages ont démarré un jour comme des projets
"pour le fun", ça ne veut pas dire qu'ils gardent ce caractère. En
lâoccurrence, Java permet de mettre au point des projets tout à fait
sérieux.
- Le C⯠est entre le Java et le C++, mais un langage dépend ant d'un os,
ne peut pas eÌtre un bon langage.
Cela tombe bien puisque C# (et tout les langages ".net") tout comme
Java ont justement été créés pour s'affranchir de l'O S, en remplaçant
l'API de l'OS par un framework.
Après l'idée de compile-once run-everywhere n'est pas une mauv aise idée
en soi⦠si un compilateur natif n'était inclus dans la VM. Du coup,
aucun n'intéreÌt de perdre tu temps lors de l'execution pour c ompiler
vers du natif.
Pour tout ce qui est transactionnel, un langage à VM+JIT s'exéc ute
aussi vite que du code compilé. L'avantage est que ton code compil é
est distribuable partout, avec une compatibilité ascendante
quasi-parfaite, et ce en gardant le code fermé.
Un débutant (plus de 2 mois) sur un langage avec garbage collector est
un hérésie. On arrive à avoir des développeur qui ne connaissent pas la
gestion de la mémoire, ni comment fonctionne un µprocesseur. A u final
ils tentent d'optimiser du code Java alors que c'est bien une chose à ne
pas faire en Java car on ne recherche pas d'efficience dans ces types de
langages.
Un débutant, où que ce soit, doit être gérer correcte ment. Si tu le
laisse bosser tout seul, tu auras forcément n'importe quoi à la
clé. La première chose que j'enseigne à n'importe quel d ébutant en
dev, c'est de ne jamais optimiser le code. On n'optimise que le algo
et encore, pas dans n'importe quelle phase de développement.
Et puis commencer sur un langage procédural : je n'en pense aucun b ien.
Y'a-t-il une raison à cela ?
Le 01/01/2014 10:25, Moreira David a écrit :sedenion writes:Le C++ marche très bien, le java est inutile (comment ce truc a fa it
pour percer ?), et les autres sont des trucs plus spécialisés . Les
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'un e plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du maté riel
par leur architecture lourde et mal optimisée histoire de justifier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
- Le C++ est lourd et complexe. Cependant, c'est un langage amusant
qu'il faut essayer.
Je ne vois vraiment pas ce qu'il y a de récréatif dans le C++. S'il y
a un langage qu'il vaut mieux aborder avec rigueur, c'est surement
celui-là .
- Le Java est déclaré comme un langage jouet par son déve loppeur
initiale. De plus ça VM est horriblement spécifié, c ̧a grammaire est
mal spécifié.
La grande majorité des langages ont démarré un jour comme des projets
"pour le fun", ça ne veut pas dire qu'ils gardent ce caractère. En
lâoccurrence, Java permet de mettre au point des projets tout à fait
sérieux.
- Le C⯠est entre le Java et le C++, mais un langage dépend ant d'un os,
ne peut pas eÌtre un bon langage.
Cela tombe bien puisque C# (et tout les langages ".net") tout comme
Java ont justement été créés pour s'affranchir de l'O S, en remplaçant
l'API de l'OS par un framework.
Après l'idée de compile-once run-everywhere n'est pas une mauv aise idée
en soi⦠si un compilateur natif n'était inclus dans la VM. Du coup,
aucun n'intéreÌt de perdre tu temps lors de l'execution pour c ompiler
vers du natif.
Pour tout ce qui est transactionnel, un langage à VM+JIT s'exéc ute
aussi vite que du code compilé. L'avantage est que ton code compil é
est distribuable partout, avec une compatibilité ascendante
quasi-parfaite, et ce en gardant le code fermé.
Un débutant (plus de 2 mois) sur un langage avec garbage collector est
un hérésie. On arrive à avoir des développeur qui ne connaissent pas la
gestion de la mémoire, ni comment fonctionne un µprocesseur. A u final
ils tentent d'optimiser du code Java alors que c'est bien une chose à ne
pas faire en Java car on ne recherche pas d'efficience dans ces types de
langages.
Un débutant, où que ce soit, doit être gérer correcte ment. Si tu le
laisse bosser tout seul, tu auras forcément n'importe quoi à la
clé. La première chose que j'enseigne à n'importe quel d ébutant en
dev, c'est de ne jamais optimiser le code. On n'optimise que le algo
et encore, pas dans n'importe quelle phase de développement.
Et puis commencer sur un langage procédural : je n'en pense aucun b ien.
Y'a-t-il une raison à cela ?
Toxico Nimbus writes:Le 01/01/2014 10:30, Moreira David a écrit :Toxico Nimbus writes:[...]merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'une plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matériel
par leur architecture lourde et mal optimisée histoire de justifier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
Tu ne peux pas être à la fois indépendant de la plateforme matériel et
optimisé. Les bytecodes existaient déjà sur les machines bien plus
limitées d'il y a quelques dizaines d'années.
le lisp par exemple sur du PDP-7 (ou 9). Donc dans les années 70. Sauf
qu'ici, il parle de la plateforme logiciel, dans ce cas MS Windows. Sauf
si Mono (c'est bien Mono ?) a évolué depuis le temps, le C♯ est sous MS
Windows, et cela uniquement.
Le C# n'est pas présent que sous Windows. Mono est un /framework/
libre concurrent de .net.
Comme tu le cites si bien : sauf si Mono a évolué depus le temps. À
l'époque où j'avais regardé le C♯ sous Linux, Mono n'était pas très
réputé.
Toxico Nimbus <toxn@free.fr> writes:
Le 01/01/2014 10:30, Moreira David a écrit :
Toxico Nimbus <toxn@free.fr> writes:
[...]
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'une plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matériel
par leur architecture lourde et mal optimisée histoire de justifier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
Tu ne peux pas être à la fois indépendant de la plateforme matériel et
optimisé. Les bytecodes existaient déjà sur les machines bien plus
limitées d'il y a quelques dizaines d'années.
le lisp par exemple sur du PDP-7 (ou 9). Donc dans les années 70. Sauf
qu'ici, il parle de la plateforme logiciel, dans ce cas MS Windows. Sauf
si Mono (c'est bien Mono ?) a évolué depuis le temps, le C♯ est sous MS
Windows, et cela uniquement.
Le C# n'est pas présent que sous Windows. Mono est un /framework/
libre concurrent de .net.
Comme tu le cites si bien : sauf si Mono a évolué depus le temps. À
l'époque où j'avais regardé le C♯ sous Linux, Mono n'était pas très
réputé.
Toxico Nimbus writes:Le 01/01/2014 10:30, Moreira David a écrit :Toxico Nimbus writes:[...]merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'une plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matériel
par leur architecture lourde et mal optimisée histoire de justifier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
Tu ne peux pas être à la fois indépendant de la plateforme matériel et
optimisé. Les bytecodes existaient déjà sur les machines bien plus
limitées d'il y a quelques dizaines d'années.
le lisp par exemple sur du PDP-7 (ou 9). Donc dans les années 70. Sauf
qu'ici, il parle de la plateforme logiciel, dans ce cas MS Windows. Sauf
si Mono (c'est bien Mono ?) a évolué depuis le temps, le C♯ est sous MS
Windows, et cela uniquement.
Le C# n'est pas présent que sous Windows. Mono est un /framework/
libre concurrent de .net.
Comme tu le cites si bien : sauf si Mono a évolué depus le temps. À
l'époque où j'avais regardé le C♯ sous Linux, Mono n'était pas très
réputé.
Toxico Nimbus writes:Le 01/01/2014 10:25, Moreira David a écrit :sedenion writes:Le C++ marche très bien, le java est inutile (comment ce truc a fait
pour percer ?), et les autres sont des trucs plus spécialisés.. Les
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'une plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matériel
par leur architecture lourde et mal optimisée histoire de justifier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
- Le C++ est lourd et complexe. Cependant, c'est un langage amusant
qu'il faut essayer.
Je ne vois vraiment pas ce qu'il y a de récréatif dans le C++. S'il y
a un langage qu'il vaut mieux aborder avec rigueur, c'est surement
celui-là.
Tu vas dire le contraire…
- Le Java est déclaré comme un langage jouet par son développeur
initiale. De plus ça VM est horriblement spécifié, ça grammaire est
mal spécifié.
La grande majorité des langages ont démarré un jour comme des projets
"pour le fun", ça ne veut pas dire qu'ils gardent ce caractère. En
l’occurrence, Java permet de mettre au point des projets tout à fait
sérieux.
… ici. Personellement, je m'amuse à écrire certaines choses dans
certains langages. Pour Java, je n'ai jamais dit le contraire.- Le C♯ est entre le Java et le C++, mais un langage dépendant d'un os,
ne peut pas être un bon langage.
Cela tombe bien puisque C# (et tout les langages ".net") tout comme
Java ont justement été créés pour s'affranchir de l'OS, en remplaçant
l'API de l'OS par un framework.
Framework ? Ce n'est même pas une bibliothèque ! C'est bien mieux.
Après l'idée de compile-once run-everywhere n'est pas une mauvaise idée
en soi… si un compilateur natif n'était inclus dans la VM. Du coup,
aucun n'intérêt de perdre tu temps lors de l'execution pour compiler
vers du natif.
Pour tout ce qui est transactionnel, un langage à VM+JIT s'exécute
aussi vite que du code compilé. L'avantage est que ton code compilé
est distribuable partout, avec une compatibilité ascendante
quasi-parfaite, et ce en gardant le code fermé.
Car c'est limité par les e/s. Je ne penses pas que quelqu'un pense à
faire une db in-memory dans un langage Jitté ou sous VM.
Toxico Nimbus <toxn@free.fr> writes:
Le 01/01/2014 10:25, Moreira David a écrit :
sedenion <root@sedenion.42> writes:
Le C++ marche très bien, le java est inutile (comment ce truc a fait
pour percer ?), et les autres sont des trucs plus spécialisés.. Les
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'une plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matériel
par leur architecture lourde et mal optimisée histoire de justifier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
- Le C++ est lourd et complexe. Cependant, c'est un langage amusant
qu'il faut essayer.
Je ne vois vraiment pas ce qu'il y a de récréatif dans le C++. S'il y
a un langage qu'il vaut mieux aborder avec rigueur, c'est surement
celui-là.
Tu vas dire le contraire…
- Le Java est déclaré comme un langage jouet par son développeur
initiale. De plus ça VM est horriblement spécifié, ça grammaire est
mal spécifié.
La grande majorité des langages ont démarré un jour comme des projets
"pour le fun", ça ne veut pas dire qu'ils gardent ce caractère. En
l’occurrence, Java permet de mettre au point des projets tout à fait
sérieux.
… ici. Personellement, je m'amuse à écrire certaines choses dans
certains langages. Pour Java, je n'ai jamais dit le contraire.
- Le C♯ est entre le Java et le C++, mais un langage dépendant d'un os,
ne peut pas être un bon langage.
Cela tombe bien puisque C# (et tout les langages ".net") tout comme
Java ont justement été créés pour s'affranchir de l'OS, en remplaçant
l'API de l'OS par un framework.
Framework ? Ce n'est même pas une bibliothèque ! C'est bien mieux.
Après l'idée de compile-once run-everywhere n'est pas une mauvaise idée
en soi… si un compilateur natif n'était inclus dans la VM. Du coup,
aucun n'intérêt de perdre tu temps lors de l'execution pour compiler
vers du natif.
Pour tout ce qui est transactionnel, un langage à VM+JIT s'exécute
aussi vite que du code compilé. L'avantage est que ton code compilé
est distribuable partout, avec une compatibilité ascendante
quasi-parfaite, et ce en gardant le code fermé.
Car c'est limité par les e/s. Je ne penses pas que quelqu'un pense à
faire une db in-memory dans un langage Jitté ou sous VM.
Toxico Nimbus writes:Le 01/01/2014 10:25, Moreira David a écrit :sedenion writes:Le C++ marche très bien, le java est inutile (comment ce truc a fait
pour percer ?), et les autres sont des trucs plus spécialisés.. Les
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d'une plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matériel
par leur architecture lourde et mal optimisée histoire de justifier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
- Le C++ est lourd et complexe. Cependant, c'est un langage amusant
qu'il faut essayer.
Je ne vois vraiment pas ce qu'il y a de récréatif dans le C++. S'il y
a un langage qu'il vaut mieux aborder avec rigueur, c'est surement
celui-là.
Tu vas dire le contraire…
- Le Java est déclaré comme un langage jouet par son développeur
initiale. De plus ça VM est horriblement spécifié, ça grammaire est
mal spécifié.
La grande majorité des langages ont démarré un jour comme des projets
"pour le fun", ça ne veut pas dire qu'ils gardent ce caractère. En
l’occurrence, Java permet de mettre au point des projets tout à fait
sérieux.
… ici. Personellement, je m'amuse à écrire certaines choses dans
certains langages. Pour Java, je n'ai jamais dit le contraire.- Le C♯ est entre le Java et le C++, mais un langage dépendant d'un os,
ne peut pas être un bon langage.
Cela tombe bien puisque C# (et tout les langages ".net") tout comme
Java ont justement été créés pour s'affranchir de l'OS, en remplaçant
l'API de l'OS par un framework.
Framework ? Ce n'est même pas une bibliothèque ! C'est bien mieux.
Après l'idée de compile-once run-everywhere n'est pas une mauvaise idée
en soi… si un compilateur natif n'était inclus dans la VM. Du coup,
aucun n'intérêt de perdre tu temps lors de l'execution pour compiler
vers du natif.
Pour tout ce qui est transactionnel, un langage à VM+JIT s'exécute
aussi vite que du code compilé. L'avantage est que ton code compilé
est distribuable partout, avec une compatibilité ascendante
quasi-parfaite, et ce en gardant le code fermé.
Car c'est limité par les e/s. Je ne penses pas que quelqu'un pense à
faire une db in-memory dans un langage Jitté ou sous VM.
1° Une bd "in-memory", ça ne sert à rien, et ce dans 100% des cas.
1° Une bd "in-memory", ça ne sert à rien, et ce dans 100% des cas.
1° Une bd "in-memory", ça ne sert à rien, et ce dans 100% des cas.
Oups, je parlais de la planification des processus, soit l'ordonanceur
de processus.
Oups, je parlais de la planification des processus, soit l'ordonanceur
de processus.
Oups, je parlais de la planification des processus, soit l'ordonanceur
de processus.
particulier. Preuve en est que mono peut l'implémenter à peu près
partout, DotGNU n'en était pas loin.
particulier. Preuve en est que mono peut l'implémenter à peu près
partout, DotGNU n'en était pas loin.
particulier. Preuve en est que mono peut l'implémenter à peu près
partout, DotGNU n'en était pas loin.
On 2014-01-02, Moreira David wrote:Oups, je parlais de la planification des processus, soit l'ordonanceur
de processus.
Dans ce cas, pourquoi ne pas dire juste « scheduler » ?
On 2014-01-02, Moreira David <vash2593@myopera.com> wrote:
Oups, je parlais de la planification des processus, soit l'ordonanceur
de processus.
Dans ce cas, pourquoi ne pas dire juste « scheduler » ?
On 2014-01-02, Moreira David wrote:Oups, je parlais de la planification des processus, soit l'ordonanceur
de processus.
Dans ce cas, pourquoi ne pas dire juste « scheduler » ?