Microsoft semble reconnaître que Java permet de développer plus
rapidement que C# et qu'il y a moins de failles de sécurité dans Java
que dans .net :
http://dsi.silicon.fr/nouveautes/microsoft-java-forever%E2%80%A6-1366
Ah bon, j'ai compris. Tu veux avoir des conversations privées avec chacun de tes interlocuteurs! Ou alors tu ne juges pas opportun de faire connaître les contribruiteurs avec qui tu discutes parce qu'ils n'en valent pas la peine.
Rhâââ, putain, j'ai re-oublié cette fois-ci... Lâche-moi un peu.
Dellara <paul.pygeon@gmail.com> a écrit :
Ah bon, j'ai compris. Tu veux avoir des conversations privées avec
chacun de tes interlocuteurs! Ou alors tu ne juges pas opportun de
faire connaître les contribruiteurs avec qui tu discutes parce qu'ils
n'en valent pas la peine.
Rhâââ, putain, j'ai re-oublié cette fois-ci... Lâche-moi un peu.
Ah bon, j'ai compris. Tu veux avoir des conversations privées avec chacun de tes interlocuteurs! Ou alors tu ne juges pas opportun de faire connaître les contribruiteurs avec qui tu discutes parce qu'ils n'en valent pas la peine.
Rhâââ, putain, j'ai re-oublié cette fois-ci... Lâche-moi un peu.
Yliur
Nicolas George <nicolas$ a écrit :
Yliur , dans le message , a écrit : > Avec beaucoup d'interfaces (pour ce qui concerne Java) ?
Oui, les interfaces sont la manière java de faire ça. Ce n'est pas la seule solution possible.
> Euh... pas forcément, si tu fais des choses "vraiment > génériques" (disons de la méta-programmation).
Ça n'évite pas de devoir énumérer tous les cas possibles au niveau local, ce qui est assez contradictoire avec le principe même de généricité.
Des remarques un peu en vrac : - Utiliser des interfaces n'est pas toujours possible après coup. - Énumérer tous les cas possibles n'est pas toujours quelque chose de gênant : ça peut te permettre d'écrire du code plus simple par dessus, le bordel se trouvant dans un traitement en dessous qui gère les types particuliers. Pas très extensible, mais le résultat est plus simple et ça convient à la gestion d'un certain nombre de cas (les "types primitifs" par exemple ; ou les types de données que tu attends, quels qu'ils soient). - Je trouve les mécanismes de généricité des langages typés statiquement trop faible. Par exemple avec les tableaux. Ou avec les nombres (c'est peut-être un peu la faute des langages "classiques", qui n'ont pas de type "nombre", mais le fait d'avoir des types statiques pousse à donner des informations techniques sur les nombres manipulés (entiers sur tant d'octets, ...). - Comment faire pour avoir une boucle read/eval/print dans un langage statique ? Le fait que tout doivent être compilé avant d'être exécuté (qui est ce qui permet de vérifier que l'attribut auquel tu accèdes existe bien) me semble compromettre cette utilisation interactive (difficile à modifier puisque tout n'est pas recompilé en un bloc : on ne peut pas modifier les éléments un par un sans que ça coince régulièrement parce que deux ou plus d'entre deux doivent être modifiés conjointement [redéfinition d'une fonction par exemple]).
Sinon ton bug ne semble pas vraiment lié au fait que le langage soit dynamique ni au typage dynamique : le champ inexistant ne semble même pas avoir été détecté à l'exécution, ce qui est pourtant possible dans un langage typé dynamiquement. Par curiosité, quel langage as-tu utilisé ?
De manière générale, je ne nie pas le fait que détecter des erreurs plus rapidement (notamment par le compilateur) soit bien. Le problème c'est qu'on ne peut pas toujours tout avoir : les langages statiques et/ou typés statiquement ont un coût caché, qui est la difficulté d'écrire du code de plus haut niveau (et donc de limiter les sources d'erreurs par ailleurs). Faire quelque chose de plus générique est tout de suite plus lourd, pénible, donc soit chiant et sujet aux erreurs, soit la lourdeur dépasse même les gains attendus et on ne le fait pas. C'est difficile d'écrire du code aussi simple dans ces langages, d'écrire des macros (comme celles de Lisp), d'écrire des méta-outils (chargement/sauvegarde de données, ...). Bien sûr on peut toujours le faire, mais si c'est trop compliqué (presque) personne ne le fait. Pour les utilisations les plus communes il y a des outils (les outils de correspondance objet/relationnel par exemple), pour les autres on laisse tomber. Écrire ce genre de choses en Java ce n'est pas si amusant que ça. Et ça devient même vite assez chiant.
L'intérêt de la souplesse des langages dynamiques et du typage dynamique ce n'est pas de s'épargner quelques déclarations de types mais de pouvoir construire des choses de plus haut niveau et d'être plus productif, en considérant que les tests doivent être faits de toutes façons. Écrire du code de plus haut niveau, plus déclaratif, permet de limiter le nombre d'erreurs dans le programme (qui ne se limitent pas à des erreurs détectables par le compilateur) et de le développer plus rapidement, le temps pouvant être reversé dans les tests ou autres activités d'amélioration de la qualité. Les erreurs détectables par un compilateur sont limitées et je trouve que les langages statiques bloquent les possibilités de limiter les erreurs par du code de plus haut niveau et de maîtriser la complexité croissante du développement quand la taille du projet augmente.
Nicolas George <nicolas$george@salle-s.org> a écrit :
Yliur , dans le message <20110628001554.0c01aecc@alcheringa>, a
écrit :
> Avec beaucoup d'interfaces (pour ce qui concerne Java) ?
Oui, les interfaces sont la manière java de faire ça. Ce n'est pas la
seule solution possible.
> Euh... pas forcément, si tu fais des choses "vraiment
> génériques" (disons de la méta-programmation).
Ça n'évite pas de devoir énumérer tous les cas possibles au niveau
local, ce qui est assez contradictoire avec le principe même de
généricité.
Des remarques un peu en vrac :
- Utiliser des interfaces n'est pas toujours possible après coup.
- Énumérer tous les cas possibles n'est pas toujours quelque chose de
gênant : ça peut te permettre d'écrire du code plus simple par
dessus, le bordel se trouvant dans un traitement en dessous qui
gère les types particuliers. Pas très extensible, mais le résultat
est plus simple et ça convient à la gestion d'un certain nombre de
cas (les "types primitifs" par exemple ; ou les types de données
que tu attends, quels qu'ils soient).
- Je trouve les mécanismes de généricité des langages typés
statiquement trop faible. Par exemple avec les tableaux. Ou
avec les nombres (c'est peut-être un peu la faute des langages
"classiques", qui n'ont pas de type "nombre", mais le fait d'avoir
des types statiques pousse à donner des informations techniques
sur les nombres manipulés (entiers sur tant d'octets, ...).
- Comment faire pour avoir une boucle read/eval/print dans un langage
statique ? Le fait que tout doivent être compilé avant d'être
exécuté (qui est ce qui permet de vérifier que l'attribut auquel tu
accèdes existe bien) me semble compromettre cette utilisation
interactive (difficile à modifier puisque tout n'est pas recompilé
en un bloc : on ne peut pas modifier les éléments un par un sans
que ça coince régulièrement parce que deux ou plus d'entre deux
doivent être modifiés conjointement [redéfinition d'une fonction
par exemple]).
Sinon ton bug ne semble pas vraiment lié au fait que le langage soit
dynamique ni au typage dynamique : le champ inexistant ne semble même
pas avoir été détecté à l'exécution, ce qui est pourtant possible dans
un langage typé dynamiquement. Par curiosité, quel langage as-tu
utilisé ?
De manière générale, je ne nie pas le fait que détecter des erreurs
plus rapidement (notamment par le compilateur) soit bien. Le problème
c'est qu'on ne peut pas toujours tout avoir : les langages statiques
et/ou typés statiquement ont un coût caché, qui est la difficulté
d'écrire du code de plus haut niveau (et donc de limiter les sources
d'erreurs par ailleurs). Faire quelque chose de plus générique est tout
de suite plus lourd, pénible, donc soit chiant et sujet aux erreurs,
soit la lourdeur dépasse même les gains attendus et on ne le fait pas.
C'est difficile d'écrire du code aussi simple dans ces langages,
d'écrire des macros (comme celles de Lisp), d'écrire des méta-outils
(chargement/sauvegarde de données, ...). Bien sûr on peut toujours le
faire, mais si c'est trop compliqué (presque) personne ne le fait. Pour
les utilisations les plus communes il y a des outils (les outils de
correspondance objet/relationnel par exemple), pour les autres on
laisse tomber. Écrire ce genre de choses en Java ce n'est pas si
amusant que ça. Et ça devient même vite assez chiant.
L'intérêt de la souplesse des langages dynamiques et du typage
dynamique ce n'est pas de s'épargner quelques déclarations de types
mais de pouvoir construire des choses de plus haut niveau et d'être
plus productif, en considérant que les tests doivent être faits de
toutes façons. Écrire du code de plus haut niveau, plus déclaratif,
permet de limiter le nombre d'erreurs dans le programme (qui ne se
limitent pas à des erreurs détectables par le compilateur) et de le
développer plus rapidement, le temps pouvant être reversé dans les
tests ou autres activités d'amélioration de la qualité. Les erreurs
détectables par un compilateur sont limitées et je trouve que les
langages statiques bloquent les possibilités de limiter les erreurs par
du code de plus haut niveau et de maîtriser la complexité croissante
du développement quand la taille du projet augmente.
Yliur , dans le message , a écrit : > Avec beaucoup d'interfaces (pour ce qui concerne Java) ?
Oui, les interfaces sont la manière java de faire ça. Ce n'est pas la seule solution possible.
> Euh... pas forcément, si tu fais des choses "vraiment > génériques" (disons de la méta-programmation).
Ça n'évite pas de devoir énumérer tous les cas possibles au niveau local, ce qui est assez contradictoire avec le principe même de généricité.
Des remarques un peu en vrac : - Utiliser des interfaces n'est pas toujours possible après coup. - Énumérer tous les cas possibles n'est pas toujours quelque chose de gênant : ça peut te permettre d'écrire du code plus simple par dessus, le bordel se trouvant dans un traitement en dessous qui gère les types particuliers. Pas très extensible, mais le résultat est plus simple et ça convient à la gestion d'un certain nombre de cas (les "types primitifs" par exemple ; ou les types de données que tu attends, quels qu'ils soient). - Je trouve les mécanismes de généricité des langages typés statiquement trop faible. Par exemple avec les tableaux. Ou avec les nombres (c'est peut-être un peu la faute des langages "classiques", qui n'ont pas de type "nombre", mais le fait d'avoir des types statiques pousse à donner des informations techniques sur les nombres manipulés (entiers sur tant d'octets, ...). - Comment faire pour avoir une boucle read/eval/print dans un langage statique ? Le fait que tout doivent être compilé avant d'être exécuté (qui est ce qui permet de vérifier que l'attribut auquel tu accèdes existe bien) me semble compromettre cette utilisation interactive (difficile à modifier puisque tout n'est pas recompilé en un bloc : on ne peut pas modifier les éléments un par un sans que ça coince régulièrement parce que deux ou plus d'entre deux doivent être modifiés conjointement [redéfinition d'une fonction par exemple]).
Sinon ton bug ne semble pas vraiment lié au fait que le langage soit dynamique ni au typage dynamique : le champ inexistant ne semble même pas avoir été détecté à l'exécution, ce qui est pourtant possible dans un langage typé dynamiquement. Par curiosité, quel langage as-tu utilisé ?
De manière générale, je ne nie pas le fait que détecter des erreurs plus rapidement (notamment par le compilateur) soit bien. Le problème c'est qu'on ne peut pas toujours tout avoir : les langages statiques et/ou typés statiquement ont un coût caché, qui est la difficulté d'écrire du code de plus haut niveau (et donc de limiter les sources d'erreurs par ailleurs). Faire quelque chose de plus générique est tout de suite plus lourd, pénible, donc soit chiant et sujet aux erreurs, soit la lourdeur dépasse même les gains attendus et on ne le fait pas. C'est difficile d'écrire du code aussi simple dans ces langages, d'écrire des macros (comme celles de Lisp), d'écrire des méta-outils (chargement/sauvegarde de données, ...). Bien sûr on peut toujours le faire, mais si c'est trop compliqué (presque) personne ne le fait. Pour les utilisations les plus communes il y a des outils (les outils de correspondance objet/relationnel par exemple), pour les autres on laisse tomber. Écrire ce genre de choses en Java ce n'est pas si amusant que ça. Et ça devient même vite assez chiant.
L'intérêt de la souplesse des langages dynamiques et du typage dynamique ce n'est pas de s'épargner quelques déclarations de types mais de pouvoir construire des choses de plus haut niveau et d'être plus productif, en considérant que les tests doivent être faits de toutes façons. Écrire du code de plus haut niveau, plus déclaratif, permet de limiter le nombre d'erreurs dans le programme (qui ne se limitent pas à des erreurs détectables par le compilateur) et de le développer plus rapidement, le temps pouvant être reversé dans les tests ou autres activités d'amélioration de la qualité. Les erreurs détectables par un compilateur sont limitées et je trouve que les langages statiques bloquent les possibilités de limiter les erreurs par du code de plus haut niveau et de maîtriser la complexité croissante du développement quand la taille du projet augmente.
Nicolas George
Yliur , dans le message , a écrit :
- Utiliser des interfaces n'est pas toujours possible après coup.
Exemples ?
Pas très extensible,
Précisément.
mais le résultat est plus simple
Je ne trouve pas.
- Je trouve les mécanismes de généricité des langages typés statiquement trop faible.
Quels langages fortement typés connais-tu pour fonder cette affirmation ?
- Comment faire pour avoir une boucle read/eval/print dans un langage statique ?
Quel est le but de la manoeuvre ?
Sinon ton bug ne semble pas vraiment lié au fait que le langage soit dynamique ni au typage dynamique : le champ inexistant ne semble même pas avoir été détecté à l'exécution, ce qui est pourtant possible dans un langage typé dynamiquement.
Effectivement. Mais il aurait été détecté plus tôt.
qui est la difficulté d'écrire du code de plus haut niveau
Tu affirmes ça, mais c'est contraire à mon expérience : je trouve largement aussi facile d'écrire du code générique en CaML qu'en Perl, par exemple. Dommage que la bibliothèque standard de CaML soit si pathétiquement pauvre.
Yliur , dans le message <20110628191031.6ad243e8@alcheringa>, a écrit :
- Utiliser des interfaces n'est pas toujours possible après coup.
Exemples ?
Pas très extensible,
Précisément.
mais le résultat
est plus simple
Je ne trouve pas.
- Je trouve les mécanismes de généricité des langages typés
statiquement trop faible.
Quels langages fortement typés connais-tu pour fonder cette affirmation ?
- Comment faire pour avoir une boucle read/eval/print dans un langage
statique ?
Quel est le but de la manoeuvre ?
Sinon ton bug ne semble pas vraiment lié au fait que le langage soit
dynamique ni au typage dynamique : le champ inexistant ne semble même
pas avoir été détecté à l'exécution, ce qui est pourtant possible dans
un langage typé dynamiquement.
Effectivement. Mais il aurait été détecté plus tôt.
qui est la difficulté
d'écrire du code de plus haut niveau
Tu affirmes ça, mais c'est contraire à mon expérience : je trouve largement
aussi facile d'écrire du code générique en CaML qu'en Perl, par exemple.
Dommage que la bibliothèque standard de CaML soit si pathétiquement pauvre.
- Utiliser des interfaces n'est pas toujours possible après coup.
Exemples ?
Pas très extensible,
Précisément.
mais le résultat est plus simple
Je ne trouve pas.
- Je trouve les mécanismes de généricité des langages typés statiquement trop faible.
Quels langages fortement typés connais-tu pour fonder cette affirmation ?
- Comment faire pour avoir une boucle read/eval/print dans un langage statique ?
Quel est le but de la manoeuvre ?
Sinon ton bug ne semble pas vraiment lié au fait que le langage soit dynamique ni au typage dynamique : le champ inexistant ne semble même pas avoir été détecté à l'exécution, ce qui est pourtant possible dans un langage typé dynamiquement.
Effectivement. Mais il aurait été détecté plus tôt.
qui est la difficulté d'écrire du code de plus haut niveau
Tu affirmes ça, mais c'est contraire à mon expérience : je trouve largement aussi facile d'écrire du code générique en CaML qu'en Perl, par exemple. Dommage que la bibliothèque standard de CaML soit si pathétiquement pauvre.
Dellara
Yliur a papoté sur Usenet le mardi 28 juin 2011 08:54:
Dellara a écrit :
Ah bon, j'ai compris. Tu veux avoir des conversations privées avec chacun de tes interlocuteurs! Ou alors tu ne juges pas opportun de faire connaître les contribruiteurs avec qui tu discutes parce qu'ils n'en valent pas la peine.
Rhâââ, putain, j'ai re-oublié cette fois-ci... Lâche-moi un peu.
D'accord... si tu m'évites de me taper des fils de 300 messages pour savoir à qui tu réponds ;)
Yliur a papoté sur Usenet le mardi 28 juin 2011 08:54:
Dellara <paul.pygeon@gmail.com> a écrit :
Ah bon, j'ai compris. Tu veux avoir des conversations privées avec
chacun de tes interlocuteurs! Ou alors tu ne juges pas opportun de
faire connaître les contribruiteurs avec qui tu discutes parce qu'ils
n'en valent pas la peine.
Rhâââ, putain, j'ai re-oublié cette fois-ci... Lâche-moi un peu.
D'accord... si tu m'évites de me taper des fils de 300 messages pour
savoir à qui tu réponds ;)
Yliur a papoté sur Usenet le mardi 28 juin 2011 08:54:
Dellara a écrit :
Ah bon, j'ai compris. Tu veux avoir des conversations privées avec chacun de tes interlocuteurs! Ou alors tu ne juges pas opportun de faire connaître les contribruiteurs avec qui tu discutes parce qu'ils n'en valent pas la peine.
Rhâââ, putain, j'ai re-oublié cette fois-ci... Lâche-moi un peu.
D'accord... si tu m'évites de me taper des fils de 300 messages pour savoir à qui tu réponds ;)
Nicolas George
Dellara , dans le message <LZuOp.52985$, a écrit :
D'accord... si tu m'évites de me taper des fils de 300 messages pour savoir à qui tu réponds ;)
D'un autre côté, n'importe quel newsreader vaguement décent connecté à un serveur pas trop moisi devrait de donner l'information en moins d'un quart de seconde, alors bon.
Dellara , dans le message <LZuOp.52985$Vp.30355@newsfe14.iad>, a écrit :
D'accord... si tu m'évites de me taper des fils de 300 messages pour
savoir à qui tu réponds ;)
D'un autre côté, n'importe quel newsreader vaguement décent connecté à un
serveur pas trop moisi devrait de donner l'information en moins d'un quart
de seconde, alors bon.
Dellara , dans le message <LZuOp.52985$, a écrit :
D'accord... si tu m'évites de me taper des fils de 300 messages pour savoir à qui tu réponds ;)
D'un autre côté, n'importe quel newsreader vaguement décent connecté à un serveur pas trop moisi devrait de donner l'information en moins d'un quart de seconde, alors bon.
