Pardonnez-moi mais je suis certinement déformé par les projets et les
milieux que j'ai fréquentés qui requièrent effectivement un très haut
niveau d'exigence concernant la fiabilité et la sûreté de fonctionnement.
Pour te donner une idée, l'ensemble des logiciels (y compris les
programmes de tests, les simulations logicielles, etc.) pour l'ISS
représentent environ 80 millions de lignes de code.
Mais un simple compilateur COBOL fait déjà dans les 250 mille lignes de
code.
Pardonnez-moi mais je suis certinement déformé par les projets et les
milieux que j'ai fréquentés qui requièrent effectivement un très haut
niveau d'exigence concernant la fiabilité et la sûreté de fonctionnement.
Pour te donner une idée, l'ensemble des logiciels (y compris les
programmes de tests, les simulations logicielles, etc.) pour l'ISS
représentent environ 80 millions de lignes de code.
Mais un simple compilateur COBOL fait déjà dans les 250 mille lignes de
code.
Pardonnez-moi mais je suis certinement déformé par les projets et les
milieux que j'ai fréquentés qui requièrent effectivement un très haut
niveau d'exigence concernant la fiabilité et la sûreté de fonctionnement.
Pour te donner une idée, l'ensemble des logiciels (y compris les
programmes de tests, les simulations logicielles, etc.) pour l'ISS
représentent environ 80 millions de lignes de code.
Mais un simple compilateur COBOL fait déjà dans les 250 mille lignes de
code.
J'ai audité des millions de lignes de code (à l'aide de Logiscope). Ce
que je peux dire c'est que, même dans les domaines les plus pointus et
qui requièrent une grande fiabilité et sûreté de fonctionnement comme le
nucléaire, l'avionique ou le spatial, il n'y a pas 10% de programmeurs
qui programment "proprement.
La faute aux variables globales !! :)) Non sérieux , tu peux un peu
détailler stp, enfin concernant le C pour pas être trop hors-sujet ?
Quand tu dis que 90% ne savent pas programmer des applications
nécessitant une grande sécurité, quelle part de l'incompétence
attribues-tu à une mauvaise connaissance (universitaire) du langage C
lui-même ? est-ce juste une question de formation incomplète au pas
assez poussée ou une question de relâchement dans la façon de coder ?
Mais je suis d'accord que pour des non informaticiens scientifiques qui
doivent faire des petites simulations ou des petits modèles, ce genre de
langage peut rendre des services mais alors il ne faut pas parler
d'informatique au sens industriel du terme (quand je dis industriel, je
rapproche la fabrication de logiciels à la fabrication d'automobiles ou
d'avions).
Et à l'heure actuelle, on utilise massivement quel langage en
informatique industrielle ? Vois-tu un avenir au C "industriel" autre
que de la maintenance d'applications (tout du moins dans le domaine que
tu connais) ?
Merci, je suis très intéressé par tes réponses.
J'ai audité des millions de lignes de code (à l'aide de Logiscope). Ce
que je peux dire c'est que, même dans les domaines les plus pointus et
qui requièrent une grande fiabilité et sûreté de fonctionnement comme le
nucléaire, l'avionique ou le spatial, il n'y a pas 10% de programmeurs
qui programment "proprement.
La faute aux variables globales !! :)) Non sérieux , tu peux un peu
détailler stp, enfin concernant le C pour pas être trop hors-sujet ?
Quand tu dis que 90% ne savent pas programmer des applications
nécessitant une grande sécurité, quelle part de l'incompétence
attribues-tu à une mauvaise connaissance (universitaire) du langage C
lui-même ? est-ce juste une question de formation incomplète au pas
assez poussée ou une question de relâchement dans la façon de coder ?
Mais je suis d'accord que pour des non informaticiens scientifiques qui
doivent faire des petites simulations ou des petits modèles, ce genre de
langage peut rendre des services mais alors il ne faut pas parler
d'informatique au sens industriel du terme (quand je dis industriel, je
rapproche la fabrication de logiciels à la fabrication d'automobiles ou
d'avions).
Et à l'heure actuelle, on utilise massivement quel langage en
informatique industrielle ? Vois-tu un avenir au C "industriel" autre
que de la maintenance d'applications (tout du moins dans le domaine que
tu connais) ?
Merci, je suis très intéressé par tes réponses.
J'ai audité des millions de lignes de code (à l'aide de Logiscope). Ce
que je peux dire c'est que, même dans les domaines les plus pointus et
qui requièrent une grande fiabilité et sûreté de fonctionnement comme le
nucléaire, l'avionique ou le spatial, il n'y a pas 10% de programmeurs
qui programment "proprement.
La faute aux variables globales !! :)) Non sérieux , tu peux un peu
détailler stp, enfin concernant le C pour pas être trop hors-sujet ?
Quand tu dis que 90% ne savent pas programmer des applications
nécessitant une grande sécurité, quelle part de l'incompétence
attribues-tu à une mauvaise connaissance (universitaire) du langage C
lui-même ? est-ce juste une question de formation incomplète au pas
assez poussée ou une question de relâchement dans la façon de coder ?
Mais je suis d'accord que pour des non informaticiens scientifiques qui
doivent faire des petites simulations ou des petits modèles, ce genre de
langage peut rendre des services mais alors il ne faut pas parler
d'informatique au sens industriel du terme (quand je dis industriel, je
rapproche la fabrication de logiciels à la fabrication d'automobiles ou
d'avions).
Et à l'heure actuelle, on utilise massivement quel langage en
informatique industrielle ? Vois-tu un avenir au C "industriel" autre
que de la maintenance d'applications (tout du moins dans le domaine que
tu connais) ?
Merci, je suis très intéressé par tes réponses.
In article , wykaaa wrote:Très intéressant mais comme le fait remarquer zeavan dans le forum, cela
reflète plus le monde académique.
Je remarque une forte poussée de Ruby, qui est un bien meilleur langage
que Python , dans le même genre de famille de langage
Bien meilleur ? en quoi ? pour l'instant, l'implementation se traine
un peu, etant purement interpretee et sans byte-code... ce qui la plombe un
peu par rapport aux voisins.
In article <op.t8wd2csm54jsyq@lemacpro.local>, wykaaa <wykaaa@yahoo.fr> wrote:
Très intéressant mais comme le fait remarquer zeavan dans le forum, cela
reflète plus le monde académique.
Je remarque une forte poussée de Ruby, qui est un bien meilleur langage
que Python , dans le même genre de famille de langage
Bien meilleur ? en quoi ? pour l'instant, l'implementation se traine
un peu, etant purement interpretee et sans byte-code... ce qui la plombe un
peu par rapport aux voisins.
In article , wykaaa wrote:Très intéressant mais comme le fait remarquer zeavan dans le forum, cela
reflète plus le monde académique.
Je remarque une forte poussée de Ruby, qui est un bien meilleur langage
que Python , dans le même genre de famille de langage
Bien meilleur ? en quoi ? pour l'instant, l'implementation se traine
un peu, etant purement interpretee et sans byte-code... ce qui la plombe un
peu par rapport aux voisins.
Il y a donc, effectivement, une formation incomplète mais rien ne
remplace l'expérience. Il faut coder, coder et encore coder...
Merci, je suis très intéressé par tes réponses.
J'espère avoir répondu à tes espérances :-)
Il y a donc, effectivement, une formation incomplète mais rien ne
remplace l'expérience. Il faut coder, coder et encore coder...
Merci, je suis très intéressé par tes réponses.
J'espère avoir répondu à tes espérances :-)
Il y a donc, effectivement, une formation incomplète mais rien ne
remplace l'expérience. Il faut coder, coder et encore coder...
Merci, je suis très intéressé par tes réponses.
J'espère avoir répondu à tes espérances :-)
In article , wykaaa
wrote:Très intéressant mais comme le fait remarquer zeavan dans le forum, cela
reflète plus le monde académique.
Je remarque une forte poussée de Ruby, qui est un bien meilleur langage
que Python , dans le même genre de famille de langage
Bien meilleur ? en quoi ? pour l'instant, l'implementation se traine
un peu, etant purement interpretee et sans byte-code... ce qui la plombe un
peu par rapport aux voisins.
Je ne parlais pas de l'implémentation mais du langage lui-même.
Ruby utilise une syntaxe simple, inspirée par Eiffel et Ada (ce qui est
forcément un plus, ces deux langages étant reconnus pour leur "propreté
syntaxique").
Il est "pur objet", un peu à la SmallTalk (même les types sont des
objets). Un langage "pur objet" est toujours un plus dans l'approche objet.
Et immense avantage, il a les threads indépendants du système
d'exploitation (on ne peut se passer du multi-threading aujourd'hui...)
Ce dernier trait a effectivement une contrepartie : une certaine lenteur.
Il suffira de faire pour Ruby ce qui a été fait pour Java (des JIT :
Just in Time Compilers) et la question sera réglée.
In article <op.t8wd2csm54jsyq@lemacpro.local>, wykaaa
<wykaaa@yahoo.fr> wrote:
Très intéressant mais comme le fait remarquer zeavan dans le forum, cela
reflète plus le monde académique.
Je remarque une forte poussée de Ruby, qui est un bien meilleur langage
que Python , dans le même genre de famille de langage
Bien meilleur ? en quoi ? pour l'instant, l'implementation se traine
un peu, etant purement interpretee et sans byte-code... ce qui la plombe un
peu par rapport aux voisins.
Je ne parlais pas de l'implémentation mais du langage lui-même.
Ruby utilise une syntaxe simple, inspirée par Eiffel et Ada (ce qui est
forcément un plus, ces deux langages étant reconnus pour leur "propreté
syntaxique").
Il est "pur objet", un peu à la SmallTalk (même les types sont des
objets). Un langage "pur objet" est toujours un plus dans l'approche objet.
Et immense avantage, il a les threads indépendants du système
d'exploitation (on ne peut se passer du multi-threading aujourd'hui...)
Ce dernier trait a effectivement une contrepartie : une certaine lenteur.
Il suffira de faire pour Ruby ce qui a été fait pour Java (des JIT :
Just in Time Compilers) et la question sera réglée.
In article , wykaaa
wrote:Très intéressant mais comme le fait remarquer zeavan dans le forum, cela
reflète plus le monde académique.
Je remarque une forte poussée de Ruby, qui est un bien meilleur langage
que Python , dans le même genre de famille de langage
Bien meilleur ? en quoi ? pour l'instant, l'implementation se traine
un peu, etant purement interpretee et sans byte-code... ce qui la plombe un
peu par rapport aux voisins.
Je ne parlais pas de l'implémentation mais du langage lui-même.
Ruby utilise une syntaxe simple, inspirée par Eiffel et Ada (ce qui est
forcément un plus, ces deux langages étant reconnus pour leur "propreté
syntaxique").
Il est "pur objet", un peu à la SmallTalk (même les types sont des
objets). Un langage "pur objet" est toujours un plus dans l'approche objet.
Et immense avantage, il a les threads indépendants du système
d'exploitation (on ne peut se passer du multi-threading aujourd'hui...)
Ce dernier trait a effectivement une contrepartie : une certaine lenteur.
Il suffira de faire pour Ruby ce qui a été fait pour Java (des JIT :
Just in Time Compilers) et la question sera réglée.
In article <47f16b4b$0$904$,
Wykaaa wrote:In article , wykaaa
wrote:Très intéressant mais comme le fait remarquer zeavan dans le forum, cela
reflète plus le monde académique.
Je remarque une forte poussée de Ruby, qui est un bien meilleur langage
que Python , dans le même genre de famille de langage
Bien meilleur ? en quoi ? pour l'instant, l'implementation se traine
un peu, etant purement interpretee et sans byte-code... ce qui la plombe un
peu par rapport aux voisins.
Je ne parlais pas de l'implémentation mais du langage lui-même.
Ruby utilise une syntaxe simple, inspirée par Eiffel et Ada (ce qui est
forcément un plus, ces deux langages étant reconnus pour leur "propreté
syntaxique").
Il est "pur objet", un peu à la SmallTalk (même les types sont des
objets). Un langage "pur objet" est toujours un plus dans l'approche objet.
Et immense avantage, il a les threads indépendants du système
d'exploitation (on ne peut se passer du multi-threading aujourd'hui...)
Ce dernier trait a effectivement une contrepartie : une certaine lenteur.
Il suffira de faire pour Ruby ce qui a été fait pour Java (des JIT :
Just in Time Compilers) et la question sera réglée.
Permet-moi d'etre sceptique, sur plusieurs points.
- la syntaxe de ruby n'est pas si simple, il a quand meme repique un
grand nombre d'idiosyncrasies de perl.
Je te l'accorde.
- l'approche `tout objet', ca fait surtout plaisir aux gens qui comparent
les langages pour le plaisir. Si ca n'etait pas le cas, on programmerait
tous en Smalltalk (mais la vraie approche objet n'est pas evidente pour
des gens qui ont ete eduques avec du procedural, soit l'immense majorite
des programmeurs professionnels... meme ceux qui font aujourd'hui du
java)
- threads independants du systeme: ca c'est juste une question de
bibliotheque. Rien qui n'empeche les autres langages de s'y mettre.
Et d'ailleurs on y vient.
- performance `il suffit de'... encore faut-il que quelqu'un la fasse, cette
implementation rapide... ca n'est pas si simple que ca, surtout sur un
langage tres dynamique. Il faut des programmeurs competents et qui y passent
du temps, ce qui demande pas mal de sous. Sauf interet d'un gros
industriel, j'y crois vraiment peu...
In article <47f16b4b$0$904$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
In article <op.t8wd2csm54jsyq@lemacpro.local>, wykaaa
<wykaaa@yahoo.fr> wrote:
Très intéressant mais comme le fait remarquer zeavan dans le forum, cela
reflète plus le monde académique.
Je remarque une forte poussée de Ruby, qui est un bien meilleur langage
que Python , dans le même genre de famille de langage
Bien meilleur ? en quoi ? pour l'instant, l'implementation se traine
un peu, etant purement interpretee et sans byte-code... ce qui la plombe un
peu par rapport aux voisins.
Je ne parlais pas de l'implémentation mais du langage lui-même.
Ruby utilise une syntaxe simple, inspirée par Eiffel et Ada (ce qui est
forcément un plus, ces deux langages étant reconnus pour leur "propreté
syntaxique").
Il est "pur objet", un peu à la SmallTalk (même les types sont des
objets). Un langage "pur objet" est toujours un plus dans l'approche objet.
Et immense avantage, il a les threads indépendants du système
d'exploitation (on ne peut se passer du multi-threading aujourd'hui...)
Ce dernier trait a effectivement une contrepartie : une certaine lenteur.
Il suffira de faire pour Ruby ce qui a été fait pour Java (des JIT :
Just in Time Compilers) et la question sera réglée.
Permet-moi d'etre sceptique, sur plusieurs points.
- la syntaxe de ruby n'est pas si simple, il a quand meme repique un
grand nombre d'idiosyncrasies de perl.
Je te l'accorde.
- l'approche `tout objet', ca fait surtout plaisir aux gens qui comparent
les langages pour le plaisir. Si ca n'etait pas le cas, on programmerait
tous en Smalltalk (mais la vraie approche objet n'est pas evidente pour
des gens qui ont ete eduques avec du procedural, soit l'immense majorite
des programmeurs professionnels... meme ceux qui font aujourd'hui du
java)
- threads independants du systeme: ca c'est juste une question de
bibliotheque. Rien qui n'empeche les autres langages de s'y mettre.
Et d'ailleurs on y vient.
- performance `il suffit de'... encore faut-il que quelqu'un la fasse, cette
implementation rapide... ca n'est pas si simple que ca, surtout sur un
langage tres dynamique. Il faut des programmeurs competents et qui y passent
du temps, ce qui demande pas mal de sous. Sauf interet d'un gros
industriel, j'y crois vraiment peu...
In article <47f16b4b$0$904$,
Wykaaa wrote:In article , wykaaa
wrote:Très intéressant mais comme le fait remarquer zeavan dans le forum, cela
reflète plus le monde académique.
Je remarque une forte poussée de Ruby, qui est un bien meilleur langage
que Python , dans le même genre de famille de langage
Bien meilleur ? en quoi ? pour l'instant, l'implementation se traine
un peu, etant purement interpretee et sans byte-code... ce qui la plombe un
peu par rapport aux voisins.
Je ne parlais pas de l'implémentation mais du langage lui-même.
Ruby utilise une syntaxe simple, inspirée par Eiffel et Ada (ce qui est
forcément un plus, ces deux langages étant reconnus pour leur "propreté
syntaxique").
Il est "pur objet", un peu à la SmallTalk (même les types sont des
objets). Un langage "pur objet" est toujours un plus dans l'approche objet.
Et immense avantage, il a les threads indépendants du système
d'exploitation (on ne peut se passer du multi-threading aujourd'hui...)
Ce dernier trait a effectivement une contrepartie : une certaine lenteur.
Il suffira de faire pour Ruby ce qui a été fait pour Java (des JIT :
Just in Time Compilers) et la question sera réglée.
Permet-moi d'etre sceptique, sur plusieurs points.
- la syntaxe de ruby n'est pas si simple, il a quand meme repique un
grand nombre d'idiosyncrasies de perl.
Je te l'accorde.
- l'approche `tout objet', ca fait surtout plaisir aux gens qui comparent
les langages pour le plaisir. Si ca n'etait pas le cas, on programmerait
tous en Smalltalk (mais la vraie approche objet n'est pas evidente pour
des gens qui ont ete eduques avec du procedural, soit l'immense majorite
des programmeurs professionnels... meme ceux qui font aujourd'hui du
java)
- threads independants du systeme: ca c'est juste une question de
bibliotheque. Rien qui n'empeche les autres langages de s'y mettre.
Et d'ailleurs on y vient.
- performance `il suffit de'... encore faut-il que quelqu'un la fasse, cette
implementation rapide... ca n'est pas si simple que ca, surtout sur un
langage tres dynamique. Il faut des programmeurs competents et qui y passent
du temps, ce qui demande pas mal de sous. Sauf interet d'un gros
industriel, j'y crois vraiment peu...
- l'approche `tout objet', ca fait surtout plaisir aux gens qui comparent
les langages pour le plaisir. Si ca n'etait pas le cas, on programmerait
tous en Smalltalk (mais la vraie approche objet n'est pas evidente pour
des gens qui ont ete eduques avec du procedural, soit l'immense majorite
des programmeurs professionnels... meme ceux qui font aujourd'hui du
java)
C'est curieux comme cet argument ressort toujours quand on parle d'une
approche "pur objet".
Moi-même j'ai appris, à l'université, à programmer procédural (premier
langage Algol 60...). je me suis mis à la conception objet dès les
premiers articles de Grady Booch dans l'ACM (en 83 donc). Puis j'ai
appris C++ (en 89) et j'ai ensuite programmé et donné de nombreux cours
(en entreprise pour des programmeurs C) de C++. Puis j'ai appris Java et
j'ai également donné des cours à partir de 97.
Aujourd'hui, les professionnels de l'informatique qui ne maîtrisent pas
encore l'objet n'ont aucune excuse !
- l'approche `tout objet', ca fait surtout plaisir aux gens qui comparent
les langages pour le plaisir. Si ca n'etait pas le cas, on programmerait
tous en Smalltalk (mais la vraie approche objet n'est pas evidente pour
des gens qui ont ete eduques avec du procedural, soit l'immense majorite
des programmeurs professionnels... meme ceux qui font aujourd'hui du
java)
C'est curieux comme cet argument ressort toujours quand on parle d'une
approche "pur objet".
Moi-même j'ai appris, à l'université, à programmer procédural (premier
langage Algol 60...). je me suis mis à la conception objet dès les
premiers articles de Grady Booch dans l'ACM (en 83 donc). Puis j'ai
appris C++ (en 89) et j'ai ensuite programmé et donné de nombreux cours
(en entreprise pour des programmeurs C) de C++. Puis j'ai appris Java et
j'ai également donné des cours à partir de 97.
Aujourd'hui, les professionnels de l'informatique qui ne maîtrisent pas
encore l'objet n'ont aucune excuse !
- l'approche `tout objet', ca fait surtout plaisir aux gens qui comparent
les langages pour le plaisir. Si ca n'etait pas le cas, on programmerait
tous en Smalltalk (mais la vraie approche objet n'est pas evidente pour
des gens qui ont ete eduques avec du procedural, soit l'immense majorite
des programmeurs professionnels... meme ceux qui font aujourd'hui du
java)
C'est curieux comme cet argument ressort toujours quand on parle d'une
approche "pur objet".
Moi-même j'ai appris, à l'université, à programmer procédural (premier
langage Algol 60...). je me suis mis à la conception objet dès les
premiers articles de Grady Booch dans l'ACM (en 83 donc). Puis j'ai
appris C++ (en 89) et j'ai ensuite programmé et donné de nombreux cours
(en entreprise pour des programmeurs C) de C++. Puis j'ai appris Java et
j'ai également donné des cours à partir de 97.
Aujourd'hui, les professionnels de l'informatique qui ne maîtrisent pas
encore l'objet n'ont aucune excuse !
In article <47f1e89c$0$850$,
Wykaaa wrote:- l'approche `tout objet', ca fait surtout plaisir aux gens qui comparent
les langages pour le plaisir. Si ca n'etait pas le cas, on programmerait
tous en Smalltalk (mais la vraie approche objet n'est pas evidente pour
des gens qui ont ete eduques avec du procedural, soit l'immense majorite
des programmeurs professionnels... meme ceux qui font aujourd'hui du
java)
C'est curieux comme cet argument ressort toujours quand on parle d'une
approche "pur objet".
Moi-même j'ai appris, à l'université, à programmer procédural (premier
langage Algol 60...). je me suis mis à la conception objet dès les
premiers articles de Grady Booch dans l'ACM (en 83 donc). Puis j'ai
appris C++ (en 89) et j'ai ensuite programmé et donné de nombreux cours
(en entreprise pour des programmeurs C) de C++. Puis j'ai appris Java et
j'ai également donné des cours à partir de 97.
Aujourd'hui, les professionnels de l'informatique qui ne maîtrisent pas
encore l'objet n'ont aucune excuse !
J'ai vu suffisamment de code C++ ou Java qui n'etait pas reellement objet,
et qui se presentait tel juste a cause du langage... ou du code construit
avec des classes enormes et des hierarchies mal foutues...
Plonger le nez dans une belle implementation smalltalk, comme squeak, fait
enormement de bien la-dessus.
A mon avis, ca n'est pas du tout evident de faire un vrai design qui donne
les benefices de l'approche objet (encapsulation, abstraction, evolutivite,
et souplesse), et j'en rencontre bien peu...
In article <47f1e89c$0$850$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
- l'approche `tout objet', ca fait surtout plaisir aux gens qui comparent
les langages pour le plaisir. Si ca n'etait pas le cas, on programmerait
tous en Smalltalk (mais la vraie approche objet n'est pas evidente pour
des gens qui ont ete eduques avec du procedural, soit l'immense majorite
des programmeurs professionnels... meme ceux qui font aujourd'hui du
java)
C'est curieux comme cet argument ressort toujours quand on parle d'une
approche "pur objet".
Moi-même j'ai appris, à l'université, à programmer procédural (premier
langage Algol 60...). je me suis mis à la conception objet dès les
premiers articles de Grady Booch dans l'ACM (en 83 donc). Puis j'ai
appris C++ (en 89) et j'ai ensuite programmé et donné de nombreux cours
(en entreprise pour des programmeurs C) de C++. Puis j'ai appris Java et
j'ai également donné des cours à partir de 97.
Aujourd'hui, les professionnels de l'informatique qui ne maîtrisent pas
encore l'objet n'ont aucune excuse !
J'ai vu suffisamment de code C++ ou Java qui n'etait pas reellement objet,
et qui se presentait tel juste a cause du langage... ou du code construit
avec des classes enormes et des hierarchies mal foutues...
Plonger le nez dans une belle implementation smalltalk, comme squeak, fait
enormement de bien la-dessus.
A mon avis, ca n'est pas du tout evident de faire un vrai design qui donne
les benefices de l'approche objet (encapsulation, abstraction, evolutivite,
et souplesse), et j'en rencontre bien peu...
In article <47f1e89c$0$850$,
Wykaaa wrote:- l'approche `tout objet', ca fait surtout plaisir aux gens qui comparent
les langages pour le plaisir. Si ca n'etait pas le cas, on programmerait
tous en Smalltalk (mais la vraie approche objet n'est pas evidente pour
des gens qui ont ete eduques avec du procedural, soit l'immense majorite
des programmeurs professionnels... meme ceux qui font aujourd'hui du
java)
C'est curieux comme cet argument ressort toujours quand on parle d'une
approche "pur objet".
Moi-même j'ai appris, à l'université, à programmer procédural (premier
langage Algol 60...). je me suis mis à la conception objet dès les
premiers articles de Grady Booch dans l'ACM (en 83 donc). Puis j'ai
appris C++ (en 89) et j'ai ensuite programmé et donné de nombreux cours
(en entreprise pour des programmeurs C) de C++. Puis j'ai appris Java et
j'ai également donné des cours à partir de 97.
Aujourd'hui, les professionnels de l'informatique qui ne maîtrisent pas
encore l'objet n'ont aucune excuse !
J'ai vu suffisamment de code C++ ou Java qui n'etait pas reellement objet,
et qui se presentait tel juste a cause du langage... ou du code construit
avec des classes enormes et des hierarchies mal foutues...
Plonger le nez dans une belle implementation smalltalk, comme squeak, fait
enormement de bien la-dessus.
A mon avis, ca n'est pas du tout evident de faire un vrai design qui donne
les benefices de l'approche objet (encapsulation, abstraction, evolutivite,
et souplesse), et j'en rencontre bien peu...
Le Mon, 31 Mar 2008 15:18:28 +0200, Marc Espie a écrit:In article , wykaaa
wrote:Comment comparer Java et Python ????
Java est utilisé dans des applications importantes qui requièrent
fiabilité, évolutivité, etc. (comme les applications militaires).
Où est Python dans l'industrie ??? NULLE PART
Python est bien un langage marginal.
Enleve tes oeilleres, ca te fera du bien...
Et puisque tu cites quelques langages du même ordre, sache que ruby a
toutes mes faveurs dans cette famille de langages.
J'ai audité des millions de lignes de code (à l'aide de Logiscope). Ce
que je peux dire c'est que, même dans les domaines les plus pointus et
qui requièrent une grande fiabilité et sûreté de fonctionnement comme le
nucléaire, l'avionique ou le spatial, il n'y a pas 10% de programmeurs
qui programment "proprement. Ce n'est pas avec des langages comme Python
qu'ils vons le faire...
Mais je suis d'accord que pour des non informaticiens scientifiques qui
doivent faire des petites simulations ou des petits modèles, ce genre de
langage peut rendre des services mais alors il ne faut pas parler
d'informatique au sens industriel du terme (quand je dis industriel, je
rapproche la fabrication de logiciels à la fabrication d'automobiles ou
d'avions).
Le Mon, 31 Mar 2008 15:18:28 +0200, Marc Espie <espie@lain.home> a écrit:
In article <op.t8vs8oia54jsyq@lemacpro.local>, wykaaa
<wykaaa@yahoo.fr> wrote:
Comment comparer Java et Python ????
Java est utilisé dans des applications importantes qui requièrent
fiabilité, évolutivité, etc. (comme les applications militaires).
Où est Python dans l'industrie ??? NULLE PART
Python est bien un langage marginal.
Enleve tes oeilleres, ca te fera du bien...
Et puisque tu cites quelques langages du même ordre, sache que ruby a
toutes mes faveurs dans cette famille de langages.
J'ai audité des millions de lignes de code (à l'aide de Logiscope). Ce
que je peux dire c'est que, même dans les domaines les plus pointus et
qui requièrent une grande fiabilité et sûreté de fonctionnement comme le
nucléaire, l'avionique ou le spatial, il n'y a pas 10% de programmeurs
qui programment "proprement. Ce n'est pas avec des langages comme Python
qu'ils vons le faire...
Mais je suis d'accord que pour des non informaticiens scientifiques qui
doivent faire des petites simulations ou des petits modèles, ce genre de
langage peut rendre des services mais alors il ne faut pas parler
d'informatique au sens industriel du terme (quand je dis industriel, je
rapproche la fabrication de logiciels à la fabrication d'automobiles ou
d'avions).
Le Mon, 31 Mar 2008 15:18:28 +0200, Marc Espie a écrit:In article , wykaaa
wrote:Comment comparer Java et Python ????
Java est utilisé dans des applications importantes qui requièrent
fiabilité, évolutivité, etc. (comme les applications militaires).
Où est Python dans l'industrie ??? NULLE PART
Python est bien un langage marginal.
Enleve tes oeilleres, ca te fera du bien...
Et puisque tu cites quelques langages du même ordre, sache que ruby a
toutes mes faveurs dans cette famille de langages.
J'ai audité des millions de lignes de code (à l'aide de Logiscope). Ce
que je peux dire c'est que, même dans les domaines les plus pointus et
qui requièrent une grande fiabilité et sûreté de fonctionnement comme le
nucléaire, l'avionique ou le spatial, il n'y a pas 10% de programmeurs
qui programment "proprement. Ce n'est pas avec des langages comme Python
qu'ils vons le faire...
Mais je suis d'accord que pour des non informaticiens scientifiques qui
doivent faire des petites simulations ou des petits modèles, ce genre de
langage peut rendre des services mais alors il ne faut pas parler
d'informatique au sens industriel du terme (quand je dis industriel, je
rapproche la fabrication de logiciels à la fabrication d'automobiles ou
d'avions).
Donc, ce que je proposerai, c'est un repas complet ;)
Donc, ce que je proposerai, c'est un repas complet ;)
Donc, ce que je proposerai, c'est un repas complet ;)
