A supposer qu'une entreprise veuille mettre son parc sous Linux.
Et qu'elle reçoive des documents venant d'Access, Excel,... peut-elle
les lire , les travailler et les renvoyer de manière que le
destinantaire sur produits Microsoft puisse les lire, etc...
?
C'est pas hallucinant, je suis sûr que toi même n'es pas capable de comprendre les hiéroglyphes que tu as pondus, quinze jours aprés. C'est un phénomène universel, je ne vois pas pourquoi tu serais spécialement épargné. Et même si tu es Emmanuel l'extra lucide, quid si ton client veut foutre lui même son nez dans ton programme?
Mais que fait Stéphane T. quand on a besoin de lui pour un troll de qualité !
-- <NiffTuRNaL> windows isnt real <NiffTuRNaL> its just a fairytale linux users use to scare their kids
Michel Talon s'est exprimé en ces termes:
C'est pas hallucinant, je suis sûr que toi même n'es pas capable de
comprendre les hiéroglyphes que tu as pondus, quinze jours aprés. C'est
un phénomène universel, je ne vois pas pourquoi tu serais spécialement
épargné. Et même si tu es Emmanuel l'extra lucide, quid si ton client
veut foutre lui même son nez dans ton programme?
Mais que fait Stéphane T. quand on a besoin de lui pour un troll de
qualité !
--
<NiffTuRNaL> windows isnt real
<NiffTuRNaL> its just a fairytale linux users use to scare their kids
C'est pas hallucinant, je suis sûr que toi même n'es pas capable de comprendre les hiéroglyphes que tu as pondus, quinze jours aprés. C'est un phénomène universel, je ne vois pas pourquoi tu serais spécialement épargné. Et même si tu es Emmanuel l'extra lucide, quid si ton client veut foutre lui même son nez dans ton programme?
Mais que fait Stéphane T. quand on a besoin de lui pour un troll de qualité !
-- <NiffTuRNaL> windows isnt real <NiffTuRNaL> its just a fairytale linux users use to scare their kids
Michel BILLAUD
(Nicolas George) writes:
Michel Talon, dans le message <cbgt44$s3u$, a écrit :
Pourquoi on a supprimé le TMTOWTDI en Perl dans Perl5?
Non, au contraire, il a été étendu, en particulier avec la possibilité de faire propre.
Question: va-t-il y avoir plus d'une façon de faire propre ?
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
george@clipper.ens.fr (Nicolas George) writes:
Michel Talon, dans le message <cbgt44$s3u$1@asmodee.lpthe.jussieu.fr>, a
écrit :
Pourquoi on a supprimé le TMTOWTDI en Perl dans Perl5?
Non, au contraire, il a été étendu, en particulier avec la possibilité
de faire propre.
Question: va-t-il y avoir plus d'une façon de faire propre ?
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Michel Talon, dans le message <cbgt44$s3u$, a écrit :
Pourquoi on a supprimé le TMTOWTDI en Perl dans Perl5?
Non, au contraire, il a été étendu, en particulier avec la possibilité de faire propre.
Question: va-t-il y avoir plus d'une façon de faire propre ?
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
talon
GP wrote:
Pas impossible, vu mes connaissances sur le sujet. Mais j'aurais cru que lorsqu'on écrit un script d'installation et qu'on ne le fait pas en bash, Python est la solution de choix. Donc, «l'interagir» demeure tout de même superficiel.
Oui, python est la solution de choix, mais pas pour interagir avec le matériel. Par exemple dans l'installeur de Redhat, Kudzu, qui teste le matériel est écrit en C, et l'installeur, anaconda en python.
Faut se fier aux solutions adoptées par Microsoft maintenant? J'ai jeté un coup d'oeil à du code java avec des variables.de.code.de.coin.de.fenetre.touin.touin. J'ai pas trouvé ça drôle. Autrement, avec le C# on parle d'un langage plus évolué, de l'ordre du C, non? Faut pas comparer ça à Perl.
Java et C# c'est à trés peu de chose prés pareil. Le middleware dont je parle, ce n'est pas celui de Microsoft, mais tout le reste, IBM, Oracle, Sap, Resin, Jboss, les produits de Apache (tomcat, et tout le reste), les produits de Sun, etc. C'est bien pour contrer cette vague que Microsoft s'est lancé dans le .NET et a pondu un clone de Java, avec la portabilité en moins.
Oui, c'est l'avantage. Certains disent le seul.
Ils ont tort, java est devenu rapide même s'il faut beaucoup de mémoire. J'ai fait pas mal d'essais récemment, et pour ce que je vois, java est environ 10 fois plus lent que C, mais 10 à 50 fois plus rapide que perl, python, ruby et co. Surtout, java permet de programmer des applications graphiques qui marchent partout avec swing. Pas besoin de se poser la question de savoir si on a la librairie gnome de tel numéro de version ou pas, comme avec wxwindows par exemple. Là c'est rééllement portable.
--
Michel TALON
GP <gilpel@inverse.nretla.org> wrote:
Pas impossible, vu mes connaissances sur le sujet. Mais j'aurais cru que
lorsqu'on écrit un script d'installation et qu'on ne le fait pas en bash,
Python est la solution de choix. Donc, «l'interagir» demeure tout de même
superficiel.
Oui, python est la solution de choix, mais pas pour interagir avec le
matériel. Par exemple dans l'installeur de Redhat, Kudzu, qui teste
le matériel est écrit en C, et l'installeur, anaconda en python.
Faut se fier aux solutions adoptées par Microsoft maintenant? J'ai jeté un coup
d'oeil à du code java avec des
variables.de.code.de.coin.de.fenetre.touin.touin. J'ai pas trouvé ça drôle.
Autrement, avec le C# on parle d'un langage plus évolué, de l'ordre du C, non?
Faut pas comparer ça à Perl.
Java et C# c'est à trés peu de chose prés pareil. Le middleware dont je
parle, ce n'est pas celui de Microsoft, mais tout le reste, IBM,
Oracle, Sap, Resin, Jboss, les produits de Apache (tomcat, et
tout le reste), les produits de Sun, etc. C'est bien pour contrer cette
vague que Microsoft s'est lancé dans le .NET et a pondu un clone de
Java, avec la portabilité en moins.
Oui, c'est l'avantage. Certains disent le seul.
Ils ont tort, java est devenu rapide même s'il faut beaucoup de mémoire.
J'ai fait pas mal d'essais récemment, et pour ce que je vois, java
est environ 10 fois plus lent que C, mais 10 à 50 fois plus rapide que
perl, python, ruby et co.
Surtout, java permet de programmer des applications graphiques qui
marchent partout avec swing. Pas besoin de se poser la question de
savoir si on a la librairie gnome de tel numéro de version ou pas,
comme avec wxwindows par exemple. Là c'est rééllement portable.
Pas impossible, vu mes connaissances sur le sujet. Mais j'aurais cru que lorsqu'on écrit un script d'installation et qu'on ne le fait pas en bash, Python est la solution de choix. Donc, «l'interagir» demeure tout de même superficiel.
Oui, python est la solution de choix, mais pas pour interagir avec le matériel. Par exemple dans l'installeur de Redhat, Kudzu, qui teste le matériel est écrit en C, et l'installeur, anaconda en python.
Faut se fier aux solutions adoptées par Microsoft maintenant? J'ai jeté un coup d'oeil à du code java avec des variables.de.code.de.coin.de.fenetre.touin.touin. J'ai pas trouvé ça drôle. Autrement, avec le C# on parle d'un langage plus évolué, de l'ordre du C, non? Faut pas comparer ça à Perl.
Java et C# c'est à trés peu de chose prés pareil. Le middleware dont je parle, ce n'est pas celui de Microsoft, mais tout le reste, IBM, Oracle, Sap, Resin, Jboss, les produits de Apache (tomcat, et tout le reste), les produits de Sun, etc. C'est bien pour contrer cette vague que Microsoft s'est lancé dans le .NET et a pondu un clone de Java, avec la portabilité en moins.
Oui, c'est l'avantage. Certains disent le seul.
Ils ont tort, java est devenu rapide même s'il faut beaucoup de mémoire. J'ai fait pas mal d'essais récemment, et pour ce que je vois, java est environ 10 fois plus lent que C, mais 10 à 50 fois plus rapide que perl, python, ruby et co. Surtout, java permet de programmer des applications graphiques qui marchent partout avec swing. Pas besoin de se poser la question de savoir si on a la librairie gnome de tel numéro de version ou pas, comme avec wxwindows par exemple. Là c'est rééllement portable.
--
Michel TALON
george
Michel Talon, dans le message <cbhe3o$10k3$, a écrit :
Surtout, java permet de programmer des applications graphiques qui marchent partout avec swing. Pas besoin de se poser la question de savoir si on a la librairie gnome de tel numéro de version ou pas, comme avec wxwindows par exemple. Là c'est rééllement portable.
Essaie d'être cohérent : le prix de cette portabilité, c'est aucune intégration dans la cohérence du bureau que tu réclames tant.
Michel Talon, dans le message <cbhe3o$10k3$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Surtout, java permet de programmer des applications graphiques qui
marchent partout avec swing. Pas besoin de se poser la question de
savoir si on a la librairie gnome de tel numéro de version ou pas,
comme avec wxwindows par exemple. Là c'est rééllement portable.
Essaie d'être cohérent : le prix de cette portabilité, c'est aucune
intégration dans la cohérence du bureau que tu réclames tant.
Michel Talon, dans le message <cbhe3o$10k3$, a écrit :
Surtout, java permet de programmer des applications graphiques qui marchent partout avec swing. Pas besoin de se poser la question de savoir si on a la librairie gnome de tel numéro de version ou pas, comme avec wxwindows par exemple. Là c'est rééllement portable.
Essaie d'être cohérent : le prix de cette portabilité, c'est aucune intégration dans la cohérence du bureau que tu réclames tant.
GP
Michel Talon wrote:
Java et C# c'est à trés peu de chose prés pareil.
Ah bon! Ben, tu vois, avec mes connaissances sur le sujet -- il faut bien que je fasse un peu d'esbrouffe pour te faire parler, autrement je n'apprendrais rien -- je ne savais pas.
Mais là, George, on vas-tu en avoir des lapins, dit qu'il y a un désavantage à l'avantage. Tu vois comme rien n'est simple!
Oui, c'est l'avantage. Certains disent le seul.
Ils ont tort, java est devenu rapide même s'il faut beaucoup de mémoire. J'ai fait pas mal d'essais récemment, et pour ce que je vois,
Tu avais mis tes lunettes roses encore! :)
java est environ 10 fois plus lent que C, mais 10 à 50 fois plus rapide que perl, python, ruby et co. Surtout, java permet de programmer des applications graphiques qui marchent partout avec swing. Pas besoin de se poser la question de savoir si on a la librairie gnome de tel numéro de version ou pas
Tu parles d'un emmerdement, toi! La recherche de librairies occupe la moitié de mes nuits!
Allez! Fini la déconne! Sur ce sujet, je te laisse avec les experts.
GP
Michel Talon wrote:
Java et C# c'est à trés peu de chose prés pareil.
Ah bon! Ben, tu vois, avec mes connaissances sur le sujet -- il faut bien que
je fasse un peu d'esbrouffe pour te faire parler, autrement je n'apprendrais
rien -- je ne savais pas.
Mais là, George, on vas-tu en avoir des lapins, dit qu'il y a un désavantage à
l'avantage. Tu vois comme rien n'est simple!
Oui, c'est l'avantage. Certains disent le seul.
Ils ont tort, java est devenu rapide même s'il faut beaucoup de mémoire.
J'ai fait pas mal d'essais récemment, et pour ce que je vois,
Tu avais mis tes lunettes roses encore! :)
java
est environ 10 fois plus lent que C, mais 10 à 50 fois plus rapide que
perl, python, ruby et co.
Surtout, java permet de programmer des applications graphiques qui
marchent partout avec swing. Pas besoin de se poser la question de
savoir si on a la librairie gnome de tel numéro de version ou pas
Tu parles d'un emmerdement, toi! La recherche de librairies occupe la moitié de
mes nuits!
Allez! Fini la déconne! Sur ce sujet, je te laisse avec les experts.
Ah bon! Ben, tu vois, avec mes connaissances sur le sujet -- il faut bien que je fasse un peu d'esbrouffe pour te faire parler, autrement je n'apprendrais rien -- je ne savais pas.
Mais là, George, on vas-tu en avoir des lapins, dit qu'il y a un désavantage à l'avantage. Tu vois comme rien n'est simple!
Oui, c'est l'avantage. Certains disent le seul.
Ils ont tort, java est devenu rapide même s'il faut beaucoup de mémoire. J'ai fait pas mal d'essais récemment, et pour ce que je vois,
Tu avais mis tes lunettes roses encore! :)
java est environ 10 fois plus lent que C, mais 10 à 50 fois plus rapide que perl, python, ruby et co. Surtout, java permet de programmer des applications graphiques qui marchent partout avec swing. Pas besoin de se poser la question de savoir si on a la librairie gnome de tel numéro de version ou pas
Tu parles d'un emmerdement, toi! La recherche de librairies occupe la moitié de mes nuits!
Allez! Fini la déconne! Sur ce sujet, je te laisse avec les experts.
GP
george
lanvir , dans le message , a écrit :
C et langage évolué... pffff pov tach
Qu'est-ce qui t'arrive ?
lanvir , dans le message <slrncdousd.u0g.lanvir@hubble.maison>, a
écrit :
Comparer C à un langage évolué, moi qui ai vu passer des casts de void* en int* pour en récupérer la valeur pointée... Ca passe pas aujourd'hui en tout cas lol
C _est_ un langage évolué, mais permissif. Il réussit l'exploit d'avoir un comportement bien défini dans les situations normales, tout en permettant des accès bas niveaux non-sûrs qui le rendent capable d'implémenter des outils très efficaces dans des situations spécialisées. C'est vraiment un exploit du point de vue de la conception.
lanvir , dans le message <slrncdp081.u0g.lanvir@hubble.maison>, a
écrit :
Comparer C à un langage évolué, moi qui ai vu passer des casts de void*
en int* pour en récupérer la valeur pointée... Ca passe pas aujourd'hui
en tout cas lol
C _est_ un langage évolué, mais permissif. Il réussit l'exploit d'avoir
un comportement bien défini dans les situations normales, tout en
permettant des accès bas niveaux non-sûrs qui le rendent capable
d'implémenter des outils très efficaces dans des situations
spécialisées. C'est vraiment un exploit du point de vue de la
conception.
Comparer C à un langage évolué, moi qui ai vu passer des casts de void* en int* pour en récupérer la valeur pointée... Ca passe pas aujourd'hui en tout cas lol
C _est_ un langage évolué, mais permissif. Il réussit l'exploit d'avoir un comportement bien défini dans les situations normales, tout en permettant des accès bas niveaux non-sûrs qui le rendent capable d'implémenter des outils très efficaces dans des situations spécialisées. C'est vraiment un exploit du point de vue de la conception.
Manuel Leclerc
C et langage évolué... pffff pov tach
Qu'est-ce qui t'arrive ?
Le C, c'est une sorte d'assembleur, le genre de langage avec lequel +1 transformé en -1 change un programme correct en coredump, undefined et tout le tralala.
Sans parler du délire signed/unsigned.
Et de la sorcellerie qu'on peut faire avec le pré-processeur.
Le C++ n'est pas fondamentalement différent, sauf que du côté sorcellerie, c'est encore pire.
J'adore ces langages, je ne pourrais pas m'en passer, mais soyons objectif : c'est de la merde en branche.
-- I think so, I'm afraid. --Larry McVoy
C et langage évolué... pffff pov tach
Qu'est-ce qui t'arrive ?
Le C, c'est une sorte d'assembleur, le genre de
langage avec lequel +1 transformé en -1 change
un programme correct en coredump, undefined et
tout le tralala.
Sans parler du délire signed/unsigned.
Et de la sorcellerie qu'on peut faire avec le
pré-processeur.
Le C++ n'est pas fondamentalement différent, sauf
que du côté sorcellerie, c'est encore pire.
J'adore ces langages, je ne pourrais pas m'en passer,
mais soyons objectif : c'est de la merde en branche.
Le C, c'est une sorte d'assembleur, le genre de langage avec lequel +1 transformé en -1 change un programme correct en coredump, undefined et tout le tralala.
Sans parler du délire signed/unsigned.
Et de la sorcellerie qu'on peut faire avec le pré-processeur.
Le C++ n'est pas fondamentalement différent, sauf que du côté sorcellerie, c'est encore pire.
J'adore ces langages, je ne pourrais pas m'en passer, mais soyons objectif : c'est de la merde en branche.
-- I think so, I'm afraid. --Larry McVoy
george
lanvir , dans le message , a écrit :
Le problème souvent dans le langage, ce n'est pas le langage, mais son utilisation.
Et ce n'est donc pas le langage qu'il faut critiquer.
Et dire que C est permissif est un doux euphémisme. Quel est le prix à payer de cet exploi de conception? L'obligation de passer son temps à gérer la mémoire, un mode fonctionnel dépassé, et d'autres qualités tellement avouables pour maintenir du code propre?
Tout ceci est vrai, mais ce ne sont pas des défauts du langage, ce sont des choix, parmi les compromis possibles entre la facilité fournie au programmeur et le contrôle dont il dispose sur ce qu'il fait exactement. Évidemment, on peut toujours souhaiter plus de contrôle ET plus de facilité, mais à l'heure actuelle personne ne sait faire. En attendant, si tu fais du C et te plains qu'il n'y a pas d'allocation automatique de mémoire, c'est simplement que tu t'es trompé de langage. C'est comme si tu prenais un compas et te plaignais ensuite que tu ne peux pas tracer des lignes droites facilement.
lanvir , dans le message <slrncdp1fr.u0g.lanvir@hubble.maison>, a
écrit :
Le problème souvent dans le langage, ce n'est pas le langage, mais son
utilisation.
Et ce n'est donc pas le langage qu'il faut critiquer.
Et dire que C est permissif est un doux euphémisme. Quel
est le prix à payer de cet exploi de conception? L'obligation de passer
son temps à gérer la mémoire, un mode fonctionnel dépassé, et d'autres
qualités tellement avouables pour maintenir du code propre?
Tout ceci est vrai, mais ce ne sont pas des défauts du langage, ce sont
des choix, parmi les compromis possibles entre la facilité fournie au
programmeur et le contrôle dont il dispose sur ce qu'il fait exactement.
Évidemment, on peut toujours souhaiter plus de contrôle ET plus de
facilité, mais à l'heure actuelle personne ne sait faire. En attendant,
si tu fais du C et te plains qu'il n'y a pas d'allocation automatique de
mémoire, c'est simplement que tu t'es trompé de langage. C'est comme si
tu prenais un compas et te plaignais ensuite que tu ne peux pas tracer
des lignes droites facilement.
Le problème souvent dans le langage, ce n'est pas le langage, mais son utilisation.
Et ce n'est donc pas le langage qu'il faut critiquer.
Et dire que C est permissif est un doux euphémisme. Quel est le prix à payer de cet exploi de conception? L'obligation de passer son temps à gérer la mémoire, un mode fonctionnel dépassé, et d'autres qualités tellement avouables pour maintenir du code propre?
Tout ceci est vrai, mais ce ne sont pas des défauts du langage, ce sont des choix, parmi les compromis possibles entre la facilité fournie au programmeur et le contrôle dont il dispose sur ce qu'il fait exactement. Évidemment, on peut toujours souhaiter plus de contrôle ET plus de facilité, mais à l'heure actuelle personne ne sait faire. En attendant, si tu fais du C et te plains qu'il n'y a pas d'allocation automatique de mémoire, c'est simplement que tu t'es trompé de langage. C'est comme si tu prenais un compas et te plaignais ensuite que tu ne peux pas tracer des lignes droites facilement.
george
"Manuel Leclerc" , dans le message <40dc86fb$, a écrit :
Le C, c'est une sorte d'assembleur, le genre de langage avec lequel +1 transformé en -1 change un programme correct en coredump, undefined et tout le tralala.
Euh, il faudra m'en montrer, des langages qui sont capables de corriger quand tu te plantes de +1 en -1, hein. Après, que le programme meure sur une segmentation fault ou une out-of-bounds-exception, c'est bonnet blanc et blanc bonnet. À ceci près que ceux qui pratiquent le second se tapent la surcharge code de débuggage même en production.
"Manuel Leclerc" , dans le message <40dc86fb$1@neottia.net>, a écrit :
Le C, c'est une sorte d'assembleur, le genre de
langage avec lequel +1 transformé en -1 change
un programme correct en coredump, undefined et
tout le tralala.
Euh, il faudra m'en montrer, des langages qui sont capables de corriger
quand tu te plantes de +1 en -1, hein. Après, que le programme meure sur
une segmentation fault ou une out-of-bounds-exception, c'est bonnet
blanc et blanc bonnet. À ceci près que ceux qui pratiquent le second se
tapent la surcharge code de débuggage même en production.
"Manuel Leclerc" , dans le message <40dc86fb$, a écrit :
Le C, c'est une sorte d'assembleur, le genre de langage avec lequel +1 transformé en -1 change un programme correct en coredump, undefined et tout le tralala.
Euh, il faudra m'en montrer, des langages qui sont capables de corriger quand tu te plantes de +1 en -1, hein. Après, que le programme meure sur une segmentation fault ou une out-of-bounds-exception, c'est bonnet blanc et blanc bonnet. À ceci près que ceux qui pratiquent le second se tapent la surcharge code de débuggage même en production.
