Le Fri, 26 May 2006 20:17:02 +0200, SL a écrit:

>
> Ecoutez, je sais pas si c'est moi qui ne comprends rien ou quoi, mais
> vous êtes bien en train de me dire que quand perl est invoqué, il
> enregistre le byte code dans un répertoire nommé .Inline ? Et que Perl
> ne parse pas le fichier texte à chaque invocation, si du byte code non
> périmé existe déjà ?

On parle bien du bytecode Java, n'est ce pas ? C'est en tout cas ce qui
est écrit dans la doc de Inline... Pour le bytecode Perl, il est possible
de le compiler et de stocker la version compilée dans un fichier .plc,
mais pour diverses raisons cette fonctionnalité n'est pas utilisée en
pratique.

> Certes, mais je ne vois pas Inline::Java faire cela, enfin.

Et bien il faut regarder mieux :

if (! $o->get_java_config('built')){ # Since we didn't build the module, this means that # it was up to date. We can therefore use the data # from the cache.

--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray

SL <nospam@nospam.com> wrote:
>
> Certes, mais je ne vois pas Inline::Java faire cela, enfin.
>
> <http://search.cpan.org/src/PATL/Inline-Java-0.51/Java.pm>
>

Tu as une explication de cette affaire ici:
http://perl.com/pub/a/2003/11/07/java.html

So what is Inline::Java doing for us? When it finds our Java code, it makes a
copy in the .java file of the proper name (javac is adamant that class names
and file names match). Then it uses our Java compiler to build a compiled
version of the program. It puts that version in a directory, using an MD5 sum
to ensure that recompiling happens when and only when the code changes.

De ce que je comprends ça doit lancer un interprète de Java à chaque appel
sur les .class déjà compilés donc au secours les performances.


--

Michel TALON

Le Fri, 26 May 2006 18:27:01 +0000, Michel Talon a écrit:

>
> De ce que je comprends ça doit lancer un interprète de Java à chaque appel
> sur les .class déjà compilés donc au secours les performances.

Tout à fait, c'est pourquoi il est prévu qu'on puisse faire appel à une
JVM déjà chargée :

SHARED_JVM ^

Starting with version 0.30, the Inline::Java JVM can now be shared
between multiple processes. The first process to start creates the JVM but
does not shut it down on exit. All other processes can then connect as
needed to the JVM. If any of these other processes where created by
forking the parent process, the Inline::Java->reconnect_JVM() function
must be called in the child to get a fresh connection to the JVM.



--
De longs désirs, une longue admiration sans espérance, voilà le moyen
d'adorer les femmes, et de rendre l'amour une passion délicieuse!
N. Rétif de la Bretonne.

Emmanuel Florac a écrit :
> Le Fri, 26 May 2006 20:17:02 +0200, SL a écrit:
>
>> Ecoutez, je sais pas si c'est moi qui ne comprends rien ou quoi,
>> mais vous êtes bien en train de me dire que quand perl est invoqué,
>> il enregistre le byte code dans un répertoire nommé .Inline ? Et
>> que Perl ne parse pas le fichier texte à chaque invocation, si du
>> byte code non périmé existe déjà ?
>
> On parle bien du bytecode Java, n'est ce pas ?

Non, moi j'en étais à perl lui-même.

>> Certes, mais je ne vois pas Inline::Java faire cela, enfin.
>
> Et bien il faut regarder mieux :
>
> if (! $o->get_java_config('built')){ # Since we didn't build the module, this means that # it was up to date. We can therefore use the data # from the cache.

Oui, et la seule fois où je vois cette propriété mise à vrai dans tous
le package, c'est au sortir d'un sub "build" qui vient de
compiler... Java.pm(420) :

$o->set_java_config('built', 1) ;

Enfin, j'ai dû passer à côté du truc.

Michel Talon a écrit :
> SL <nospam@nospam.com> wrote:
>>
>> Certes, mais je ne vois pas Inline::Java faire cela, enfin.
>>
>> <http://search.cpan.org/src/PATL/Inline-Java-0.51/Java.pm>
>>
>
> Tu as une explication de cette affaire ici:
> http://perl.com/pub/a/2003/11/07/java.html
>
> So what is Inline::Java doing for us? When it finds our Java code,
> it makes a copy in the .java file of the proper name (javac is
> adamant that class names and file names match). Then it uses our
> Java compiler to build a compiled version of the program. It puts
> that version in a directory, using an MD5 sum to ensure that
> recompiling happens when and only when the code changes.

Bon, la messe est dite.

C'est assez folklo le passage où le code source est passé aux regexp
pour retrouver le nom des classes publiques et enregistrer dans des
fichiers ".java" le code avant de le compiler...

> De ce que je comprends ça doit lancer un interprète de Java à chaque
> appel sur les .class déjà compilés donc au secours les performances.

Tout ça marche probablement très bien mais j'aimerais pas reposer sur
un truc pareil.

Michel Billaud a écrit :
> Laquelle ne se mesure pas sur la longueur du programme minimum, comme
> quoi la remarque sur python était hors sujet, ce que devait faire
> ressortir la comparaison avec un autre langage, où le programme
> minimum est encore plus court, la conclusion sur l'absence de
> conclusion à en tirer étant dans le "et ?" final.
>
> Qui n'a pas suivi ? :-)

Ben toi, puisque si tu avais lu plus haut tu aurais vu qu'il est fait
mention de "verbosité de langage", mais aussi de "Hello World", en
assembleur, et en Perl.
L'exemple sur python était là pour montrer que l'on peut faire également
très court avec ce langage (surtout pour un Hello World).
Je ne savais pas qu'on pouvais faire plus court en Lisp, merci pour
l'information.
D'ailleurs la même expression fonctionne également très bien en Python.
Quoi qu'il en soit je suis bien d'accord pour dire qu'un "Hello, World"
est loin d'être suffisant pour évaluer un langage. (Mais ça a déjà été
dit plus haut par Michel Talon).


> C'était
> peut être plus pertinent, pour comparer les langages que le hello
> world (venu du K et R ?).

Quel est le rapport entre K&R en les "Hello, World" ?

Michel Billaud <billaud@labri.fr> wrote:
> Prodejeu <prodejeu@free.fr> writes:
>
> [java verbeux]
>
> > C'est sûr qu'en Python un Hello, World c'est plus court :
> > print "Hello, World"
>
> en lisp
>
> "Hello, World"
>
> et ?

Et la souplesse, qu'en fais tu?

niobe% gcl
GCL (GNU Common Lisp) 2.6.7 ANSI Mar 17 2006 21:52:37

....

>(+ 1 2)

3

>(+ "Hello" "World!")

Error in + [or a callee]: "Hello" is not of type NUMBER.

niobe% python
Python 2.4.2 (#2, Mar 15 2006, 09:09:01)
[GCC 3.4.4 [FreeBSD] 20050518] on freebsd6
Type "", "copyright", "credits" or "license" for more information.
>>> print "Hello"+" World!"
Hello World!


>
> MB

--

Michel TALON

Le Fri, 26 May 2006 22:25:32 +0200, SL a écrit:

>
> Non, moi j'en étais à perl lui-même.

On peut créer des fichiers Perl compilés (.plc), mais pour une raison
quelconque personne n'utilise cette possibilité. Néammoins Audrey Tang
a récemment utilisé cette fonctionnalité pour un module qui sert à
rendre les source-filters "présentables" . Il faudrait retrouver
l'article (peut-être sur use.perl.org?).

--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Aït Ahmed.

Le Fri, 26 May 2006 22:33:10 +0200, SL a écrit:

>
> C'est assez folklo le passage où le code source est passé aux regexp
> pour retrouver le nom des classes publiques et enregistrer dans des
> fichiers ".java" le code avant de le compiler...

Contrairement à Perl, Java est parfaitement parsable. Ce n'est pas a
priori dangereux...

--
"Dope will get you through times of no money better
than money will get you through times of no dope."
Freewheelin' Franklin

talon@lpthe.jussieu.fr (Michel Talon) wrote:
> Et la souplesse, qu'en fais tu?
>
> niobe% gcl
> GCL (GNU Common Lisp) 2.6.7 ANSI Mar 17 2006 21:52:37
>
> ...
>
> >(+ 1 2)
>
> 3
>
> >(+ "Hello" "World!")
>
> Error in + [or a callee]: "Hello" is not of type NUMBER.

Et c'est pour ça que le RPL est vraiment un bon langage, tout du moins
en mode interactif. C'est d'ailleurs ce qui a fait le succès des
calculatrices HP.

castor ~% rpl -i
+++RPL/2 version 4.00pre8 (samedi 26.02.2005 à 10:05:42 CEST)
+++Copyright (C) 1989 à 2003, 2004 BERTRAND Joël

+++Ce logiciel est un logiciel libre sans aucune garantie de
fonctionnement.
+++Pour plus de détails, utilisez la commande 'warranty'.

+++"Hello" " World" +

1: "Hello World"
+++

Khanh-Dang a écrit :
> talon@lpthe.jussieu.fr (Michel Talon) wrote:
>> Et la souplesse, qu'en fais tu?
>>
>> niobe% gcl
>> GCL (GNU Common Lisp) 2.6.7 ANSI Mar 17 2006 21:52:37
>>
>> ...
>>
>>> (+ 1 2)
>> 3
>>
>>> (+ "Hello" "World!")
>> Error in + [or a callee]: "Hello" is not of type NUMBER.
>
> Et c'est pour ça que le RPL est vraiment un bon langage, tout du moins
> en mode interactif. C'est d'ailleurs ce qui a fait le succès des
> calculatrices HP.
>
> castor ~% rpl -i
> +++RPL/2 version 4.00pre8 (samedi 26.02.2005 à 10:05:42 CEST)
> +++Copyright (C) 1989 à 2003, 2004 BERTRAND Joël
>
> +++Ce logiciel est un logiciel libre sans aucune garantie de
> fonctionnement.
> +++Pour plus de détails, utilisez la commande 'warranty'.
>
> +++"Hello" " World" +
>
> 1: "Hello World"
> +++
les "shells" sont des compilateurs ?

$ print "Hello" "World!"
print "Hello" "World"
Hello World
$
--
| Mon 1er est bête, l' horreur si sale ou méchant, fait pitié si n' |
| est que pauvre. Mon 2ème l' est aussi, mais plutôt benêt. Mon 3ème |
| adore les trous de serrure. Mon tout, bien ciblé, achète n' importe |
| quoi, même (surtout ?) si c' est cher. ^<©>^ http://rajao.net |

Prodejeu wrote:
Désolé de na pas avoir pu répondre plus tôt, j'étais parti en vacances.

>
> Merci beaucoup, mais justement "reparlons-en", tout en ayant déjà
> utilisé (peu c'est vrai) ces trois langages, je trouve quand même que
> Java a une plus belle syntaxe.
La syntaxe du Java est héritée de celle du C et emprunte un peu de celle du
C++. Le problème, à mes yeux bien sûr, de cette syntaxe (comme celle
d'ailleurs d'Eiffel) est que c'est un langage à parenthèses ou plus
exactement un langage orienté verbe. Un langage orienté sujet (Smalltalk,
Lisaac, ...) est, à mon avis, pour avoir programmé avec des langages de ces
deux catégories, plus adapté à la conception objet et est, surtoût, plus
facile à relire.

> Pour ce qui est de SmallTalk, le concept est intéressant mais c'est en
> grande partie la syntaxe qui m'a génée.
C'est normal, venant de la famille C, la syntaxe Smalltalk impose de changer
ses habitudes (dans mon cas, j'ai eu un peu de mal aussi). Elle impose
aussi à penser /correctement/ objet, ce qui n'est pas vraiment le cas de
Java par exemple (c'est pourquoi un certain nombre de personnes conseillent
de savoir programmer correctement en Smalltalk avant de passer à un langage
de masse).
Toutefois, pour moi, le plus gros pb de Java vient des exceptions : son
implémentation de celles-ci fait que les exceptions ne sont plus vraiment
utilisées pour gérer des exceptions comme il devrait être, et sont
utilisées même pour manipuler des erreurs (qui sont, rappelons le, des cas
"normaux" d'un programme).

> Idem pour Objective C, même si le concept de typage dyanmique est assez
> pratique dans ce genre de langage.
Elle permet surtoût de garder la simplicité recharchée par Java à ses
débuts, tout en gardant flexibilité et expressivité, ce qu'a perdu Java en
privilégiant le typage statique sans support de la généricité contrainte
(ce que fait maintenant Java 5). Toutefois, il est vrai, la généricité
contrainte complexifie le langage, mais ceci est /obligatoire/ si on désire
faire correctement de l'objet avec un langage à typage statique. A moins
qu'une solution de type de l'attribut de type 'class d'Ada dans Java
pouvait permettre à celui-ci de garder à la fois simplicité et une certaine
flexibilité et expressivité.

> Et toujours idem pour Eiffel même si c'est vrai que j'apprécie le fait
> qu'il soit contrairement à Java, 100% objet.
Pourtant c'est un langage à parenthèses, mais il est vrai plus de la lignée
de Pascal que du C.

Miguel Moquillon a écrit :
> Un langage orienté sujet (Smalltalk,
> Lisaac, ...) est, à mon avis, pour avoir programmé avec des langages de ces
> deux catégories, plus adapté à la conception objet et est, surtoût, plus
> facile à relire.

Je pense plutôt que c'est plus une question d'habitude.
J'avais quasiment pas fait de C++ avant de faire du java et pourtant je
m'y suis habitué très vite.
Par contre il m'arrive encore très souvent d'avoir du mal avec du
SmallTalk, et de me demander comment j'écrirais la même chose en Java.

> Toutefois, pour moi, le plus gros pb de Java vient des exceptions : son
> implémentation de celles-ci fait que les exceptions ne sont plus vraiment
> utilisées pour gérer des exceptions comme il devrait être, et sont
> utilisées même pour manipuler des erreurs (qui sont, rappelons le, des cas
> "normaux" d'un programme).

Tout dépend de comment le développeur les utilisent.
Je trouve que les exceptions générées par les classes de l'API, sont
bien faite.
Si on se contente de les intercepter, je ne vois pas où est le problème.
Par contre, si on s'amuse à mettre des exceptions là où une méthode
aurait pu renvoyer une donnée, c'est sur que là c'est mauvais.
Maintenant il faut pas non plus exagérer et faire comme en C, où pour
chaque fonction il y a toute une liste de codes d'erreur.
Le côté "pratique" d'un langage est quand même attirant.


>> Idem pour Objective C, même si le concept de typage dyanmique est assez
>> pratique dans ce genre de langage.
> Elle permet surtoût de garder la simplicité recharchée par Java à ses
> débuts, tout en gardant flexibilité et expressivité, ce qu'a perdu Java en
> privilégiant le typage statique sans support de la généricité contrainte
> (ce que fait maintenant Java 5). Toutefois, il est vrai, la généricité
> contrainte complexifie le langage, mais ceci est /obligatoire/ si on désire
> faire correctement de l'objet avec un langage à typage statique. A moins
> qu'une solution de type de l'attribut de type 'class d'Ada dans Java
> pouvait permettre à celui-ci de garder à la fois simplicité et une certaine
> flexibilité et expressivité.

Je me trompe peut-être, mais est-ce qu'un langage à typage dynamique
(surtout dans le cas de langages interprétés ou pseudo-compilé) n'est
pas plus gourmand en ressources qu'un langage à typage statique ?

De plus, je trouve les langages à typage assez dangereux, surtout pour
les débutants et même encore un peu plus tard (l'erreur est humaine ;-) ).
Il m'est souvent arrivé d'avoir quelques soucis avec PHP à ce sujet, et
de chercher le type et le contenu de certaines variables.

Prodejeu wrote:

>> Toutefois, pour moi, le plus gros pb de Java vient des exceptions : son
>> implémentation de celles-ci fait que les exceptions ne sont plus vraiment
>> utilisées pour gérer des exceptions comme il devrait être, et sont
>> utilisées même pour manipuler des erreurs (qui sont, rappelons le, des
>> cas "normaux" d'un programme).
>
> Tout dépend de comment le développeur les utilisent.
> Je trouve que les exceptions générées par les classes de l'API, sont
> bien faite.
Je dirais non. En général, les exceptions relèvent de l'application et non
d'une API. Exemple de FileInputStream. Dans le cas d'une application qui
souhaite lire un fichier de conf placé dans /etc. Ceci signifie que ce
fichier peut-être modifié par l'utilisateur. Si ce fichier n'est pas trouvé
ou ne peut être lu, ceci est une erreur et pas une exception parce que, en
le mettant à disposition du tout à chacun, le cas que ce produit ce genre
d'erreur ne peut être considéré comme une excéption. Donc, la déclaration
de l'exception FileNotFoundException est conceptuellement fausse car ceci
relève de l'erreur (cas "normal") et non de l'exception. Maintenant, si le
fichier de conf est mis dans un lieu caché (par exemple un jar) et qu'il
n'est pas trouvé ou ne peut être lu par l'application relève lui de
l'exception et non de l'erreur car ce cas ne devrait pas se produire si
l'application est correctement construite et déployée.
Nous avons donc un exemple où une exception est mal utilisée. Et ceci
conduit finalement avec le temps aux développeurs à ne plus penser
correctement les exceptions, ce qui amène souvent à alourdir la conception
d'un programme. N'oublions pas que notre façon de percevoir les choses et
conditionné par les outils que l'on utilise, et plus particulièrement par
le langage.

> Je me trompe peut-être, mais est-ce qu'un langage à typage dynamique
> (surtout dans le cas de langages interprétés ou pseudo-compilé) n'est
> pas plus gourmand en ressources qu'un langage à typage statique ?
Non, tu ne te trompes pas. Mais ce qui est vraiment gourmand, ce sont les
VM, et plus particulièrement les JVM (ce sont les VM les plus lourdes que
j'ai rencontré).

>
> De plus, je trouve les langages à typage assez dangereux, surtout pour
> les débutants et même encore un peu plus tard (l'erreur est humaine ;-) ).
> Il m'est souvent arrivé d'avoir quelques soucis avec PHP à ce sujet, et
> de chercher le type et le contenu de certaines variables.
PHP est un autre pb. Dans ce langage, tout est global ce qui amène souvent à
de désagréables surprises (je n'ai pas touché à PHP 5).
Avec des langages comme Smalltalk par exmple, tu n'as pas ce genre de pb.
Par exemple, en cours de codage, lorsque tu écris un envoi de message à un
objet qui n'y répond pas, l'environnement de dév. te le signale.

Miguel Moquillon , dans le message
<447c4710$0$19575$636a55ce@news.free.fr>, a écrit:
> Ceci signifie que ce
> fichier peut-être modifié par l'utilisateur. Si ce fichier n'est pas trouvé
> ou ne peut être lu, ceci est une erreur et pas une exception parce que, en
> le mettant à disposition du tout à chacun, le cas que ce produit ce genre
> d'erreur ne peut être considéré comme une excéption.

Là, c'est toi qui a des idées préconçues sur ce que doivent être les
exceptions, probablement orienté par un des cens que peut avoir ce mot en
français courant.

Nicolas George wrote:

> Miguel Moquillon , dans le message
> <447c4710$0$19575$636a55ce@news.free.fr>, a écrit:
>>Ceci signifie que ce
>> fichier peut-être modifié par l'utilisateur. Si ce fichier n'est pas
>> trouvé ou ne peut être lu, ceci est une erreur et pas une exception parce
>> que, en le mettant à disposition du tout à chacun, le cas que ce produit
>> ce genre d'erreur ne peut être considéré comme une excéption.
>
> Là, c'est toi qui a des idées préconçues sur ce que doivent être les
> exceptions, probablement orienté par un des cens que peut avoir ce mot en
> français courant.
Non, je ne crois pas. C'est ce que l'on apprend en Génie Logiciel.
Je suis concepteur et effectivement j'ai appris à bien faire attention au
sens des mots car ceci peut avoir un impact important aussi bien en
architecture qu'en conception.

Miguel Moquillon , dans le message
<447c4c67$0$21196$626a54ce@news.free.fr>, a écrit:
> Non, je ne crois pas. C'est ce que l'on apprend en Génie Logiciel.

J'ai vu des gens apprendre à mettre des underscores au début des
identificateurs en C, alors ce qu'on apprend...

Le «génie logiciel», c'est fait pour que des gens médiocres arrivent à
pondre des programmes pas trop buggés pour répondre à des besoins simples.
Ce n'est pas vraiment une référence pour ce qui est de la qualité du code.

> Je suis concepteur et effectivement j'ai appris à bien faire attention au
> sens des mots car ceci peut avoir un impact important aussi bien en
> architecture qu'en conception.

Le sens des mots dans un jargon technique ne coïncide que rarement avec le
sens commun des mêmes mots. Si on n'a pas compris ça, ça va mal se passer.

Miguel Moquillon a écrit :
> En général, les exceptions relèvent de l'application et non
> d'une API. Exemple de FileInputStream. Dans le cas d'une application qui
> souhaite lire un fichier de conf placé dans /etc. Ceci signifie que ce
> fichier peut-être modifié par l'utilisateur. Si ce fichier n'est pas trouvé
> ou ne peut être lu, ceci est une erreur et pas une exception parce que, en
> le mettant à disposition du tout à chacun, le cas que ce produit ce genre
> d'erreur ne peut être considéré comme une excéption. Donc, la déclaration
> de l'exception FileNotFoundException est conceptuellement fausse car ceci
> relève de l'erreur (cas "normal") et non de l'exception. Maintenant, si le
> fichier de conf est mis dans un lieu caché (par exemple un jar) et qu'il
> n'est pas trouvé ou ne peut être lu par l'application relève lui de
> l'exception et non de l'erreur car ce cas ne devrait pas se produire si
> l'application est correctement construite et déployée.
> Nous avons donc un exemple où une exception est mal utilisée. Et ceci
> conduit finalement avec le temps aux développeurs à ne plus penser
> correctement les exceptions, ce qui amène souvent à alourdir la conception
> d'un programme. N'oublions pas que notre façon de percevoir les choses et
> conditionné par les outils que l'on utilise, et plus particulièrement par
> le langage.

Je suis d'accord avec toi, néanmoins dans notre cas si on essaye de
faire la même chose en C (lecture d'un fichier inexistant), cela va
conduire sur un plantage de l'application.
En Java l'application ne plantera pas, parce que cette exception doit
obligatoirement être gérée.
Je t'accorde que tout développeur digne de ce nom va tester l'existence
des données avant d'essayer de les manipuler, mais grâce à ce genre de
système on dispose d'une "sécurité supplémentaire", qu'il faut utiliser
à bon escient.
De plus, je lis pas mal de bouquins et de tutoriels sur Java et la
plupart conseillent vraiment de prendre garde à bien utiliser les
exceptions, c'est à dire de ne pas s'appuyer dessus pour gérer des
erreurs, mais bien pour prévoir les éventuelles exceptions, donc si les
débutant en Java savent lire, il ne devrait pas y avoir de problème ;-).

>> Je me trompe peut-être, mais est-ce qu'un langage à typage dynamique
>> (surtout dans le cas de langages interprétés ou pseudo-compilé) n'est
>> pas plus gourmand en ressources qu'un langage à typage statique ?
> Non, tu ne te trompes pas. Mais ce qui est vraiment gourmand, ce sont les
> VM, et plus particulièrement les JVM (ce sont les VM les plus lourdes que
> j'ai rencontré).

Ils en sont conscient chez Sun, et c'est d'ailleurs un de leurs cheval
de bataille.
Les performances ont pas mal évoluées dans les dernières versions
majeures de la JRE.


Le typage dynamique ne devrait pas avoir de conséquences majeures sur
les perfs d'un langage pseudo-compilé (voire pas du tout sur un langage
compilé), au contraire d'un langage interprété ?
Si mon allégation est juste, une version de Java utilisant le typage
dynamique ne devrait pas être beaucoup plus lente que l'originale,
néanmoins je ne vois toujours pas l'intérêt pour Java.

>> De plus, je trouve les langages à typage assez dangereux, surtout pour
>> les débutants et même encore un peu plus tard (l'erreur est humaine ;-) ).
>> Il m'est souvent arrivé d'avoir quelques soucis avec PHP à ce sujet, et
>> de chercher le type et le contenu de certaines variables.
> PHP est un autre pb. Dans ce langage, tout est global ce qui amène souvent à
> de désagréables surprises (je n'ai pas touché à PHP 5).
> Avec des langages comme Smalltalk par exmple, tu n'as pas ce genre de pb.
> Par exemple, en cours de codage, lorsque tu écris un envoi de message à un
> objet qui n'y répond pas, l'environnement de dév. te le signale.

Quand tu dis "un envoi de message à un objet qui n'y répond pas", tu
entends :
-Référence inexistante
ou
-Objet du mauvais type
ou
-Les deux ?

Malgré cela il peut toujours exister des messages identique (même nom,
même paramètres) pour deux objets différents, l'environnement peut pas
grand chose en cas d'erreur dans ce cas de figure, non ?

Nicolas George a écrit :
> J'ai vu des gens apprendre à mettre des underscores au début des
> identificateurs en C, alors ce qu'on apprend...

Ce n'est parce qu'on apprend que l'on comprend.
Il faut parfois un petit laps de temps entre les deux, la pratique aide
beaucoup aussi.
Je ne connais personne capable de réussir parfaitement du premier coup
surtout en programmation (sauf quelques prétentieux, mais d'après eux...
;-) ).

> Le « génie logiciel », c'est fait pour que des gens médiocres arrivent à
> pondre des programmes pas trop buggés pour répondre à des besoins simples.
> Ce n'est pas vraiment une référence pour ce qui est de la qualité du code.

Tu devrais donc reprendre quelques cours de "Génie Logiciel", et
"d'ouverture d'esprit" tant que tu y est.
Il me semble que beaucoup de grands Noms dans le domaine prêchent les
"bonnes pratiques" en programmation ; le Génie Logiciel sert justement à
nous inculquer ces bonnes pratiques qu'il est très difficile (voire
impossible sans) d'appréhender sans.

>> Je suis concepteur et effectivement j'ai appris à bien faire attention au
>> sens des mots car ceci peut avoir un impact important aussi bien en
>> architecture qu'en conception.
>
> Le sens des mots dans un jargon technique ne coïncide que rarement avec le
> sens commun des mêmes mots. Si on n'a pas compris ça, ça va mal se passer.

C'est pour cela qu'il faut d'autant plus faire attention au sens des
mots. ;-)

Prodejeu wrote:
> Quand tu dis "un envoi de message à un objet qui n'y répond pas", tu
> entends :
> -Référence inexistante
> ou
> -Objet du mauvais type
> ou
> -Les deux ?
Message non défini pour le type de l'objet.

>
> Malgré cela il peut toujours exister des messages identique (même nom,
> même paramètres) pour deux objets différents, l'environnement peut pas
> grand chose en cas d'erreur dans ce cas de figure, non ?
Exacte s'il n'a pas la connaissance du type. S'il y a eu un :
myObject := Array new.
par exemple, il sait alors que myObject est de type Array.

Prodejeu , dans le message <447c5521$0$21282$626a54ce@news.free.fr>, a
écrit:
> Ce n'est parce qu'on apprend que l'on comprend.

Ta phrase ne veut rien dire. Tu devrais te relire.

> Il faut parfois un petit laps de temps entre les deux, la pratique aide
> beaucoup aussi.
> Je ne connais personne capable de réussir parfaitement du premier coup
> surtout en programmation (sauf quelques prétentieux, mais d'après eux...
> ;-) ).

Je ne vois pas le rapport.

> le Génie Logiciel sert justement à
> nous inculquer ces bonnes pratiques qu'il est très difficile (voire
> impossible sans) d'appréhender sans.

Les bonnes pratiques, c'est bien, mais il faut savoir les appliquer à bon
escient. Pour ça, il faut une vision d'ensemble du problème, une large
culture pour évaluer ce qui peut se faire, et une bonne connaissance du
niveau des autres contributeurs du projet.

Ce n'est pas quelque chose qui peut s'enseigner, hélas. Donc quand on doit
former des gens pour aller pisser des logiciels de gestion à la chaîne, on
limite la casse avec des règles simplistes et immuables. Mais ce n'est qu'un
pis-aller.

Le Tue, 30 May 2006 13:11:17 +0200, Prodejeu a écrit:

>
> De plus, je trouve les langages à typage assez dangereux, surtout pour
> les débutants et même encore un peu plus tard (l'erreur est humaine ;-) ).
> Il m'est souvent arrivé d'avoir quelques soucis avec PHP à ce sujet, et
> de chercher le type et le contenu de certaines variables.

Sauf que php est le seul qui implémente ça de façon stupide (voir
l'opérateur de comparaison).

--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Aït Ahmed.

Nicolas George a écrit :
> Prodejeu , dans le message <447c5521$0$21282$626a54ce@news.free.fr>, a
> écrit :
>> Ce n'est parce qu'on apprend que l'on comprend.
>
> Ta phrase ne veut rien dire. Tu devrais te relire.

Pourtant ma phrase est correcte et a du sens.
Ce n'est peut-être pas moi qui devrait la relire.

>> Il faut parfois un petit laps de temps entre les deux, la pratique aide
>> beaucoup aussi.
>> Je ne connais personne capable de réussir parfaitement du premier coup
>> surtout en programmation (sauf quelques prétentieux, mais d'après eux...
>> ;-) ).
>
> Je ne vois pas le rapport.

C'est en lien directe avec la phrase précédente.

> Les bonnes pratiques, c'est bien, mais il faut savoir les appliquer à bon
> escient.

Je suis tout à fait d'accord.
De mon point de vue personnel, je pense qu'une fois que les "bonnes
pratiques" sont comprises, il faut encore du temps pour les appliquer
correctement, perso j'appelle ça l'expérience.

> Pour ça, il faut une vision d'ensemble du problème, une large
> culture pour évaluer ce qui peut se faire, et une bonne connaissance du
> niveau des autres contributeurs du projet.

Si par bonne culture tu entends "pratique" (donc de l'expérience), je
complètement d'accord avec toi, sinon ta bonne culture il n'y a pas
mieux que les banc de l'école pour l'obtenir.
Par contre, avoir "une bonne connaissance du niveau des autres
contributeurs du projet" c'est bien pour le chef de projet, sinon pour
les autres ça sert pas à grand chose.

> Ce n'est pas quelque chose qui peut s'enseigner, hélas. Donc quand on doit
> former des gens pour aller pisser des logiciels de gestion à la chaîne, on
> limite la casse avec des règles simplistes et immuables. Mais ce n'est qu'un
> pis-aller.

Chacun sont point de vue.
Le tien repose peut-être sur ce que tu as constaté, mais pour ma part
j'ai vu à plusieurs reprise des gars très compétent sortir de BTS
Informatique de Gestion alors que la formation ne va pas plus loin que
le Génie Logiciel.
De plus pour ton information, au niveau bac+4 en Génie Logiciel, on
étudie les Design Pattern (l'expérience aidera ensuite à bien les employer).

Emmanuel Florac a écrit :
> Le Tue, 30 May 2006 13:11:17 +0200, Prodejeu a écrit :
>
>> De plus, je trouve les langages à typage assez dangereux, surtout pour
>> les débutants et même encore un peu plus tard (l'erreur est humaine ;-) ).
>> Il m'est souvent arrivé d'avoir quelques soucis avec PHP à ce sujet, et
>> de chercher le type et le contenu de certaines variables.
>
> Sauf que php est le seul qui implémente ça de façon stupide (voir
> l'opérateur de comparaison).
>

Malgré ça, il est très fiable contrairement à d'autres de chez M$ qui le
sont beaucoup moins...