Bon, les gars, vous qui êtes linuxiens comme moi, est-il normal que je
n'arrive pas à dénicher de linuxien compétent depuis presque 6 mois ? Je
ne sais pas, il me semble que c'est la crise, tout ça, et qu'il devrait y
avoir des gens qui cherchent du boulot. Au lieu de quoi, je ne reçois que
des CV de "Java drones" (pour les développeurs) et "certification
MCSE" (pour les administrateurs). Comment se fait-ce?
Il y a deux/trois ans j'ai l'impression qu'il y avait plein monde et là,
pfuit....
--
The fact that a believer is happier than a sceptic is no more to the
point than the fact that a drunken man is happier than a sober one.
The happiness of credulity is a cheap and dangerous quality.
George Bernard Shaw
Le 20-10-2009, ? propos de Re: De la difficulté à trouver des linuxiens professionnels, Richard Delorme ?crivait dans fr.comp.os.linux.debats :
Le 20/10/2009 13:59, JKB a écrit :
L'intérêt des langages interprétés est qu'ils sont rapides à écrire, c'est tout.
Une fois qu'on a viré les interprètes historiques (principalement Basic, mais j'ai déjà vu un interprète C...), on arrive à trouver des trucs sérieux. Ces langages sont intéressants et leurs caractéristiques sont différentes de celles des langages compilés.
En particulier, on peut faire des choses amusantes lors de l'exécution des fonctions (modification des routines). On peut évaluer des fonctions entrées par l'utilisateur si l'interprète n'est pas mauvais. Essaye de modifier lors de l'exécution un bout de fonction dans un code compilé, c'est assez casse-gueule. Essaye d'exécuter des fonctions entrées par l'utilisateur avec un langage compilé comme le C.
Merci de m'expliquer pourquoi il est plus rapide d'écrire pour un langage interprété que pour un langage compilé. Il y a une quinzaine d'année, j'utilisais un programme d'analyse d'images (pas Photoshop, un programme beaucoup plus cher qui tournait sur une station SGI), qui permettait l'ajout de fonctions de deux façons : - à l'aide d'un interpréteur C (en fait une sous partie du langage). L'éditeur était intégré au logiciel et l'ajout d'une fonctionnalité était souvent simplisme (avec enregistrement des click et tout ça). - en recompilant l'application avec, outre les bibliothèques de l'application, des fichiers C (K&R) écrits par mes soins qui ajoutaient de nouvelles fonctions au logiciel (accessible via le menu du logiciel et tout ça). Cette technique était bien sûr beaucoup plus fastidieuse et plus longue. Par contre à l'exécution c'était beaucoup plus rapide. Donc, oui, un utilisateur peut ajouter des fonctions à un programme via un compilateur tout comme on peut le faire par un interpréteur ; je l'ai fait quotidiennement pendant plusieurs années. La différence ? ça se code plus vite via un interpréteur, ça s'exécute plus vite via le compilateur.
-- Richard
Le 20/10/2009 16:59, JKB a écrit :
Le 20-10-2009, ? propos de
Re: De la difficulté à trouver des linuxiens professionnels,
Richard Delorme ?crivait dans fr.comp.os.linux.debats :
Le 20/10/2009 13:59, JKB a écrit :
L'intérêt des langages interprétés est qu'ils sont rapides à écrire,
c'est tout.
Une fois qu'on a viré les interprètes historiques (principalement
Basic, mais j'ai déjà vu un interprète C...), on arrive à trouver
des trucs sérieux. Ces langages sont intéressants et leurs
caractéristiques sont différentes de celles des langages compilés.
En particulier, on peut faire des choses amusantes lors de
l'exécution des fonctions (modification des routines). On peut
évaluer des fonctions entrées par l'utilisateur si l'interprète
n'est pas mauvais. Essaye de modifier lors de
l'exécution un bout de fonction dans un code compilé, c'est assez
casse-gueule. Essaye d'exécuter des fonctions entrées par
l'utilisateur avec un langage compilé comme le C.
Merci de m'expliquer pourquoi il est plus rapide d'écrire pour un
langage interprété que pour un langage compilé.
Il y a une quinzaine d'année, j'utilisais un programme d'analyse
d'images (pas Photoshop, un programme beaucoup plus cher qui tournait
sur une station SGI), qui permettait l'ajout de fonctions de deux façons :
- à l'aide d'un interpréteur C (en fait une sous partie du langage).
L'éditeur était intégré au logiciel et l'ajout d'une fonctionnalité
était souvent simplisme (avec enregistrement des click et tout ça).
- en recompilant l'application avec, outre les bibliothèques de
l'application, des fichiers C (K&R) écrits par mes soins qui ajoutaient
de nouvelles fonctions au logiciel (accessible via le menu du logiciel
et tout ça). Cette technique était bien sûr beaucoup plus fastidieuse et
plus longue. Par contre à l'exécution c'était beaucoup plus rapide.
Donc, oui, un utilisateur peut ajouter des fonctions à un programme via
un compilateur tout comme on peut le faire par un interpréteur ; je l'ai
fait quotidiennement pendant plusieurs années. La différence ? ça se
code plus vite via un interpréteur, ça s'exécute plus vite via le
compilateur.
Le 20-10-2009, ? propos de Re: De la difficulté à trouver des linuxiens professionnels, Richard Delorme ?crivait dans fr.comp.os.linux.debats :
Le 20/10/2009 13:59, JKB a écrit :
L'intérêt des langages interprétés est qu'ils sont rapides à écrire, c'est tout.
Une fois qu'on a viré les interprètes historiques (principalement Basic, mais j'ai déjà vu un interprète C...), on arrive à trouver des trucs sérieux. Ces langages sont intéressants et leurs caractéristiques sont différentes de celles des langages compilés.
En particulier, on peut faire des choses amusantes lors de l'exécution des fonctions (modification des routines). On peut évaluer des fonctions entrées par l'utilisateur si l'interprète n'est pas mauvais. Essaye de modifier lors de l'exécution un bout de fonction dans un code compilé, c'est assez casse-gueule. Essaye d'exécuter des fonctions entrées par l'utilisateur avec un langage compilé comme le C.
Merci de m'expliquer pourquoi il est plus rapide d'écrire pour un langage interprété que pour un langage compilé. Il y a une quinzaine d'année, j'utilisais un programme d'analyse d'images (pas Photoshop, un programme beaucoup plus cher qui tournait sur une station SGI), qui permettait l'ajout de fonctions de deux façons : - à l'aide d'un interpréteur C (en fait une sous partie du langage). L'éditeur était intégré au logiciel et l'ajout d'une fonctionnalité était souvent simplisme (avec enregistrement des click et tout ça). - en recompilant l'application avec, outre les bibliothèques de l'application, des fichiers C (K&R) écrits par mes soins qui ajoutaient de nouvelles fonctions au logiciel (accessible via le menu du logiciel et tout ça). Cette technique était bien sûr beaucoup plus fastidieuse et plus longue. Par contre à l'exécution c'était beaucoup plus rapide. Donc, oui, un utilisateur peut ajouter des fonctions à un programme via un compilateur tout comme on peut le faire par un interpréteur ; je l'ai fait quotidiennement pendant plusieurs années. La différence ? ça se code plus vite via un interpréteur, ça s'exécute plus vite via le compilateur.
-- Richard
Richard Delorme
Le 20/10/2009 17:04, Nicolas George a écrit :
Richard Delorme , dans le message <4adda2be$0$965$, a écrit :
L'intérêt des langages interprétés est qu'ils sont rapides à écrire, c'est tout.
On peut compiler du python et interpréter du C.
Pour avoir utiliser les deux, je confirme que le C interprété est plus à écrire/exécuter rapide que le python compilé et maintien mon affirmation.
-- Richard
Le 20/10/2009 17:04, Nicolas George a écrit :
Richard Delorme , dans le message
<4adda2be$0$965$ba4acef3@news.orange.fr>, a écrit :
L'intérêt des langages interprétés est qu'ils sont rapides à écrire,
c'est tout.
On peut compiler du python et interpréter du C.
Pour avoir utiliser les deux, je confirme que le C interprété est plus à
écrire/exécuter rapide que le python compilé et maintien mon affirmation.
Richard Delorme , dans le message <4adda2be$0$965$, a écrit :
L'intérêt des langages interprétés est qu'ils sont rapides à écrire, c'est tout.
On peut compiler du python et interpréter du C.
Pour avoir utiliser les deux, je confirme que le C interprété est plus à écrire/exécuter rapide que le python compilé et maintien mon affirmation.
-- Richard
Nicolas George
Richard Delorme , dans le message <4addeaf5$0$940$, a écrit :
Pour avoir utiliser les deux, je confirme que le C interprété est plus à écrire/exécuter rapide que le python compilé et maintien mon affirmation.
Ta phrase ne veut rien dire. On devine qu'il faut faire une permutation des mots, mais selon celle qu'on choisit, on peut obtenir tout ou son contraire.
Quant à moi, j'affirme que la distinction entre langage compilé et langage interprété est dénuée d'intérêt, et même de fondement.
La distinction pertinente, c'est entre langage de haut niveau et langage de bas niveau.
Et ton exemple de logiciel de traitement d'image, c'est juste un exemple de programmation médiocre : il serait trivial d'appeler le compilateur en sous-main pour produire une bibliothèque partagée, et obtenir directement l'apparence d'un code interprété (édition et exécution en direct) mais l'efficacité d'un code compilé.
Richard Delorme , dans le message
<4addeaf5$0$940$ba4acef3@news.orange.fr>, a écrit :
Pour avoir utiliser les deux, je confirme que le C interprété est plus à
écrire/exécuter rapide que le python compilé et maintien mon affirmation.
Ta phrase ne veut rien dire. On devine qu'il faut faire une permutation des
mots, mais selon celle qu'on choisit, on peut obtenir tout ou son contraire.
Quant à moi, j'affirme que la distinction entre langage compilé et langage
interprété est dénuée d'intérêt, et même de fondement.
La distinction pertinente, c'est entre langage de haut niveau et langage de
bas niveau.
Et ton exemple de logiciel de traitement d'image, c'est juste un exemple de
programmation médiocre : il serait trivial d'appeler le compilateur en
sous-main pour produire une bibliothèque partagée, et obtenir directement
l'apparence d'un code interprété (édition et exécution en direct) mais
l'efficacité d'un code compilé.
Richard Delorme , dans le message <4addeaf5$0$940$, a écrit :
Pour avoir utiliser les deux, je confirme que le C interprété est plus à écrire/exécuter rapide que le python compilé et maintien mon affirmation.
Ta phrase ne veut rien dire. On devine qu'il faut faire une permutation des mots, mais selon celle qu'on choisit, on peut obtenir tout ou son contraire.
Quant à moi, j'affirme que la distinction entre langage compilé et langage interprété est dénuée d'intérêt, et même de fondement.
La distinction pertinente, c'est entre langage de haut niveau et langage de bas niveau.
Et ton exemple de logiciel de traitement d'image, c'est juste un exemple de programmation médiocre : il serait trivial d'appeler le compilateur en sous-main pour produire une bibliothèque partagée, et obtenir directement l'apparence d'un code interprété (édition et exécution en direct) mais l'efficacité d'un code compilé.
Richard Delorme
Le 20/10/2009 18:59, Nicolas George a écrit :
Richard Delorme , dans le message <4addeaf5$0$940$, a écrit :
Pour avoir utiliser les deux, je confirme que le C interprété est plus à écrire/exécuter rapide que le python compilé et maintien mon affirmation.
Ta phrase ne veut rien dire.
Désolé j'ai écrit et modifier des bouts trop vite.
On devine qu'il faut faire une permutation des mots, mais selon celle qu'on choisit, on peut obtenir tout ou son contraire.
Il fallait lire: « Pour avoir utiliser les deux, je confirme que le C interprété est plus rapide à écrire/exécuter que le python compilé et je maintiens mon affirmation.»
Quant à moi, j'affirme que la distinction entre langage compilé et langage interprété est dénuée d'intérêt, et même de fondement.
La distinction pertinente, c'est entre langage de haut niveau et langage de bas niveau.
Bof. On peut écrire du haut niveau en C et du bas niveau en python.
Et ton exemple de logiciel de traitement d'image, c'est juste un exemple de programmation médiocre : il serait trivial d'appeler le compilateur en sous-main pour produire une bibliothèque partagée, et obtenir directement l'apparence d'un code interprété (édition et exécution en direct) mais l'efficacité d'un code compilé.
Connaissant le temps de compilation de l'époque, ce n'était certainement pas une technique réaliste.
-- Richard
Le 20/10/2009 18:59, Nicolas George a écrit :
Richard Delorme , dans le message
<4addeaf5$0$940$ba4acef3@news.orange.fr>, a écrit :
Pour avoir utiliser les deux, je confirme que le C interprété est plus à
écrire/exécuter rapide que le python compilé et maintien mon affirmation.
Ta phrase ne veut rien dire.
Désolé j'ai écrit et modifier des bouts trop vite.
On devine qu'il faut faire une permutation des
mots, mais selon celle qu'on choisit, on peut obtenir tout ou son contraire.
Il fallait lire: « Pour avoir utiliser les deux, je confirme que le C
interprété est plus rapide à écrire/exécuter que le python compilé et je
maintiens mon affirmation.»
Quant à moi, j'affirme que la distinction entre langage compilé et langage
interprété est dénuée d'intérêt, et même de fondement.
La distinction pertinente, c'est entre langage de haut niveau et langage de
bas niveau.
Bof. On peut écrire du haut niveau en C et du bas niveau en python.
Et ton exemple de logiciel de traitement d'image, c'est juste un exemple de
programmation médiocre : il serait trivial d'appeler le compilateur en
sous-main pour produire une bibliothèque partagée, et obtenir directement
l'apparence d'un code interprété (édition et exécution en direct) mais
l'efficacité d'un code compilé.
Connaissant le temps de compilation de l'époque, ce n'était certainement
pas une technique réaliste.
Richard Delorme , dans le message <4addeaf5$0$940$, a écrit :
Pour avoir utiliser les deux, je confirme que le C interprété est plus à écrire/exécuter rapide que le python compilé et maintien mon affirmation.
Ta phrase ne veut rien dire.
Désolé j'ai écrit et modifier des bouts trop vite.
On devine qu'il faut faire une permutation des mots, mais selon celle qu'on choisit, on peut obtenir tout ou son contraire.
Il fallait lire: « Pour avoir utiliser les deux, je confirme que le C interprété est plus rapide à écrire/exécuter que le python compilé et je maintiens mon affirmation.»
Quant à moi, j'affirme que la distinction entre langage compilé et langage interprété est dénuée d'intérêt, et même de fondement.
La distinction pertinente, c'est entre langage de haut niveau et langage de bas niveau.
Bof. On peut écrire du haut niveau en C et du bas niveau en python.
Et ton exemple de logiciel de traitement d'image, c'est juste un exemple de programmation médiocre : il serait trivial d'appeler le compilateur en sous-main pour produire une bibliothèque partagée, et obtenir directement l'apparence d'un code interprété (édition et exécution en direct) mais l'efficacité d'un code compilé.
Connaissant le temps de compilation de l'époque, ce n'était certainement pas une technique réaliste.
-- Richard
Nicolas George
Richard Delorme , dans le message <4addf0b0$0$903$, a écrit :
Bof. On peut écrire du haut niveau en C et du bas niveau en python.
Non, il faut toujours gérer la mémoire en C, et jamais en python, par exemple.
Connaissant le temps de compilation de l'époque, ce n'était certainement pas une technique réaliste.
C'est que c'est un trop gros bout qui est compilé d'un coup.
Richard Delorme , dans le message
<4addf0b0$0$903$ba4acef3@news.orange.fr>, a écrit :
Bof. On peut écrire du haut niveau en C et du bas niveau en python.
Non, il faut toujours gérer la mémoire en C, et jamais en python, par
exemple.
Connaissant le temps de compilation de l'époque, ce n'était certainement
pas une technique réaliste.
C'est que c'est un trop gros bout qui est compilé d'un coup.
Richard Delorme , dans le message <4addf0b0$0$903$, a écrit :
Bof. On peut écrire du haut niveau en C et du bas niveau en python.
Non, il faut toujours gérer la mémoire en C, et jamais en python, par exemple.
Connaissant le temps de compilation de l'époque, ce n'était certainement pas une technique réaliste.
C'est que c'est un trop gros bout qui est compilé d'un coup.
Richard Delorme
Le 20/10/2009 19:58, Nicolas George a écrit :
Richard Delorme , dans le message <4addf0b0$0$903$, a écrit :
Bof. On peut écrire du haut niveau en C et du bas niveau en python.
Non, il faut toujours gérer la mémoire en C,
Non, on peut écrire un "hello world" sans gérer la mémoire, ou même des programmes significativement plus important, qui utilisent des types abstrait gérant eux-mêmes la mémoire.
et jamais en python, par exemple.
A quoi sert la méthode __del__() alors ? Et le collect() du garbage collector ?
Connaissant le temps de compilation de l'époque, ce n'était certainement pas une technique réaliste.
C'est que c'est un trop gros bout qui est compilé d'un coup.
Il suffit parfois de quelques en-têtes (inutiles dans un interpréteur C mais indispensable pour un programme compilé) pour créer un gros bout de code.
-- Richard
Le 20/10/2009 19:58, Nicolas George a écrit :
Richard Delorme , dans le message
<4addf0b0$0$903$ba4acef3@news.orange.fr>, a écrit :
Bof. On peut écrire du haut niveau en C et du bas niveau en python.
Non, il faut toujours gérer la mémoire en C,
Non, on peut écrire un "hello world" sans gérer la mémoire, ou même des
programmes significativement plus important, qui utilisent des types
abstrait gérant eux-mêmes la mémoire.
et jamais en python, par exemple.
A quoi sert la méthode __del__() alors ? Et le collect() du garbage
collector ?
Connaissant le temps de compilation de l'époque, ce n'était certainement
pas une technique réaliste.
C'est que c'est un trop gros bout qui est compilé d'un coup.
Il suffit parfois de quelques en-têtes (inutiles dans un interpréteur C
mais indispensable pour un programme compilé) pour créer un gros bout de
code.
Richard Delorme , dans le message <4addf0b0$0$903$, a écrit :
Bof. On peut écrire du haut niveau en C et du bas niveau en python.
Non, il faut toujours gérer la mémoire en C,
Non, on peut écrire un "hello world" sans gérer la mémoire, ou même des programmes significativement plus important, qui utilisent des types abstrait gérant eux-mêmes la mémoire.
et jamais en python, par exemple.
A quoi sert la méthode __del__() alors ? Et le collect() du garbage collector ?
Connaissant le temps de compilation de l'époque, ce n'était certainement pas une technique réaliste.
C'est que c'est un trop gros bout qui est compilé d'un coup.
Il suffit parfois de quelques en-têtes (inutiles dans un interpréteur C mais indispensable pour un programme compilé) pour créer un gros bout de code.
-- Richard
JKB
Le 20-10-2009, ? propos de Re: De la difficulté à trouver des linuxiens professionnels, Richard Delorme ?crivait dans fr.comp.os.linux.debats :
Le 20/10/2009 16:59, JKB a écrit :
Le 20-10-2009, ? propos de Re: De la difficulté à trouver des linuxiens professionnels, Richard Delorme ?crivait dans fr.comp.os.linux.debats :
Le 20/10/2009 13:59, JKB a écrit :
L'intérêt des langages interprétés est qu'ils sont rapides à écrire, c'est tout.
Une fois qu'on a viré les interprètes historiques (principalement Basic, mais j'ai déjà vu un interprète C...), on arrive à trouver des trucs sérieux. Ces langages sont intéressants et leurs caractéristiques sont différentes de celles des langages compilés.
En particulier, on peut faire des choses amusantes lors de l'exécution des fonctions (modification des routines). On peut évaluer des fonctions entrées par l'utilisateur si l'interprète n'est pas mauvais. Essaye de modifier lors de l'exécution un bout de fonction dans un code compilé, c'est assez casse-gueule. Essaye d'exécuter des fonctions entrées par l'utilisateur avec un langage compilé comme le C.
Merci de m'expliquer pourquoi il est plus rapide d'écrire pour un langage interprété que pour un langage compilé.
Je ne dis pas que c'est plus rapide. Il y a tout simplement des langages non compilables et qui ne sont pas inintéressants.
Il y a une quinzaine d'année, j'utilisais un programme d'analyse d'images (pas Photoshop, un programme beaucoup plus cher qui tournait sur une station SGI), qui permettait l'ajout de fonctions de deux façons : - à l'aide d'un interpréteur C (en fait une sous partie du langage). L'éditeur était intégré au logiciel et l'ajout d'une fonctionnalité était souvent simplisme (avec enregistrement des click et tout ça). - en recompilant l'application avec, outre les bibliothèques de l'application, des fichiers C (K&R) écrits par mes soins qui ajoutaient de nouvelles fonctions au logiciel (accessible via le menu du logiciel et tout ça). Cette technique était bien sûr beaucoup plus fastidieuse et plus longue. Par contre à l'exécution c'était beaucoup plus rapide. Donc, oui, un utilisateur peut ajouter des fonctions à un programme via un compilateur tout comme on peut le faire par un interpréteur ; je l'ai fait quotidiennement pendant plusieurs années. La différence ? ça se code plus vite via un interpréteur, ça s'exécute plus vite via le compilateur.
Je sais écrire un makefile et une compilation ne me pose aucun problème.
Note aussi que je ne parle pas de rajouter une fonction à un programme, mais de manipuler des fonctions voire de modifier les fonctions déjà existantes, c'est autre chose. Je le fais quotidiennement et je ne vois pas comment le faire avec un langage compilé. Avec un interprété ou un semi-compilé, c'est faisable. Avec un compilé, à moins de patcher à la volée le binaire, je ne vois pas.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 20-10-2009, ? propos de
Re: De la difficulté à trouver des linuxiens professionnels,
Richard Delorme ?crivait dans fr.comp.os.linux.debats :
Le 20/10/2009 16:59, JKB a écrit :
Le 20-10-2009, ? propos de
Re: De la difficulté à trouver des linuxiens professionnels,
Richard Delorme ?crivait dans fr.comp.os.linux.debats :
Le 20/10/2009 13:59, JKB a écrit :
L'intérêt des langages interprétés est qu'ils sont rapides à écrire,
c'est tout.
Une fois qu'on a viré les interprètes historiques (principalement
Basic, mais j'ai déjà vu un interprète C...), on arrive à trouver
des trucs sérieux. Ces langages sont intéressants et leurs
caractéristiques sont différentes de celles des langages compilés.
En particulier, on peut faire des choses amusantes lors de
l'exécution des fonctions (modification des routines). On peut
évaluer des fonctions entrées par l'utilisateur si l'interprète
n'est pas mauvais. Essaye de modifier lors de
l'exécution un bout de fonction dans un code compilé, c'est assez
casse-gueule. Essaye d'exécuter des fonctions entrées par
l'utilisateur avec un langage compilé comme le C.
Merci de m'expliquer pourquoi il est plus rapide d'écrire pour un
langage interprété que pour un langage compilé.
Je ne dis pas que c'est plus rapide. Il y a tout simplement des
langages non compilables et qui ne sont pas inintéressants.
Il y a une quinzaine d'année, j'utilisais un programme d'analyse
d'images (pas Photoshop, un programme beaucoup plus cher qui tournait
sur une station SGI), qui permettait l'ajout de fonctions de deux façons :
- à l'aide d'un interpréteur C (en fait une sous partie du langage).
L'éditeur était intégré au logiciel et l'ajout d'une fonctionnalité
était souvent simplisme (avec enregistrement des click et tout ça).
- en recompilant l'application avec, outre les bibliothèques de
l'application, des fichiers C (K&R) écrits par mes soins qui ajoutaient
de nouvelles fonctions au logiciel (accessible via le menu du logiciel
et tout ça). Cette technique était bien sûr beaucoup plus fastidieuse et
plus longue. Par contre à l'exécution c'était beaucoup plus rapide.
Donc, oui, un utilisateur peut ajouter des fonctions à un programme via
un compilateur tout comme on peut le faire par un interpréteur ; je l'ai
fait quotidiennement pendant plusieurs années. La différence ? ça se
code plus vite via un interpréteur, ça s'exécute plus vite via le
compilateur.
Je sais écrire un makefile et une compilation ne me pose aucun
problème.
Note aussi que je ne parle pas de rajouter une fonction à un
programme, mais de manipuler des fonctions voire de modifier les
fonctions déjà existantes, c'est autre chose. Je le fais
quotidiennement et je ne vois pas comment le faire avec un langage
compilé. Avec un interprété ou un semi-compilé, c'est faisable. Avec
un compilé, à moins de patcher à la volée le binaire, je ne vois
pas.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 20-10-2009, ? propos de Re: De la difficulté à trouver des linuxiens professionnels, Richard Delorme ?crivait dans fr.comp.os.linux.debats :
Le 20/10/2009 16:59, JKB a écrit :
Le 20-10-2009, ? propos de Re: De la difficulté à trouver des linuxiens professionnels, Richard Delorme ?crivait dans fr.comp.os.linux.debats :
Le 20/10/2009 13:59, JKB a écrit :
L'intérêt des langages interprétés est qu'ils sont rapides à écrire, c'est tout.
Une fois qu'on a viré les interprètes historiques (principalement Basic, mais j'ai déjà vu un interprète C...), on arrive à trouver des trucs sérieux. Ces langages sont intéressants et leurs caractéristiques sont différentes de celles des langages compilés.
En particulier, on peut faire des choses amusantes lors de l'exécution des fonctions (modification des routines). On peut évaluer des fonctions entrées par l'utilisateur si l'interprète n'est pas mauvais. Essaye de modifier lors de l'exécution un bout de fonction dans un code compilé, c'est assez casse-gueule. Essaye d'exécuter des fonctions entrées par l'utilisateur avec un langage compilé comme le C.
Merci de m'expliquer pourquoi il est plus rapide d'écrire pour un langage interprété que pour un langage compilé.
Je ne dis pas que c'est plus rapide. Il y a tout simplement des langages non compilables et qui ne sont pas inintéressants.
Il y a une quinzaine d'année, j'utilisais un programme d'analyse d'images (pas Photoshop, un programme beaucoup plus cher qui tournait sur une station SGI), qui permettait l'ajout de fonctions de deux façons : - à l'aide d'un interpréteur C (en fait une sous partie du langage). L'éditeur était intégré au logiciel et l'ajout d'une fonctionnalité était souvent simplisme (avec enregistrement des click et tout ça). - en recompilant l'application avec, outre les bibliothèques de l'application, des fichiers C (K&R) écrits par mes soins qui ajoutaient de nouvelles fonctions au logiciel (accessible via le menu du logiciel et tout ça). Cette technique était bien sûr beaucoup plus fastidieuse et plus longue. Par contre à l'exécution c'était beaucoup plus rapide. Donc, oui, un utilisateur peut ajouter des fonctions à un programme via un compilateur tout comme on peut le faire par un interpréteur ; je l'ai fait quotidiennement pendant plusieurs années. La différence ? ça se code plus vite via un interpréteur, ça s'exécute plus vite via le compilateur.
Je sais écrire un makefile et une compilation ne me pose aucun problème.
Note aussi que je ne parle pas de rajouter une fonction à un programme, mais de manipuler des fonctions voire de modifier les fonctions déjà existantes, c'est autre chose. Je le fais quotidiennement et je ne vois pas comment le faire avec un langage compilé. Avec un interprété ou un semi-compilé, c'est faisable. Avec un compilé, à moins de patcher à la volée le binaire, je ne vois pas.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Nicolas George
Richard Delorme , dans le message <4ade0278$0$972$, a écrit :
Non, on peut écrire un "hello world" sans gérer la mémoire,
C'est à peu près tout.
ou même des programmes significativement plus important, qui utilisent des types abstrait gérant eux-mêmes la mémoire.
Ça reste donc du bas niveau.
A quoi sert la méthode __del__() alors ? Et le collect() du garbage collector ?
À faire autre chose.
Richard Delorme , dans le message
<4ade0278$0$972$ba4acef3@news.orange.fr>, a écrit :
Non, on peut écrire un "hello world" sans gérer la mémoire,
C'est à peu près tout.
ou même des
programmes significativement plus important, qui utilisent des types
abstrait gérant eux-mêmes la mémoire.
Ça reste donc du bas niveau.
A quoi sert la méthode __del__() alors ? Et le collect() du garbage
collector ?
Richard Delorme , dans le message <4ade0278$0$972$, a écrit :
Non, on peut écrire un "hello world" sans gérer la mémoire,
C'est à peu près tout.
ou même des programmes significativement plus important, qui utilisent des types abstrait gérant eux-mêmes la mémoire.
Ça reste donc du bas niveau.
A quoi sert la méthode __del__() alors ? Et le collect() du garbage collector ?
À faire autre chose.
Doug713705
Le Tue, 20 Oct 2009 19:41:54 +0300, Mihamina Rakotomandimby a gâché de la bande passante pour nous écrire :
10/20/2009 06:07 PM, Michel Talon:
Si tu parles des "impératifs de production" l'un d'entre eux est aussi la "maintenabilité". Bonne chance avec Perl pour ça, Emmanuel est en train d'en faire l'expérience.
Mais rien ne dit qu'elle est négative, son expérience.
Rencontrer des difficultés a trouver du personnel est rarement une expérience positive pour une entreprise.
-- @+ Doug - Linux user #307925 - Slamd64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
Le Tue, 20 Oct 2009 19:41:54 +0300, Mihamina Rakotomandimby a gâché de
la bande passante pour nous écrire :
10/20/2009 06:07 PM, Michel Talon:
Si tu parles des "impératifs de production" l'un d'entre eux est aussi
la "maintenabilité". Bonne chance avec Perl pour ça, Emmanuel est en
train d'en faire l'expérience.
Mais rien ne dit qu'elle est négative, son expérience.
Rencontrer des difficultés a trouver du personnel est rarement une
expérience positive pour une entreprise.
--
@+
Doug - Linux user #307925 - Slamd64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]
Le Tue, 20 Oct 2009 19:41:54 +0300, Mihamina Rakotomandimby a gâché de la bande passante pour nous écrire :
10/20/2009 06:07 PM, Michel Talon:
Si tu parles des "impératifs de production" l'un d'entre eux est aussi la "maintenabilité". Bonne chance avec Perl pour ça, Emmanuel est en train d'en faire l'expérience.
Mais rien ne dit qu'elle est négative, son expérience.
Rencontrer des difficultés a trouver du personnel est rarement une expérience positive pour une entreprise.
-- @+ Doug - Linux user #307925 - Slamd64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
talon
Mihamina Rakotomandimby wrote:
10/20/2009 06:07 PM, Michel Talon: > Si tu parles des "impératifs de production" l'un d'entre eux est aussi > la "maintenabilité". Bonne chance avec Perl pour ça, Emmanuel est en > train d'en faire l'expérience.
Mais rien ne dit qu'elle est négative, son expérience.
Bien il a l'air d'avoir du mal à trouver des mainteneurs ...
10/20/2009 06:07 PM, Michel Talon:
> Si tu parles des "impératifs de production" l'un d'entre eux est aussi
> la "maintenabilité". Bonne chance avec Perl pour ça, Emmanuel est en
> train d'en faire l'expérience.
Mais rien ne dit qu'elle est négative, son expérience.
Bien il a l'air d'avoir du mal à trouver des mainteneurs ...
10/20/2009 06:07 PM, Michel Talon: > Si tu parles des "impératifs de production" l'un d'entre eux est aussi > la "maintenabilité". Bonne chance avec Perl pour ça, Emmanuel est en > train d'en faire l'expérience.
Mais rien ne dit qu'elle est négative, son expérience.
Bien il a l'air d'avoir du mal à trouver des mainteneurs ...
