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 ?
Bah, avec la réflexion et l'introspection, on peu en faire des choses, en Java.
Je n'ai pas dit que c'etait nul non plus...
SL
De manière générale je suis d'accord avec toi pour dire que la « bibliothèque standard » de Java est très large, et très impressionante. Je te faisais juste remarquer que celle de Perl ne l'était pas moins, avec en prime une facilité d'utilisation de celles qui ne viennent pas en standard que je n'ai pas vraiment vu ailleurs.
J'utilise essentiellement les API XML et dans ce domaine il y a des choses en java pour lesquelles il n'y a pas d'équivalent ailleurs, notamment des parseurs validants utilisants les schémas par exemple (quoique, je crois que libxml2 prend du Relax NG, mais le support complet des Schéma W3C n'est pas prévu il me semble). C'est inévitable, java est toujours le langage de la première implémentation avec XML.
Je me souviens qu'il y a quatre ou cinq ans, à la parution du bouquin sur Perl et XML, l'auteur se demandait pourquoi Perl n'était pas au niveau sur ce domaine, et avait même moins de succès que Python. Je sais pas si ça a changé depuis.
De manière générale je suis d'accord avec toi pour dire que la
« bibliothèque standard » de Java est très large, et très
impressionante. Je te faisais juste remarquer que celle de Perl ne
l'était pas moins, avec en prime une facilité d'utilisation de
celles qui ne viennent pas en standard que je n'ai pas vraiment vu
ailleurs.
J'utilise essentiellement les API XML et dans ce domaine il y a des
choses en java pour lesquelles il n'y a pas d'équivalent ailleurs,
notamment des parseurs validants utilisants les schémas par exemple
(quoique, je crois que libxml2 prend du Relax NG, mais le support
complet des Schéma W3C n'est pas prévu il me semble). C'est
inévitable, java est toujours le langage de la première implémentation
avec XML.
Je me souviens qu'il y a quatre ou cinq ans, à la parution du bouquin
sur Perl et XML, l'auteur se demandait pourquoi Perl n'était pas au
niveau sur ce domaine, et avait même moins de succès que Python. Je
sais pas si ça a changé depuis.
De manière générale je suis d'accord avec toi pour dire que la « bibliothèque standard » de Java est très large, et très impressionante. Je te faisais juste remarquer que celle de Perl ne l'était pas moins, avec en prime une facilité d'utilisation de celles qui ne viennent pas en standard que je n'ai pas vraiment vu ailleurs.
J'utilise essentiellement les API XML et dans ce domaine il y a des choses en java pour lesquelles il n'y a pas d'équivalent ailleurs, notamment des parseurs validants utilisants les schémas par exemple (quoique, je crois que libxml2 prend du Relax NG, mais le support complet des Schéma W3C n'est pas prévu il me semble). C'est inévitable, java est toujours le langage de la première implémentation avec XML.
Je me souviens qu'il y a quatre ou cinq ans, à la parution du bouquin sur Perl et XML, l'auteur se demandait pourquoi Perl n'était pas au niveau sur ce domaine, et avait même moins de succès que Python. Je sais pas si ça a changé depuis.
Nicolas George
SL , dans le message , a écrit :
Autre exemple de comparaison avec Lips :
In a strictly statically typed language like C or C++, data types are etched in stone when the source code is compiled. [...] In contrast, a dynamic language such as Smalltalk or Lisp has a runtime system that manages the types of objects and performs necessary type checking while an application is executing. These kinds of languages allow for more complex behavior, and are in many respects more powerful. However, they are also generally slower, less safe, and harder to debug.
Voilà un gus qui, de toute évidence, n'a jamais regardé OCaml de près...
SL , dans le message <u7j4ewavn.fsf@nospam.com>, a écrit :
Autre exemple de comparaison avec Lips :
In a strictly statically typed language like C or C++, data types
are etched in stone when the source code is compiled. [...] In
contrast, a dynamic language such as Smalltalk or Lisp has a
runtime system that manages the types of objects and performs
necessary type checking while an application is executing. These
kinds of languages allow for more complex behavior, and are in
many respects more powerful. However, they are also generally
slower, less safe, and harder to debug.
Voilà un gus qui, de toute évidence, n'a jamais regardé OCaml de près...
In a strictly statically typed language like C or C++, data types are etched in stone when the source code is compiled. [...] In contrast, a dynamic language such as Smalltalk or Lisp has a runtime system that manages the types of objects and performs necessary type checking while an application is executing. These kinds of languages allow for more complex behavior, and are in many respects more powerful. However, they are also generally slower, less safe, and harder to debug.
Voilà un gus qui, de toute évidence, n'a jamais regardé OCaml de près...
SL
SL , dans le message , a écrit :
Autre exemple de comparaison avec Lips :
In a strictly statically typed language like C or C++, data types are etched in stone when the source code is compiled. [...] In contrast, a dynamic language such as Smalltalk or Lisp has a runtime system that manages the types of objects and performs necessary type checking while an application is executing. These kinds of languages allow for more complex behavior, and are in many respects more powerful. However, they are also generally slower, less safe, and harder to debug.
Voilà un gus qui, de toute évidence, n'a jamais regardé OCaml de près...
Peut être bien, et moi non plus ; mais pour être plus charitable avec l'auteur je mets le passage entier, je l'avais un peu charcuté (ça ne change rien sur OCmal il semble) :
(PS : "dynamic" ne conserne donc pas la réflexion, cf. premières lignes)
------------------
1.4.2 Type Safety and Method Binding
One attribute of a language is the kind of type checking it uses. When we categorize a language as static or dynamic we are referring to the amount of information about variable types that is known at compile time versus what is determined while the application is running.
In a strictly statically typed language like C or C++, data types are etched in stone when the source code is compiled. The compiler benefits from having enough information to enforce usage rules, so that it can catch many kinds of errors before the code is executed, such as storing a floating-point value in an integer variable. The code doesn't require runtime type checking, so it can be compiled to be small and fast. But statically typed languages are inflexible. They don't support high-level constructs like lists and collections as naturally as languages with dynamic type checking, and they make it impossible for an application to safely import new data types while it's running.
In contrast, a dynamic language such as Smalltalk or Lisp has a runtime system that manages the types of objects and performs necessary type checking while an application is executing. These kinds of languages allow for more complex behavior, and are in many respects more powerful. However, they are also generally slower, less safe, and harder to debug.
The differences in languages have been likened to the differences among kinds of automobiles.[1] Statically typed languages like C++ are analogous to a sports car—reasonably safe and fast—but useful only if you're driving on a nicely paved road. Highly dynamic languages like Smalltalk are more like an offroad vehicle: they afford you more freedom, but can be somewhat unwieldy. It can be fun (and sometimes faster) to go roaring through the back woods, but you might also get stuck in a ditch or mauled by bears.
[1] The credit for the car analogy goes to Marshall P. Cline, author of the C++ FAQ.
Another attribute of a language is the way it binds method calls to their definitions. In an earlybinding language like C or C++, the definitions of methods are normally bound at compile time, unless the programmer specifies otherwise. Smalltalk, on the other hand, is a late-binding language because it locates the definitions of methods dynamically at runtime. Early-binding is important for performance reasons; an application can run without the overhead incurred by searching method tables at runtime. But late-binding is more flexible. It's also necessary in an object-oriented language, where a subclass can override methods in its superclass, and only the runtime system can determine which method to run.
Java provides some of the benefits of both C++ and Smalltalk; it's a statically typed, late-binding language. Every object in Java has a well-defined type that is known at compile time. This means the Java compiler can do the same kind of static type checking and usage analysis as C++. As a result, you can't assign an object to the wrong type of variable or call nonexistent methods on an object. The Java compiler goes even further and prevents you from messing up and trying to use uninitialized variables.
However, Java is fully runtime typed as well. The Java runtime system keeps track of all objects and makes it possible to determine their types and relationships during execution. This means you can inspect an object at runtime to determine what it is. Unlike C or C++, casts from one type of object to another are checked by the runtime system, and it's even possible to use completely new kinds of dynamically loaded objects with a level of type safety.
Since Java is a late-binding language, all methods are like virtual methods in C++. This makes it possible for a subclass to override methods in its superclass. But Java also allows you to gain the performance benefits of early-binding by explicitly declaring (with the final modifier) that certain methods can't be overridden by subclassing, removing the need for runtime lookup. (Adaptive runtime compilers like HotSpot may be able to eliminate the need for you to worry about this though, as they can detect usage patterns and improve performance automatically, where possible.)
-------------
SL , dans le message <u7j4ewavn.fsf@nospam.com>, a écrit :
Autre exemple de comparaison avec Lips :
In a strictly statically typed language like C or C++, data types
are etched in stone when the source code is compiled. [...] In
contrast, a dynamic language such as Smalltalk or Lisp has a
runtime system that manages the types of objects and performs
necessary type checking while an application is executing. These
kinds of languages allow for more complex behavior, and are in
many respects more powerful. However, they are also generally
slower, less safe, and harder to debug.
Voilà un gus qui, de toute évidence, n'a jamais regardé OCaml de près...
Peut être bien, et moi non plus ; mais pour être plus charitable avec
l'auteur je mets le passage entier, je l'avais un peu charcuté (ça ne
change rien sur OCmal il semble) :
(PS : "dynamic" ne conserne donc pas la réflexion, cf. premières
lignes)
------------------
1.4.2 Type Safety and Method Binding
One attribute of a language is the kind of type checking it uses. When
we categorize a language as static or dynamic we are referring to the
amount of information about variable types that is known at compile
time versus what is determined while the application is running.
In a strictly statically typed language like C or C++, data types are
etched in stone when the source code is compiled. The compiler
benefits from having enough information to enforce usage rules, so
that it can catch many kinds of errors before the code is executed,
such as storing a floating-point value in an integer variable. The
code doesn't require runtime type checking, so it can be compiled to
be small and fast. But statically typed languages are inflexible. They
don't support high-level constructs like lists and collections as
naturally as languages with dynamic type checking, and they make it
impossible for an application to safely import new data types while
it's running.
In contrast, a dynamic language such as Smalltalk or Lisp has a
runtime system that manages the types of objects and performs
necessary type checking while an application is executing. These
kinds of languages allow for more complex behavior, and are in many
respects more powerful. However, they are also generally slower, less
safe, and harder to debug.
The differences in languages have been likened to the differences
among kinds of automobiles.[1] Statically typed languages like C++ are
analogous to a sports car—reasonably safe and fast—but useful only if
you're driving on a nicely paved road. Highly dynamic languages like
Smalltalk are more like an offroad vehicle: they afford you more
freedom, but can be somewhat unwieldy. It can be fun (and sometimes
faster) to go roaring through the back woods, but you might also get
stuck in a ditch or mauled by bears.
[1] The credit for the car analogy goes to Marshall P. Cline, author
of the C++ FAQ.
Another attribute of a language is the way it binds method calls to
their definitions. In an earlybinding language like C or C++, the
definitions of methods are normally bound at compile time, unless the
programmer specifies otherwise. Smalltalk, on the other hand, is a
late-binding language because it locates the definitions of methods
dynamically at runtime. Early-binding is important for performance
reasons; an application can run without the overhead incurred by
searching method tables at runtime. But late-binding is more
flexible. It's also necessary in an object-oriented language, where a
subclass can override methods in its superclass, and only the runtime
system can determine which method to run.
Java provides some of the benefits of both C++ and Smalltalk; it's a
statically typed, late-binding language. Every object in Java has a
well-defined type that is known at compile time. This means the Java
compiler can do the same kind of static type checking and usage
analysis as C++. As a result, you can't assign an object to the wrong
type of variable or call nonexistent methods on an object. The Java
compiler goes even further and prevents you from messing up and trying
to use uninitialized variables.
However, Java is fully runtime typed as well. The Java runtime system
keeps track of all objects and makes it possible to determine their
types and relationships during execution. This means you can inspect
an object at runtime to determine what it is. Unlike C or C++, casts
from one type of object to another are checked by the runtime system,
and it's even possible to use completely new kinds of dynamically
loaded objects with a level of type safety.
Since Java is a late-binding language, all methods are like virtual
methods in C++. This makes it possible for a subclass to override
methods in its superclass. But Java also allows you to gain the
performance benefits of early-binding by explicitly declaring (with
the final modifier) that certain methods can't be overridden by
subclassing, removing the need for runtime lookup. (Adaptive runtime
compilers like HotSpot may be able to eliminate the need for you to
worry about this though, as they can detect usage patterns and improve
performance automatically, where possible.)
In a strictly statically typed language like C or C++, data types are etched in stone when the source code is compiled. [...] In contrast, a dynamic language such as Smalltalk or Lisp has a runtime system that manages the types of objects and performs necessary type checking while an application is executing. These kinds of languages allow for more complex behavior, and are in many respects more powerful. However, they are also generally slower, less safe, and harder to debug.
Voilà un gus qui, de toute évidence, n'a jamais regardé OCaml de près...
Peut être bien, et moi non plus ; mais pour être plus charitable avec l'auteur je mets le passage entier, je l'avais un peu charcuté (ça ne change rien sur OCmal il semble) :
(PS : "dynamic" ne conserne donc pas la réflexion, cf. premières lignes)
------------------
1.4.2 Type Safety and Method Binding
One attribute of a language is the kind of type checking it uses. When we categorize a language as static or dynamic we are referring to the amount of information about variable types that is known at compile time versus what is determined while the application is running.
In a strictly statically typed language like C or C++, data types are etched in stone when the source code is compiled. The compiler benefits from having enough information to enforce usage rules, so that it can catch many kinds of errors before the code is executed, such as storing a floating-point value in an integer variable. The code doesn't require runtime type checking, so it can be compiled to be small and fast. But statically typed languages are inflexible. They don't support high-level constructs like lists and collections as naturally as languages with dynamic type checking, and they make it impossible for an application to safely import new data types while it's running.
In contrast, a dynamic language such as Smalltalk or Lisp has a runtime system that manages the types of objects and performs necessary type checking while an application is executing. These kinds of languages allow for more complex behavior, and are in many respects more powerful. However, they are also generally slower, less safe, and harder to debug.
The differences in languages have been likened to the differences among kinds of automobiles.[1] Statically typed languages like C++ are analogous to a sports car—reasonably safe and fast—but useful only if you're driving on a nicely paved road. Highly dynamic languages like Smalltalk are more like an offroad vehicle: they afford you more freedom, but can be somewhat unwieldy. It can be fun (and sometimes faster) to go roaring through the back woods, but you might also get stuck in a ditch or mauled by bears.
[1] The credit for the car analogy goes to Marshall P. Cline, author of the C++ FAQ.
Another attribute of a language is the way it binds method calls to their definitions. In an earlybinding language like C or C++, the definitions of methods are normally bound at compile time, unless the programmer specifies otherwise. Smalltalk, on the other hand, is a late-binding language because it locates the definitions of methods dynamically at runtime. Early-binding is important for performance reasons; an application can run without the overhead incurred by searching method tables at runtime. But late-binding is more flexible. It's also necessary in an object-oriented language, where a subclass can override methods in its superclass, and only the runtime system can determine which method to run.
Java provides some of the benefits of both C++ and Smalltalk; it's a statically typed, late-binding language. Every object in Java has a well-defined type that is known at compile time. This means the Java compiler can do the same kind of static type checking and usage analysis as C++. As a result, you can't assign an object to the wrong type of variable or call nonexistent methods on an object. The Java compiler goes even further and prevents you from messing up and trying to use uninitialized variables.
However, Java is fully runtime typed as well. The Java runtime system keeps track of all objects and makes it possible to determine their types and relationships during execution. This means you can inspect an object at runtime to determine what it is. Unlike C or C++, casts from one type of object to another are checked by the runtime system, and it's even possible to use completely new kinds of dynamically loaded objects with a level of type safety.
Since Java is a late-binding language, all methods are like virtual methods in C++. This makes it possible for a subclass to override methods in its superclass. But Java also allows you to gain the performance benefits of early-binding by explicitly declaring (with the final modifier) that certain methods can't be overridden by subclassing, removing the need for runtime lookup. (Adaptive runtime compilers like HotSpot may be able to eliminate the need for you to worry about this though, as they can detect usage patterns and improve performance automatically, where possible.)
-------------
Nicolas George
SL , dans le message , a écrit :
ça ne change rien sur OCmal il semble
Effectivement, ça aurait plutôt tendance à confirmer, en particulier :
But statically typed languages are inflexible. They don't support high-level constructs like lists and collections as naturally as languages with dynamic type checking
SL , dans le message <u3bf2p8ra.fsf@nospam.com>, a écrit :
ça ne
change rien sur OCmal il semble
Effectivement, ça aurait plutôt tendance à confirmer, en particulier :
But statically typed languages are inflexible. They
don't support high-level constructs like lists and collections as
naturally as languages with dynamic type checking
Effectivement, ça aurait plutôt tendance à confirmer, en particulier :
But statically typed languages are inflexible. They don't support high-level constructs like lists and collections as naturally as languages with dynamic type checking
seb666fr2
Stéphane Zuckerman wrote:
Je te faisais juste remarquer que celle de Perl ne l'était pas moins, a vec en prime une facilité d'utilisation de celles qui ne viennent pas en st andard que je n'ai pas vraiment vu ailleurs.
Je te ferais remarquer que je n'ai pas initié ce sous-thread dans le but de savoir qui a la plus grosse, mais uniquement dans le but de démontrer que ce qui est le plus important dans un langage, ce sont ses APIs et pas sa syntaxe.
Stéphane Zuckerman wrote:
Je te faisais juste remarquer que celle de Perl ne l'était pas moins, a vec
en prime une facilité d'utilisation de celles qui ne viennent pas en st andard
que je n'ai pas vraiment vu ailleurs.
Je te ferais remarquer que je n'ai pas initié ce sous-thread dans le
but de
savoir qui a la plus grosse, mais uniquement dans le but de démontrer
que
ce qui est le plus important dans un langage, ce sont ses APIs et pas
sa syntaxe.
Je te faisais juste remarquer que celle de Perl ne l'était pas moins, a vec en prime une facilité d'utilisation de celles qui ne viennent pas en st andard que je n'ai pas vraiment vu ailleurs.
Je te ferais remarquer que je n'ai pas initié ce sous-thread dans le but de savoir qui a la plus grosse, mais uniquement dans le but de démontrer que ce qui est le plus important dans un langage, ce sont ses APIs et pas sa syntaxe.
Khanh-Dang
wrote:
Mon but n'étais pas de partir sur une histoire de j'ai la plus grande moi aussi, mais simplement de démontrer que ce qui fait qu'un langage, ce sont ses APIs et pas sa syntaxe.
Tu te contredis.
Si ce qui fait un langage est la qualité et la quantité des API disponibles, alors il s'agit bien d'avoir la plus grosse, grosse en quantité et grosse en qualité.
Et tout ce qu'on essaye de te faire comprendre, c'est que la CPAN n'a rien à envier aux API Java, tant en qualité qu'en quantité.
seb666fr2@yahoo.fr wrote:
Mon but n'étais pas de partir sur une histoire de j'ai la plus grande
moi
aussi, mais simplement de démontrer que ce qui fait qu'un langage, ce
sont ses APIs et pas sa syntaxe.
Tu te contredis.
Si ce qui fait un langage est la qualité et la quantité des API
disponibles, alors il s'agit bien d'avoir la plus grosse, grosse en
quantité et grosse en qualité.
Et tout ce qu'on essaye de te faire comprendre, c'est que la CPAN n'a
rien à envier aux API Java, tant en qualité qu'en quantité.
Mon but n'étais pas de partir sur une histoire de j'ai la plus grande moi aussi, mais simplement de démontrer que ce qui fait qu'un langage, ce sont ses APIs et pas sa syntaxe.
Tu te contredis.
Si ce qui fait un langage est la qualité et la quantité des API disponibles, alors il s'agit bien d'avoir la plus grosse, grosse en quantité et grosse en qualité.
Et tout ce qu'on essaye de te faire comprendre, c'est que la CPAN n'a rien à envier aux API Java, tant en qualité qu'en quantité.
Stéphane Zuckerman
On Mon, 22 May 2006, wrote:
Stéphane Zuckerman wrote:
Je te faisais juste remarquer que celle de Perl ne l'était pas moins, avec en prime une facilité d'utilisation de celles qui ne viennent pas en standard que je n'ai pas vraiment vu ailleurs.
Je te ferais remarquer que je n'ai pas initié ce sous-thread dans le but de savoir qui a la plus grosse, mais uniquement dans le but de démontrer que ce qui est le plus important dans un langage, ce sont ses APIs et pas sa syntaxe.
Par API je suppose que tu veux dire "bibliothèques fournies en standard". Mouais. Bof. Si les bibliothèques dont tu as besoin sont facilement trouvables/installables, tu peux te permettre de prendre un langage qui te plaît plus niveau syntaxe.
De plus, je trouve vraiment Java lourd à écrire. S'il n'y avait pas des IDE type NetBeans ou Eclipse pour simplifier la frappe, je m'arracherais le peu de cheveux qui me restent.
De plus, lorsqu'on doit écrire des machins avec InputStream/OutputStream dans tous les sens, je trouve que la façon de faire est quand même bien compliquée, comparé à C++.
-- "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 Mon, 22 May 2006, seb666fr2@yahoo.fr wrote:
Stéphane Zuckerman wrote:
Je te faisais juste remarquer que celle de Perl ne l'était pas moins, avec
en prime une facilité d'utilisation de celles qui ne viennent pas en standard
que je n'ai pas vraiment vu ailleurs.
Je te ferais remarquer que je n'ai pas initié ce sous-thread dans le
but de
savoir qui a la plus grosse, mais uniquement dans le but de démontrer
que
ce qui est le plus important dans un langage, ce sont ses APIs et pas
sa syntaxe.
Par API je suppose que tu veux dire "bibliothèques fournies en standard".
Mouais. Bof. Si les bibliothèques dont tu as besoin sont facilement
trouvables/installables, tu peux te permettre de prendre un langage qui te
plaît plus niveau syntaxe.
De plus, je trouve vraiment Java lourd à écrire. S'il n'y avait pas des
IDE type NetBeans ou Eclipse pour simplifier la frappe, je m'arracherais
le peu de cheveux qui me restent.
De plus, lorsqu'on doit écrire des machins avec InputStream/OutputStream
dans tous les sens, je trouve que la façon de faire est quand même bien
compliquée, comparé à C++.
--
"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)
Je te faisais juste remarquer que celle de Perl ne l'était pas moins, avec en prime une facilité d'utilisation de celles qui ne viennent pas en standard que je n'ai pas vraiment vu ailleurs.
Je te ferais remarquer que je n'ai pas initié ce sous-thread dans le but de savoir qui a la plus grosse, mais uniquement dans le but de démontrer que ce qui est le plus important dans un langage, ce sont ses APIs et pas sa syntaxe.
Par API je suppose que tu veux dire "bibliothèques fournies en standard". Mouais. Bof. Si les bibliothèques dont tu as besoin sont facilement trouvables/installables, tu peux te permettre de prendre un langage qui te plaît plus niveau syntaxe.
De plus, je trouve vraiment Java lourd à écrire. S'il n'y avait pas des IDE type NetBeans ou Eclipse pour simplifier la frappe, je m'arracherais le peu de cheveux qui me restent.
De plus, lorsqu'on doit écrire des machins avec InputStream/OutputStream dans tous les sens, je trouve que la façon de faire est quand même bien compliquée, comparé à C++.
-- "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)
Emmanuel Florac
Le Mon, 22 May 2006 03:09:36 -0700, seb666fr2 a écrit :
de standard dans un cas et pas dans l'autre. Personnellement je préfère ce modèle de fonctionnement à celui où tout le monde fait ce qu'il veut parce que cela représente une sorte de garde fou.
Donc tu préfères le logiciel proprio au libre. Dommage pour toi.
-- Je suis riche des biens dont je sais me passer. Louis-Jean-Baptiste Etienne Vigée.
Le Mon, 22 May 2006 03:09:36 -0700, seb666fr2 a écrit :
de standard dans un cas et pas dans l'autre. Personnellement je
préfère ce
modèle de fonctionnement à celui où tout le monde fait ce qu'il veut
parce
que cela représente une sorte de garde fou.
Donc tu préfères le logiciel proprio au libre. Dommage pour toi.
--
Je suis riche des biens dont je sais me passer.
Louis-Jean-Baptiste Etienne Vigée.
Le Mon, 22 May 2006 03:09:36 -0700, seb666fr2 a écrit :
de standard dans un cas et pas dans l'autre. Personnellement je préfère ce modèle de fonctionnement à celui où tout le monde fait ce qu'il veut parce que cela représente une sorte de garde fou.
Donc tu préfères le logiciel proprio au libre. Dommage pour toi.
-- Je suis riche des biens dont je sais me passer. Louis-Jean-Baptiste Etienne Vigée.
Emmanuel Florac
Le Mon, 22 May 2006 13:14:12 +0200, Stéphane Zuckerman a écrit :
De manière générale je suis d'accord avec toi pour dire que la « bibliothèque standard » de Java est très large, et très impressionante. Je te faisais juste remarquer que celle de Perl ne l'était pas moins,
Apparemment, on devrait atteindre les 10000 modules sur CPAN très bientôt...
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Le Mon, 22 May 2006 13:14:12 +0200, Stéphane Zuckerman a écrit :
De manière générale je suis d'accord avec toi pour dire que la
« bibliothèque standard » de Java est très large, et très impressionante.
Je te faisais juste remarquer que celle de Perl ne l'était pas moins,
Apparemment, on devrait atteindre les 10000 modules sur CPAN très
bientôt...
--
A thing of beauty is a joy forever.
J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.
Le Mon, 22 May 2006 13:14:12 +0200, Stéphane Zuckerman a écrit :
De manière générale je suis d'accord avec toi pour dire que la « bibliothèque standard » de Java est très large, et très impressionante. Je te faisais juste remarquer que celle de Perl ne l'était pas moins,
Apparemment, on devrait atteindre les 10000 modules sur CPAN très bientôt...
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
