TImaniac a écrit 6423 commentaires

D'ailleur on est sur LinuxFR, et F-Spot, Tomboy, GnomeDo, Banshee & co ont été codés avec mono uniquement à cause de la compatibilité avec .NET, tous ces logiciels tournant outofthebox sous Windows et n'ayant aucune dépendance à Gnome.

On parle de la doc de .NET, qui elle est relativement complète et bien rangée.

un petit bout de cython
C'est pas du Python, c'est un autre langage, même si la syntaxe est la même. Pérénité sur le long terme inconnue, portabilité limitée.

fait du cython et le probleme est "presque reglé".
Avec généricité & co ? Et tous les avantages que procurent le typage statique aux outils de développement (y'a pas que le compilateur : IDE, refactoring & co) ?

je ne pense pas que le passage de l'etape de "compilation/check des types" soit une securité.
c'est une sécurité. Certainement pas suffisante, mais ca en est une.
Les tests unitaires en sont une autre, les 2 sont complémentaires et l'un ne remplace sûrement pas l'autre.

Pour LINQ, c'est encore subjectif, mais en pratique c'est quelque chose qui se reecrit en python pur en peu de temps grace au generateurs et autres.
Tu comprends pas. LINQ, c'est de combiner tous les avantages d'un langage de requêtage comme SQL avec les avantages d'un langage typé statiquement.
En C# si j'écris :
var artists = from album in database.GetAlbums()
where album.Name.StartWith("The")
orderby album.Name
select album.Artist;
foreach(var artist in artists)
Console.WriteLine(artist.toto); //erreur, la propriété toto n'existe pas !

le compilateur fait de l'inférence de type et ma variable ids est une suite d'objets du même type que Artist. Le typage est conservé et si je manipule cette liste, le compilateur peut me renvoyer une belle erreur à la compilation, et pas durant l'exécution d'un hypothétique test unitaire.
De plus ca permet à mon IDE de me proposer instantanément la liste des propriétés de mon objet artist quand je tapes "artist.".

T'auras beau reproduire l'API en Python, comme tu peux le faire en C# ou Java d'ailleur, tu n'auras pas l'intérêt principal qui est l'intégration dans le système de typage.

ce n'est pas explicite et c'est trop magique
Quand t'as la complétion, c'est explicite. LINQ est intégralement codé en méthode d'extensions et tout le monde est content de pouvoir utiliser LINQ sur ses listes d'objets traditionnelles.

par contre c'est faisable en ruby, en python
Là encore, les méthodes d'extensions permettent avant tout de conserver le typage statique, ce qui n'est pas le cas en Ruby ou en Python.

cela existe aussi en python
Non, le service peut être rendu à l'aide d'autres outils ou langages comme cython ou JNI, mais ce n'est pas proposé par Python.

Ce qui fait la force de C#, c'est son côté tout terrain, qui fait qu'il n'est sûrement pas le meilleur dans un domaine, mais cela en fait souvent un bon compromis.

L'argument de départ était qu'une VM c'est pratique, parce qu'on est facilement multiplateforme tout en ayant une forme de code assez bas niveau. Ce qui permet de "cacher" les sources.
Non, l'argument est de dire qu'une VM a pour principal objectif de faciliter le déploiement de binaire, problématique lié au proprio avec son besoin de distribuer des binaires; et dire que le libre n'a donc pas besoin de VM puisqu'on distribue des sources.

Moi je montre 2 choses :
- le bytecode permet de retrouver une bonne partie du code source, ce qui enmerde certains industriels, d'où le succès des obfuscateurs de bytecode.
Avant un distributeur de soft proporio proposait plusieurs binaires si plusieurs architectures en gardant le code source caché, maintenant il n'en déploie plus qu'un, au prix d'un code source moins caché (bytecode), à moins d'utiliser un soft pour le rendre plus obscure.
- la problématique de déploiement de binaire est également présente dans le libre, c'est la forme la plus généralement utilisée par les grandes distributions linux. Techniquement, ce qui est intéressant pour le proprio l'est aussi pour le libre, ce sont des atouts "techniques", pas politiques.

j'ai quand même du mal à croire qu'il n'y a pas un "gentil dictateur"
Python a son gentil dictateur : http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life

Ben la logique est simple : le bytecode ne va pas dans le sens de "cacher" du code propriétaire, au contraire (ce que j'essai de montrer). La preuve, les softs d'obfusction ont dû débarqués pour colmater en partie la brèche.

Dans la "recherche" ?
Ils cherchent où ? sur google ?

http://www.google.fr/search?hl=fr&q=.net+obfuscator&(...)

http://www.google.fr/search?hl=fr&q=java+obfuscator&(...)

Ca existe depuis des années.

Alors arrêtons d'utiliser tous ce qui est cité sur cette page, la problématique est là même :
http://www-03.ibm.com/linux/ossstds/isplist.html
Y'a des petits trucs intéressants pourtant, mais bon le développement ouvert de LL avec ces standards n'est pas possible : OpenDocument, XML, DITA, UDDI, SOAP, XQuery, XSL, etc.

J'ai python, j'ai QT (ou gtk), pourquoi devrais-je utiliser Mono ? Cela m'apportera il quelque chose ?
Apprend à lire, c'est argumenté plus haut.

Je veux un langage relativement performant parcque mon application fait un minimum de traitement : C# est plus rapide que Python.

Je veux une documentation complète : C# est mieux documenté que Python.

Je veux un langage dont la pérénité est assurée : du code C# 1 est toujours compatible avec C# 3, le langage est standardisé.

Je veux un langage "sûr" avec typage statique qui me permette de faire du refactoring sans devoir prier pour que mes hypothétiques tests unitaires couvrent bien l'ensemble du fonctionnel : C# est bien meilleur que Python.

Je veux un langage avec des fonctionnalités évoluées de requête parcque je manipule beaucoup de données, je prends C# 3 parcqu'il a LINQ que Python n'a pas.

Je veux un langage qui me permette à l'occasion d'avoir de bonnes performances sans me taper du code natif : je prends C# parcque je pourrais ponctuellement utiliser les pointeurs.

Je veux un langage qui me permette d'étendre des types sans utiliser tout en gardant les avantages du typage statique : je prends C# avec les méthodes d'extensions.

Je veux un langage qui me produit des binaires compatibles avec d'autres langages simplement : je prends C# qui me permet de produire des composants réutilisables en VB.NET, en C++/CLI, en IronPython, en Boo.

C'est le problème quand la documentation est plus complète, il faut ajouter des niveaux de classement supplémentaire.
Regarde la doc de split :
http://java.sun.com/javase/6/docs/api/java/lang/String.html#(...)
http://msdn.microsoft.com/fr-fr/library/b873y76a.aspx
Tu vois la doc de MS sur une seule page comme le fait Sun ?
Regarde la doc de Python sur la même fonction, tu verras que y'a même pas besoin de sommaire tellement c'est succinct :
http://docs.python.org/library/stdtypes.html

A peu prêt aussi osé que de comparer le risque qu'il y a à utiliser F-Spot par rapport au fait de jouer avec un bûcher.

Sauf que pour beaucoup d'applications, ce que cherche un développeur c'est pas la peformance, c'est le meilleur compromis entre performance et pleins d'autres trucs :
- simplicité
- sécurité
- compatibilité
- popularité
- support
- fun
- etc.

Si nos ancètre n'avaient jamais eu les couilles de jouer avec le feu, je sais pas où en serait la civilisation aujourd'hui.

Python[...] il est évident que tu a besoin d'une VM.
C# ou de Java[...] tu n'a pas fondamentalement besoin d'une VM.
Tu peux compiler du Python.
Tu peux interpréter du C# ou du Java (ce dernier a d'ailleur été conçu dans cet optique initialement).

Je pense que ça vient en partie d'un raisonnement qui a court dans le monde du logiciel propriétaire et qui est "comment faire tourner mon beau binaire chez le maximum de clients".
C'est une problématique qui existe aussi dans le logiciel libre faut pas croire. La plupart des distributions Linux populaires sont fournies sous la forme de binaires.
Et c'est sûrement pas une partie de plaisir de fournir des ressources supplémentaires (temps, CPU, espace disque) afin de compiler les softs pour différentes architectures (ex : Debian).
Sans parler de l'embarqué.
Avoir accès aux sources ne veut pas dire que c'est le moyen numéro 1 de distribuer un logiciel libre.

Comparons alors, prenons la classe string, en Python, Qt et .NET :
http://docs.python.org/library/stdtypes.html#string-methods
http://doc.trolltech.com/4.5/qstring.html
http://msdn.microsoft.com/fr-fr/library/system.string_member(...) (faut cliquer sur chaque méthode pour avoir les exemples et tout). Et en français s'il te plaît.

Y'a un 3ème mode pour mono/.NET/GCJ :
code source -> bytecode -> code natif -> exécution.

Pas plus qu'un backend de compilateur avec un langage inteermédiaire (llvm ?)
Forcement, c'est une VM.

endian/big endian ne pose problème qu'avec les layout de fichier.
Oui, c'est un problème. http://www.ibm.com/developerworks/aix/library/au-endianc/ind(...)

Si tes threads n'étaient géré que par la VM tu aurais de gros soucis de perf....
Et ? Je parle d'abstraction, dessous y'a du code natif et les threads de l'OS, c'est bien le but.

Faire abstraction de la machine, c'est aussi fournir des services qui ne sont pas offerts en natif : introspection, gestionnaire de mémoire, protection contre les débordements, contrôle fin des droits d'exécution (sandboxing & co), interopérabilité entre les langages de programmation, gestion des exceptions.
Une VM facilite aussi la création de nouveaux langages en proposant de base tous ces outils.
C'est aussi faire abstraction des incompatibilités de la machine qui peut casser mon soft en C recompilé : 32 vs 64 bits, litle-big endian, etc.
C'est aussi faire abstraction des incompatibilités de l'OS : gestion des threads notamment.
C'est aussi utile dans des situations ou recompiler n'est pas une option : déployer une applet web par exemple ou bêtement exécuter du javascript sans utiliser d'interpréteur.

Le coup du "c'est nécessaire pour le proprio qui cache les sources" est un mauvais argument, bien au contraire : ce type de VM a une sémantique bien plus proche du langage utilisé dans le code source : un coup de décompilateur permet de retrouver le code source dans un format proche de l'original (sans les commentaires forcement).

Un peu comme IBM envers OpenDocument & co :
http://www-03.ibm.com/linux/ossstds/isplist.html
""Covered Implementations" are those specific portions of a product that implement and comply with a Covered Specification and are included in a fully compliant implementation of that Covered Specification

Parcque le runtime offre c'est un bon compromis niveau performance / fonctionnalité comparé à C/C++ ou Python/Ruby.
Parcque le support multi-langages est bien intégré (IronPython, Boo & co)
Parcque le langage (C# 3) est bien plus cool et avancé que Java (LINQ, expressions lambda, event, méthodes d'extensions, etc.)
Parcqu'on peut réutiliser ses compétences Windows.
Parcque la compatibilité avec Microsoft assure une large documentation et l'accès à de nombreux outils et bibliothèques tierces, bref de quoi séduire les développeurs.
Parcque mono intègre tout ce qui faut outofthebox pour développer une application Gnome.
Parcque la communauté de developpeurs est très réactive, notamment face aux bugs.

Evidemment tu trouveras beaucoup de ces atouts ailleurs, mais tout réunis ca fait une plateforme sexy.

http://www.ikvm.net/

Ben ca dépend des SSII. Chez nous c'est pas 80% en tout cas.

Tu connais beaucoup de boîte d'intérim qui réalise des projets au forfait dans leurs locaux ?

Simple et ca marche :)
Encore merci !

oui c'est bien un emu10k1.
Je vais regarder asfxload et aconnect.
Merci !