Toxico Nimbus wrote:
Les exception sont quand même quelque chose de plus élégant et
extensible que le code de retour + errno.
Le problème n'est pas que c'est plus ou moins élégant, c'est que ça
permet de poursuivre le traîtement ailleurs dans la pile d'appels.
JKB dit que c'est une mauvaise chose, les gens qui ont réfléchi au
problème ont inventé ce mécanisme car ils pensaient que ça avait une
utilité précise - à commencer, je me répète, par les concepteurs de
lisp, qui ont été suivis par ceux de Java, de Python, etc. Ce n'est pas
une grande surprise, car les concepteurs de Java, de Python, etc.
étaient souvent issus du monde lisp ou smalltalk. Il en est de
même d'ailleurs de la gestion automatique de mémoire, etc. Evidemment
si on considère que le C est l'alpha et l'omega de la programmation ...
Toxico Nimbus <ToxN@free.fr> wrote:
Les exception sont quand même quelque chose de plus élégant et
extensible que le code de retour + errno.
Le problème n'est pas que c'est plus ou moins élégant, c'est que ça
permet de poursuivre le traîtement ailleurs dans la pile d'appels.
JKB dit que c'est une mauvaise chose, les gens qui ont réfléchi au
problème ont inventé ce mécanisme car ils pensaient que ça avait une
utilité précise - à commencer, je me répète, par les concepteurs de
lisp, qui ont été suivis par ceux de Java, de Python, etc. Ce n'est pas
une grande surprise, car les concepteurs de Java, de Python, etc.
étaient souvent issus du monde lisp ou smalltalk. Il en est de
même d'ailleurs de la gestion automatique de mémoire, etc. Evidemment
si on considère que le C est l'alpha et l'omega de la programmation ...
Toxico Nimbus wrote:
Les exception sont quand même quelque chose de plus élégant et
extensible que le code de retour + errno.
Le problème n'est pas que c'est plus ou moins élégant, c'est que ça
permet de poursuivre le traîtement ailleurs dans la pile d'appels.
JKB dit que c'est une mauvaise chose, les gens qui ont réfléchi au
problème ont inventé ce mécanisme car ils pensaient que ça avait une
utilité précise - à commencer, je me répète, par les concepteurs de
lisp, qui ont été suivis par ceux de Java, de Python, etc. Ce n'est pas
une grande surprise, car les concepteurs de Java, de Python, etc.
étaient souvent issus du monde lisp ou smalltalk. Il en est de
même d'ailleurs de la gestion automatique de mémoire, etc. Evidemment
si on considère que le C est l'alpha et l'omega de la programmation ...
On 6/21/11 2:37 AM, Aéris wrote:
sub write_to_file
{
my $file = shift;
my $data = shift;
open(OUT,">",$file) or die $!;
print OUT $data;
close(OUT);
return 1;
}
On 6/21/11 2:37 AM, Aéris wrote:
sub write_to_file
{
my $file = shift;
my $data = shift;
open(OUT,">",$file) or die $!;
print OUT $data;
close(OUT);
return 1;
}
On 6/21/11 2:37 AM, Aéris wrote:
sub write_to_file
{
my $file = shift;
my $data = shift;
open(OUT,">",$file) or die $!;
print OUT $data;
close(OUT);
return 1;
}
>> La seule
>> différence, c'est qu'il faut avoir des gens plus
>> compétents.
>
> Non, ce n'est pas la seule différence. Plus de choses à gérer =>
> plus d'erreurs. A moins que tu écrives des programmes sans jamais
> aucune erreur ?
Alors explique-moi pourquoi les plus belles conneries qui
m'aient été données de voir, c'est justement dans des codes Java ?
> Moins d'attention du développeur gaspillée, moins de pollution dans
> le code.
Aucun rapport. Si tu ne fais pas attention, tu feras des
conneries quel que soit le langage.
>> Ta métaphore est pour le moins bizarre. Là où il te faut un
>> débutant pour bricoler un tru sur un coin de table avec Java, il te
>> faudra des gens plus compétents avec du C ou du C++.
>
> Où est l'avantage du C ici ?
Du langage, rien. Tu auras simplement un dev plus compétent.
>> Et il ne faut
>> surtout pas me faire croire qu'un développeur Java qui ne connaît
>> ni ne comprend rien à la gestion de la mémoire est un bon
>> développeur.
>
> Il y a moins de choses à écrire pour gérer la mémoire correctement
> en Java, si tu ne vois pas l'avantage de mettre moins de bordel
> dans du code, je ne vois pas le problème.
C'est juste un faux avantage. Ça permet juste à des gens qui
ne comprennent pas vraiment ce qu'ils font d'écrire des trucs, choses
qu'ils ne pourraient jamais faire dans un autre langage. Et
c'est ce qui est pervers dans l'utilisation de Java. Utiliser des tas
de notions sans comprendre ce qui est derrière est suicidaire. Et Java
est mauvais à cause de ça. Maintenant, je ne vais pas passer
des heures à essayer d'expliquer pourquoi. J'arrive à comprendre qu'on
trouve pratique certains points du langage, mais cela reste à
mes yeux l'un des pires langages qui existe.
> La partie à comprendre en moins en java c'est les destructeurs
> (C++),
Oui, et on voit les conneries des pointeurs qui ne sont jamais
déréférencés avec ce que ça implique, par exemple...
> la libération de tous les objets en profondeur [jusque là il n'y a
> pas grand chose d'important pour la programmation en général, c'est
> surtout de la pratique] et sans doute des trucs obscurs avec les
> pointeurs, les passages par valeur ou par référence (C++), ... En
> fait pas grand chose, la plupart des choses simplifiées en Java ne
> servent pas à comprendre fondamentalement le fonctionnement de la
> mémoire, il s'agit de bazar à gérer. Ben oui, il y a quelques trucs
> à comprendre quand on programme, il y a juste moins de choses à se
> rappeler en Java, et la plupart ne sont que des contraintes de
> gestion manuelle.
Et c'est justement là qu'on n'est plus du tout d'accord. On
n'est pas d'accord parce que quelqu'un qui passe par les étapes
Fortran->C->C++->Java ne codera pas du tout de la même façon
que ceux qui attaquent directement par du Java. Et bizarrement, ils
feront moins de conneries. On ne peut pas utiliser un
langage, même un truc qui masque tout à l'utilisateur, sans savoir
peu ou prou ce qu'on fait.
> Et tu n'expliques pas en quoi c'est un problème qu'il fasse ça
> quand ça lui chante ou quand il en a besoin. Oui, sur le moment
> c'est plus complexe, et donc ?
Et donc ça te bouffe pour rien des ressources qui seraient
utiles ailleurs. Et ne me dis pas qu'on peut multiplier par dix la
puissance de la machine qui fait tourner la JVM. C'est une réponse
aberrante parce que sur un serveur, on est toujours au taquet. Alors
la JVM qui swappe et qui se fige parce que le GC a décidé de regarder
ce qui se passe en mémoire, c'est juste complètement idiot comme
fonctionnement.
>> > Tu répètes toujours ça en bougonnant parce que le collecteur
>> > ramasse la mémoire quand ça lui chante plutôt que quand toi tu le
>> > décides à la main de vrai développeur avec qui on ne la fait pas,
>> > mais tu te gardes d'expliquer précisément en quoi c'est
>> > "contre-productif". De quel point de vue ? Elle est quand même
>> > récupérée ta mémoire, non ?
>>
>> Oui, elle est quand même récupérée. Il faut simplement
>> lancer à la main une usine à gaz pour la récupérer. C'est juste ça.
>
> Mais non. Le collecteur récupère la mémoire tout seul s'il en a
> besoin, il n'y a pas besoin de le lancer à la main. Tu peux si tu
> veux, mais ce n'est pas nécessaire.
Ai-je dis le contraire ? Oui, il fonctionne tout seul.
Néanmoins, il vaut mieux dans certains softs le lancer à la main. Je
te donne un exemple très bête. J'ai un programme Java, un serveur,
qui alloue 35 Mo par session utilisateur. Le truc est utilisé par
3000 personnes. Je te laisse le calcul à faire. Problème : lorsqu'un
utilisateur distant a un problème sur sa connexion internet, sa
session s'arrête. Tu me crois si tu veux, mais le GC de la JVM de
Sun, sous Solaris 10/sparc mais plusieurs minutes à libérer
effectivement la mémoire. Alors tu me diras aussi que la JVM de va
pas planter parce qu'en dernier ressort, le GC va passer par là. Mais
avant qu'il ne commence à bosser ton serveur rame comme ce n'est pas
permis parce qu'il swappe ! Donc si tu veux garder des performances
correctes, tu colles un thread qui tourne dans un coin avec un appel
au GC toutes les trentes secondes. C'est exactement ce que j'appelle
de la programmation dégueulasse. Ce qui est aussi marrant, c'est que
la même JVM (numéro de version identique) ne se comporte pas de la
même façon sous Windows, sous OpenVMS ou sous Linux. Sous OpenVMS et
Linux, le GC fonctionne à peu près normalement. Sous Solaris,
il faut se méfier, et sous Windows, c'est une catastrophe. Ne me
demande pas pourquoi, c'est une constatation.
>> > De ne pas être obligé de se faire chier à écrire du code partout
>> > pour traiter les erreurs et arriver au même résultat ? C'est
>> > vrai, c'est trop triste...
>>
>> Le problème des exceptions, c'est exactement le même que
>> celui des GC. Ça récupère tout et n'importe quoi, mais ça le
>> récupère.
>
> On peut parler de trucs précis de la vraie vie ? Comment ça ça
> récupère tout et n'importe quoi ? Les exceptions ne récupèrent rien
> en elle-même.
Rajoute 'gestionnaire' si ça peut te faire plaisir.
>> La seule
>> différence, c'est qu'il faut avoir des gens plus
>> compétents.
>
> Non, ce n'est pas la seule différence. Plus de choses à gérer =>
> plus d'erreurs. A moins que tu écrives des programmes sans jamais
> aucune erreur ?
Alors explique-moi pourquoi les plus belles conneries qui
m'aient été données de voir, c'est justement dans des codes Java ?
> Moins d'attention du développeur gaspillée, moins de pollution dans
> le code.
Aucun rapport. Si tu ne fais pas attention, tu feras des
conneries quel que soit le langage.
>> Ta métaphore est pour le moins bizarre. Là où il te faut un
>> débutant pour bricoler un tru sur un coin de table avec Java, il te
>> faudra des gens plus compétents avec du C ou du C++.
>
> Où est l'avantage du C ici ?
Du langage, rien. Tu auras simplement un dev plus compétent.
>> Et il ne faut
>> surtout pas me faire croire qu'un développeur Java qui ne connaît
>> ni ne comprend rien à la gestion de la mémoire est un bon
>> développeur.
>
> Il y a moins de choses à écrire pour gérer la mémoire correctement
> en Java, si tu ne vois pas l'avantage de mettre moins de bordel
> dans du code, je ne vois pas le problème.
C'est juste un faux avantage. Ça permet juste à des gens qui
ne comprennent pas vraiment ce qu'ils font d'écrire des trucs, choses
qu'ils ne pourraient jamais faire dans un autre langage. Et
c'est ce qui est pervers dans l'utilisation de Java. Utiliser des tas
de notions sans comprendre ce qui est derrière est suicidaire. Et Java
est mauvais à cause de ça. Maintenant, je ne vais pas passer
des heures à essayer d'expliquer pourquoi. J'arrive à comprendre qu'on
trouve pratique certains points du langage, mais cela reste à
mes yeux l'un des pires langages qui existe.
> La partie à comprendre en moins en java c'est les destructeurs
> (C++),
Oui, et on voit les conneries des pointeurs qui ne sont jamais
déréférencés avec ce que ça implique, par exemple...
> la libération de tous les objets en profondeur [jusque là il n'y a
> pas grand chose d'important pour la programmation en général, c'est
> surtout de la pratique] et sans doute des trucs obscurs avec les
> pointeurs, les passages par valeur ou par référence (C++), ... En
> fait pas grand chose, la plupart des choses simplifiées en Java ne
> servent pas à comprendre fondamentalement le fonctionnement de la
> mémoire, il s'agit de bazar à gérer. Ben oui, il y a quelques trucs
> à comprendre quand on programme, il y a juste moins de choses à se
> rappeler en Java, et la plupart ne sont que des contraintes de
> gestion manuelle.
Et c'est justement là qu'on n'est plus du tout d'accord. On
n'est pas d'accord parce que quelqu'un qui passe par les étapes
Fortran->C->C++->Java ne codera pas du tout de la même façon
que ceux qui attaquent directement par du Java. Et bizarrement, ils
feront moins de conneries. On ne peut pas utiliser un
langage, même un truc qui masque tout à l'utilisateur, sans savoir
peu ou prou ce qu'on fait.
> Et tu n'expliques pas en quoi c'est un problème qu'il fasse ça
> quand ça lui chante ou quand il en a besoin. Oui, sur le moment
> c'est plus complexe, et donc ?
Et donc ça te bouffe pour rien des ressources qui seraient
utiles ailleurs. Et ne me dis pas qu'on peut multiplier par dix la
puissance de la machine qui fait tourner la JVM. C'est une réponse
aberrante parce que sur un serveur, on est toujours au taquet. Alors
la JVM qui swappe et qui se fige parce que le GC a décidé de regarder
ce qui se passe en mémoire, c'est juste complètement idiot comme
fonctionnement.
>> > Tu répètes toujours ça en bougonnant parce que le collecteur
>> > ramasse la mémoire quand ça lui chante plutôt que quand toi tu le
>> > décides à la main de vrai développeur avec qui on ne la fait pas,
>> > mais tu te gardes d'expliquer précisément en quoi c'est
>> > "contre-productif". De quel point de vue ? Elle est quand même
>> > récupérée ta mémoire, non ?
>>
>> Oui, elle est quand même récupérée. Il faut simplement
>> lancer à la main une usine à gaz pour la récupérer. C'est juste ça.
>
> Mais non. Le collecteur récupère la mémoire tout seul s'il en a
> besoin, il n'y a pas besoin de le lancer à la main. Tu peux si tu
> veux, mais ce n'est pas nécessaire.
Ai-je dis le contraire ? Oui, il fonctionne tout seul.
Néanmoins, il vaut mieux dans certains softs le lancer à la main. Je
te donne un exemple très bête. J'ai un programme Java, un serveur,
qui alloue 35 Mo par session utilisateur. Le truc est utilisé par
3000 personnes. Je te laisse le calcul à faire. Problème : lorsqu'un
utilisateur distant a un problème sur sa connexion internet, sa
session s'arrête. Tu me crois si tu veux, mais le GC de la JVM de
Sun, sous Solaris 10/sparc mais plusieurs minutes à libérer
effectivement la mémoire. Alors tu me diras aussi que la JVM de va
pas planter parce qu'en dernier ressort, le GC va passer par là. Mais
avant qu'il ne commence à bosser ton serveur rame comme ce n'est pas
permis parce qu'il swappe ! Donc si tu veux garder des performances
correctes, tu colles un thread qui tourne dans un coin avec un appel
au GC toutes les trentes secondes. C'est exactement ce que j'appelle
de la programmation dégueulasse. Ce qui est aussi marrant, c'est que
la même JVM (numéro de version identique) ne se comporte pas de la
même façon sous Windows, sous OpenVMS ou sous Linux. Sous OpenVMS et
Linux, le GC fonctionne à peu près normalement. Sous Solaris,
il faut se méfier, et sous Windows, c'est une catastrophe. Ne me
demande pas pourquoi, c'est une constatation.
>> > De ne pas être obligé de se faire chier à écrire du code partout
>> > pour traiter les erreurs et arriver au même résultat ? C'est
>> > vrai, c'est trop triste...
>>
>> Le problème des exceptions, c'est exactement le même que
>> celui des GC. Ça récupère tout et n'importe quoi, mais ça le
>> récupère.
>
> On peut parler de trucs précis de la vraie vie ? Comment ça ça
> récupère tout et n'importe quoi ? Les exceptions ne récupèrent rien
> en elle-même.
Rajoute 'gestionnaire' si ça peut te faire plaisir.
>> La seule
>> différence, c'est qu'il faut avoir des gens plus
>> compétents.
>
> Non, ce n'est pas la seule différence. Plus de choses à gérer =>
> plus d'erreurs. A moins que tu écrives des programmes sans jamais
> aucune erreur ?
Alors explique-moi pourquoi les plus belles conneries qui
m'aient été données de voir, c'est justement dans des codes Java ?
> Moins d'attention du développeur gaspillée, moins de pollution dans
> le code.
Aucun rapport. Si tu ne fais pas attention, tu feras des
conneries quel que soit le langage.
>> Ta métaphore est pour le moins bizarre. Là où il te faut un
>> débutant pour bricoler un tru sur un coin de table avec Java, il te
>> faudra des gens plus compétents avec du C ou du C++.
>
> Où est l'avantage du C ici ?
Du langage, rien. Tu auras simplement un dev plus compétent.
>> Et il ne faut
>> surtout pas me faire croire qu'un développeur Java qui ne connaît
>> ni ne comprend rien à la gestion de la mémoire est un bon
>> développeur.
>
> Il y a moins de choses à écrire pour gérer la mémoire correctement
> en Java, si tu ne vois pas l'avantage de mettre moins de bordel
> dans du code, je ne vois pas le problème.
C'est juste un faux avantage. Ça permet juste à des gens qui
ne comprennent pas vraiment ce qu'ils font d'écrire des trucs, choses
qu'ils ne pourraient jamais faire dans un autre langage. Et
c'est ce qui est pervers dans l'utilisation de Java. Utiliser des tas
de notions sans comprendre ce qui est derrière est suicidaire. Et Java
est mauvais à cause de ça. Maintenant, je ne vais pas passer
des heures à essayer d'expliquer pourquoi. J'arrive à comprendre qu'on
trouve pratique certains points du langage, mais cela reste à
mes yeux l'un des pires langages qui existe.
> La partie à comprendre en moins en java c'est les destructeurs
> (C++),
Oui, et on voit les conneries des pointeurs qui ne sont jamais
déréférencés avec ce que ça implique, par exemple...
> la libération de tous les objets en profondeur [jusque là il n'y a
> pas grand chose d'important pour la programmation en général, c'est
> surtout de la pratique] et sans doute des trucs obscurs avec les
> pointeurs, les passages par valeur ou par référence (C++), ... En
> fait pas grand chose, la plupart des choses simplifiées en Java ne
> servent pas à comprendre fondamentalement le fonctionnement de la
> mémoire, il s'agit de bazar à gérer. Ben oui, il y a quelques trucs
> à comprendre quand on programme, il y a juste moins de choses à se
> rappeler en Java, et la plupart ne sont que des contraintes de
> gestion manuelle.
Et c'est justement là qu'on n'est plus du tout d'accord. On
n'est pas d'accord parce que quelqu'un qui passe par les étapes
Fortran->C->C++->Java ne codera pas du tout de la même façon
que ceux qui attaquent directement par du Java. Et bizarrement, ils
feront moins de conneries. On ne peut pas utiliser un
langage, même un truc qui masque tout à l'utilisateur, sans savoir
peu ou prou ce qu'on fait.
> Et tu n'expliques pas en quoi c'est un problème qu'il fasse ça
> quand ça lui chante ou quand il en a besoin. Oui, sur le moment
> c'est plus complexe, et donc ?
Et donc ça te bouffe pour rien des ressources qui seraient
utiles ailleurs. Et ne me dis pas qu'on peut multiplier par dix la
puissance de la machine qui fait tourner la JVM. C'est une réponse
aberrante parce que sur un serveur, on est toujours au taquet. Alors
la JVM qui swappe et qui se fige parce que le GC a décidé de regarder
ce qui se passe en mémoire, c'est juste complètement idiot comme
fonctionnement.
>> > Tu répètes toujours ça en bougonnant parce que le collecteur
>> > ramasse la mémoire quand ça lui chante plutôt que quand toi tu le
>> > décides à la main de vrai développeur avec qui on ne la fait pas,
>> > mais tu te gardes d'expliquer précisément en quoi c'est
>> > "contre-productif". De quel point de vue ? Elle est quand même
>> > récupérée ta mémoire, non ?
>>
>> Oui, elle est quand même récupérée. Il faut simplement
>> lancer à la main une usine à gaz pour la récupérer. C'est juste ça.
>
> Mais non. Le collecteur récupère la mémoire tout seul s'il en a
> besoin, il n'y a pas besoin de le lancer à la main. Tu peux si tu
> veux, mais ce n'est pas nécessaire.
Ai-je dis le contraire ? Oui, il fonctionne tout seul.
Néanmoins, il vaut mieux dans certains softs le lancer à la main. Je
te donne un exemple très bête. J'ai un programme Java, un serveur,
qui alloue 35 Mo par session utilisateur. Le truc est utilisé par
3000 personnes. Je te laisse le calcul à faire. Problème : lorsqu'un
utilisateur distant a un problème sur sa connexion internet, sa
session s'arrête. Tu me crois si tu veux, mais le GC de la JVM de
Sun, sous Solaris 10/sparc mais plusieurs minutes à libérer
effectivement la mémoire. Alors tu me diras aussi que la JVM de va
pas planter parce qu'en dernier ressort, le GC va passer par là. Mais
avant qu'il ne commence à bosser ton serveur rame comme ce n'est pas
permis parce qu'il swappe ! Donc si tu veux garder des performances
correctes, tu colles un thread qui tourne dans un coin avec un appel
au GC toutes les trentes secondes. C'est exactement ce que j'appelle
de la programmation dégueulasse. Ce qui est aussi marrant, c'est que
la même JVM (numéro de version identique) ne se comporte pas de la
même façon sous Windows, sous OpenVMS ou sous Linux. Sous OpenVMS et
Linux, le GC fonctionne à peu près normalement. Sous Solaris,
il faut se méfier, et sous Windows, c'est une catastrophe. Ne me
demande pas pourquoi, c'est une constatation.
>> > De ne pas être obligé de se faire chier à écrire du code partout
>> > pour traiter les erreurs et arriver au même résultat ? C'est
>> > vrai, c'est trop triste...
>>
>> Le problème des exceptions, c'est exactement le même que
>> celui des GC. Ça récupère tout et n'importe quoi, mais ça le
>> récupère.
>
> On peut parler de trucs précis de la vraie vie ? Comment ça ça
> récupère tout et n'importe quoi ? Les exceptions ne récupèrent rien
> en elle-même.
Rajoute 'gestionnaire' si ça peut te faire plaisir.
>> La seule
>> différence, c'est qu'il faut avoir des gens plus
>> compétents.
>
> Non, ce n'est pas la seule différence. Plus de choses à gérer =>
> plus d'erreurs. A moins que tu écrives des programmes sans jamais
> aucune erreur ?
Alors explique-moi pourquoi les plus belles conneries qui
m'aient été données de voir, c'est justement dans des codes Java ?
C'est une expérience considérée comme statistiquement objective ?
> Moins d'attention du développeur gaspillée, moins de pollution dans
> le code.
Aucun rapport. Si tu ne fais pas attention, tu feras des
conneries quel que soit le langage.
Tu ne fais *jamais* de conneries ?
>> Ta métaphore est pour le moins bizarre. Là où il te faut un
>> débutant pour bricoler un tru sur un coin de table avec Java, il te
>> faudra des gens plus compétents avec du C ou du C++.
>
> Où est l'avantage du C ici ?
Du langage, rien. Tu auras simplement un dev plus compétent.
Non : tu auras plus de gens capables de faire le même programme, avec
le même niveau de qualité.
>> Et il ne faut
>> surtout pas me faire croire qu'un développeur Java qui ne connaît
>> ni ne comprend rien à la gestion de la mémoire est un bon
>> développeur.
>
> Il y a moins de choses à écrire pour gérer la mémoire correctement
> en Java, si tu ne vois pas l'avantage de mettre moins de bordel
> dans du code, je ne vois pas le problème.
C'est juste un faux avantage. Ça permet juste à des gens qui
ne comprennent pas vraiment ce qu'ils font d'écrire des trucs, choses
qu'ils ne pourraient jamais faire dans un autre langage. Et
c'est ce qui est pervers dans l'utilisation de Java. Utiliser des tas
de notions sans comprendre ce qui est derrière est suicidaire. Et Java
est mauvais à cause de ça. Maintenant, je ne vais pas passer
des heures à essayer d'expliquer pourquoi. J'arrive à comprendre qu'on
trouve pratique certains points du langage, mais cela reste à
mes yeux l'un des pires langages qui existe.
Ça ne permet pas "juste" ça, ça permet aussi à tout le monde d'avoir
autre chose à foutre que se préoccuper des détails. Et s'il y a moins
de choses à comprendre, ce n'est pas forcément suicidaire que les
développeurs en sachent moins sur certains points. Il suffit qu'il
comprenne ce qu'il leur reste à gérer.
> La partie à comprendre en moins en java c'est les destructeurs
> (C++),
Oui, et on voit les conneries des pointeurs qui ne sont jamais
déréférencés avec ce que ça implique, par exemple...
On parle toujours de Java là ? Il y a très peu de choses à
déréférencer, seulement quelques ressources particulières, comme déjà
mentionné (gestion de cache par exemple ; même pour ça on peut
utiliser des références faibles).
> la libération de tous les objets en profondeur [jusque là il n'y a
> pas grand chose d'important pour la programmation en général, c'est
> surtout de la pratique] et sans doute des trucs obscurs avec les
> pointeurs, les passages par valeur ou par référence (C++), ... En
> fait pas grand chose, la plupart des choses simplifiées en Java ne
> servent pas à comprendre fondamentalement le fonctionnement de la
> mémoire, il s'agit de bazar à gérer. Ben oui, il y a quelques trucs
> à comprendre quand on programme, il y a juste moins de choses à se
> rappeler en Java, et la plupart ne sont que des contraintes de
> gestion manuelle.
Et c'est justement là qu'on n'est plus du tout d'accord. On
n'est pas d'accord parce que quelqu'un qui passe par les étapes
Fortran->C->C++->Java ne codera pas du tout de la même façon
que ceux qui attaquent directement par du Java. Et bizarrement, ils
feront moins de conneries. On ne peut pas utiliser un
langage, même un truc qui masque tout à l'utilisateur, sans savoir
peu ou prou ce qu'on fait.
Oui, les développeurs qui ont une formation plus large et/ou plus
approfondie sont mieux formés et donc plus compétent (enfin en
supposant qu'ils aient tout assimilé). Tu veux démontrer que les
développeurs mieux formés sont meilleurs ? Youhou, quelle grande
découverte. Sauf que toutes ces compétences ne sont pas forcément
nécessaires. Dans "peu ou prou", il y a "peu" : les développeurs n'ont
pas besoin de connaître autant de subtilité (ça ne veut pas dire rien,
mais moins de choses), et surtout pas à s'en préoccuper, même s'il
savent comment ça fonctionne.
> Et tu n'expliques pas en quoi c'est un problème qu'il fasse ça
> quand ça lui chante ou quand il en a besoin. Oui, sur le moment
> c'est plus complexe, et donc ?
Et donc ça te bouffe pour rien des ressources qui seraient
utiles ailleurs. Et ne me dis pas qu'on peut multiplier par dix la
puissance de la machine qui fait tourner la JVM. C'est une réponse
aberrante parce que sur un serveur, on est toujours au taquet. Alors
la JVM qui swappe et qui se fige parce que le GC a décidé de regarder
ce qui se passe en mémoire, c'est juste complètement idiot comme
fonctionnement.
Euh... "la JVM qui swappe" ? Tu autorises la JVM à consommer tout ça de
mémoire ?
Si tu veux que le travail du collecteur soit mieux réparti, tu regardes
ses options de configuration au lancement de la JVM et/ou tu le lances
à la main à certains endroits dans ton programme.
>> > Tu répètes toujours ça en bougonnant parce que le collecteur
>> > ramasse la mémoire quand ça lui chante plutôt que quand toi tu le
>> > décides à la main de vrai développeur avec qui on ne la fait pas,
>> > mais tu te gardes d'expliquer précisément en quoi c'est
>> > "contre-productif". De quel point de vue ? Elle est quand même
>> > récupérée ta mémoire, non ?
>>
>> Oui, elle est quand même récupérée. Il faut simplement
>> lancer à la main une usine à gaz pour la récupérer. C'est juste ça.
>
> Mais non. Le collecteur récupère la mémoire tout seul s'il en a
> besoin, il n'y a pas besoin de le lancer à la main. Tu peux si tu
> veux, mais ce n'est pas nécessaire.
Ai-je dis le contraire ? Oui, il fonctionne tout seul.
Néanmoins, il vaut mieux dans certains softs le lancer à la main. Je
te donne un exemple très bête. J'ai un programme Java, un serveur,
qui alloue 35 Mo par session utilisateur. Le truc est utilisé par
3000 personnes. Je te laisse le calcul à faire. Problème : lorsqu'un
utilisateur distant a un problème sur sa connexion internet, sa
session s'arrête. Tu me crois si tu veux, mais le GC de la JVM de
Sun, sous Solaris 10/sparc mais plusieurs minutes à libérer
effectivement la mémoire. Alors tu me diras aussi que la JVM de va
pas planter parce qu'en dernier ressort, le GC va passer par là. Mais
avant qu'il ne commence à bosser ton serveur rame comme ce n'est pas
permis parce qu'il swappe ! Donc si tu veux garder des performances
correctes, tu colles un thread qui tourne dans un coin avec un appel
au GC toutes les trentes secondes. C'est exactement ce que j'appelle
de la programmation dégueulasse. Ce qui est aussi marrant, c'est que
la même JVM (numéro de version identique) ne se comporte pas de la
même façon sous Windows, sous OpenVMS ou sous Linux. Sous OpenVMS et
Linux, le GC fonctionne à peu près normalement. Sous Solaris,
il faut se méfier, et sous Windows, c'est une catastrophe. Ne me
demande pas pourquoi, c'est une constatation.
Je ne sais pas si c'est "dégueulasse" (terme technique à définir), mais
c'est plus simple. Et s'il manque 2 minutes de mémoire sur ton serveur,
il n'y a pas déjà un problème ? Tu veux dire que la collecte
automatique de la mémoire te consomme une poignée de mémoire en plus ?
Le collecteur de mémoire devrait sans doute pouvoir faire ça tout seul,
regarde ses options de configuration.
>> > De ne pas être obligé de se faire chier à écrire du code partout
>> > pour traiter les erreurs et arriver au même résultat ? C'est
>> > vrai, c'est trop triste...
>>
>> Le problème des exceptions, c'est exactement le même que
>> celui des GC. Ça récupère tout et n'importe quoi, mais ça le
>> récupère.
>
> On peut parler de trucs précis de la vraie vie ? Comment ça ça
> récupère tout et n'importe quoi ? Les exceptions ne récupèrent rien
> en elle-même.
Rajoute 'gestionnaire' si ça peut te faire plaisir.
J'ai compris, les gestionnaires d'exceptions récupèrent "tout et"
n'importe quoi. Mais ce n'est pas précis, tu peux expliquer le problème
exact ?
>> La seule
>> différence, c'est qu'il faut avoir des gens plus
>> compétents.
>
> Non, ce n'est pas la seule différence. Plus de choses à gérer =>
> plus d'erreurs. A moins que tu écrives des programmes sans jamais
> aucune erreur ?
Alors explique-moi pourquoi les plus belles conneries qui
m'aient été données de voir, c'est justement dans des codes Java ?
C'est une expérience considérée comme statistiquement objective ?
> Moins d'attention du développeur gaspillée, moins de pollution dans
> le code.
Aucun rapport. Si tu ne fais pas attention, tu feras des
conneries quel que soit le langage.
Tu ne fais *jamais* de conneries ?
>> Ta métaphore est pour le moins bizarre. Là où il te faut un
>> débutant pour bricoler un tru sur un coin de table avec Java, il te
>> faudra des gens plus compétents avec du C ou du C++.
>
> Où est l'avantage du C ici ?
Du langage, rien. Tu auras simplement un dev plus compétent.
Non : tu auras plus de gens capables de faire le même programme, avec
le même niveau de qualité.
>> Et il ne faut
>> surtout pas me faire croire qu'un développeur Java qui ne connaît
>> ni ne comprend rien à la gestion de la mémoire est un bon
>> développeur.
>
> Il y a moins de choses à écrire pour gérer la mémoire correctement
> en Java, si tu ne vois pas l'avantage de mettre moins de bordel
> dans du code, je ne vois pas le problème.
C'est juste un faux avantage. Ça permet juste à des gens qui
ne comprennent pas vraiment ce qu'ils font d'écrire des trucs, choses
qu'ils ne pourraient jamais faire dans un autre langage. Et
c'est ce qui est pervers dans l'utilisation de Java. Utiliser des tas
de notions sans comprendre ce qui est derrière est suicidaire. Et Java
est mauvais à cause de ça. Maintenant, je ne vais pas passer
des heures à essayer d'expliquer pourquoi. J'arrive à comprendre qu'on
trouve pratique certains points du langage, mais cela reste à
mes yeux l'un des pires langages qui existe.
Ça ne permet pas "juste" ça, ça permet aussi à tout le monde d'avoir
autre chose à foutre que se préoccuper des détails. Et s'il y a moins
de choses à comprendre, ce n'est pas forcément suicidaire que les
développeurs en sachent moins sur certains points. Il suffit qu'il
comprenne ce qu'il leur reste à gérer.
> La partie à comprendre en moins en java c'est les destructeurs
> (C++),
Oui, et on voit les conneries des pointeurs qui ne sont jamais
déréférencés avec ce que ça implique, par exemple...
On parle toujours de Java là ? Il y a très peu de choses à
déréférencer, seulement quelques ressources particulières, comme déjà
mentionné (gestion de cache par exemple ; même pour ça on peut
utiliser des références faibles).
> la libération de tous les objets en profondeur [jusque là il n'y a
> pas grand chose d'important pour la programmation en général, c'est
> surtout de la pratique] et sans doute des trucs obscurs avec les
> pointeurs, les passages par valeur ou par référence (C++), ... En
> fait pas grand chose, la plupart des choses simplifiées en Java ne
> servent pas à comprendre fondamentalement le fonctionnement de la
> mémoire, il s'agit de bazar à gérer. Ben oui, il y a quelques trucs
> à comprendre quand on programme, il y a juste moins de choses à se
> rappeler en Java, et la plupart ne sont que des contraintes de
> gestion manuelle.
Et c'est justement là qu'on n'est plus du tout d'accord. On
n'est pas d'accord parce que quelqu'un qui passe par les étapes
Fortran->C->C++->Java ne codera pas du tout de la même façon
que ceux qui attaquent directement par du Java. Et bizarrement, ils
feront moins de conneries. On ne peut pas utiliser un
langage, même un truc qui masque tout à l'utilisateur, sans savoir
peu ou prou ce qu'on fait.
Oui, les développeurs qui ont une formation plus large et/ou plus
approfondie sont mieux formés et donc plus compétent (enfin en
supposant qu'ils aient tout assimilé). Tu veux démontrer que les
développeurs mieux formés sont meilleurs ? Youhou, quelle grande
découverte. Sauf que toutes ces compétences ne sont pas forcément
nécessaires. Dans "peu ou prou", il y a "peu" : les développeurs n'ont
pas besoin de connaître autant de subtilité (ça ne veut pas dire rien,
mais moins de choses), et surtout pas à s'en préoccuper, même s'il
savent comment ça fonctionne.
> Et tu n'expliques pas en quoi c'est un problème qu'il fasse ça
> quand ça lui chante ou quand il en a besoin. Oui, sur le moment
> c'est plus complexe, et donc ?
Et donc ça te bouffe pour rien des ressources qui seraient
utiles ailleurs. Et ne me dis pas qu'on peut multiplier par dix la
puissance de la machine qui fait tourner la JVM. C'est une réponse
aberrante parce que sur un serveur, on est toujours au taquet. Alors
la JVM qui swappe et qui se fige parce que le GC a décidé de regarder
ce qui se passe en mémoire, c'est juste complètement idiot comme
fonctionnement.
Euh... "la JVM qui swappe" ? Tu autorises la JVM à consommer tout ça de
mémoire ?
Si tu veux que le travail du collecteur soit mieux réparti, tu regardes
ses options de configuration au lancement de la JVM et/ou tu le lances
à la main à certains endroits dans ton programme.
>> > Tu répètes toujours ça en bougonnant parce que le collecteur
>> > ramasse la mémoire quand ça lui chante plutôt que quand toi tu le
>> > décides à la main de vrai développeur avec qui on ne la fait pas,
>> > mais tu te gardes d'expliquer précisément en quoi c'est
>> > "contre-productif". De quel point de vue ? Elle est quand même
>> > récupérée ta mémoire, non ?
>>
>> Oui, elle est quand même récupérée. Il faut simplement
>> lancer à la main une usine à gaz pour la récupérer. C'est juste ça.
>
> Mais non. Le collecteur récupère la mémoire tout seul s'il en a
> besoin, il n'y a pas besoin de le lancer à la main. Tu peux si tu
> veux, mais ce n'est pas nécessaire.
Ai-je dis le contraire ? Oui, il fonctionne tout seul.
Néanmoins, il vaut mieux dans certains softs le lancer à la main. Je
te donne un exemple très bête. J'ai un programme Java, un serveur,
qui alloue 35 Mo par session utilisateur. Le truc est utilisé par
3000 personnes. Je te laisse le calcul à faire. Problème : lorsqu'un
utilisateur distant a un problème sur sa connexion internet, sa
session s'arrête. Tu me crois si tu veux, mais le GC de la JVM de
Sun, sous Solaris 10/sparc mais plusieurs minutes à libérer
effectivement la mémoire. Alors tu me diras aussi que la JVM de va
pas planter parce qu'en dernier ressort, le GC va passer par là. Mais
avant qu'il ne commence à bosser ton serveur rame comme ce n'est pas
permis parce qu'il swappe ! Donc si tu veux garder des performances
correctes, tu colles un thread qui tourne dans un coin avec un appel
au GC toutes les trentes secondes. C'est exactement ce que j'appelle
de la programmation dégueulasse. Ce qui est aussi marrant, c'est que
la même JVM (numéro de version identique) ne se comporte pas de la
même façon sous Windows, sous OpenVMS ou sous Linux. Sous OpenVMS et
Linux, le GC fonctionne à peu près normalement. Sous Solaris,
il faut se méfier, et sous Windows, c'est une catastrophe. Ne me
demande pas pourquoi, c'est une constatation.
Je ne sais pas si c'est "dégueulasse" (terme technique à définir), mais
c'est plus simple. Et s'il manque 2 minutes de mémoire sur ton serveur,
il n'y a pas déjà un problème ? Tu veux dire que la collecte
automatique de la mémoire te consomme une poignée de mémoire en plus ?
Le collecteur de mémoire devrait sans doute pouvoir faire ça tout seul,
regarde ses options de configuration.
>> > De ne pas être obligé de se faire chier à écrire du code partout
>> > pour traiter les erreurs et arriver au même résultat ? C'est
>> > vrai, c'est trop triste...
>>
>> Le problème des exceptions, c'est exactement le même que
>> celui des GC. Ça récupère tout et n'importe quoi, mais ça le
>> récupère.
>
> On peut parler de trucs précis de la vraie vie ? Comment ça ça
> récupère tout et n'importe quoi ? Les exceptions ne récupèrent rien
> en elle-même.
Rajoute 'gestionnaire' si ça peut te faire plaisir.
J'ai compris, les gestionnaires d'exceptions récupèrent "tout et"
n'importe quoi. Mais ce n'est pas précis, tu peux expliquer le problème
exact ?
>> La seule
>> différence, c'est qu'il faut avoir des gens plus
>> compétents.
>
> Non, ce n'est pas la seule différence. Plus de choses à gérer =>
> plus d'erreurs. A moins que tu écrives des programmes sans jamais
> aucune erreur ?
Alors explique-moi pourquoi les plus belles conneries qui
m'aient été données de voir, c'est justement dans des codes Java ?
C'est une expérience considérée comme statistiquement objective ?
> Moins d'attention du développeur gaspillée, moins de pollution dans
> le code.
Aucun rapport. Si tu ne fais pas attention, tu feras des
conneries quel que soit le langage.
Tu ne fais *jamais* de conneries ?
>> Ta métaphore est pour le moins bizarre. Là où il te faut un
>> débutant pour bricoler un tru sur un coin de table avec Java, il te
>> faudra des gens plus compétents avec du C ou du C++.
>
> Où est l'avantage du C ici ?
Du langage, rien. Tu auras simplement un dev plus compétent.
Non : tu auras plus de gens capables de faire le même programme, avec
le même niveau de qualité.
>> Et il ne faut
>> surtout pas me faire croire qu'un développeur Java qui ne connaît
>> ni ne comprend rien à la gestion de la mémoire est un bon
>> développeur.
>
> Il y a moins de choses à écrire pour gérer la mémoire correctement
> en Java, si tu ne vois pas l'avantage de mettre moins de bordel
> dans du code, je ne vois pas le problème.
C'est juste un faux avantage. Ça permet juste à des gens qui
ne comprennent pas vraiment ce qu'ils font d'écrire des trucs, choses
qu'ils ne pourraient jamais faire dans un autre langage. Et
c'est ce qui est pervers dans l'utilisation de Java. Utiliser des tas
de notions sans comprendre ce qui est derrière est suicidaire. Et Java
est mauvais à cause de ça. Maintenant, je ne vais pas passer
des heures à essayer d'expliquer pourquoi. J'arrive à comprendre qu'on
trouve pratique certains points du langage, mais cela reste à
mes yeux l'un des pires langages qui existe.
Ça ne permet pas "juste" ça, ça permet aussi à tout le monde d'avoir
autre chose à foutre que se préoccuper des détails. Et s'il y a moins
de choses à comprendre, ce n'est pas forcément suicidaire que les
développeurs en sachent moins sur certains points. Il suffit qu'il
comprenne ce qu'il leur reste à gérer.
> La partie à comprendre en moins en java c'est les destructeurs
> (C++),
Oui, et on voit les conneries des pointeurs qui ne sont jamais
déréférencés avec ce que ça implique, par exemple...
On parle toujours de Java là ? Il y a très peu de choses à
déréférencer, seulement quelques ressources particulières, comme déjà
mentionné (gestion de cache par exemple ; même pour ça on peut
utiliser des références faibles).
> la libération de tous les objets en profondeur [jusque là il n'y a
> pas grand chose d'important pour la programmation en général, c'est
> surtout de la pratique] et sans doute des trucs obscurs avec les
> pointeurs, les passages par valeur ou par référence (C++), ... En
> fait pas grand chose, la plupart des choses simplifiées en Java ne
> servent pas à comprendre fondamentalement le fonctionnement de la
> mémoire, il s'agit de bazar à gérer. Ben oui, il y a quelques trucs
> à comprendre quand on programme, il y a juste moins de choses à se
> rappeler en Java, et la plupart ne sont que des contraintes de
> gestion manuelle.
Et c'est justement là qu'on n'est plus du tout d'accord. On
n'est pas d'accord parce que quelqu'un qui passe par les étapes
Fortran->C->C++->Java ne codera pas du tout de la même façon
que ceux qui attaquent directement par du Java. Et bizarrement, ils
feront moins de conneries. On ne peut pas utiliser un
langage, même un truc qui masque tout à l'utilisateur, sans savoir
peu ou prou ce qu'on fait.
Oui, les développeurs qui ont une formation plus large et/ou plus
approfondie sont mieux formés et donc plus compétent (enfin en
supposant qu'ils aient tout assimilé). Tu veux démontrer que les
développeurs mieux formés sont meilleurs ? Youhou, quelle grande
découverte. Sauf que toutes ces compétences ne sont pas forcément
nécessaires. Dans "peu ou prou", il y a "peu" : les développeurs n'ont
pas besoin de connaître autant de subtilité (ça ne veut pas dire rien,
mais moins de choses), et surtout pas à s'en préoccuper, même s'il
savent comment ça fonctionne.
> Et tu n'expliques pas en quoi c'est un problème qu'il fasse ça
> quand ça lui chante ou quand il en a besoin. Oui, sur le moment
> c'est plus complexe, et donc ?
Et donc ça te bouffe pour rien des ressources qui seraient
utiles ailleurs. Et ne me dis pas qu'on peut multiplier par dix la
puissance de la machine qui fait tourner la JVM. C'est une réponse
aberrante parce que sur un serveur, on est toujours au taquet. Alors
la JVM qui swappe et qui se fige parce que le GC a décidé de regarder
ce qui se passe en mémoire, c'est juste complètement idiot comme
fonctionnement.
Euh... "la JVM qui swappe" ? Tu autorises la JVM à consommer tout ça de
mémoire ?
Si tu veux que le travail du collecteur soit mieux réparti, tu regardes
ses options de configuration au lancement de la JVM et/ou tu le lances
à la main à certains endroits dans ton programme.
>> > Tu répètes toujours ça en bougonnant parce que le collecteur
>> > ramasse la mémoire quand ça lui chante plutôt que quand toi tu le
>> > décides à la main de vrai développeur avec qui on ne la fait pas,
>> > mais tu te gardes d'expliquer précisément en quoi c'est
>> > "contre-productif". De quel point de vue ? Elle est quand même
>> > récupérée ta mémoire, non ?
>>
>> Oui, elle est quand même récupérée. Il faut simplement
>> lancer à la main une usine à gaz pour la récupérer. C'est juste ça.
>
> Mais non. Le collecteur récupère la mémoire tout seul s'il en a
> besoin, il n'y a pas besoin de le lancer à la main. Tu peux si tu
> veux, mais ce n'est pas nécessaire.
Ai-je dis le contraire ? Oui, il fonctionne tout seul.
Néanmoins, il vaut mieux dans certains softs le lancer à la main. Je
te donne un exemple très bête. J'ai un programme Java, un serveur,
qui alloue 35 Mo par session utilisateur. Le truc est utilisé par
3000 personnes. Je te laisse le calcul à faire. Problème : lorsqu'un
utilisateur distant a un problème sur sa connexion internet, sa
session s'arrête. Tu me crois si tu veux, mais le GC de la JVM de
Sun, sous Solaris 10/sparc mais plusieurs minutes à libérer
effectivement la mémoire. Alors tu me diras aussi que la JVM de va
pas planter parce qu'en dernier ressort, le GC va passer par là. Mais
avant qu'il ne commence à bosser ton serveur rame comme ce n'est pas
permis parce qu'il swappe ! Donc si tu veux garder des performances
correctes, tu colles un thread qui tourne dans un coin avec un appel
au GC toutes les trentes secondes. C'est exactement ce que j'appelle
de la programmation dégueulasse. Ce qui est aussi marrant, c'est que
la même JVM (numéro de version identique) ne se comporte pas de la
même façon sous Windows, sous OpenVMS ou sous Linux. Sous OpenVMS et
Linux, le GC fonctionne à peu près normalement. Sous Solaris,
il faut se méfier, et sous Windows, c'est une catastrophe. Ne me
demande pas pourquoi, c'est une constatation.
Je ne sais pas si c'est "dégueulasse" (terme technique à définir), mais
c'est plus simple. Et s'il manque 2 minutes de mémoire sur ton serveur,
il n'y a pas déjà un problème ? Tu veux dire que la collecte
automatique de la mémoire te consomme une poignée de mémoire en plus ?
Le collecteur de mémoire devrait sans doute pouvoir faire ça tout seul,
regarde ses options de configuration.
>> > De ne pas être obligé de se faire chier à écrire du code partout
>> > pour traiter les erreurs et arriver au même résultat ? C'est
>> > vrai, c'est trop triste...
>>
>> Le problème des exceptions, c'est exactement le même que
>> celui des GC. Ça récupère tout et n'importe quoi, mais ça le
>> récupère.
>
> On peut parler de trucs précis de la vraie vie ? Comment ça ça
> récupère tout et n'importe quoi ? Les exceptions ne récupèrent rien
> en elle-même.
Rajoute 'gestionnaire' si ça peut te faire plaisir.
J'ai compris, les gestionnaires d'exceptions récupèrent "tout et"
n'importe quoi. Mais ce n'est pas précis, tu peux expliquer le problème
exact ?
Euh... "la JVM qui swappe" ? Tu autorises la JVM à consommer tout ça de
mémoire ?
Euh... "la JVM qui swappe" ? Tu autorises la JVM à consommer tout ça de
mémoire ?
Euh... "la JVM qui swappe" ? Tu autorises la JVM à consommer tout ça de
mémoire ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 20/06/2011 14:50, totof01 a écrit :
> Imagine que ton code est chargé de gérer le déplacement d'une mac hine-
> outil, et que ton malloc se vautre alors que tu es en train de faire
> un positionnement en vitesse rapide de ton outil. Il serait plus
> judicieux de couper les moteurs de déplacement de ton outil avent de
> se vautrer non ? Si tu laisses un segfault se produire avant de couper
> ton moteur, et que tu attaques la matiere en vitesse rapide, ça risqu e
> d'être drole.
Ai-je dis le contraire ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 20/06/2011 14:50, totof01 a écrit :
> Imagine que ton code est chargé de gérer le déplacement d'une mac hine-
> outil, et que ton malloc se vautre alors que tu es en train de faire
> un positionnement en vitesse rapide de ton outil. Il serait plus
> judicieux de couper les moteurs de déplacement de ton outil avent de
> se vautrer non ? Si tu laisses un segfault se produire avant de couper
> ton moteur, et que tu attaques la matiere en vitesse rapide, ça risqu e
> d'être drole.
Ai-je dis le contraire ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 20/06/2011 14:50, totof01 a écrit :
> Imagine que ton code est chargé de gérer le déplacement d'une mac hine-
> outil, et que ton malloc se vautre alors que tu es en train de faire
> un positionnement en vitesse rapide de ton outil. Il serait plus
> judicieux de couper les moteurs de déplacement de ton outil avent de
> se vautrer non ? Si tu laisses un segfault se produire avant de couper
> ton moteur, et que tu attaques la matiere en vitesse rapide, ça risqu e
> d'être drole.
Ai-je dis le contraire ?
Avec quinze ans de pratique sur les deux, je pense que ça commence
à montrer une tendance.
Avec quinze ans de pratique sur les deux, je pense que ça commence
à montrer une tendance.
Avec quinze ans de pratique sur les deux, je pense que ça commence
à montrer une tendance.
Qu'est-ce qu'il ne faut pas lire...
JKB
Qu'est-ce qu'il ne faut pas lire...
JKB
Qu'est-ce qu'il ne faut pas lire...
JKB
>> > Non, ce n'est pas la seule différence. Plus de choses à gérer =>
>> > plus d'erreurs. A moins que tu écrives des programmes sans jamais
>> > aucune erreur ?
>>
>> Alors explique-moi pourquoi les plus belles conneries qui
>> m'aient été données de voir, c'est justement dans des codes Java ?
>
> C'est une expérience considérée comme statistiquement objective ?
Avec quinze ans de pratique sur les deux, je pense que ça
commence à montrer une tendance.
>> > Moins d'attention du développeur gaspillée, moins de pollution
>> > dans le code.
>>
>> Aucun rapport. Si tu ne fais pas attention, tu feras des
>> conneries quel que soit le langage.
>
> Tu ne fais *jamais* de conneries ?
Ai-je prétendu le contraire ?
>> > La partie à comprendre en moins en java c'est les destructeurs
>> > (C++),
>>
>> Oui, et on voit les conneries des pointeurs qui ne sont
>> jamais déréférencés avec ce que ça implique, par exemple...
>
> On parle toujours de Java là ? Il y a très peu de choses à
> déréférencer, seulement quelques ressources particulières, comme
> déjà mentionné (gestion de cache par exemple ; même pour ça on peut
> utiliser des références faibles).
Lorsqu'il reste un pointeur quelque part qui pointe sur une
zone de la mémoire, cette zone n'est pas libérée. C'est un effet
pervers du GC, que tu le veuilles ou non. Et ce genre de bêtise est
très vite fait.
> Oui, les développeurs qui ont une formation plus large et/ou plus
> approfondie sont mieux formés et donc plus compétent (enfin en
> supposant qu'ils aient tout assimilé). Tu veux démontrer que les
> développeurs mieux formés sont meilleurs ? Youhou, quelle grande
> découverte. Sauf que toutes ces compétences ne sont pas forcément
> nécessaires. Dans "peu ou prou", il y a "peu" : les développeurs
> n'ont pas besoin de connaître autant de subtilité (ça ne veut pas
> dire rien, mais moins de choses), et surtout pas à s'en préoccuper,
> même s'il savent comment ça fonctionne.
Il y a deux niveaux. Celui où le dev sait que ça se passe
d'une certaine façon même s'il ne doit pas le gérer et celui où le
dev ne pipe mot à ce qu'il fait parce qu'il n'a pas conscience des
mécanismes. Mon expérience me dit que la plupart des devs
java qui n'ont fait que du java sont dans la deuxième catégorie. Et
figure-toi, ça me pose quelques problèmes quand je suis
obligé de passer derrière eux.
Pour ta gouverne, la JVM de Sun outrepasse allègrement les
options de mémoire minimale et maximale. Ne me demande pas pourquoi,
mais c'est un fait. J'ai un processus qui est censé ne pas dépasser
plus d'un Go de mémoire, et il occupe présentement 6 Go de mémoire de
autant de swap (Solaris sparc avec une JVM 1.6 64 bits). La
aussi, la JVM (ou son GC) sait mieux que le dev ce qu'il faut
utiliser comme paramètres. En fait, j'ai de plus en plus l'impression
que Java, c'est le microsoft des langage. Il sait mieux qu'un dev ce
qui est bon pour lui.
Je t'ai aussi déjà expliqué que dans la vraie vie, le dev qui
est pressé et dont le compilateur râle colle un gestionnaire
ramasse-tout (c'est aussi vrai en C++) et au final, c'est
contre-productif.
>> > Non, ce n'est pas la seule différence. Plus de choses à gérer =>
>> > plus d'erreurs. A moins que tu écrives des programmes sans jamais
>> > aucune erreur ?
>>
>> Alors explique-moi pourquoi les plus belles conneries qui
>> m'aient été données de voir, c'est justement dans des codes Java ?
>
> C'est une expérience considérée comme statistiquement objective ?
Avec quinze ans de pratique sur les deux, je pense que ça
commence à montrer une tendance.
>> > Moins d'attention du développeur gaspillée, moins de pollution
>> > dans le code.
>>
>> Aucun rapport. Si tu ne fais pas attention, tu feras des
>> conneries quel que soit le langage.
>
> Tu ne fais *jamais* de conneries ?
Ai-je prétendu le contraire ?
>> > La partie à comprendre en moins en java c'est les destructeurs
>> > (C++),
>>
>> Oui, et on voit les conneries des pointeurs qui ne sont
>> jamais déréférencés avec ce que ça implique, par exemple...
>
> On parle toujours de Java là ? Il y a très peu de choses à
> déréférencer, seulement quelques ressources particulières, comme
> déjà mentionné (gestion de cache par exemple ; même pour ça on peut
> utiliser des références faibles).
Lorsqu'il reste un pointeur quelque part qui pointe sur une
zone de la mémoire, cette zone n'est pas libérée. C'est un effet
pervers du GC, que tu le veuilles ou non. Et ce genre de bêtise est
très vite fait.
> Oui, les développeurs qui ont une formation plus large et/ou plus
> approfondie sont mieux formés et donc plus compétent (enfin en
> supposant qu'ils aient tout assimilé). Tu veux démontrer que les
> développeurs mieux formés sont meilleurs ? Youhou, quelle grande
> découverte. Sauf que toutes ces compétences ne sont pas forcément
> nécessaires. Dans "peu ou prou", il y a "peu" : les développeurs
> n'ont pas besoin de connaître autant de subtilité (ça ne veut pas
> dire rien, mais moins de choses), et surtout pas à s'en préoccuper,
> même s'il savent comment ça fonctionne.
Il y a deux niveaux. Celui où le dev sait que ça se passe
d'une certaine façon même s'il ne doit pas le gérer et celui où le
dev ne pipe mot à ce qu'il fait parce qu'il n'a pas conscience des
mécanismes. Mon expérience me dit que la plupart des devs
java qui n'ont fait que du java sont dans la deuxième catégorie. Et
figure-toi, ça me pose quelques problèmes quand je suis
obligé de passer derrière eux.
Pour ta gouverne, la JVM de Sun outrepasse allègrement les
options de mémoire minimale et maximale. Ne me demande pas pourquoi,
mais c'est un fait. J'ai un processus qui est censé ne pas dépasser
plus d'un Go de mémoire, et il occupe présentement 6 Go de mémoire de
autant de swap (Solaris sparc avec une JVM 1.6 64 bits). La
aussi, la JVM (ou son GC) sait mieux que le dev ce qu'il faut
utiliser comme paramètres. En fait, j'ai de plus en plus l'impression
que Java, c'est le microsoft des langage. Il sait mieux qu'un dev ce
qui est bon pour lui.
Je t'ai aussi déjà expliqué que dans la vraie vie, le dev qui
est pressé et dont le compilateur râle colle un gestionnaire
ramasse-tout (c'est aussi vrai en C++) et au final, c'est
contre-productif.
>> > Non, ce n'est pas la seule différence. Plus de choses à gérer =>
>> > plus d'erreurs. A moins que tu écrives des programmes sans jamais
>> > aucune erreur ?
>>
>> Alors explique-moi pourquoi les plus belles conneries qui
>> m'aient été données de voir, c'est justement dans des codes Java ?
>
> C'est une expérience considérée comme statistiquement objective ?
Avec quinze ans de pratique sur les deux, je pense que ça
commence à montrer une tendance.
>> > Moins d'attention du développeur gaspillée, moins de pollution
>> > dans le code.
>>
>> Aucun rapport. Si tu ne fais pas attention, tu feras des
>> conneries quel que soit le langage.
>
> Tu ne fais *jamais* de conneries ?
Ai-je prétendu le contraire ?
>> > La partie à comprendre en moins en java c'est les destructeurs
>> > (C++),
>>
>> Oui, et on voit les conneries des pointeurs qui ne sont
>> jamais déréférencés avec ce que ça implique, par exemple...
>
> On parle toujours de Java là ? Il y a très peu de choses à
> déréférencer, seulement quelques ressources particulières, comme
> déjà mentionné (gestion de cache par exemple ; même pour ça on peut
> utiliser des références faibles).
Lorsqu'il reste un pointeur quelque part qui pointe sur une
zone de la mémoire, cette zone n'est pas libérée. C'est un effet
pervers du GC, que tu le veuilles ou non. Et ce genre de bêtise est
très vite fait.
> Oui, les développeurs qui ont une formation plus large et/ou plus
> approfondie sont mieux formés et donc plus compétent (enfin en
> supposant qu'ils aient tout assimilé). Tu veux démontrer que les
> développeurs mieux formés sont meilleurs ? Youhou, quelle grande
> découverte. Sauf que toutes ces compétences ne sont pas forcément
> nécessaires. Dans "peu ou prou", il y a "peu" : les développeurs
> n'ont pas besoin de connaître autant de subtilité (ça ne veut pas
> dire rien, mais moins de choses), et surtout pas à s'en préoccuper,
> même s'il savent comment ça fonctionne.
Il y a deux niveaux. Celui où le dev sait que ça se passe
d'une certaine façon même s'il ne doit pas le gérer et celui où le
dev ne pipe mot à ce qu'il fait parce qu'il n'a pas conscience des
mécanismes. Mon expérience me dit que la plupart des devs
java qui n'ont fait que du java sont dans la deuxième catégorie. Et
figure-toi, ça me pose quelques problèmes quand je suis
obligé de passer derrière eux.
Pour ta gouverne, la JVM de Sun outrepasse allègrement les
options de mémoire minimale et maximale. Ne me demande pas pourquoi,
mais c'est un fait. J'ai un processus qui est censé ne pas dépasser
plus d'un Go de mémoire, et il occupe présentement 6 Go de mémoire de
autant de swap (Solaris sparc avec une JVM 1.6 64 bits). La
aussi, la JVM (ou son GC) sait mieux que le dev ce qu'il faut
utiliser comme paramètres. En fait, j'ai de plus en plus l'impression
que Java, c'est le microsoft des langage. Il sait mieux qu'un dev ce
qui est bon pour lui.
Je t'ai aussi déjà expliqué que dans la vraie vie, le dev qui
est pressé et dont le compilateur râle colle un gestionnaire
ramasse-tout (c'est aussi vrai en C++) et au final, c'est
contre-productif.
Le 21/06/2011 14:57, JKB a écrit :Avec quinze ans de pratique sur les deux, je pense que ça commence
à montrer une tendance.
C'est facile de comparer un code en C avec 15 ans d'XP avec le même code
Java avec 0 XP et d'en tirer des conclusions sur la comète…
Le 21/06/2011 14:57, JKB a écrit :
Avec quinze ans de pratique sur les deux, je pense que ça commence
à montrer une tendance.
C'est facile de comparer un code en C avec 15 ans d'XP avec le même code
Java avec 0 XP et d'en tirer des conclusions sur la comète…
Le 21/06/2011 14:57, JKB a écrit :Avec quinze ans de pratique sur les deux, je pense que ça commence
à montrer une tendance.
C'est facile de comparer un code en C avec 15 ans d'XP avec le même code
Java avec 0 XP et d'en tirer des conclusions sur la comète…
