Microsoft et Java

Le Mon, 20 Jun 2011 13:25:42 +0000 (UTC)
JKB <jkb@koenigsberg.invalid> a écrit :

Le Mon, 20 Jun 2011 15:09:11 +0200,
Yliur <yliur@free.fr> écrivait :
>> Ce qui me pose problème, c'est la rigidité du
>> 'je suis obligé de coller un gestionnaire d'exception, sauf
>> que là, je n'ai pas le temps, et comme je ne veux pas m'emmerder,
>> je colle un gestionnaire générique qui ne fait rien parce que ça
>> ira bien'.
>
> Quelle différence avec 'je suis obligé de coller une gestion
> d'erreur, sauf que là, je n'ai pas le temps, et comme je ne veux pas
> m'emmerder, je ne fais rien parce que ça ira bien' ?

C'est au contraire très différent. En C, tu écris une gestion
des erreurs volontairement. En Java, tu l'écris parce que sans, ça ne
compile pas.

Non.

En C tu l'écris volontairement (ou te ne l'écris pas, auquel cas tu es
dans un cas bien bien pourri où ton programme fait n'importe quoi). Et
tu l'écris partout. Et le développeur C de base ne l'écrit pas, ou
alors juste ce qui l'inspire, ou ce qui lui a posé problème. Tu n'as
jamais vu un programme en C où les erreurs n'étaient pas gérées,
parce que ça serait fait plus tard ?

En Java tu l'écris volontairement seulement là où il y a quelque
chose à gérer. Où alors tu ne l'écris pas et soit le compilateur le
fait remarquer, soit tu es dans un cas vaguement moins pourri qu'en C
parce qu'au moins l'erreur est remontée.

La différence est qu'avec Java, le dev de base
commence par écrire un méchant catch all en se disant qu'il
peaufinera plus tard, ce qui est rarement fait. La démarche n'est pas
du tout la même.

Le compilateur ne fait que signaler le problème, il ne peut pas
t'obliger à le résoudre proprement. Il met au moins le doigt dessus, ce
qui n'est pas le cas en C.

Le Mon, 20 Jun 2011 15:51:02 +0200,
Yliur <yliur@free.fr> écrivait :

>> Ça, c'est parce que tu n'en as rien à faire. Appelle un peu
>> le GC à la main sur une application serveur écrite en Java, et tu
>> vas voir qu'il est particulièrement inefficace.
>
> ?
> Tu veux dire qu'il est lent ? Ou qu'il ne fait pas son boulot
> correctement ?

Qu'il réagit et libère la mémoire avec beaucoup de retard.
Quand dans une application, un appel explicite au GC te
libère d'un seul coup 50% de la mémoire utilisée, c'est qu'il est
mauvais.

Pourquoi ? La JVM avait peut-être bien mieux à faire avant. La mémoire
non libérée est quand même virtuellement disponible : en cas de manque,
le collecteur va venir la chercher.

Et si pour une raison ou une autre tu penses que tu sais mieux que la
JVM quand la récupération de la mémoire est souhaitable (tu sais
qu'entre deux opérations il va y avoir un moment à ne rien faire par
exemple), tu peux toujours la guider en demandant la collecte à ce
moment.

C'est exactement mon discours.

> Est-ce que quand le développement C est à la bourre, le développeur
> C fait appel à ses pouvoirs magiques (divins), une grande lumière
> descend du ciel et l'aide à travailler deux fois plus vite pour
> faire à la main et correctement toutes les vérifications d'erreur
> et toute la libération de la mémoire ?

Il y a juste une différence. Le dev C, en général, est
beaucoup plus capé que le développeur Java parce que le langage est
plus difficile d'accès.

Mais le langage est plus difficile, ce qui équilibre. Il y a plus de
trucs à gérer, c'est plus compliqué, pour arriver à faire des
programmes qui marchent aussi bien il faut une formation/pratique plus
grande. Le seul résultat c'est que tu te retrouves avec moins de
développeurs capables de faire le boulot.

Et du code de bien meilleure qualité en règle générale.

>> Je pense
>> pour ma part que ce truc est le pire des traitements d'erreur parce
>> qu'il s'appuie sur tout un tas de choses y compris le GC.
>
> On peut lister les choses ? Ça peut être intéressant pour
> comprendre en quoi c'est gênant.

Sur la remontée des erreurs sur la pile (c'est justement
l'intérêt de l'exception).
Sur le GC pour libérer ce qui doit être libéré.
Sur le système d'interruption hard (ou une émulation de
celui-ci). Et c'est sans compter sur quelques interactions amusantes
avec l'OS.

Bon, maintenant qu'on a la liste, on peut savoir en quoi c'est gênant ?
Enfin les deux premiers points ont déjà l'air en cours de discussion, si
je comprends bien ce que tu dis...

Je crois avoir déjà expliqué en quoi c'est gênant...

>> C'est une
>> aberration totale parce qu'on n'a pas envie que le
>> développe sache (faire) une gestion propre et efficace qui est un
>> peu plus complexe. J'ai sous le coude une application Java, à peu
>> près écrite correctement qui fonctionne sur une architecture trois
>> tiers en réseau. À chaque fois qu'il y a un paquet qui passe à la
>> trappe ou une session utilisateur qui se bauge, les erreurs sont
>> récupérées, mais il faut un temps certain pour que le GC libère la
>> mémoire associée et un appel à la main peu libérer plusieurs
>> centaines de Mo !
>
> Et... ?

Ben c'était là qu'il fallait répondre.

> Tiens, rien à voir, mais on peut en faire des trucs amusants. J'ai
> vu des gens expliquer comment avec beaucoup de mémoire pour la JVM
> on pouvait la lancer en mode "optimisations agressives" : le
> collecteur de mémoire ne s'occupe pas de récupérer de la mémoire
> avant qu'il n'y en ait plus de disponible (au moins tant qu'il y a
> autre chose à exécuter). Donc si l'appli n'a pas besoin d'être sur
> pied 100% du temps on peut décider au moment de la lancer de la
> laisser goinfrer la mémoire puis l'éteindre et la relancer pour
> éviter le temps passer à récupérer la mémoire.

Et c'est intelligent ? Ce qui coûte cher, c'est l'allocation
de la mémoire, pas sa libération.

Là c'était un truc pas très important, qui me passait par la tête (pour
les développeurs Java plutôt), comme je l'indiquais.

Le GC est un truc qui n'est là que
pour obvier aux problèmes des développeurs infichus d'utiliser la
mémoire correctement.

Phrase de vieux con (désolé mais bon...).
Considérer que les outils pour simplifier le développement (ou quoi que
ce soit dans ce que les humains produisent) sert juste aux guignols qui
ne savent pas faire ça "comme les vrais" est historiquement idiot. Oui,
des outils qui simplifient la construction de couches supérieures çà
peut avoir des inconvénients, oui ça permet à plus de gens de
travailler dans le domaine, sans avoir à tout connaître (ce qui a
un avantage évident), mais les réduire à leurs inconvénients sans voir
les avantages c'est juste une phrase traditionnelle des vieux vers les
jeunes (pour simplifier un peu) : "pfff... de notre temps on savait
faire correctement". C'est rigolo mais ça néglige complètement les
questions de productivité, de quantité de main d'oeuvre
nécessaire/disponible, de complexité croissante (des logiciels par
exemple), ... C'est défendre l'artisanat contre l'industrie en disant :
"bah c'est tout pourri" (ben merci pour la subtilité). Oui, il peut y
avoir des avantages à l'artisanat et des inconvénients à l'industrie,
mais nier en vrac les avantages de l'industrialisation en terme de
productivité, de fiabilité, ... c'est légèrement un petit peu n'importe
quoi.

Je ne vois vraiment pas le rapport. Qu'est-ce qui empêche de coder
correctement ? Ce n'est ni plus difficile ni plus long. La seule
différence, c'est qu'il faut avoir des gens plus compétents. 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++. 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.

>> Résultat des courses, toutes les erreurs sont gérés
>> à la C, proprement, car la gestion par exception faisait juste
>> planter la JVM sur un 'out of memory exception' !
>
> On pourrait avoir le code incriminé avant d'attribuer ça aux
> exceptions ou au ramasse-miettes ? Le collecteur de mémoire est
> censé récupérer la mémoire quand elle n'est plus utilisée (et qu'il
> n'a rien à faire ou qu'il a besoin de mémoire ailleurs par exemple),
> donc il n'y a pas de lien entre le fait qu'il la récupère par gros
> paquets et le fait qu'il en manque.

Le problème est qu'il fait ça quand ça lui chante.

Je ne vois pas le rapport avec ton erreur de mémoire : il fait ça quand
ça lui chante ou quand il en a besoin.

Alors là, excuse-moi, mais je me marre. Oui, il fait ça quand ça lui
chante. Lorsque tu fais un free() dans un bout de code C (ou un
delete en C++), tu as déjà marqué la mémoire comme disponible. Si
ton allocateur n'est pas fait n'importe comment, il utilise un
système évolué qui fait qu'il a déjà dans une liste la taille du
bloc libéré. Le fait de réallouer de la mémoire sera quasi immédiat.
Si ton GC qui ne s'est pas encore déclanché n'a plus de mémoire, il
faut d'abord qu'il récupère les miettes. Le boulot est beaucoup plus
complexe qu'une seule allocation. Tu peux regarder comment est fichu
Boehm-GC, c'est instructif. Le GC est une hérésie qui ne se justifie
que par le fait que certains développeurs ne veulent pas gérer la
mémoire.

> L'appli ne sait en général pas quoi faire de l'erreur localement
> (quel que soit le système) : elle ne sait que libérer des
> ressources et faire remonter l'erreur. Donc sur le chemin il faut
> tout libérer. En C ça consiste à écrire dans toutes les fonctions
> du code de gestion des erreurs et de libération de la mémoire. En
> Java ça consiste simplement à écrire un try/finally autour du code
> gérant certaines ressources (fichiers, ...), le reste du temps la
> mémoire n'est pas gérée à la main. Donc il n'y a pas besoin de
> remplir le code de gestion d'erreurs, il suffit de se concentrer
> sur les points où ces ressources sont manipulées.

Et c'est justement ce qui fait que c'est mauvais. Si tu as une
petite application et 8 Go de mémoire, c'est peut-être
efficace. Autrement, c'est contre-productif.

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.

> L'appli sait en général "traiter" l'erreur à plus haut niveau : il
> s'agit de remonter l'erreur le plus précisément possible et de
> décider de la politique de gestion des erreurs (si tel traitement
> plante, qu'est-ce que je fais ?). Je ne vois pas la différence
> entre les codes d'erreur et les exceptions pour ça (à part que les
> exceptions sont des objets faciles à remonter et qui peuvent
> contenir facilement beaucoup d'information).

Euh... Comment dire... Non. Tu as au contraire moins
d'information parce qu'elle est moins fine. L'exception que tu
récupères tout en haut est une exception sur un ensemble de lignes de
code (sinon, tu utiliserais une gestion à la C). L'information sur ce
qui s'est passé réellement est difficile à extraire.

Je voulais dire que tu peux entasser facilement plein d'information
dans l'objet, c'est tout.
Mais le code d'erreur que tu récupères tout en haut, il ne concerne pas
un ensemble de lignes de code ?

Non. Il récupère l'erreur d'une fonction. C'est toute la différence
entre le code d'erreur et l'exception.

>> la syntaxe java consiste à mettre des
>> gestionnaires d'exception un peu partout,
>
> Non.

Ah bon ? Les try{} catch() que mon compilo m'impose ne sont
pas obligatoires ?

S'il te l'impose, sans doute. Mais ce n'est pas la même chose que "un
peu partout". Il y en a besoin à certains endroits seulement. Il y a
beaucoup moins de chose à écrire que pour gérer des codes d'erreur et
tout libérer sur le trajet retour.

>> renvoyer l'exception au père,
>> grand'père ou arrière-grand'père voire pire par un throw.
>
> En quoi c'est pire ?

Parce que ça saute des appels de fonction. Si tu ne vois pas
la différence entre les deux façons de faire, je ne puis rien pour
toi.

Je vois très bien la différence, et ça saute les appels de fonction
parce qu'il n'y a rien à faire, ce n'est pas compliqué à comprendre
quand même...

En C tu es *obligé* de tout gérer pas à pas, de gérer les erreurs
*partout* parce que dans de très nombreuses fonctions tu as quelque
chose à libérer (ne serait-ce que de la mémoire). En Java tu n'as pas à
faire ça : tu te contentes de protéger les ressources qui doivent
l'être (beaucoup moins de choses qu'en C, ça ne concerne que quelques
types de ressources) et de traiter le problème à un second niveau (plus
haut) pour décider ce comment l'appli doit réagir à cet événement
imprévu.

Déjà, là, on a un problème. Une erreur _doit_ être un événement
prévu.

Et je ne vois pas en quoi être obligé de tout se taper à la main c'est
moins pire que juste le faire là où il faut (remarque en C il faut
aussi le faire "juste là où il faut", sauf que c'est partout ; ah ben
non, même là où il n'y a rien à faire il faut se taper la remonté des
codes d'erreur quand même).

>> Le seul
>> moyen de gérer correctement une erreur est de la remonter le long
>> de la pile en la gérant à chaque appel de fonction.
>
> L'exception remonte effectivement la pile. Et il n'y a que quelques
> points où il y a réellement besoin de la traiter, contrairement au
> C. Donc au lieu d'étaler partout du code de gestion de la mémoire
> qui doit être gérée à la main partout (et qui *oblige* à une
> gestion pas à pas de l'erreur), on s'en dispense en Java et on ne
> gère les exceptions que dans le cas de la libération de certaines
> ressources (il y en a assez peu).

Et c'est exactement ce que je reproche aux exceptions.

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.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le Mon, 20 Jun 2011 15:56:45 +0200,
Yliur <yliur@free.fr> écrivait :

Le Mon, 20 Jun 2011 13:25:42 +0000 (UTC)
JKB <jkb@koenigsberg.invalid> a écrit :

Le Mon, 20 Jun 2011 15:09:11 +0200,
Yliur <yliur@free.fr> écrivait :
>> Ce qui me pose problème, c'est la rigidité du
>> 'je suis obligé de coller un gestionnaire d'exception, sauf
>> que là, je n'ai pas le temps, et comme je ne veux pas m'emmerder,
>> je colle un gestionnaire générique qui ne fait rien parce que ça
>> ira bien'.
>
> Quelle différence avec 'je suis obligé de coller une gestion
> d'erreur, sauf que là, je n'ai pas le temps, et comme je ne veux pas
> m'emmerder, je ne fais rien parce que ça ira bien' ?

C'est au contraire très différent. En C, tu écris une gestion
des erreurs volontairement. En Java, tu l'écris parce que sans, ça ne
compile pas.

Non.

En C tu l'écris volontairement (ou te ne l'écris pas, auquel cas tu es
dans un cas bien bien pourri où ton programme fait n'importe quoi). Et
tu l'écris partout. Et le développeur C de base ne l'écrit pas, ou
alors juste ce qui l'inspire, ou ce qui lui a posé problème. Tu n'as
jamais vu un programme en C où les erreurs n'étaient pas gérées,
parce que ça serait fait plus tard ?

Pas chez moi en tout cas. Règle numéro 1, toutes les valeurs de
retour de fonctions sont récupérées et traitées.

En Java tu l'écris volontairement seulement là où il y a quelque
chose à gérer. Où alors tu ne l'écris pas et soit le compilateur le
fait remarquer, soit tu es dans un cas vaguement moins pourri qu'en C
parce qu'au moins l'erreur est remontée.

Mon compilo me jette s'il manque un try {} catch() autour de tout un
tas de choses. Après, il se contrefiche de savoir si l'exception est
traitée ou non. Et c'est bien ce que je reproche au système.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le Mon, 20 Jun 2011 14:39:18 +0000 (UTC)
JKB <jkb@koenigsberg.invalid> a écrit :

Le Mon, 20 Jun 2011 15:56:45 +0200,
Yliur <yliur@free.fr> écrivait :
> Le Mon, 20 Jun 2011 13:25:42 +0000 (UTC)
> JKB <jkb@koenigsberg.invalid> a écrit :
>
>> Le Mon, 20 Jun 2011 15:09:11 +0200,
>> Yliur <yliur@free.fr> écrivait :
>> >> Ce qui me pose problème, c'est la rigidité du
>> >> 'je suis obligé de coller un gestionnaire d'exception, sauf
>> >> que là, je n'ai pas le temps, et comme je ne veux pas
>> >> m'emmerder, je colle un gestionnaire générique qui ne fait rien
>> >> parce que ça ira bien'.
>> >
>> > Quelle différence avec 'je suis obligé de coller une gestion
>> > d'erreur, sauf que là, je n'ai pas le temps, et comme je ne veux
>> > pas m'emmerder, je ne fais rien parce que ça ira bien' ?
>>
>> C'est au contraire très différent. En C, tu écris une
>> gestion des erreurs volontairement. En Java, tu l'écris parce que
>> sans, ça ne compile pas.
>
> Non.
>
> En C tu l'écris volontairement (ou te ne l'écris pas, auquel cas tu
> es dans un cas bien bien pourri où ton programme fait n'importe
> quoi). Et tu l'écris partout. Et le développeur C de base ne
> l'écrit pas, ou alors juste ce qui l'inspire, ou ce qui lui a posé
> problème. Tu n'as jamais vu un programme en C où les erreurs
> n'étaient pas gérées, parce que ça serait fait plus tard ?

Pas chez moi en tout cas. Règle numéro 1, toutes les valeurs
de retour de fonctions sont récupérées et traitées.

Ben en Java chez moi les exceptions sont correctement traitées. Si tu
te compares aux développeurs mauvais/débutants/... pour dire que Java
c'est pourri, tu biaises un peu le débat, non ?

> En Java tu l'écris volontairement seulement là où il y a quelque
> chose à gérer. Où alors tu ne l'écris pas et soit le compilateur le
> fait remarquer, soit tu es dans un cas vaguement moins pourri qu'en
> C parce qu'au moins l'erreur est remontée.

Mon compilo me jette s'il manque un try {} catch() autour de
tout un tas de choses. Après, il se contrefiche de savoir si
l'exception est traitée ou non. Et c'est bien ce que je reproche au
système.

Il ne peut pas décider à ta place si tu as fait ou non ce qu'il
fallait. Pas plus qu'un compilateur C. S'ils savaient ce qu'il faut
faire, il pourraient le faire eux-même. Le compilateur Java met le
doigt sur certains points, à toi d'utiliser son aide et de faire
attention aux endroits où c'est important en général.

Le 20/06/2011 14:52, JKB a écrit :

Le Mon, 20 Jun 2011 12:32:43 +0200,
Toxico Nimbus<ToxN@free.fr> écrivait :

Le 20/06/2011 08:55, JKB a écrit :

Écoute, tu peux être convaincu que les exceptions sont le meilleur
traitement possible d'une erreur. C'est ton droit. Je pense pour ma
part que ce truc est le pire des traitements d'erreur parce qu'il
s'appuie sur tout un tas de choses y compris le GC. C'est une
aberration totale parce qu'on n'a pas envie que le développe sache
(faire) une gestion propre et efficace qui est un peu plus complexe.

[SNIP]

Les exceptions, c'est bien
lorsque tu as un petit programme dans un coin. Lorsque tu as un truc
énorme, c'est une monumentale connerie.

En somme ce qui te gêne dans les exceptions, c'est le garbage collector
et les mauvaises pratiques des devs Java ?

Pas exactement. Ce qui me pose problème, c'est la rigidité du 'je
suis obligé de coller un gestionnaire d'exception, sauf que là, je
n'ai pas le temps, et comme je ne veux pas m'emmerder, je colle un
gestionnaire générique qui ne fait rien parce que ça ira bien'.

Pour ma part que ce soit en C, C++, Java ou autre, les morceaux non
codés par flemme sont repérés par un FIXME ou un TODO faciles à
retrouver en phase de finition. D'autre part Java permet aussi de coller
un méchant RunTimeException qui saute à la figure de l'utilisateur et
oblige aussi à combler la brèche plus tard. Pour ceusses qui utilisent
un bon IDE, le try catch vide avec le TODO est même ajouté automatiquement.

Tu peux définir techniquement "totalement dégueulasse" ?

Récupérer à l'endroit où on peut réellement traiter l'erreur (soit
beaucoup plus haut dans la pile) une exception générique. C'est
idiot et la syntaxe java consiste à mettre des gestionnaires
d'exception un peu partout, renvoyer l'exception au père, grand'père
ou arrière-grand'père voire pire par un throw. Le seul moyen de gérer
correctement une erreur est de la remonter le long de la pile en la
gérant à chaque appel de fonction.

Non, la syntaxe Java permet tout à fait de gérer les exceptions ligne
par ligne, c'est même la seule manière propre de faire et c'est
rigoureusement identique au test d'un code d'erreur du C, à la gestion
de la mémoire près.

Ah, tu vois, finalement, tu es d'accord avec moi. Et dans ce cas,
l'exception n'apporte rien puisque l'intérêt de l'exception est
justement de ne pas gérer les erreurs ligne après ligne.

Les exception sont quand même quelque chose de plus élégant et
extensible que le code de retour + errno.

--
Toxico Nimbus

Le Mon, 20 Jun 2011 17:45:38 +0200,
Toxico Nimbus <ToxN@free.fr> écrivait :

Ah, tu vois, finalement, tu es d'accord avec moi. Et dans ce cas,
l'exception n'apporte rien puisque l'intérêt de l'exception est
justement de ne pas gérer les erreurs ligne après ligne.

Les exception sont quand même quelque chose de plus élégant et
extensible que le code de retour + errno.

Je n'ai jamais dit qu'élégant, extensible et efficace étaient des
synonymes...

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

> Pourquoi ? La JVM avait peut-être bien mieux à faire avant. La
> mémoire non libérée est quand même virtuellement disponible : en
> cas de manque, le collecteur va venir la chercher.
>
> Et si pour une raison ou une autre tu penses que tu sais mieux que
> la JVM quand la récupération de la mémoire est souhaitable (tu sais
> qu'entre deux opérations il va y avoir un moment à ne rien faire par
> exemple), tu peux toujours la guider en demandant la collecte à ce
> moment.

C'est exactement mon discours.

Ah, on est d'accord alors : le collecteur récupère la mémoire quand la
JVM n'est pas pressée ou qu'il y a besoin de mémoire, et en plus si tu
veux tu peux le guider, ce qui est bien mieux qu'en C ;) .

>> > Est-ce que quand le développement C est à la bourre, le
>> > développeur C fait appel à ses pouvoirs magiques (divins), une
>> > grande lumière descend du ciel et l'aide à travailler deux fois
>> > plus vite pour faire à la main et correctement toutes les
>> > vérifications d'erreur et toute la libération de la mémoire ?
>>
>> Il y a juste une différence. Le dev C, en général, est
>> beaucoup plus capé que le développeur Java parce que le langage est
>> plus difficile d'accès.
>
> Mais le langage est plus difficile, ce qui équilibre. Il y a plus de
> trucs à gérer, c'est plus compliqué, pour arriver à faire des
> programmes qui marchent aussi bien il faut une formation/pratique
> plus grande. Le seul résultat c'est que tu te retrouves avec moins
> de développeurs capables de faire le boulot.

Et du code de bien meilleure qualité en règle générale.

Ensuite si tu fais une moyenne sur d'un côté l'élite des développeurs C
et de l'autre tous les développeurs Java, tu triches un peu sur la
comparaison. Oui, avec de meilleurs développeur tu as du meilleur code,
quel que soit le langage. Peut-être que si le C a une réputation de
langage à produire des programmes illisibles c'est que tous les
développeurs C ne font pas toujours tout proprement, hein.

>> > On peut lister les choses ? Ça peut être intéressant pour
>> > comprendre en quoi c'est gênant.
>>
>> Sur la remontée des erreurs sur la pile (c'est justement
>> l'intérêt de l'exception).
>> Sur le GC pour libérer ce qui doit être libéré.
>> Sur le système d'interruption hard (ou une émulation de
>> celui-ci). Et c'est sans compter sur quelques interactions
>> amusantes avec l'OS.
>
> Bon, maintenant qu'on a la liste, on peut savoir en quoi c'est
> gênant ? Enfin les deux premiers points ont déjà l'air en cours de
> discussion, si je comprends bien ce que tu dis...

Je crois avoir déjà expliqué en quoi c'est gênant...

Je n'ai pas compris le 3ème point.

> Phrase de vieux con (désolé mais bon...).
> Considérer que les outils pour simplifier le développement (ou quoi
> que ce soit dans ce que les humains produisent) sert juste aux
> guignols qui ne savent pas faire ça "comme les vrais" est
> historiquement idiot. Oui, des outils qui simplifient la
> construction de couches supérieures çà peut avoir des
> inconvénients, oui ça permet à plus de gens de travailler dans le
> domaine, sans avoir à tout connaître (ce qui a un avantage
> évident), mais les réduire à leurs inconvénients sans voir les
> avantages c'est juste une phrase traditionnelle des vieux vers les
> jeunes (pour simplifier un peu) : "pfff... de notre temps on savait
> faire correctement". C'est rigolo mais ça néglige complètement les
> questions de productivité, de quantité de main d'oeuvre
> nécessaire/disponible, de complexité croissante (des logiciels par
> exemple), ... C'est défendre l'artisanat contre l'industrie en
> disant : "bah c'est tout pourri" (ben merci pour la subtilité).
> Oui, il peut y avoir des avantages à l'artisanat et des
> inconvénients à l'industrie, mais nier en vrac les avantages de
> l'industrialisation en terme de productivité, de fiabilité, ...
> c'est légèrement un petit peu n'importe quoi.

Je ne vois vraiment pas le rapport.

Le fait que tu craches sur les outils automatiques parce que les gens
qui savent pas faire "comme les vrais" peuvent s'en servir. Ou tout
simplement que les développeurs (même ceux qui savent faire) passent du
temps à autre chose qu'à écrire des tartines de gestion de la mémoire à
la main.

Qu'est-ce qui empêche de
coder correctement ?

Rien.

Ce n'est ni plus difficile ni plus long.

Ce n'est ni plus long ni plus difficile d'écrire beaucoup plus de
bordel pour gérer la mémoire ? Il y a des limites à la mauvaise foi,
non ?

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 ?

Moins d'attention du développeur gaspillée, moins de pollution dans le
code.

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 ?

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.

La partie à comprendre en moins en java c'est les destructeurs (C++),
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.

> Je ne vois pas le rapport avec ton erreur de mémoire : il fait ça
> quand ça lui chante ou quand il en a besoin.

Alors là, excuse-moi, mais je me marre. Oui, il fait ça quand
ça lui chante. Lorsque tu fais un free() dans un bout de code C (ou un
delete en C++), tu as déjà marqué la mémoire comme
disponible. Si ton allocateur n'est pas fait n'importe comment, il
utilise un système évolué qui fait qu'il a déjà dans une liste la
taille du bloc libéré. Le fait de réallouer de la mémoire sera quasi
immédiat. Si ton GC qui ne s'est pas encore déclanché n'a plus de
mémoire, il faut d'abord qu'il récupère les miettes. Le boulot est
beaucoup plus complexe qu'une seule allocation. Tu peux regarder
comment est fichu Boehm-GC, c'est instructif. Le GC est une hérésie
qui ne se justifie que par le fait que certains développeurs ne
veulent pas gérer la mémoire.

Les développeurs ont souvent autre chose à foutre.

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 ?

> 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.

>> > L'appli sait en général "traiter" l'erreur à plus haut niveau :
>> > il s'agit de remonter l'erreur le plus précisément possible et de
>> > décider de la politique de gestion des erreurs (si tel traitement
>> > plante, qu'est-ce que je fais ?). Je ne vois pas la différence
>> > entre les codes d'erreur et les exceptions pour ça (à part que
>> > les exceptions sont des objets faciles à remonter et qui peuvent
>> > contenir facilement beaucoup d'information).
>>
>> Euh... Comment dire... Non. Tu as au contraire moins
>> d'information parce qu'elle est moins fine. L'exception que tu
>> récupères tout en haut est une exception sur un ensemble de lignes
>> de code (sinon, tu utiliserais une gestion à la C). L'information
>> sur ce qui s'est passé réellement est difficile à extraire.
>
> Je voulais dire que tu peux entasser facilement plein d'information
> dans l'objet, c'est tout.
> Mais le code d'erreur que tu récupères tout en haut, il ne concerne
> pas un ensemble de lignes de code ?

Non. Il récupère l'erreur d'une fonction. C'est toute la
différence entre le code d'erreur et l'exception.

?
Quelle est la différence ? Il récupère un code d'erreur qui est remonté
depuis loin, ou un code d'erreur propre à la fonction appelante. Pareil
avec les exceptions : tu récupères une exception venue de loin dont la
plupart du temps tu ne sais que faire à part la laisser passer
(automatiquement en général) ; ou alors tu veux que telle ou telle
fonction fournisse une exception différente selon ce qui s'est passé :
c'est le cas où elle sait quoi faire de l'exception, et elle peut si
elle veut lever une autre exception (tout en conservant les infos sur
l'exception d'origine) ou autre (suivant ce que tu veux en faire).

> En C tu es *obligé* de tout gérer pas à pas, de gérer les erreurs
> *partout* parce que dans de très nombreuses fonctions tu as quelque
> chose à libérer (ne serait-ce que de la mémoire). En Java tu n'as
> pas à faire ça : tu te contentes de protéger les ressources qui
> doivent l'être (beaucoup moins de choses qu'en C, ça ne concerne
> que quelques types de ressources) et de traiter le problème à un
> second niveau (plus haut) pour décider ce comment l'appli doit
> réagir à cet événement imprévu.

Déjà, là, on a un problème. Une erreur _doit_ être un
événement prévu.

Imprévu au sens où ce n'est pas le déroulement standard du programme
(cas exceptionnel, exception, tout ça). Suivant ta politique de gestion
des exceptions, tu peux les traiter plus ou moins finement en fonction
de leur type.

> 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.

Le Mon, 20 Jun 2011 17:56:27 +0200,
Yliur <yliur@free.fr> écrivait :

> Pourquoi ? La JVM avait peut-être bien mieux à faire avant. La
> mémoire non libérée est quand même virtuellement disponible : en
> cas de manque, le collecteur va venir la chercher.
>
> Et si pour une raison ou une autre tu penses que tu sais mieux que
> la JVM quand la récupération de la mémoire est souhaitable (tu sais
> qu'entre deux opérations il va y avoir un moment à ne rien faire par
> exemple), tu peux toujours la guider en demandant la collecte à ce
> moment.

C'est exactement mon discours.

Ah, on est d'accord alors : le collecteur récupère la mémoire quand la
JVM n'est pas pressée ou qu'il y a besoin de mémoire, et en plus si tu
veux tu peux le guider, ce qui est bien mieux qu'en C ;) .

Là, on ne l'est plus du tout.

<snip>

>> Sur la remontée des erreurs sur la pile (c'est justement
>> l'intérêt de l'exception).
>> Sur le GC pour libérer ce qui doit être libéré.
>> Sur le système d'interruption hard (ou une émulation de
>> celui-ci). Et c'est sans compter sur quelques interactions
>> amusantes avec l'OS.
>
> Bon, maintenant qu'on a la liste, on peut savoir en quoi c'est
> gênant ? Enfin les deux premiers points ont déjà l'air en cours de
> discussion, si je comprends bien ce que tu dis...

Je crois avoir déjà expliqué en quoi c'est gênant...

Je n'ai pas compris le 3ème point.

C'est toute un bidouillage sur les piles de retour qui n'est pas
simple du tout. Tu vas me dire que c'est géré par la JVM. Certes,
mais ça reste quelque chose d'extrêmement coûteux.

> Phrase de vieux con (désolé mais bon...).
> Considérer que les outils pour simplifier le développement (ou quoi
> que ce soit dans ce que les humains produisent) sert juste aux
> guignols qui ne savent pas faire ça "comme les vrais" est
> historiquement idiot. Oui, des outils qui simplifient la
> construction de couches supérieures çà peut avoir des
> inconvénients, oui ça permet à plus de gens de travailler dans le
> domaine, sans avoir à tout connaître (ce qui a un avantage
> évident), mais les réduire à leurs inconvénients sans voir les
> avantages c'est juste une phrase traditionnelle des vieux vers les
> jeunes (pour simplifier un peu) : "pfff... de notre temps on savait
> faire correctement". C'est rigolo mais ça néglige complètement les
> questions de productivité, de quantité de main d'oeuvre
> nécessaire/disponible, de complexité croissante (des logiciels par
> exemple), ... C'est défendre l'artisanat contre l'industrie en
> disant : "bah c'est tout pourri" (ben merci pour la subtilité).
> Oui, il peut y avoir des avantages à l'artisanat et des
> inconvénients à l'industrie, mais nier en vrac les avantages de
> l'industrialisation en terme de productivité, de fiabilité, ...
> c'est légèrement un petit peu n'importe quoi.

Je ne vois vraiment pas le rapport.

Le fait que tu craches sur les outils automatiques parce que les gens
qui savent pas faire "comme les vrais" peuvent s'en servir. Ou tout
simplement que les développeurs (même ceux qui savent faire) passent du
temps à autre chose qu'à écrire des tartines de gestion de la mémoire à
la main.

Qu'est-ce qui empêche de
coder correctement ?

Rien.

Ce n'est ni plus difficile ni plus long.

Ce n'est ni plus long ni plus difficile d'écrire beaucoup plus de
bordel pour gérer la mémoire ? Il y a des limites à la mauvaise foi,
non ?

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.

> Je ne vois pas le rapport avec ton erreur de mémoire : il fait ça
> quand ça lui chante ou quand il en a besoin.

Alors là, excuse-moi, mais je me marre. Oui, il fait ça quand
ça lui chante. Lorsque tu fais un free() dans un bout de code C (ou un
delete en C++), tu as déjà marqué la mémoire comme
disponible. Si ton allocateur n'est pas fait n'importe comment, il
utilise un système évolué qui fait qu'il a déjà dans une liste la
taille du bloc libéré. Le fait de réallouer de la mémoire sera quasi
immédiat. Si ton GC qui ne s'est pas encore déclanché n'a plus de
mémoire, il faut d'abord qu'il récupère les miettes. Le boulot est
beaucoup plus complexe qu'une seule allocation. Tu peux regarder
comment est fichu Boehm-GC, c'est instructif. Le GC est une hérésie
qui ne se justifie que par le fait que certains développeurs ne
veulent pas gérer la mémoire.

Les développeurs ont souvent autre chose à foutre.

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.

>> > L'appli sait en général "traiter" l'erreur à plus haut niveau :
>> > il s'agit de remonter l'erreur le plus précisément possible et de
>> > décider de la politique de gestion des erreurs (si tel traitement
>> > plante, qu'est-ce que je fais ?). Je ne vois pas la différence
>> > entre les codes d'erreur et les exceptions pour ça (à part que
>> > les exceptions sont des objets faciles à remonter et qui peuvent
>> > contenir facilement beaucoup d'information).
>>
>> Euh... Comment dire... Non. Tu as au contraire moins
>> d'information parce qu'elle est moins fine. L'exception que tu
>> récupères tout en haut est une exception sur un ensemble de lignes
>> de code (sinon, tu utiliserais une gestion à la C). L'information
>> sur ce qui s'est passé réellement est difficile à extraire.
>
> Je voulais dire que tu peux entasser facilement plein d'information
> dans l'objet, c'est tout.
> Mais le code d'erreur que tu récupères tout en haut, il ne concerne
> pas un ensemble de lignes de code ?

Non. Il récupère l'erreur d'une fonction. C'est toute la
différence entre le code d'erreur et l'exception.

?
Quelle est la différence ? Il récupère un code d'erreur qui est remonté
depuis loin, ou un code d'erreur propre à la fonction appelante. Pareil
avec les exceptions : tu récupères une exception venue de loin dont la
plupart du temps tu ne sais que faire à part la laisser passer
(automatiquement en général) ; ou alors tu veux que telle ou telle
fonction fournisse une exception différente selon ce qui s'est passé :
c'est le cas où elle sait quoi faire de l'exception, et elle peut si
elle veut lever une autre exception (tout en conservant les infos sur
l'exception d'origine) ou autre (suivant ce que tu veux en faire).

Ce n'est pas du tout le même mécanisme et les implications ne sont
pas les mêmes. Je ne parle pas du point de vue de l'utilisateur mais
de l'implantation du langage.

> En C tu es *obligé* de tout gérer pas à pas, de gérer les erreurs
> *partout* parce que dans de très nombreuses fonctions tu as quelque
> chose à libérer (ne serait-ce que de la mémoire). En Java tu n'as
> pas à faire ça : tu te contentes de protéger les ressources qui
> doivent l'être (beaucoup moins de choses qu'en C, ça ne concerne
> que quelques types de ressources) et de traiter le problème à un
> second niveau (plus haut) pour décider ce comment l'appli doit
> réagir à cet événement imprévu.

Déjà, là, on a un problème. Une erreur _doit_ être un
événement prévu.

Imprévu au sens où ce n'est pas le déroulement standard du programme
(cas exceptionnel, exception, tout ça). Suivant ta politique de gestion
des exceptions, tu peux les traiter plus ou moins finement en fonction
de leur type.

> 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.

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 20/06/2011 14:52, JKB a écrit :

Ah, tu vois, finalement, tu es d'accord avec moi. Et dans ce cas,
l'exception n'apporte rien puisque l'intérêt de l'exception est
justement de ne pas gérer les erreurs ligne après ligne.

Code selon JBK :

int writeToFile(char *filename, char *data, int *written) {
File *file = new File();
if ( open(filename, file) != 0 ) {
*written = -1;
return ERROR_UNABLE_TO_OPEN_FILE;
}

int w = 0;
if ( write(file, data, &w) != 0 ) {
*written = -1;
delete file;
return ERROR_UNABLE_TO_WRITE_DATA;
}

*written = w;
delete file;
return 0;
}

Noter :
— les multiples passages par référence parce que la valeur de retour est
déjà occupée par le code d'erreur
— la complexité absurde de la gestion de « written », obligeant à
déclarer une variable locale afin de ne pas affecter une valeur débile
en cas d'erreur
— l'ultra-complexité du nettoyage du « file » temporaire
– la longueur du code
– la duplication du « *written = -1; » ou encore du « delete file; »

Je n'ose trop ajouter le moindre bout de code là-dedans de peur
d'exponentialiser la complexité de la gestion des variables temporaires
(de plus en plus seront à nettoyer au fur et à mesure de la progression
dans la fonction.

À comparer à la même fonction en Java :

int writeToFile(String filename, String data) throw FileException,
IOException {
File file = new File();
try {
// Lancera une FileException en cas d'erreur
open(filename, file);
// Lancera une IOException en cas d'erreur
return write(file, data);
} finally {
file.close();
}
}

2× moins de code, 0 duplication, aucune variable locale bidon, pas de
complexité ni d'imbrication…

Je laisse au lecteur le soin de décider quel code est le plus propre, le
plus réutilisable, le plus maintenable…

- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN/5NWAAoJEK8zQvxDY4P9brsIAJ2sWnA1vdwS0oatkzgMiyd+
sT+4VGhKLzgDZb/2xvVuO+xfAGPGTtwwxuSTTN0Aw8VmTHUFh6qqwLpvxf4k9AWm
8M8AL5cjjwEPhzP1RCT+9NJ5yO+zsqwYQ7x13FHD5kN1qc090UynYxPmhzsh5lLC
fYTGo2miriiqXOzCZKV+gHVYmI9lEl02M4zEsLgP7xtrrQfYniqcZ0TyhRj/HtuH
AWKYVMmU6jMzy7j/fru+oSkZ9gBv8vyjal7RAPcxjFdd4u8ce09x65LkIHrbd4ve
KZICMEL3OpbY1rMx+/0V4y1C/wkwrSdJQpYTDLY85gN+8tj+SQR85MFWTZDSO1U =YpSs
-----END PGP SIGNATURE-----

-----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 machine-
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 risque
d'être drole.

Ai-je dis le contraire ?
Et justement en Java, j'ai la possibilité de foutre un gros try/catch
dès que j'ai lancé les moteurs pour choper toute exception possible et
imaginable que le programme pourrait avoir, afin d'arrêter proprement
les moteurs le cas échéant.
En C⁺⁺, je suis totalement dépendant de la bonne volonté des autres
développeurs : une seule valeur de retour de malloc de pas tester et le
soft se crasherait comme une loutre bourrée un soir de pleine lune.

En C, l'ensemble de mes développeurs doit être non seulement excellent
mais parfait, sous peine d'être buggé.
En Java, un seul développeur excellent suffit, le reste peut coder comme
des pieds gauches.

PS : Ça ne signifie pas que je cautionne les mauvais développeurs en
Java, juste qu'ils ne me planteront pas mon soft !
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN/5TpAAoJEK8zQvxDY4P9GY8H/3RKC0UOLs+RWqGqNR5a5v3a
mZoCM9VXFG/o1UN2SM9CAcSdHFOSiBTLEJlzF20wkd4m23bZdH1bYEfa80YPQjW8
uuKLFN1Gk1qMEOw4pQBAA9FBgscCjrP2bDHH2CrLHFTjt2/U0ZReoz9KI13ItPIk
aa8MlJcbf37ufw/S+8uYV9rpIOogiw8ugSqxnb87vjVxZyyHAlKqWJ8MwynGxSJv
FLW/jkAJF/gkeueS7c/YuHN0P2CUB2EgD4og3Vs0Q3QmlrPC/WDn9WrRUCMA/Onw
JY6WRQAA9I5Wc9KxdK+PxHKuG+cSLLSxlxsjEwHPcdOQRYh+5VdeyUk6JGL/I+M =fu7a
-----END PGP SIGNATURE-----