Le principal souci comme beaucoup, c'est le temps. Je dois pouvoir
consacrer 4-6 heures de programmation effective par semaine et une
bonne dose de lecture de code chaque jour. Je pense consacrer 2 ou 3
années... Ca devrait correspondre à 20-25h par mois et
approximativement 500hr par an ou 250hr par semestre. Je crois c'est
le volume horaire d'une matière dans l'enseignement supérieur (travail
personnel compris).
Mais une formation offre d'autres matières qui
forment un tout ou un cycle.
En tant que comptable, je dispose de connaissances qui devraient me
mener à la gestion de base de données. Je ne sais pas si certains
parmi vous connaissent le monde de la finance mais je crois savoir que
maintenant les ordres d'achats et de ventes (spéculation ou autre)
sont passés automatiquement par des ordinateurs voir l'article du
Canard du enchainé du 12 mai 2010 sur le High Frequency Trading, il y
a un côté hallucinant mais qui ne m'attire pas et je n'ai pas un
niveau en maths qui me permettrait de comprendre les modèles et lois
mathématiques appliqués de la finance, et puis jusqu'au lyçée, plus
les maths étaient abstrait, moins j'étais intéressé...il doit me
manquer quelques bases mais ça ne m'a pas empêché de me rattraper par
la suite quand c'est devenu plus concret avec des problèmes de la vie
de tout les jours qu'on peut avoir en statistiques avec la lois
binomiale, de poisson, normale, le calcul matriciel...
Je me dis que si je suis comptable, ça serait logique de rester dans
un domaine voisin (je crois qu'un langage comme Windev permet des
manipulations avec les bases de données, tout comme Php...).
J'utilise aussi Linux et je suis un peu "frustré" de ne pas pouvoir
accéder au code et programmer des périphériques... Je dois essayer de
rester cohérent surtout si je choisis un chemin plus court et que si
l'autre chemin est plus long, il sera moins probable que je trouverais
quelque chose...mais je suis très intéressé et prêt à passer plusieurs
mois à pour par exemple comprendre le fonctionnement d'un port série.
Le principal souci comme beaucoup, c'est le temps. Je dois pouvoir
consacrer 4-6 heures de programmation effective par semaine et une
bonne dose de lecture de code chaque jour. Je pense consacrer 2 ou 3
années... Ca devrait correspondre à 20-25h par mois et
approximativement 500hr par an ou 250hr par semestre. Je crois c'est
le volume horaire d'une matière dans l'enseignement supérieur (travail
personnel compris).
Mais une formation offre d'autres matières qui
forment un tout ou un cycle.
En tant que comptable, je dispose de connaissances qui devraient me
mener à la gestion de base de données. Je ne sais pas si certains
parmi vous connaissent le monde de la finance mais je crois savoir que
maintenant les ordres d'achats et de ventes (spéculation ou autre)
sont passés automatiquement par des ordinateurs voir l'article du
Canard du enchainé du 12 mai 2010 sur le High Frequency Trading, il y
a un côté hallucinant mais qui ne m'attire pas et je n'ai pas un
niveau en maths qui me permettrait de comprendre les modèles et lois
mathématiques appliqués de la finance, et puis jusqu'au lyçée, plus
les maths étaient abstrait, moins j'étais intéressé...il doit me
manquer quelques bases mais ça ne m'a pas empêché de me rattraper par
la suite quand c'est devenu plus concret avec des problèmes de la vie
de tout les jours qu'on peut avoir en statistiques avec la lois
binomiale, de poisson, normale, le calcul matriciel...
Je me dis que si je suis comptable, ça serait logique de rester dans
un domaine voisin (je crois qu'un langage comme Windev permet des
manipulations avec les bases de données, tout comme Php...).
J'utilise aussi Linux et je suis un peu "frustré" de ne pas pouvoir
accéder au code et programmer des périphériques... Je dois essayer de
rester cohérent surtout si je choisis un chemin plus court et que si
l'autre chemin est plus long, il sera moins probable que je trouverais
quelque chose...mais je suis très intéressé et prêt à passer plusieurs
mois à pour par exemple comprendre le fonctionnement d'un port série.
Le principal souci comme beaucoup, c'est le temps. Je dois pouvoir
consacrer 4-6 heures de programmation effective par semaine et une
bonne dose de lecture de code chaque jour. Je pense consacrer 2 ou 3
années... Ca devrait correspondre à 20-25h par mois et
approximativement 500hr par an ou 250hr par semestre. Je crois c'est
le volume horaire d'une matière dans l'enseignement supérieur (travail
personnel compris).
Mais une formation offre d'autres matières qui
forment un tout ou un cycle.
En tant que comptable, je dispose de connaissances qui devraient me
mener à la gestion de base de données. Je ne sais pas si certains
parmi vous connaissent le monde de la finance mais je crois savoir que
maintenant les ordres d'achats et de ventes (spéculation ou autre)
sont passés automatiquement par des ordinateurs voir l'article du
Canard du enchainé du 12 mai 2010 sur le High Frequency Trading, il y
a un côté hallucinant mais qui ne m'attire pas et je n'ai pas un
niveau en maths qui me permettrait de comprendre les modèles et lois
mathématiques appliqués de la finance, et puis jusqu'au lyçée, plus
les maths étaient abstrait, moins j'étais intéressé...il doit me
manquer quelques bases mais ça ne m'a pas empêché de me rattraper par
la suite quand c'est devenu plus concret avec des problèmes de la vie
de tout les jours qu'on peut avoir en statistiques avec la lois
binomiale, de poisson, normale, le calcul matriciel...
Je me dis que si je suis comptable, ça serait logique de rester dans
un domaine voisin (je crois qu'un langage comme Windev permet des
manipulations avec les bases de données, tout comme Php...).
J'utilise aussi Linux et je suis un peu "frustré" de ne pas pouvoir
accéder au code et programmer des périphériques... Je dois essayer de
rester cohérent surtout si je choisis un chemin plus court et que si
l'autre chemin est plus long, il sera moins probable que je trouverais
quelque chose...mais je suis très intéressé et prêt à passer plusieurs
mois à pour par exemple comprendre le fonctionnement d'un port série.
En tant que comptable, je dispose de connaissances qui devraient me
mener à la gestion de base de données.
Je ne sais pas si certains
parmi vous connaissent le monde de la finance mais je crois savoir que
maintenant les ordres d'achats et de ventes (spéculation ou autre)
sont passés automatiquement par des ordinateurs
Canard du enchainé du 12 mai 2010 sur le High Frequency Trading,
plus les maths étaient abstrait, moins j'étais intéressé...
Je me dis que si je suis comptable, ça serait logique de rester dans
un domaine voisin
(je crois qu'un langage comme Windev permet des
manipulations avec les bases de données, tout comme Php...).
J'utilise aussi Linux et je suis un peu "frustré" de ne pas pouvoir
accéder au code et programmer des périphériques...
En tant que comptable, je dispose de connaissances qui devraient me
mener à la gestion de base de données.
Je ne sais pas si certains
parmi vous connaissent le monde de la finance mais je crois savoir que
maintenant les ordres d'achats et de ventes (spéculation ou autre)
sont passés automatiquement par des ordinateurs
Canard du enchainé du 12 mai 2010 sur le High Frequency Trading,
plus les maths étaient abstrait, moins j'étais intéressé...
Je me dis que si je suis comptable, ça serait logique de rester dans
un domaine voisin
(je crois qu'un langage comme Windev permet des
manipulations avec les bases de données, tout comme Php...).
J'utilise aussi Linux et je suis un peu "frustré" de ne pas pouvoir
accéder au code et programmer des périphériques...
En tant que comptable, je dispose de connaissances qui devraient me
mener à la gestion de base de données.
Je ne sais pas si certains
parmi vous connaissent le monde de la finance mais je crois savoir que
maintenant les ordres d'achats et de ventes (spéculation ou autre)
sont passés automatiquement par des ordinateurs
Canard du enchainé du 12 mai 2010 sur le High Frequency Trading,
plus les maths étaient abstrait, moins j'étais intéressé...
Je me dis que si je suis comptable, ça serait logique de rester dans
un domaine voisin
(je crois qu'un langage comme Windev permet des
manipulations avec les bases de données, tout comme Php...).
J'utilise aussi Linux et je suis un peu "frustré" de ne pas pouvoir
accéder au code et programmer des périphériques...
Par contre effectivement, en 1988 on a eu du boulot pour apprendre aux
ordinateurs à ne pas se planter tout seuls ; vu ce qui s'est semble-t-il
passé le mois dernier sur le Nasdaq,
Par contre effectivement, en 1988 on a eu du boulot pour apprendre aux
ordinateurs à ne pas se planter tout seuls ; vu ce qui s'est semble-t-il
passé le mois dernier sur le Nasdaq,
Par contre effectivement, en 1988 on a eu du boulot pour apprendre aux
ordinateurs à ne pas se planter tout seuls ; vu ce qui s'est semble-t-il
passé le mois dernier sur le Nasdaq,
Le 14-06-2010, Antoine Leca a écrit :
> Marc Boyer écrivit :
>>>> Ou pour échanger des entiers entre deux machines d'archi distincte s ?
>>> .. et ils masquent ces concessions dans de belles classes qui masquen t
>>> les détails d'implémentation à ceux qui veulent les utiliser.
>> Je ne pense pas que ce soit des concessions: séparer l'interface
>> de l'implantation fait partie du travail en OO.
> En C aussi (et désolé pour essayer de revenir au sujet du groupe) :
> lorsqu'on écrit un morceau de code destiné être utilisé plusieu rs fois,
> il est de bon ton d'écrire un fichier .h, qui suffit normalement à
> décrire l'interface, et l'implémentation est gardée dans du code (qui
> peut être regroupé dans des bibliothèques).
Sauf qu'en C, masquer l'implantation des types de données, c'est
se battre contre le compilateur. Si on veut remplacer une liste
chaînée par une table de hachage, il va falloir espérer qu'aucun
code utilisateur n'a utilisé la représentation interne du type.
Ce qu'on arrive bien à faire avec .h/.c, c'est cacher
l'implantation des algos. Pas le type des données.
Arriver à écrire une fonction "find" qui prend en paramêtre
un critère et tout objet ayant une méthode "first()" et une
autre "next()", c'est pas évident.
Après, ces bases de séparation interface/implémentation, c'est plu s
des types de données abstraits (ADT), dont l'OO est un dérivé.
>> C'est plus compliqué d'apprendre à se servir d'une scie sauteu se,
>> d'une scie scirculaire et d'un marteau piqueur que de s'en tenir
>> à clou/marteau/scie égoïne. Mais pour monter une cloison, on va plus
>> vite avec les bons outils.
> Ce que ne sont ni le marteau piqueur, ni la grue. Autrement dit, les
> outils complexes ne sont pas forcément des outils universels : ce son t
> deux concepts assez orthogonaux, ÀMHA.
> Le débat est en fait de savoir si la POO (ou C++, ou C) sont universe ls;
> en ce qui concerne la POO, les puristes dont parlait Samuel semblent
> trancher dans ce sens ; les Vrais Programmeurs du folklore sont
> évidemment de l'avis opposé ; entre les deux... il y a beaucoup d'a vis !
Mon propos, c'est que l'enjeux du code actuel, c'est le passage à
l'échelle, et que le C n'offre pas de support pour traiter cela
(hormis .h/.c, #define, <stdint.h>...).
La POO est le paradigme actuel pour contenir cette complexité. C'es t
compliqué, mais le problème est difficile.
Le 14-06-2010, Antoine Leca <r...@localhost.invalid> a écrit :
> Marc Boyer écrivit :
>>>> Ou pour échanger des entiers entre deux machines d'archi distincte s ?
>>> .. et ils masquent ces concessions dans de belles classes qui masquen t
>>> les détails d'implémentation à ceux qui veulent les utiliser.
>> Je ne pense pas que ce soit des concessions: séparer l'interface
>> de l'implantation fait partie du travail en OO.
> En C aussi (et désolé pour essayer de revenir au sujet du groupe) :
> lorsqu'on écrit un morceau de code destiné être utilisé plusieu rs fois,
> il est de bon ton d'écrire un fichier .h, qui suffit normalement à
> décrire l'interface, et l'implémentation est gardée dans du code (qui
> peut être regroupé dans des bibliothèques).
Sauf qu'en C, masquer l'implantation des types de données, c'est
se battre contre le compilateur. Si on veut remplacer une liste
chaînée par une table de hachage, il va falloir espérer qu'aucun
code utilisateur n'a utilisé la représentation interne du type.
Ce qu'on arrive bien à faire avec .h/.c, c'est cacher
l'implantation des algos. Pas le type des données.
Arriver à écrire une fonction "find" qui prend en paramêtre
un critère et tout objet ayant une méthode "first()" et une
autre "next()", c'est pas évident.
Après, ces bases de séparation interface/implémentation, c'est plu s
des types de données abstraits (ADT), dont l'OO est un dérivé.
>> C'est plus compliqué d'apprendre à se servir d'une scie sauteu se,
>> d'une scie scirculaire et d'un marteau piqueur que de s'en tenir
>> à clou/marteau/scie égoïne. Mais pour monter une cloison, on va plus
>> vite avec les bons outils.
> Ce que ne sont ni le marteau piqueur, ni la grue. Autrement dit, les
> outils complexes ne sont pas forcément des outils universels : ce son t
> deux concepts assez orthogonaux, ÀMHA.
> Le débat est en fait de savoir si la POO (ou C++, ou C) sont universe ls;
> en ce qui concerne la POO, les puristes dont parlait Samuel semblent
> trancher dans ce sens ; les Vrais Programmeurs du folklore sont
> évidemment de l'avis opposé ; entre les deux... il y a beaucoup d'a vis !
Mon propos, c'est que l'enjeux du code actuel, c'est le passage à
l'échelle, et que le C n'offre pas de support pour traiter cela
(hormis .h/.c, #define, <stdint.h>...).
La POO est le paradigme actuel pour contenir cette complexité. C'es t
compliqué, mais le problème est difficile.
Le 14-06-2010, Antoine Leca a écrit :
> Marc Boyer écrivit :
>>>> Ou pour échanger des entiers entre deux machines d'archi distincte s ?
>>> .. et ils masquent ces concessions dans de belles classes qui masquen t
>>> les détails d'implémentation à ceux qui veulent les utiliser.
>> Je ne pense pas que ce soit des concessions: séparer l'interface
>> de l'implantation fait partie du travail en OO.
> En C aussi (et désolé pour essayer de revenir au sujet du groupe) :
> lorsqu'on écrit un morceau de code destiné être utilisé plusieu rs fois,
> il est de bon ton d'écrire un fichier .h, qui suffit normalement à
> décrire l'interface, et l'implémentation est gardée dans du code (qui
> peut être regroupé dans des bibliothèques).
Sauf qu'en C, masquer l'implantation des types de données, c'est
se battre contre le compilateur. Si on veut remplacer une liste
chaînée par une table de hachage, il va falloir espérer qu'aucun
code utilisateur n'a utilisé la représentation interne du type.
Ce qu'on arrive bien à faire avec .h/.c, c'est cacher
l'implantation des algos. Pas le type des données.
Arriver à écrire une fonction "find" qui prend en paramêtre
un critère et tout objet ayant une méthode "first()" et une
autre "next()", c'est pas évident.
Après, ces bases de séparation interface/implémentation, c'est plu s
des types de données abstraits (ADT), dont l'OO est un dérivé.
>> C'est plus compliqué d'apprendre à se servir d'une scie sauteu se,
>> d'une scie scirculaire et d'un marteau piqueur que de s'en tenir
>> à clou/marteau/scie égoïne. Mais pour monter une cloison, on va plus
>> vite avec les bons outils.
> Ce que ne sont ni le marteau piqueur, ni la grue. Autrement dit, les
> outils complexes ne sont pas forcément des outils universels : ce son t
> deux concepts assez orthogonaux, ÀMHA.
> Le débat est en fait de savoir si la POO (ou C++, ou C) sont universe ls;
> en ce qui concerne la POO, les puristes dont parlait Samuel semblent
> trancher dans ce sens ; les Vrais Programmeurs du folklore sont
> évidemment de l'avis opposé ; entre les deux... il y a beaucoup d'a vis !
Mon propos, c'est que l'enjeux du code actuel, c'est le passage à
l'échelle, et que le C n'offre pas de support pour traiter cela
(hormis .h/.c, #define, <stdint.h>...).
La POO est le paradigme actuel pour contenir cette complexité. C'es t
compliqué, mais le problème est difficile.
On 14 juin, 16:05, Marc Boyer
wrote:Le 14-06-2010, Antoine Leca a écrit :
> Marc Boyer écrivit :
>>>> Ou pour échanger des entiers entre deux machines d'archi distinctes ?
>>> .. et ils masquent ces concessions dans de belles classes qui masquent
>>> les détails d'implémentation à ceux qui veulent les utiliser.
>> Je ne pense pas que ce soit des concessions: séparer l'interface
>> de l'implantation fait partie du travail en OO.
> En C aussi (et désolé pour essayer de revenir au sujet du groupe) :
> lorsqu'on écrit un morceau de code destiné être utilisé plusieurs fois,
> il est de bon ton d'écrire un fichier .h, qui suffit normalement à
> décrire l'interface, et l'implémentation est gardée dans du code (qui
> peut être regroupé dans des bibliothèques).
Sauf qu'en C, masquer l'implantation des types de données, c'est
se battre contre le compilateur. Si on veut remplacer une liste
chaînée par une table de hachage, il va falloir espérer qu'aucun
code utilisateur n'a utilisé la représentation interne du type.
Ce qu'on arrive bien à faire avec .h/.c, c'est cacher
l'implantation des algos. Pas le type des données.
Arriver à écrire une fonction "find" qui prend en paramêtre
un critère et tout objet ayant une méthode "first()" et une
autre "next()", c'est pas évident.
Cela suppose une semantique par reference (e.g. Java), ou des
templates a-la-C++ pour une semantique par valeur.
Et cela suppose une
recherche lineaire alors que le "conteneur" est peut-etre capable de
mieux. Les iterateurs restent une abstraction de bas niveau.
La POO est le paradigme actuel pour contenir cette complexité. C'est
compliqué, mais le problème est difficile.
Le probleme est difficile si on cherche a valider le programme a la
compilation (ce qui est impossible sauf cas trivial).
Cette
"validation" ne couvre en general que les erreurs simples et de typo
alors que le code devient de plus en plus complique pour satisfaire le
systeme de type (et les erreurs simples deviennent plus frequentes et
plus compliquees ;-).
type statique valide != type dynamique valide != algorithme valide
Quand on programme, il faut se positionner par rapport ces aspects et
accepter les contraintes inherentes a chacun.
On 14 juin, 16:05, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
wrote:
Le 14-06-2010, Antoine Leca <r...@localhost.invalid> a écrit :
> Marc Boyer écrivit :
>>>> Ou pour échanger des entiers entre deux machines d'archi distinctes ?
>>> .. et ils masquent ces concessions dans de belles classes qui masquent
>>> les détails d'implémentation à ceux qui veulent les utiliser.
>> Je ne pense pas que ce soit des concessions: séparer l'interface
>> de l'implantation fait partie du travail en OO.
> En C aussi (et désolé pour essayer de revenir au sujet du groupe) :
> lorsqu'on écrit un morceau de code destiné être utilisé plusieurs fois,
> il est de bon ton d'écrire un fichier .h, qui suffit normalement à
> décrire l'interface, et l'implémentation est gardée dans du code (qui
> peut être regroupé dans des bibliothèques).
Sauf qu'en C, masquer l'implantation des types de données, c'est
se battre contre le compilateur. Si on veut remplacer une liste
chaînée par une table de hachage, il va falloir espérer qu'aucun
code utilisateur n'a utilisé la représentation interne du type.
Ce qu'on arrive bien à faire avec .h/.c, c'est cacher
l'implantation des algos. Pas le type des données.
Arriver à écrire une fonction "find" qui prend en paramêtre
un critère et tout objet ayant une méthode "first()" et une
autre "next()", c'est pas évident.
Cela suppose une semantique par reference (e.g. Java), ou des
templates a-la-C++ pour une semantique par valeur.
Et cela suppose une
recherche lineaire alors que le "conteneur" est peut-etre capable de
mieux. Les iterateurs restent une abstraction de bas niveau.
La POO est le paradigme actuel pour contenir cette complexité. C'est
compliqué, mais le problème est difficile.
Le probleme est difficile si on cherche a valider le programme a la
compilation (ce qui est impossible sauf cas trivial).
Cette
"validation" ne couvre en general que les erreurs simples et de typo
alors que le code devient de plus en plus complique pour satisfaire le
systeme de type (et les erreurs simples deviennent plus frequentes et
plus compliquees ;-).
type statique valide != type dynamique valide != algorithme valide
Quand on programme, il faut se positionner par rapport ces aspects et
accepter les contraintes inherentes a chacun.
On 14 juin, 16:05, Marc Boyer
wrote:Le 14-06-2010, Antoine Leca a écrit :
> Marc Boyer écrivit :
>>>> Ou pour échanger des entiers entre deux machines d'archi distinctes ?
>>> .. et ils masquent ces concessions dans de belles classes qui masquent
>>> les détails d'implémentation à ceux qui veulent les utiliser.
>> Je ne pense pas que ce soit des concessions: séparer l'interface
>> de l'implantation fait partie du travail en OO.
> En C aussi (et désolé pour essayer de revenir au sujet du groupe) :
> lorsqu'on écrit un morceau de code destiné être utilisé plusieurs fois,
> il est de bon ton d'écrire un fichier .h, qui suffit normalement à
> décrire l'interface, et l'implémentation est gardée dans du code (qui
> peut être regroupé dans des bibliothèques).
Sauf qu'en C, masquer l'implantation des types de données, c'est
se battre contre le compilateur. Si on veut remplacer une liste
chaînée par une table de hachage, il va falloir espérer qu'aucun
code utilisateur n'a utilisé la représentation interne du type.
Ce qu'on arrive bien à faire avec .h/.c, c'est cacher
l'implantation des algos. Pas le type des données.
Arriver à écrire une fonction "find" qui prend en paramêtre
un critère et tout objet ayant une méthode "first()" et une
autre "next()", c'est pas évident.
Cela suppose une semantique par reference (e.g. Java), ou des
templates a-la-C++ pour une semantique par valeur.
Et cela suppose une
recherche lineaire alors que le "conteneur" est peut-etre capable de
mieux. Les iterateurs restent une abstraction de bas niveau.
La POO est le paradigme actuel pour contenir cette complexité. C'est
compliqué, mais le problème est difficile.
Le probleme est difficile si on cherche a valider le programme a la
compilation (ce qui est impossible sauf cas trivial).
Cette
"validation" ne couvre en general que les erreurs simples et de typo
alors que le code devient de plus en plus complique pour satisfaire le
systeme de type (et les erreurs simples deviennent plus frequentes et
plus compliquees ;-).
type statique valide != type dynamique valide != algorithme valide
Quand on programme, il faut se positionner par rapport ces aspects et
accepter les contraintes inherentes a chacun.
Le 16-06-2010, ld a écrit :
> On 14 juin, 16:05, Marc Boyer
> wrote:
>> Le 14-06-2010, Antoine Leca a écrit :
>> > Marc Boyer écrivit :
>> >>>> Ou pour échanger des entiers entre deux machines d'archi distin ctes ?
>> >>> .. et ils masquent ces concessions dans de belles classes qui masq uent
>> >>> les détails d'implémentation à ceux qui veulent les utiliser .
>> >> Je ne pense pas que ce soit des concessions: séparer l'interf ace
>> >> de l'implantation fait partie du travail en OO.
>> > En C aussi (et désolé pour essayer de revenir au sujet du groupe ) :
>> > lorsqu'on écrit un morceau de code destiné être utilisé plus ieurs fois,
>> > il est de bon ton d'écrire un fichier .h, qui suffit normalement à
>> > décrire l'interface, et l'implémentation est gardée dans du co de (qui
>> > peut être regroupé dans des bibliothèques).
>> Sauf qu'en C, masquer l'implantation des types de données, c' est
>> se battre contre le compilateur. Si on veut remplacer une liste
>> chaînée par une table de hachage, il va falloir espérer qu'aucun
>> code utilisateur n'a utilisé la représentation interne du type.
>> Ce qu'on arrive bien à faire avec .h/.c, c'est cacher
>> l'implantation des algos. Pas le type des données.
>> Arriver à écrire une fonction "find" qui prend en paramêt re
>> un critère et tout objet ayant une méthode "first()" et une
>> autre "next()", c'est pas évident.
> Cela suppose une semantique par reference (e.g. Java), ou des
> templates a-la-C++ pour une semantique par valeur.
Dans les deux cas, cela permet d'appliquer un code sur une structure
de données dont on ne connait qu'une partie de l'interface (ce qui
était mon propos), et que le faire en C, c'est pas facile
(et ne me dit
pas que COS ne fait que 7KLOC, dont que c'est pas difficile, ni que
OOC-S n'en fait que 300).
> Et cela suppose une
> recherche lineaire alors que le "conteneur" est peut-etre capable de
> mieux. Les iterateurs restent une abstraction de bas niveau.
Oui, on pourrait imaginer un "find" encore plus générique,
c'était juste un exemple.
>> La POO est le paradigme actuel pour contenir cette complexité. C 'est
>> compliqué, mais le problème est difficile.
> Le probleme est difficile si on cherche a valider le programme a la
> compilation (ce qui est impossible sauf cas trivial).
<pub>
On fait des progrès quand même ;-)
</pub>
> Cette
> "validation" ne couvre en general que les erreurs simples et de typo
> alors que le code devient de plus en plus complique pour satisfaire le
> systeme de type (et les erreurs simples deviennent plus frequentes et
> plus compliquees ;-).
> type statique valide != type dynamique valide != algorithme valide
> Quand on programme, il faut se positionner par rapport ces aspects et
> accepter les contraintes inherentes a chacun.
Je ne nie pas ce que tu dis, mais à mon sens, la difficulité d u
code actuel n'est pas l'algorithmique (a part certains domaines métiers ),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
Les problèmes actuels seraient plutôt dans la gestion des gros
systèmes, l'assemblage de milliers de composants, tous plutôt simple,
tous quasiment corrects, mais dont l'assemblage (et la maintenance)
est compliqué au possible.
La partie automatique de détection d'erreurs se fait grace au typag e
et à l'OO (qui a gagné la guerre face à ses concurents).
Le 16-06-2010, ld <laurent.den...@gmail.com> a écrit :
> On 14 juin, 16:05, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
> wrote:
>> Le 14-06-2010, Antoine Leca <r...@localhost.invalid> a écrit :
>> > Marc Boyer écrivit :
>> >>>> Ou pour échanger des entiers entre deux machines d'archi distin ctes ?
>> >>> .. et ils masquent ces concessions dans de belles classes qui masq uent
>> >>> les détails d'implémentation à ceux qui veulent les utiliser .
>> >> Je ne pense pas que ce soit des concessions: séparer l'interf ace
>> >> de l'implantation fait partie du travail en OO.
>> > En C aussi (et désolé pour essayer de revenir au sujet du groupe ) :
>> > lorsqu'on écrit un morceau de code destiné être utilisé plus ieurs fois,
>> > il est de bon ton d'écrire un fichier .h, qui suffit normalement à
>> > décrire l'interface, et l'implémentation est gardée dans du co de (qui
>> > peut être regroupé dans des bibliothèques).
>> Sauf qu'en C, masquer l'implantation des types de données, c' est
>> se battre contre le compilateur. Si on veut remplacer une liste
>> chaînée par une table de hachage, il va falloir espérer qu'aucun
>> code utilisateur n'a utilisé la représentation interne du type.
>> Ce qu'on arrive bien à faire avec .h/.c, c'est cacher
>> l'implantation des algos. Pas le type des données.
>> Arriver à écrire une fonction "find" qui prend en paramêt re
>> un critère et tout objet ayant une méthode "first()" et une
>> autre "next()", c'est pas évident.
> Cela suppose une semantique par reference (e.g. Java), ou des
> templates a-la-C++ pour une semantique par valeur.
Dans les deux cas, cela permet d'appliquer un code sur une structure
de données dont on ne connait qu'une partie de l'interface (ce qui
était mon propos), et que le faire en C, c'est pas facile
(et ne me dit
pas que COS ne fait que 7KLOC, dont que c'est pas difficile, ni que
OOC-S n'en fait que 300).
> Et cela suppose une
> recherche lineaire alors que le "conteneur" est peut-etre capable de
> mieux. Les iterateurs restent une abstraction de bas niveau.
Oui, on pourrait imaginer un "find" encore plus générique,
c'était juste un exemple.
>> La POO est le paradigme actuel pour contenir cette complexité. C 'est
>> compliqué, mais le problème est difficile.
> Le probleme est difficile si on cherche a valider le programme a la
> compilation (ce qui est impossible sauf cas trivial).
<pub>
On fait des progrès quand même ;-)
</pub>
> Cette
> "validation" ne couvre en general que les erreurs simples et de typo
> alors que le code devient de plus en plus complique pour satisfaire le
> systeme de type (et les erreurs simples deviennent plus frequentes et
> plus compliquees ;-).
> type statique valide != type dynamique valide != algorithme valide
> Quand on programme, il faut se positionner par rapport ces aspects et
> accepter les contraintes inherentes a chacun.
Je ne nie pas ce que tu dis, mais à mon sens, la difficulité d u
code actuel n'est pas l'algorithmique (a part certains domaines métiers ),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
Les problèmes actuels seraient plutôt dans la gestion des gros
systèmes, l'assemblage de milliers de composants, tous plutôt simple,
tous quasiment corrects, mais dont l'assemblage (et la maintenance)
est compliqué au possible.
La partie automatique de détection d'erreurs se fait grace au typag e
et à l'OO (qui a gagné la guerre face à ses concurents).
Le 16-06-2010, ld a écrit :
> On 14 juin, 16:05, Marc Boyer
> wrote:
>> Le 14-06-2010, Antoine Leca a écrit :
>> > Marc Boyer écrivit :
>> >>>> Ou pour échanger des entiers entre deux machines d'archi distin ctes ?
>> >>> .. et ils masquent ces concessions dans de belles classes qui masq uent
>> >>> les détails d'implémentation à ceux qui veulent les utiliser .
>> >> Je ne pense pas que ce soit des concessions: séparer l'interf ace
>> >> de l'implantation fait partie du travail en OO.
>> > En C aussi (et désolé pour essayer de revenir au sujet du groupe ) :
>> > lorsqu'on écrit un morceau de code destiné être utilisé plus ieurs fois,
>> > il est de bon ton d'écrire un fichier .h, qui suffit normalement à
>> > décrire l'interface, et l'implémentation est gardée dans du co de (qui
>> > peut être regroupé dans des bibliothèques).
>> Sauf qu'en C, masquer l'implantation des types de données, c' est
>> se battre contre le compilateur. Si on veut remplacer une liste
>> chaînée par une table de hachage, il va falloir espérer qu'aucun
>> code utilisateur n'a utilisé la représentation interne du type.
>> Ce qu'on arrive bien à faire avec .h/.c, c'est cacher
>> l'implantation des algos. Pas le type des données.
>> Arriver à écrire une fonction "find" qui prend en paramêt re
>> un critère et tout objet ayant une méthode "first()" et une
>> autre "next()", c'est pas évident.
> Cela suppose une semantique par reference (e.g. Java), ou des
> templates a-la-C++ pour une semantique par valeur.
Dans les deux cas, cela permet d'appliquer un code sur une structure
de données dont on ne connait qu'une partie de l'interface (ce qui
était mon propos), et que le faire en C, c'est pas facile
(et ne me dit
pas que COS ne fait que 7KLOC, dont que c'est pas difficile, ni que
OOC-S n'en fait que 300).
> Et cela suppose une
> recherche lineaire alors que le "conteneur" est peut-etre capable de
> mieux. Les iterateurs restent une abstraction de bas niveau.
Oui, on pourrait imaginer un "find" encore plus générique,
c'était juste un exemple.
>> La POO est le paradigme actuel pour contenir cette complexité. C 'est
>> compliqué, mais le problème est difficile.
> Le probleme est difficile si on cherche a valider le programme a la
> compilation (ce qui est impossible sauf cas trivial).
<pub>
On fait des progrès quand même ;-)
</pub>
> Cette
> "validation" ne couvre en general que les erreurs simples et de typo
> alors que le code devient de plus en plus complique pour satisfaire le
> systeme de type (et les erreurs simples deviennent plus frequentes et
> plus compliquees ;-).
> type statique valide != type dynamique valide != algorithme valide
> Quand on programme, il faut se positionner par rapport ces aspects et
> accepter les contraintes inherentes a chacun.
Je ne nie pas ce que tu dis, mais à mon sens, la difficulité d u
code actuel n'est pas l'algorithmique (a part certains domaines métiers ),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
Les problèmes actuels seraient plutôt dans la gestion des gros
systèmes, l'assemblage de milliers de composants, tous plutôt simple,
tous quasiment corrects, mais dont l'assemblage (et la maintenance)
est compliqué au possible.
La partie automatique de détection d'erreurs se fait grace au typag e
et à l'OO (qui a gagné la guerre face à ses concurents).
Je ne nie pas ce que tu dis, mais à mon sens, la difficulité du
code actuel n'est pas l'algorithmique (a part certains domaines métiers),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
Les problèmes actuels seraient plutôt dans la gestion des gros
systèmes, l'assemblage de milliers de composants, tous plutôt simple,
tous quasiment corrects, mais dont l'assemblage (et la maintenance)
est compliqué au possible.
Je ne nie pas ce que tu dis, mais à mon sens, la difficulité du
code actuel n'est pas l'algorithmique (a part certains domaines métiers),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
Les problèmes actuels seraient plutôt dans la gestion des gros
systèmes, l'assemblage de milliers de composants, tous plutôt simple,
tous quasiment corrects, mais dont l'assemblage (et la maintenance)
est compliqué au possible.
Je ne nie pas ce que tu dis, mais à mon sens, la difficulité du
code actuel n'est pas l'algorithmique (a part certains domaines métiers),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
Les problèmes actuels seraient plutôt dans la gestion des gros
systèmes, l'assemblage de milliers de composants, tous plutôt simple,
tous quasiment corrects, mais dont l'assemblage (et la maintenance)
est compliqué au possible.
On 16 juin, 16:46, Marc Boyer
wrote:Le 16-06-2010, ld a écrit :
> On 14 juin, 16:05, Marc Boyer
> wrote:
>> Le 14-06-2010, Antoine Leca a écrit :
> Cela suppose une semantique par reference (e.g. Java), ou des
> templates a-la-C++ pour une semantique par valeur.
Dans les deux cas, cela permet d'appliquer un code sur une structure
de données dont on ne connait qu'une partie de l'interface (ce qui
était mon propos), et que le faire en C, c'est pas facile
C'est ce point que je ne comprends pas. Ce n'est pas plus difficile en
C qu'en autre chose si on choisi la bonne approche.
mais tu peux aussi regarder du cote de libavl ou de nombreuses autres
bibliotheques qui utilisent aussi le concept d'iterateur en C et ce
n'est pas complique.
> type statique valide != type dynamique valide != algorithme valide
> Quand on programme, il faut se positionner par rapport ces aspects et
> accepter les contraintes inherentes a chacun.
Je ne nie pas ce que tu dis, mais à mon sens, la difficulité du
code actuel n'est pas l'algorithmique (a part certains domaines métiers),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
Les problèmes actuels seraient plutôt dans la gestion des gros
systèmes, l'assemblage de milliers de composants, tous plutôt simple,
tous quasiment corrects, mais dont l'assemblage (et la maintenance)
est compliqué au possible.
Le probleme vient principalement du fait que ce que tu appelles des
composants n'en sont pas. Sinon il y en aurait beaucoup moins et
l'assemblage serait en grande partie "automatique".
La partie automatique de détection d'erreurs se fait grace au typage
et à l'OO (qui a gagné la guerre face à ses concurents).
Mais la guerre des langages n'est pas finie ;-) Des languages comme
Scala ou Haskell ont une popularite croissante. Mais ce sont aussi de
beaux exemples qui montrent la difficulte de capturer _simplement_
certain concepts (composition des interfaces et variabilite par
exemple) dans un systeme a typage statique.
On 16 juin, 16:46, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
wrote:
Le 16-06-2010, ld <laurent.den...@gmail.com> a écrit :
> On 14 juin, 16:05, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
> wrote:
>> Le 14-06-2010, Antoine Leca <r...@localhost.invalid> a écrit :
> Cela suppose une semantique par reference (e.g. Java), ou des
> templates a-la-C++ pour une semantique par valeur.
Dans les deux cas, cela permet d'appliquer un code sur une structure
de données dont on ne connait qu'une partie de l'interface (ce qui
était mon propos), et que le faire en C, c'est pas facile
C'est ce point que je ne comprends pas. Ce n'est pas plus difficile en
C qu'en autre chose si on choisi la bonne approche.
mais tu peux aussi regarder du cote de libavl ou de nombreuses autres
bibliotheques qui utilisent aussi le concept d'iterateur en C et ce
n'est pas complique.
> type statique valide != type dynamique valide != algorithme valide
> Quand on programme, il faut se positionner par rapport ces aspects et
> accepter les contraintes inherentes a chacun.
Je ne nie pas ce que tu dis, mais à mon sens, la difficulité du
code actuel n'est pas l'algorithmique (a part certains domaines métiers),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
Les problèmes actuels seraient plutôt dans la gestion des gros
systèmes, l'assemblage de milliers de composants, tous plutôt simple,
tous quasiment corrects, mais dont l'assemblage (et la maintenance)
est compliqué au possible.
Le probleme vient principalement du fait que ce que tu appelles des
composants n'en sont pas. Sinon il y en aurait beaucoup moins et
l'assemblage serait en grande partie "automatique".
La partie automatique de détection d'erreurs se fait grace au typage
et à l'OO (qui a gagné la guerre face à ses concurents).
Mais la guerre des langages n'est pas finie ;-) Des languages comme
Scala ou Haskell ont une popularite croissante. Mais ce sont aussi de
beaux exemples qui montrent la difficulte de capturer _simplement_
certain concepts (composition des interfaces et variabilite par
exemple) dans un systeme a typage statique.
On 16 juin, 16:46, Marc Boyer
wrote:Le 16-06-2010, ld a écrit :
> On 14 juin, 16:05, Marc Boyer
> wrote:
>> Le 14-06-2010, Antoine Leca a écrit :
> Cela suppose une semantique par reference (e.g. Java), ou des
> templates a-la-C++ pour une semantique par valeur.
Dans les deux cas, cela permet d'appliquer un code sur une structure
de données dont on ne connait qu'une partie de l'interface (ce qui
était mon propos), et que le faire en C, c'est pas facile
C'est ce point que je ne comprends pas. Ce n'est pas plus difficile en
C qu'en autre chose si on choisi la bonne approche.
mais tu peux aussi regarder du cote de libavl ou de nombreuses autres
bibliotheques qui utilisent aussi le concept d'iterateur en C et ce
n'est pas complique.
> type statique valide != type dynamique valide != algorithme valide
> Quand on programme, il faut se positionner par rapport ces aspects et
> accepter les contraintes inherentes a chacun.
Je ne nie pas ce que tu dis, mais à mon sens, la difficulité du
code actuel n'est pas l'algorithmique (a part certains domaines métiers),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
Les problèmes actuels seraient plutôt dans la gestion des gros
systèmes, l'assemblage de milliers de composants, tous plutôt simple,
tous quasiment corrects, mais dont l'assemblage (et la maintenance)
est compliqué au possible.
Le probleme vient principalement du fait que ce que tu appelles des
composants n'en sont pas. Sinon il y en aurait beaucoup moins et
l'assemblage serait en grande partie "automatique".
La partie automatique de détection d'erreurs se fait grace au typage
et à l'OO (qui a gagné la guerre face à ses concurents).
Mais la guerre des langages n'est pas finie ;-) Des languages comme
Scala ou Haskell ont une popularite croissante. Mais ce sont aussi de
beaux exemples qui montrent la difficulte de capturer _simplement_
certain concepts (composition des interfaces et variabilite par
exemple) dans un systeme a typage statique.
Marc Boyer écrivit :Je ne nie pas ce que tu dis, mais à mon sens, la difficulité du
code actuel n'est pas l'algorithmique (a part certains domaines métiers),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
À mon avis, ce n'est pas propre au génie logiciel, cela s'étend à
l'ensemble des « sciences de l'ingénieur » (génie sans qualificatif a un
autre sens !) : savoir, la plus grand part des problèmes ne sont pas
techniquement difficiles, unitairement ; par contre ils sont complexes.
Les problèmes actuels seraient plutôt dans la gestion des gros
systèmes, l'assemblage de milliers de composants, tous plutôt simple,
tous quasiment corrects, mais dont l'assemblage (et la maintenance)
est compliqué au possible.
Si l'assemblage est compliqué, c'est que le composant est mauvais : en
effet, la fonction réelle d'un composant est au moins autant de réaliser
les fonctionnalités promises, que d'assurer la possibilité de la mise en
œuvre (l'assemblage facile) : sinon, tu as inventé une brique à hautes
performances mais qui nécessite un ingénieur pour monter le mur (à la
place du maçon) : désolé, mais avec cela tu ne peux pas faire de maison!
Et la tromperie du système, c'est que les cahiers des charges s'arrêtent
à la première partie... parce que c'est la plus facile à spécifier (je
dis la même chose que Laurent).
Marc Boyer écrivit :
Je ne nie pas ce que tu dis, mais à mon sens, la difficulité du
code actuel n'est pas l'algorithmique (a part certains domaines métiers),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
À mon avis, ce n'est pas propre au génie logiciel, cela s'étend à
l'ensemble des « sciences de l'ingénieur » (génie sans qualificatif a un
autre sens !) : savoir, la plus grand part des problèmes ne sont pas
techniquement difficiles, unitairement ; par contre ils sont complexes.
Les problèmes actuels seraient plutôt dans la gestion des gros
systèmes, l'assemblage de milliers de composants, tous plutôt simple,
tous quasiment corrects, mais dont l'assemblage (et la maintenance)
est compliqué au possible.
Si l'assemblage est compliqué, c'est que le composant est mauvais : en
effet, la fonction réelle d'un composant est au moins autant de réaliser
les fonctionnalités promises, que d'assurer la possibilité de la mise en
œuvre (l'assemblage facile) : sinon, tu as inventé une brique à hautes
performances mais qui nécessite un ingénieur pour monter le mur (à la
place du maçon) : désolé, mais avec cela tu ne peux pas faire de maison!
Et la tromperie du système, c'est que les cahiers des charges s'arrêtent
à la première partie... parce que c'est la plus facile à spécifier (je
dis la même chose que Laurent).
Marc Boyer écrivit :Je ne nie pas ce que tu dis, mais à mon sens, la difficulité du
code actuel n'est pas l'algorithmique (a part certains domaines métiers),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
À mon avis, ce n'est pas propre au génie logiciel, cela s'étend à
l'ensemble des « sciences de l'ingénieur » (génie sans qualificatif a un
autre sens !) : savoir, la plus grand part des problèmes ne sont pas
techniquement difficiles, unitairement ; par contre ils sont complexes.
Les problèmes actuels seraient plutôt dans la gestion des gros
systèmes, l'assemblage de milliers de composants, tous plutôt simple,
tous quasiment corrects, mais dont l'assemblage (et la maintenance)
est compliqué au possible.
Si l'assemblage est compliqué, c'est que le composant est mauvais : en
effet, la fonction réelle d'un composant est au moins autant de réaliser
les fonctionnalités promises, que d'assurer la possibilité de la mise en
œuvre (l'assemblage facile) : sinon, tu as inventé une brique à hautes
performances mais qui nécessite un ingénieur pour monter le mur (à la
place du maçon) : désolé, mais avec cela tu ne peux pas faire de maison!
Et la tromperie du système, c'est que les cahiers des charges s'arrêtent
à la première partie... parce que c'est la plus facile à spécifier (je
dis la même chose que Laurent).
Le 16-06-2010, Antoine Leca a écrit :Marc Boyer écrivit :Je ne nie pas ce que tu dis, mais à mon sens, la difficulité du
code actuel n'est pas l'algorithmique (a part certains domaines métiers),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
À mon avis, ce n'est pas propre au génie logiciel, cela s'étend à
l'ensemble des « sciences de l'ingénieur » (génie sans qualificatif a un
autre sens !) : savoir, la plus grand part des problèmes ne sont pas
techniquement difficiles, unitairement ; par contre ils sont complexes.
Je ne suis pas sûr. L'écoulement des gaz dans un réacteurs, c'est
compliqué.
Et le logiciel a cela de particulier qu'il a tendance a être
très sensible aux petites erreurs.
Le 16-06-2010, Antoine Leca <root@localhost.invalid> a écrit :
Marc Boyer écrivit :
Je ne nie pas ce que tu dis, mais à mon sens, la difficulité du
code actuel n'est pas l'algorithmique (a part certains domaines métiers),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
À mon avis, ce n'est pas propre au génie logiciel, cela s'étend à
l'ensemble des « sciences de l'ingénieur » (génie sans qualificatif a un
autre sens !) : savoir, la plus grand part des problèmes ne sont pas
techniquement difficiles, unitairement ; par contre ils sont complexes.
Je ne suis pas sûr. L'écoulement des gaz dans un réacteurs, c'est
compliqué.
Et le logiciel a cela de particulier qu'il a tendance a être
très sensible aux petites erreurs.
Le 16-06-2010, Antoine Leca a écrit :Marc Boyer écrivit :Je ne nie pas ce que tu dis, mais à mon sens, la difficulité du
code actuel n'est pas l'algorithmique (a part certains domaines métiers),
et les grands plantages informatiques ne sont pas liés à des
pb d'algorithmes.
À mon avis, ce n'est pas propre au génie logiciel, cela s'étend à
l'ensemble des « sciences de l'ingénieur » (génie sans qualificatif a un
autre sens !) : savoir, la plus grand part des problèmes ne sont pas
techniquement difficiles, unitairement ; par contre ils sont complexes.
Je ne suis pas sûr. L'écoulement des gaz dans un réacteurs, c'est
compliqué.
Et le logiciel a cela de particulier qu'il a tendance a être
très sensible aux petites erreurs.