Sun a finalement annoncé le passage prochain de son langage Java, en
Open Source.
L'hésitation porte à l'heure actuelle sur le type exact de licence, Sun
voulant garder la main sur le langage.
Quoiqu'il en soit le code de Java sera ouvert.
Cela va t-il sonner le glas pour les techno .NET ?
On a trop tendance a coder en C notamment des programme qui pourrait être réaliser plus vite grâce à l'API ou aux librairies d'autres langages.
Soit dit en passant, on dit « bibliothèque » en français, Au temps pour moi, j'ai pas fait attention.
Mais je préfère utiliser library dans ce cas, parce que je trouve que les traductions des termes techniques sont souvent assez mauvaises (ici ça va encore). Souvenez-vous de ce bon vieux "cédérom" et du petit dernier le "dévédérom". Merci l'académie française !
et un langage n'a pas d'API, c'est une bibliothèque qui en a une.
En fouillant un peu sur le net j'ai trouvé cette définition d'API :
Application and Programming Interface. Bibliothèque de fonctions généralement de bas niveau destinées à être réutilisées dans diverses applications afin de réaliser des traitements de plus haut niveau. [...] source :
Dans mon esprit : les langages disposent de "bibliothèques", ce qui inclus les API puisque ce sont des bibliothèques. Selon toi qu'est-ce qu'une API ?
Prodejeu , dans le message <447fe718$0$27285$626a54ce@news.free.fr>, a
On a trop tendance a coder en C notamment des programme qui pourrait
être réaliser plus vite grâce à l'API ou aux librairies d'autres langages.
Soit dit en passant, on dit « bibliothèque » en français,
Au temps pour moi, j'ai pas fait attention.
Mais je préfère utiliser library dans ce cas, parce que je trouve que
les traductions des termes techniques sont souvent assez mauvaises (ici
ça va encore). Souvenez-vous de ce bon vieux "cédérom" et du petit
dernier le "dévédérom". Merci l'académie française !
et un langage n'a
pas d'API, c'est une bibliothèque qui en a une.
En fouillant un peu sur le net j'ai trouvé cette définition d'API :
Application and Programming Interface.
Bibliothèque de fonctions généralement de bas niveau destinées à être
réutilisées dans diverses applications afin de réaliser des traitements
de plus haut niveau. [...]
source :
On a trop tendance a coder en C notamment des programme qui pourrait être réaliser plus vite grâce à l'API ou aux librairies d'autres langages.
Soit dit en passant, on dit « bibliothèque » en français, Au temps pour moi, j'ai pas fait attention.
Mais je préfère utiliser library dans ce cas, parce que je trouve que les traductions des termes techniques sont souvent assez mauvaises (ici ça va encore). Souvenez-vous de ce bon vieux "cédérom" et du petit dernier le "dévédérom". Merci l'académie française !
et un langage n'a pas d'API, c'est une bibliothèque qui en a une.
En fouillant un peu sur le net j'ai trouvé cette définition d'API :
Application and Programming Interface. Bibliothèque de fonctions généralement de bas niveau destinées à être réutilisées dans diverses applications afin de réaliser des traitements de plus haut niveau. [...] source :
Dans mon esprit : les langages disposent de "bibliothèques", ce qui inclus les API puisque ce sont des bibliothèques. Selon toi qu'est-ce qu'une API ?
Stéphane Zuckerman
On Fri, 2 Jun 2006, Prodejeu wrote:
Prodejeu , dans le message <447fe718$0$27285$, a
On a trop tendance a coder en C notamment des programme qui pourrait être réaliser plus vite grâce à l'API ou aux librairies d'autres langages.
Soit dit en passant, on dit « bibliothèque » en français, Au temps pour moi, j'ai pas fait attention.
Mais je préfère utiliser library dans ce cas, parce que je trouve que les traductions des termes techniques sont souvent assez mauvaises (ici ça va encore). Souvenez-vous de ce bon vieux "cédérom" et du petit dernier le "dévédérom". Merci l'académie française !
et un langage n'a pas d'API, c'est une bibliothèque qui en a une.
En fouillant un peu sur le net j'ai trouvé cette définition d'API :
Application and Programming Interface. Bibliothèque de fonctions généralement de bas niveau destinées à être réutilisées dans diverses applications afin de réaliser des traitements de plus haut niveau. [...] source :
Dans mon esprit : les langages disposent de "bibliothèques", ce qui inclus les API puisque ce sont des bibliothèques. Selon toi qu'est-ce qu'une API ?
Ben, dans "Application and Programming Interface", y'a "Interface". Une API définit l'interface permettant de se servir d'une bibliothèque, selon moi. En C, tu peux très bien déclarer une interface de manipulation de listes chaînées par exemple (dans un fichier d'en-tête), mais ne pas définir ce code dans le même fichier. Mais le programmeur-utilisateur n'a pas besoin de plus. L'API permet de savoir comment manipuler une bibliothèque, mais n'est pas la bibliothèque.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
On Fri, 2 Jun 2006, Prodejeu wrote:
Prodejeu , dans le message <447fe718$0$27285$626a54ce@news.free.fr>, a
On a trop tendance a coder en C notamment des programme qui pourrait
être réaliser plus vite grâce à l'API ou aux librairies d'autres langages.
Soit dit en passant, on dit « bibliothèque » en français,
Au temps pour moi, j'ai pas fait attention.
Mais je préfère utiliser library dans ce cas, parce que je trouve que les
traductions des termes techniques sont souvent assez mauvaises (ici ça va
encore). Souvenez-vous de ce bon vieux "cédérom" et du petit dernier le
"dévédérom". Merci l'académie française !
et un langage n'a
pas d'API, c'est une bibliothèque qui en a une.
En fouillant un peu sur le net j'ai trouvé cette définition d'API :
Application and Programming Interface.
Bibliothèque de fonctions généralement de bas niveau destinées à être
réutilisées dans diverses applications afin de réaliser des traitements
de plus haut niveau. [...]
source :
Dans mon esprit : les langages disposent de "bibliothèques", ce qui inclus
les API puisque ce sont des bibliothèques.
Selon toi qu'est-ce qu'une API ?
Ben, dans "Application and Programming Interface", y'a "Interface". Une
API définit l'interface permettant de se servir d'une bibliothèque, selon
moi. En C, tu peux très bien déclarer une interface de manipulation de
listes chaînées par exemple (dans un fichier d'en-tête), mais ne pas
définir ce code dans le même fichier. Mais le programmeur-utilisateur n'a
pas besoin de plus. L'API permet de savoir comment manipuler une
bibliothèque, mais n'est pas la bibliothèque.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
On a trop tendance a coder en C notamment des programme qui pourrait être réaliser plus vite grâce à l'API ou aux librairies d'autres langages.
Soit dit en passant, on dit « bibliothèque » en français, Au temps pour moi, j'ai pas fait attention.
Mais je préfère utiliser library dans ce cas, parce que je trouve que les traductions des termes techniques sont souvent assez mauvaises (ici ça va encore). Souvenez-vous de ce bon vieux "cédérom" et du petit dernier le "dévédérom". Merci l'académie française !
et un langage n'a pas d'API, c'est une bibliothèque qui en a une.
En fouillant un peu sur le net j'ai trouvé cette définition d'API :
Application and Programming Interface. Bibliothèque de fonctions généralement de bas niveau destinées à être réutilisées dans diverses applications afin de réaliser des traitements de plus haut niveau. [...] source :
Dans mon esprit : les langages disposent de "bibliothèques", ce qui inclus les API puisque ce sont des bibliothèques. Selon toi qu'est-ce qu'une API ?
Ben, dans "Application and Programming Interface", y'a "Interface". Une API définit l'interface permettant de se servir d'une bibliothèque, selon moi. En C, tu peux très bien déclarer une interface de manipulation de listes chaînées par exemple (dans un fichier d'en-tête), mais ne pas définir ce code dans le même fichier. Mais le programmeur-utilisateur n'a pas besoin de plus. L'API permet de savoir comment manipuler une bibliothèque, mais n'est pas la bibliothèque.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Nicolas George
Prodejeu , dans le message <448046cf$0$21282$, a écrit :
Application and Programming Interface. Bibliothèque de fonctions généralement de bas niveau destinées à être réutilisées dans diverses applications afin de réaliser des traitements de plus haut niveau. [...] source :
Cette définition est mauvaise. Déjà, la traduction du sigle est mauvaise, le and est de trop. L'API, c'est l'interface d'une bibliothèque, la structure des fonctions qu'elle exporte pour une application qui veut l'utiliser. En particulier, des bibliothèques différentes peuvent partager une même API.
Dans mon esprit : les langages disposent de "bibliothèques", ce qui inclus les API puisque ce sont des bibliothèques.
Un langage a une une bibliothèque standard et des bibliothèques tierces. On peut considérer que la bibliothèque standard fait partie du langage, mais mais son API n'est pas « l'API du langage ». Si l'on parle de l'API du langage, ça désigne l'API de l'interpréteur en tant que bibliothèque, embarqué dans une application plus large.
Prodejeu , dans le message <448046cf$0$21282$626a54ce@news.free.fr>, a
écrit :
Application and Programming Interface.
Bibliothèque de fonctions généralement de bas niveau destinées à être
réutilisées dans diverses applications afin de réaliser des traitements
de plus haut niveau. [...]
source :
Cette définition est mauvaise. Déjà, la traduction du sigle est mauvaise, le
and est de trop. L'API, c'est l'interface d'une bibliothèque, la structure
des fonctions qu'elle exporte pour une application qui veut l'utiliser. En
particulier, des bibliothèques différentes peuvent partager une même API.
Dans mon esprit : les langages disposent de "bibliothèques", ce qui
inclus les API puisque ce sont des bibliothèques.
Un langage a une une bibliothèque standard et des bibliothèques tierces. On
peut considérer que la bibliothèque standard fait partie du langage, mais
mais son API n'est pas « l'API du langage ». Si l'on parle de l'API du
langage, ça désigne l'API de l'interpréteur en tant que bibliothèque,
embarqué dans une application plus large.
Prodejeu , dans le message <448046cf$0$21282$, a écrit :
Application and Programming Interface. Bibliothèque de fonctions généralement de bas niveau destinées à être réutilisées dans diverses applications afin de réaliser des traitements de plus haut niveau. [...] source :
Cette définition est mauvaise. Déjà, la traduction du sigle est mauvaise, le and est de trop. L'API, c'est l'interface d'une bibliothèque, la structure des fonctions qu'elle exporte pour une application qui veut l'utiliser. En particulier, des bibliothèques différentes peuvent partager une même API.
Dans mon esprit : les langages disposent de "bibliothèques", ce qui inclus les API puisque ce sont des bibliothèques.
Un langage a une une bibliothèque standard et des bibliothèques tierces. On peut considérer que la bibliothèque standard fait partie du langage, mais mais son API n'est pas « l'API du langage ». Si l'on parle de l'API du langage, ça désigne l'API de l'interpréteur en tant que bibliothèque, embarqué dans une application plus large.
Patrice Karatchentzeff
(Michel Talon) writes:
Prodejeu wrote:
Et j'ai bossé dans une entreprise où l'administrateur réseau n'avait aucun diplôme et se débrouillait au moins aussi bien qu'un pro.
Tu comprends bien que le corollaire de ce que tu dis, c'est que l'enseignement supérieur dans cette matière ne sert absolument à rien. Pensée qui est tellement sacrilège que je me garde de faire plus que de l'évoquer fugitivement.
Si tu vas par là, on peut élaguer beaucoup de choses dans l'enseignement supérieur...
Et j'ai bossé dans une entreprise où l'administrateur réseau n'avait
aucun diplôme et se débrouillait au moins aussi bien qu'un pro.
Tu comprends bien que le corollaire de ce que tu dis, c'est que l'enseignement
supérieur dans cette matière ne sert absolument à rien. Pensée qui est
tellement sacrilège que je me garde de faire plus que de l'évoquer
fugitivement.
Si tu vas par là, on peut élaguer beaucoup de choses dans
l'enseignement supérieur...
Et j'ai bossé dans une entreprise où l'administrateur réseau n'avait aucun diplôme et se débrouillait au moins aussi bien qu'un pro.
Tu comprends bien que le corollaire de ce que tu dis, c'est que l'enseignement supérieur dans cette matière ne sert absolument à rien. Pensée qui est tellement sacrilège que je me garde de faire plus que de l'évoquer fugitivement.
Si tu vas par là, on peut élaguer beaucoup de choses dans l'enseignement supérieur...
Le Fri, 02 Jun 2006 09:21:59 +0200, Prodejeu a écrit :
Par contre, à titre personnel je suis assez réticent à mélanger les langages dans un même développement, à l'exception : -Des développement client/serveur, on a quasiment deux applications complétement distinctes, et si ont utilise directement le reseau, ou du CORBA il n'y a pas de problème. -Et pour l'ajout d'un langage de script à application (pour l'écriture de plugins...)
On peut effectivement utiliser deux langages complètement différents pour le client et le serveur. Mais il est également intéressant par exemple de mixer le C et un langage de haut niveau (Perl, Python) pour un bon équilibre entre performance du code et vitesse de développement.
C'est l'une des grandes tendances, le langage de script sert de glue entre des extensions en C ou C++ qui font la partie demandant des performances, ou des accés spéciaux à l'OS. C'est pour ça qu'ont été développés des outils permettant de faciliter la programmation de l'interface entre le programme natif et le programme de scripts, par exemple swig ou boost-python pour python. En matière scientifique, où on demande quand même des performances de calcul, il y a des choses tout à fait similaires avec des programmes comme matlab ou scilab. Ils présentent à l'utilisateur un langage d'interaction plus rapide à utiliser que de programmer directement la totalité du calcul en Fortran, et qui sert de glue entre des routines Fortran qui sont dans le système, optimisées pour la vitesse.
C'est un peu différent de ce que dit Emmanuel, en tout cas dans le cas de Matlab : si on vectorise proprement, les données sont traitées avec des implémentations en C ou fortran et non avec le langage interprété, mais on programme bien toujours uniquement en Matlab. D'ailleurs c'est exactement comme avec Perl : on a intérêt à faire le maximum dans des "grep" ou des "map", plutôt que d'exprimer des boucles en Perl, traitées par l'interpréteur. Il me semble qu'Emmanuel parlait plutôt du fait d'écrire son programme en plusieurs langages.
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Fri, 02 Jun 2006 09:21:59 +0200, Prodejeu a écrit :
Par contre, à titre personnel je suis assez réticent à mélanger
les langages dans un même développement, à l'exception : -Des
développement client/serveur, on a quasiment deux applications
complétement distinctes, et si ont utilise directement le reseau,
ou du CORBA il n'y a pas de problème. -Et pour l'ajout d'un
langage de script à application (pour l'écriture de plugins...)
On peut effectivement utiliser deux langages complètement
différents pour le client et le serveur. Mais il est également
intéressant par exemple de mixer le C et un langage de haut niveau
(Perl, Python) pour un bon équilibre entre performance du code et
vitesse de développement.
C'est l'une des grandes tendances, le langage de script sert de glue
entre des extensions en C ou C++ qui font la partie demandant des
performances, ou des accés spéciaux à l'OS. C'est pour ça qu'ont été
développés des outils permettant de faciliter la programmation de
l'interface entre le programme natif et le programme de scripts, par
exemple swig ou boost-python pour python. En matière scientifique,
où on demande quand même des performances de calcul, il y a des
choses tout à fait similaires avec des programmes comme matlab ou
scilab. Ils présentent à l'utilisateur un langage d'interaction plus
rapide à utiliser que de programmer directement la totalité du
calcul en Fortran, et qui sert de glue entre des routines Fortran
qui sont dans le système, optimisées pour la vitesse.
C'est un peu différent de ce que dit Emmanuel, en tout cas dans le cas
de Matlab : si on vectorise proprement, les données sont traitées avec
des implémentations en C ou fortran et non avec le langage interprété,
mais on programme bien toujours uniquement en Matlab. D'ailleurs c'est
exactement comme avec Perl : on a intérêt à faire le maximum dans des
"grep" ou des "map", plutôt que d'exprimer des boucles en Perl,
traitées par l'interpréteur. Il me semble qu'Emmanuel parlait plutôt
du fait d'écrire son programme en plusieurs langages.
Le Fri, 02 Jun 2006 09:21:59 +0200, Prodejeu a écrit :
Par contre, à titre personnel je suis assez réticent à mélanger les langages dans un même développement, à l'exception : -Des développement client/serveur, on a quasiment deux applications complétement distinctes, et si ont utilise directement le reseau, ou du CORBA il n'y a pas de problème. -Et pour l'ajout d'un langage de script à application (pour l'écriture de plugins...)
On peut effectivement utiliser deux langages complètement différents pour le client et le serveur. Mais il est également intéressant par exemple de mixer le C et un langage de haut niveau (Perl, Python) pour un bon équilibre entre performance du code et vitesse de développement.
C'est l'une des grandes tendances, le langage de script sert de glue entre des extensions en C ou C++ qui font la partie demandant des performances, ou des accés spéciaux à l'OS. C'est pour ça qu'ont été développés des outils permettant de faciliter la programmation de l'interface entre le programme natif et le programme de scripts, par exemple swig ou boost-python pour python. En matière scientifique, où on demande quand même des performances de calcul, il y a des choses tout à fait similaires avec des programmes comme matlab ou scilab. Ils présentent à l'utilisateur un langage d'interaction plus rapide à utiliser que de programmer directement la totalité du calcul en Fortran, et qui sert de glue entre des routines Fortran qui sont dans le système, optimisées pour la vitesse.
C'est un peu différent de ce que dit Emmanuel, en tout cas dans le cas de Matlab : si on vectorise proprement, les données sont traitées avec des implémentations en C ou fortran et non avec le langage interprété, mais on programme bien toujours uniquement en Matlab. D'ailleurs c'est exactement comme avec Perl : on a intérêt à faire le maximum dans des "grep" ou des "map", plutôt que d'exprimer des boucles en Perl, traitées par l'interpréteur. Il me semble qu'Emmanuel parlait plutôt du fait d'écrire son programme en plusieurs langages.
SL
Tu comprends bien que le corollaire de ce que tu dis, c'est que l'enseignement supérieur dans cette matière ne sert absolument à rien. Pensée qui est tellement sacrilège que je me garde de faire plus que de l'évoquer fugitivement.
Si tu vas par là, on peut élaguer beaucoup de choses dans l'enseignement supérieur...
Quoi par exemple ?
Tu comprends bien que le corollaire de ce que tu dis, c'est que
l'enseignement supérieur dans cette matière ne sert absolument à
rien. Pensée qui est tellement sacrilège que je me garde de faire
plus que de l'évoquer fugitivement.
Si tu vas par là, on peut élaguer beaucoup de choses dans
l'enseignement supérieur...
Tu comprends bien que le corollaire de ce que tu dis, c'est que l'enseignement supérieur dans cette matière ne sert absolument à rien. Pensée qui est tellement sacrilège que je me garde de faire plus que de l'évoquer fugitivement.
Si tu vas par là, on peut élaguer beaucoup de choses dans l'enseignement supérieur...
Quoi par exemple ?
talon
SL wrote:
C'est un peu différent de ce que dit Emmanuel, en tout cas dans le cas de Matlab : si on vectorise proprement, les données sont traitées avec des implémentations en C ou fortran et non avec le langage interprété, mais on programme bien toujours uniquement en Matlab. D'ailleurs c'est
C'est bien ce que je disais, il me semble. De la même façon si tu utilises les mêmes routines scientifiques en Fortran comme la bibliothèque Atlas, qui sont utilisées par scilab, comme extensions de python, ce qui est fait par scipy ou numpy, tu vas aussi écrire ton propre problème en python mais les calculs lourds seront faits par le programme compilé depuis Fortran, derrière. Il y a aussi la possibilité de programmer dans un mélange de C et de python, c'est à dire d'écrire soi même en C les choses qui demandent des calculs, mais de laisser le python et le C mêlés, c'est ce que fait pyrex. Exemple ici: http://ldots.org/pyrex-guide/7-complete.html
exactement comme avec Perl : on a intérêt à faire le maximum dans des "grep" ou des "map", plutôt que d'exprimer des boucles en Perl, traitées par l'interpréteur. Il me semble qu'Emmanuel parlait plutôt du fait d'écrire son programme en plusieurs langages.
Je suis bien d'accord, les regexp en perl, python, etc. sont typiquement des exemples d'extension exactement comme ce dont on parle au dessus, dés qu'on rentre dans une regexp, on ne fait plus du perl en fait, c'est pour ça que ça va vite. Tu penses qu'Emmanuel voulait parler d'une partie des modules écrits dans un langage une autre dans un autre? Je n'avais pas compris ça.
--
Michel TALON
SL <nospam@nospam.com> wrote:
C'est un peu différent de ce que dit Emmanuel, en tout cas dans le cas
de Matlab : si on vectorise proprement, les données sont traitées avec
des implémentations en C ou fortran et non avec le langage interprété,
mais on programme bien toujours uniquement en Matlab. D'ailleurs c'est
C'est bien ce que je disais, il me semble. De la même façon si tu utilises les
mêmes routines scientifiques en Fortran comme la bibliothèque Atlas, qui sont
utilisées par scilab, comme extensions de python, ce qui est fait par scipy ou
numpy, tu vas aussi écrire ton propre problème en python mais les calculs
lourds seront faits par le programme compilé depuis Fortran, derrière. Il y a
aussi la possibilité de programmer dans un mélange de C et de python, c'est à
dire d'écrire soi même en C les choses qui demandent des calculs, mais de
laisser le python et le C mêlés, c'est ce que fait pyrex. Exemple ici:
http://ldots.org/pyrex-guide/7-complete.html
exactement comme avec Perl : on a intérêt à faire le maximum dans des
"grep" ou des "map", plutôt que d'exprimer des boucles en Perl,
traitées par l'interpréteur. Il me semble qu'Emmanuel parlait plutôt
du fait d'écrire son programme en plusieurs langages.
Je suis bien d'accord, les regexp en perl, python, etc. sont typiquement des
exemples d'extension exactement comme ce dont on parle au dessus, dés qu'on
rentre dans une regexp, on ne fait plus du perl en fait, c'est pour ça que ça
va vite.
Tu penses qu'Emmanuel voulait parler d'une partie des modules écrits dans un
langage une autre dans un autre? Je n'avais pas compris ça.
C'est un peu différent de ce que dit Emmanuel, en tout cas dans le cas de Matlab : si on vectorise proprement, les données sont traitées avec des implémentations en C ou fortran et non avec le langage interprété, mais on programme bien toujours uniquement en Matlab. D'ailleurs c'est
C'est bien ce que je disais, il me semble. De la même façon si tu utilises les mêmes routines scientifiques en Fortran comme la bibliothèque Atlas, qui sont utilisées par scilab, comme extensions de python, ce qui est fait par scipy ou numpy, tu vas aussi écrire ton propre problème en python mais les calculs lourds seront faits par le programme compilé depuis Fortran, derrière. Il y a aussi la possibilité de programmer dans un mélange de C et de python, c'est à dire d'écrire soi même en C les choses qui demandent des calculs, mais de laisser le python et le C mêlés, c'est ce que fait pyrex. Exemple ici: http://ldots.org/pyrex-guide/7-complete.html
exactement comme avec Perl : on a intérêt à faire le maximum dans des "grep" ou des "map", plutôt que d'exprimer des boucles en Perl, traitées par l'interpréteur. Il me semble qu'Emmanuel parlait plutôt du fait d'écrire son programme en plusieurs langages.
Je suis bien d'accord, les regexp en perl, python, etc. sont typiquement des exemples d'extension exactement comme ce dont on parle au dessus, dés qu'on rentre dans une regexp, on ne fait plus du perl en fait, c'est pour ça que ça va vite. Tu penses qu'Emmanuel voulait parler d'une partie des modules écrits dans un langage une autre dans un autre? Je n'avais pas compris ça.
--
Michel TALON
Emmanuel Florac
Le Sat, 03 Jun 2006 16:29:40 +0200, SL a écrit :
Il me semble qu'Emmanuel parlait plutôt du fait d'écrire son programme en plusieurs langages.
Oui, par exemple comme je l'ai mentionné (dans le cas de Perl) avec Inline::C, ou XS (pour ceux qui ont du poil uniquement...). La plupart des librairies d'accès aux bases de données de Perl sont en C, par exemple (et très rapides), de même les modules SDL, GD, Gtk et compagnie.
-- Writing about music is like dancing about architecture. Frank Zappa
Le Sat, 03 Jun 2006 16:29:40 +0200, SL a écrit :
Il me semble qu'Emmanuel parlait plutôt
du fait d'écrire son programme en plusieurs langages.
Oui, par exemple comme je l'ai mentionné (dans le cas de Perl) avec
Inline::C, ou XS (pour ceux qui ont du poil uniquement...).
La plupart des librairies d'accès aux bases de données de Perl sont en
C, par exemple (et très rapides), de même les modules SDL, GD, Gtk et
compagnie.
--
Writing about music is like dancing about architecture.
Frank Zappa
Il me semble qu'Emmanuel parlait plutôt du fait d'écrire son programme en plusieurs langages.
Oui, par exemple comme je l'ai mentionné (dans le cas de Perl) avec Inline::C, ou XS (pour ceux qui ont du poil uniquement...). La plupart des librairies d'accès aux bases de données de Perl sont en C, par exemple (et très rapides), de même les modules SDL, GD, Gtk et compagnie.
-- Writing about music is like dancing about architecture. Frank Zappa
SL
Le Sat, 03 Jun 2006 16:29:40 +0200, SL a écrit :
Il me semble qu'Emmanuel parlait plutôt du fait d'écrire son programme en plusieurs langages.
Oui, par exemple comme je l'ai mentionné (dans le cas de Perl) avec Inline::C, ou XS (pour ceux qui ont du poil uniquement...).
Ou Inline::Java, mais on ne m'ôtera pas de l'idée que je trouve que c'est un peu branlant ; pour l'interfaçage de plusieurs langages, c'est pas ce permet de faire, de façon plus avancée, des trucs autour de C# ?
La plupart des librairies d'accès aux bases de données de Perl sont en C, par exemple (et très rapides),
Là on est à nouveau dans le cas de programme écrit /en Perl/, mais dont l'interpréteur délègue l'exécution à des modules écrit en C, non ?
Le Sat, 03 Jun 2006 16:29:40 +0200, SL a écrit :
Il me semble qu'Emmanuel parlait plutôt du fait d'écrire son
programme en plusieurs langages.
Oui, par exemple comme je l'ai mentionné (dans le cas de Perl) avec
Inline::C, ou XS (pour ceux qui ont du poil uniquement...).
Ou Inline::Java, mais on ne m'ôtera pas de l'idée que je trouve que
c'est un peu branlant ; pour l'interfaçage de plusieurs langages,
c'est pas ce permet de faire, de façon plus avancée, des trucs autour
de C# ?
La plupart des librairies d'accès aux bases de données de Perl sont
en C, par exemple (et très rapides),
Là on est à nouveau dans le cas de programme écrit /en Perl/, mais
dont l'interpréteur délègue l'exécution à des modules écrit en C, non
?
Il me semble qu'Emmanuel parlait plutôt du fait d'écrire son programme en plusieurs langages.
Oui, par exemple comme je l'ai mentionné (dans le cas de Perl) avec Inline::C, ou XS (pour ceux qui ont du poil uniquement...).
Ou Inline::Java, mais on ne m'ôtera pas de l'idée que je trouve que c'est un peu branlant ; pour l'interfaçage de plusieurs langages, c'est pas ce permet de faire, de façon plus avancée, des trucs autour de C# ?
La plupart des librairies d'accès aux bases de données de Perl sont en C, par exemple (et très rapides),
Là on est à nouveau dans le cas de programme écrit /en Perl/, mais dont l'interpréteur délègue l'exécution à des modules écrit en C, non ?
Emmanuel Florac
Le Sat, 03 Jun 2006 17:17:05 +0200, SL a écrit :
Oui, par exemple comme je l'ai mentionné (dans le cas de Perl) avec Inline::C, ou XS (pour ceux qui ont du poil uniquement...).
Ou Inline::Java, mais on ne m'ôtera pas de l'idée que je trouve que c'est un peu branlant ; pour l'interfaçage de plusieurs langages, c'est pas ce permet de faire, de façon plus avancée, des trucs autour de C# ?
Je viens de lire sur feu tpj.com un article sur une grosse application basée sur Inline::Java, comme quoi ça doit pas être trop pourri.
La plupart des librairies d'accès aux bases de données de Perl sont en C, par exemple (et très rapides),
Là on est à nouveau dans le cas de programme écrit /en Perl/, mais dont l'interpréteur délègue l'exécution à des modules écrit en C, non ?
Oui bien sûr. Même quand on fait du Inline::C, c'est un peu pareil : on a seulement le gros avantage d'avoir tout le code sous la main et de ne pas avoir à gérer les subtilités d'interconnexion entre les deux codes, c'est "magique" (je définis une fonction en C, et paf, je peux l'appeler dans le code Perl).
-- Sutor ne ultra Crepidam.
Le Sat, 03 Jun 2006 17:17:05 +0200, SL a écrit :
Oui, par exemple comme je l'ai mentionné (dans le cas de Perl) avec
Inline::C, ou XS (pour ceux qui ont du poil uniquement...).
Ou Inline::Java, mais on ne m'ôtera pas de l'idée que je trouve que
c'est un peu branlant ; pour l'interfaçage de plusieurs langages,
c'est pas ce permet de faire, de façon plus avancée, des trucs autour
de C# ?
Je viens de lire sur feu tpj.com un article sur une grosse application
basée sur Inline::Java, comme quoi ça doit pas être trop pourri.
La plupart des librairies d'accès aux bases de données de Perl sont
en C, par exemple (et très rapides),
Là on est à nouveau dans le cas de programme écrit /en Perl/, mais
dont l'interpréteur délègue l'exécution à des modules écrit en C,
non
?
Oui bien sûr. Même quand on fait du Inline::C, c'est un peu pareil : on
a seulement le gros avantage d'avoir tout le code sous la main et de ne
pas avoir à gérer les subtilités d'interconnexion entre les deux
codes, c'est "magique" (je définis une fonction en C, et paf, je peux
l'appeler dans le code Perl).
Oui, par exemple comme je l'ai mentionné (dans le cas de Perl) avec Inline::C, ou XS (pour ceux qui ont du poil uniquement...).
Ou Inline::Java, mais on ne m'ôtera pas de l'idée que je trouve que c'est un peu branlant ; pour l'interfaçage de plusieurs langages, c'est pas ce permet de faire, de façon plus avancée, des trucs autour de C# ?
Je viens de lire sur feu tpj.com un article sur une grosse application basée sur Inline::Java, comme quoi ça doit pas être trop pourri.
La plupart des librairies d'accès aux bases de données de Perl sont en C, par exemple (et très rapides),
Là on est à nouveau dans le cas de programme écrit /en Perl/, mais dont l'interpréteur délègue l'exécution à des modules écrit en C, non ?
Oui bien sûr. Même quand on fait du Inline::C, c'est un peu pareil : on a seulement le gros avantage d'avoir tout le code sous la main et de ne pas avoir à gérer les subtilités d'interconnexion entre les deux codes, c'est "magique" (je définis une fonction en C, et paf, je peux l'appeler dans le code Perl).
