Ce qui me fait marre, c'est que tous leurs arguments de compatibilité peuvent dit dans l'autre sens : MSO pas compatible avec OOo, MSO ne reconnaît pas nos scripts... :-)
Ecoute j'ai développé en C sous Linux. Quand il y avait un bug, je n'ai jamais eu besoin de regarder si il y avait un bug dans le système, le langage ou n'importe ou ailleurs. J'avais juste à trouver MON erreur.
Depuis que je développe en VB.NET je passe mon temps à chercher le problème de .NET. C'est clair, il y a plus souvent des erreurs dans .NET que dans mon programme.
T'as du mal à comprendre le terme "exemple", ça peut arriver pour d'autres points avec Mono, et le fait de changer de langage n'y fera rien.
Ce que je voulais dire, c'est que tu pourras pas dire : "y'a un bug, je vais prendre tel langage, réputé pour être très fiable", même un langage super fiable deviendra dépendant de ton runtime commun.
Oui, c'est vrai.
Mais j'ai quand même peur d'entendre des remarques du genre "ils n'ont pas la capacité de créer leur framework, ils pompent sur MS"...
Je penses que ni Java ni C#.NET ne sont des solutions à retenir.
Pour que Gnome ne se séparre pas totalement du reste de la communauté, il faut qu'il reste proche du C pour permettre l'utilisation de bibliothèques communes écrites en C.
Par exemple, pour les appareils photos numériques une bibliothèque écrite en C, GPhoto2, est utilisée par kde, gnome et d'autres encore.
L'utilisation du Java risque d'inciter le développement de telles bibliothèques directement en Java et ne permettra donc pas son utilisation par d'autres projets.
Pour le C#, malgré l'ouverture des spécifications etc., je pense qu'il ne faut pas s'aventurer de ce côté là. On ne sait pas ce que peut inventer MS pour nous attaquer.
De plus, (je ne suis pas sûr) il me semble que Mono ne soit pas terminé et se lancer avec un langage qui n'est pas encore fonctionnel, c'est un peu risqué.
Pour ma part la solution serait l'Objective-C avec la conservation du Foundation Framework de GNUstep et la création d'un GUI spécifique Gnome.
Il faut également que l'ObjC permet la communication inter-process, la distribution d'objets de manière quasi-transparente (plus facile que le Net-remoting de .NET).
Pour te répondre une dernière fois, je vais prendre un exemple concret.
J'ai des collègues qui ont développé une application pour tester des appareils de mesures quelconques. Leur application devait tourner pendant environ 4 jours pour effectuer les tests.
Ils l'ont développé en VB .NET et par manque de chance ont eu des problèmes de mémoire car le GC ne fonctionne pas correctement sur .NET. Leurs tests s'arrêtaient au bout de 2 jours avec un message du genre plus de mémoire.
Alors, on peut se dire qu'il fallait choisir un langage avec une meilleure gestion de la mémoire, mais c'est le runtime qui la gère donc ça ne changera rien.
Voila pourquoi je dis qu'on choisit un langage pour ses qualités internes et non pour sa syntaxe.
La seule chose qu'apporte le runtime commun, c'est la généralisation des défauts et la perte des qualités spécifiques.
Ce que je voulais dire c'est choisir un langage pour favoriser telle ou telle qualité.
Avec le runtime commun, il n'y a aucun moyen de privilégier un aspect particulier d'un langage.
Que je programme en C ou VB, la vitesse d'exécution sera la même.
Alors que moi je choisirais le C quand l'application devra être rapide, et le VB lorsque l'application nécessitera des capacités de plugins évoluées.
Tant qu'à faire, autant créer un langage mieux adapté au runtime plutôt que d'adapter par je ne sais quel moyen d'autres langages dont les qualités spécifiques sont perdues.
Pour finir, si des gens se donnent la peine de créer de nouveaux langages, c'est pas pour inventer une nouvelle syntaxe, mais pour apporter des nouveautés internes.
Ton commentaire m'a réellement intéressé et j'ai donc voulu voir à quoi ça ressemble.
Utilisant une Debian, j'ai regardé si un paquet était disponible.
Effectivement il y en a un mais il est classé en non-US.
Il me semble que les non-US sont interdits pour cause de cryptographie ou un truc dans le genre. Du coup je ne sais pas si c'est l'idéal pour le futur de Gnome.
J'aimerais connaître l'intérêt d'un tel portage. Moi, quand j'utilise un langage, c'est pas pour sa syntaxe... je regarde sa vitesse, sa stabilité, ses caractéristiques internes...
bref, je ne vois pas l'intérêt qu'on peut avoir à porter 10000 langages sur le même runtime.
Ce langage possède peut-être quand même un petit souci :
Apple peut rajouter des specs à OpenStep, étant propriétaire.
Si GNUstep se rapproche trop d'eux, ils pourront facilement allourdir les specs de manière à limiter la compatibilité, en se basant sur la lenteur de développement (par rapport à la leur).
En effet, je mélange tout pour aller plus vite. Je penses de toutes façons que les langages sont associés à leurs frameworks respectifs, sauf pour le C++ qui en possède plusieurs.
Par contre pour cocoa, je ne crois pas m'être trompé, car la doc du framework se trouve sous cocoa sur le site d'Apple.
Te plains pas, il y a un langage dont il ne parle même pas (peut-être ne sait-il pas qu'il existe :-)), l'Objective-C.
C'est un langage très rapide, très évolué et comparable (à mon avis) à Java et à .NET.
Avec cependant un gros avantage : il possède un framework éprouvé, simple à utiliser et complet sans être trop lourd (ce framework c'est GNUstep, qui répond aux specs OpenStep, comme Cocoa de MacOS X).
[^] # Re: Microsoft parle d'OpenOffice.org
Posté par nicolassanchez . En réponse à la dépêche Microsoft parle d'OpenOffice.org. Évalué à 1.
J'en déduis qu'ils l'ont sûrement sur leur poste, non ?
[^] # Re: Microsoft parle d'OpenOffice.org
Posté par nicolassanchez . En réponse à la dépêche Microsoft parle d'OpenOffice.org. Évalué à 1.
[^] # Re: Microsoft parle d'OpenOffice.org
Posté par nicolassanchez . En réponse à la dépêche Microsoft parle d'OpenOffice.org. Évalué à 1.
Ça ne marche pas chez moi :-(
# Re: Microsoft parle d'OpenOffice.org
Posté par nicolassanchez . En réponse à la dépêche Microsoft parle d'OpenOffice.org. Évalué à 5.
[^] # Re: Microsoft parle d'OpenOffice.org
Posté par nicolassanchez . En réponse à la dépêche Microsoft parle d'OpenOffice.org. Évalué à 0.
Creator: QuarkXPress(tm) 4.11
Producer: Acrobat Distiller 4.05 for Macintosh
OK c'est pour le PDF dont on parle ... :-)
[^] # Re: Microsoft parle d'OpenOffice.org
Posté par nicolassanchez . En réponse à la dépêche Microsoft parle d'OpenOffice.org. Évalué à 2.
[^] # Re: Microsoft parle d'OpenOffice.org
Posté par nicolassanchez . En réponse à la dépêche Microsoft parle d'OpenOffice.org. Évalué à 1.
[^] # Re: Microsoft parle d'OpenOffice.org
Posté par nicolassanchez . En réponse à la dépêche Microsoft parle d'OpenOffice.org. Évalué à 0.
Par exemple ta base de données, dis moi l'intérêt de l'avoir intégrée à OOo.
[^] # Re: On oublie toujours OCaml
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 2.
Depuis que je développe en VB.NET je passe mon temps à chercher le problème de .NET. C'est clair, il y a plus souvent des erreurs dans .NET que dans mon programme.
[^] # Re: On oublie toujours OCaml
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
Ce que je voulais dire, c'est que tu pourras pas dire : "y'a un bug, je vais prendre tel langage, réputé pour être très fiable", même un langage super fiable deviendra dépendant de ton runtime commun.
[^] # Re: Havoc Pennington se pose des questions sur les langages du libre
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
Mais j'ai quand même peur d'entendre des remarques du genre "ils n'ont pas la capacité de créer leur framework, ils pompent sur MS"...
[^] # Re: Havoc Pennington se pose des questions sur les langages du libre
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
[^] # Re: Havoc Pennington se pose des questions sur les langages du libre
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
Dans ce cas, ils pourraient remplacer le C++ par l'ObjC simplement ? non ? c'est idiot ?
[^] # Re: Havoc Pennington se pose des questions sur les langages du libre
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
Pour que Gnome ne se séparre pas totalement du reste de la communauté, il faut qu'il reste proche du C pour permettre l'utilisation de bibliothèques communes écrites en C.
Par exemple, pour les appareils photos numériques une bibliothèque écrite en C, GPhoto2, est utilisée par kde, gnome et d'autres encore.
L'utilisation du Java risque d'inciter le développement de telles bibliothèques directement en Java et ne permettra donc pas son utilisation par d'autres projets.
Pour le C#, malgré l'ouverture des spécifications etc., je pense qu'il ne faut pas s'aventurer de ce côté là. On ne sait pas ce que peut inventer MS pour nous attaquer.
De plus, (je ne suis pas sûr) il me semble que Mono ne soit pas terminé et se lancer avec un langage qui n'est pas encore fonctionnel, c'est un peu risqué.
Pour ma part la solution serait l'Objective-C avec la conservation du Foundation Framework de GNUstep et la création d'un GUI spécifique Gnome.
Il faut également que l'ObjC permet la communication inter-process, la distribution d'objets de manière quasi-transparente (plus facile que le Net-remoting de .NET).
[^] # Re: On oublie toujours OCaml
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 2.
J'ai des collègues qui ont développé une application pour tester des appareils de mesures quelconques. Leur application devait tourner pendant environ 4 jours pour effectuer les tests.
Ils l'ont développé en VB .NET et par manque de chance ont eu des problèmes de mémoire car le GC ne fonctionne pas correctement sur .NET. Leurs tests s'arrêtaient au bout de 2 jours avec un message du genre plus de mémoire.
Alors, on peut se dire qu'il fallait choisir un langage avec une meilleure gestion de la mémoire, mais c'est le runtime qui la gère donc ça ne changera rien.
Voila pourquoi je dis qu'on choisit un langage pour ses qualités internes et non pour sa syntaxe.
La seule chose qu'apporte le runtime commun, c'est la généralisation des défauts et la perte des qualités spécifiques.
[^] # Re: On oublie toujours OCaml
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 2.
Avec le runtime commun, il n'y a aucun moyen de privilégier un aspect particulier d'un langage.
Que je programme en C ou VB, la vitesse d'exécution sera la même.
Alors que moi je choisirais le C quand l'application devra être rapide, et le VB lorsque l'application nécessitera des capacités de plugins évoluées.
Tant qu'à faire, autant créer un langage mieux adapté au runtime plutôt que d'adapter par je ne sais quel moyen d'autres langages dont les qualités spécifiques sont perdues.
Pour finir, si des gens se donnent la peine de créer de nouveaux langages, c'est pas pour inventer une nouvelle syntaxe, mais pour apporter des nouveautés internes.
[^] # Re: Erlang a également été oublié
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
Utilisant une Debian, j'ai regardé si un paquet était disponible.
Effectivement il y en a un mais il est classé en non-US.
Il me semble que les non-US sont interdits pour cause de cryptographie ou un truc dans le genre. Du coup je ne sais pas si c'est l'idéal pour le futur de Gnome.
[^] # Re: On oublie toujours OCaml
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 0.
bref, je ne vois pas l'intérêt qu'on peut avoir à porter 10000 langages sur le même runtime.
Si quelqu'un peut m'éclairer.
[^] # Re: Havoc Pennington se pose des questions les langages du libre
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 2.
Suffit de voir comme Microsoft attaque Linux par tous les moyens...
voir http://www.microsoft.com/france/lesfaits(...) pour comprendre qu'ils ont peur...
[^] # Re: Havoc Pennington se pose des questions les langages du libre
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
openstep a été normalisé avec NeXT et Sun.
Ils ont quand même déjà ajouté NSDocument et NSDocumentController.
[^] # Re: Havoc Pennington se pose des questions les langages du libre
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
Apple peut rajouter des specs à OpenStep, étant propriétaire.
Si GNUstep se rapproche trop d'eux, ils pourront facilement allourdir les specs de manière à limiter la compatibilité, en se basant sur la lenteur de développement (par rapport à la leur).
[^] # Re: Havoc Pennington se pose des questions les langages du libre
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
Par contre pour cocoa, je ne crois pas m'être trompé, car la doc du framework se trouve sous cocoa sur le site d'Apple.
[^] # Re: Havoc Pennington se pose des questions les langages du libre
Posté par nicolassanchez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 4.
C'est un langage très rapide, très évolué et comparable (à mon avis) à Java et à .NET.
Avec cependant un gros avantage : il possède un framework éprouvé, simple à utiliser et complet sans être trop lourd (ce framework c'est GNUstep, qui répond aux specs OpenStep, comme Cocoa de MacOS X).
[^] # Re: Guide des prestataires
Posté par nicolassanchez . En réponse à la dépêche Guide des prestataires. Évalué à 4.
[^] # Re: Captures d'ecran cliquables
Posté par nicolassanchez . En réponse à la dépêche Gtk+ 2.4.0 est sorti. Évalué à 1.