TImaniac a écrit 6420 commentaires

Ah oui tiens si tu es fan de la syntaxe Python, essai une variante typée statiquement et plus performante : Boo.

Parcque QT c'est une bibliothèque, accessible depuis de nombreux langages. Hors le débat n'est pas sur le choix d'une bibliothèque (auquel cas on serait retomber sur un troll GTK/Qt/wx&Co), mais les langages.

comment c'est possible, vu que les libs natives ne le sont pas... Oui alors c'est moi qui n'ait rien compris ;)
Ben avec Mono par exemple, tu peux wrapper OpenGL, et ce sera les mêmes binaires que tu redistribueras sous Linux et Windows. Evidemment OpenGL sera spécifique, mais ton bytecode sera parfaitement portable. Le gros avantage c'est aussi d'assurer l'intégration dans le langage C#, et donc d'avoir toutes les vérifications de type du compilateur et aussi la sécurité d'exécution qui va avec.

arghhh ... cassé ... tu m'as eu ... brice ...
:-p

non, mais on peut en dire de même pour le produit généré par mono, ou dot.net ...
Sauf que Mono/.NET est conçu pour être compilé en natif, ce que fait l'environnement d'exécution. Bref, je reste sur mon affirmation, Python/Ruby ne sont pas compilé en natif de manière multiplateforme. Seule Psycho se rapproche de l'idée, en perdant la portabilité (et donc une partie de l'intérêt).

os, string, ... bref toutes les libs faisant partie de "python"
C'est pas la question.
En C#, je peux déclarer :
[DllImport("opengl")]
public static extern void FonctionNative(string arg1, int arg2);
C'est intégré au langage, c'est compilé en code managé, c'est donc portable sans modification et sans avoir à utiliser le langage intermédiaire.

Bref, t'es cassé sur toute la ligne :)

Oui c'est effectivement en bonne partie du au typage, qui empêche Python d'avoir par exemple une gestion du versionning. Bref, c'est pas pareil, et y'a bien de grosses différences, cqfd.

Microsoft aurait pu se joindre au Java Community Process
Non. Microsoft avait juste des objectifs différents, à savoir l'intégration avec l'existant : technos COM/ActiveX, MFC, etc. Microsoft a avant tout fait un produit pour ses clients existant, et Java ne répondait mais alors pas du tout à ces objectifs.

Microsoft aurait pu se joindre au format OpenDoc mais préfère promouvoir son propre format.
Microsoft a là encore dû assurer la "compatibilité" avec l'existant : le dernier format Office sera backporté dans les précédentes suites Office, et sera capable de supporter les mêmes informations. Le format OpenDocument ne répondait pas là non plus à cet objectif.

Visual Studio 2005 pond du XHTML correct il me semble.

les "génériques" (terme pompeux de crosoft) sont nativement dans python depuis des lustres (cf ses propriétés de typage dynamique)
Ahahaha. Les génériques ont justement l'avantage de proposer un typage statique pour éviter d'éventuelles couilles à l'exécution et au passage améliorer les perfs. Alors en Python je vois mal, mais alors très mal comment tu vas t'y prendre. Mais vas-y montre moi puisque t'y crois :)
Allez, propose moi par exemple un morceau de code qui me déclare une pile d'entier, et uniquement d'entier. Bien sûr l'implémentation de la pile est générique.

python compile aussi le py en pyc, c'est natif et multi plateforme ...
"pyc is a compiler that compiles python source code to bytecode"
T'as un processeur qui interprête le bytecode Python en natif toi ?

c'est une différence, mais est-ce un avantage ?!?
Là n'est pas la question. C'est en tout cas une grosse différence.

Appels bibliothèques natives multi-plateforme et intégré au langage
en python aussi ... non ? ;-)
Non. Ou alors j'ai jamais vu. Mais je veux bien que tu me montres encore une fois :)

Python n'a peut être pas toutes les diff que j'ai cités, mais il en a la plupart.

Pour le moment je trouve que python est un bon choix !
Tes choix sont vraiment incompréhensibles :
- tu précises ne pas vouloir d'interprété.
- je te propose Java
- tu veux pas non plus de VM
Conclusion : tu te penches sur Python qui utilise à la fois une VM et qui est interprété (????)

http://www.mono-project.com/Guide:Running_Mono_Applications
Limitations ? Que sous Linux, et n'embarque pas Gnome :) Permet en tout cas d'exécuter une appli sans avoir Mono et ses libs d'installé.

C# reprends les delegates je crois, avec une decennie -au moins- de retard
En même temps les delegates c'est les pointeurs de fonction ala C, c'est pas une innovation qui tue :)
Et puis Objective-C utilise un environnement d'exécution, et visiblement ca ne répond pas aux critères.

La BDD est là pour stocker les données et pour faciliter les requêtes. Elle n'est pas là pour combler les faiblesses du langage et faire office de couche métier. Alors quand y'a un problème de perf, non, ne pas déléguer plus de tâches au moteur de bdd. Tous les moteurs de bdd ont une limite, et il y aura un moment où tu ne pourras plus passer à l'échelle. D'où l'intérêt de choisir un langage adapté pour la couche métier, qui propose des services spécifiques lorsqu'on s'attend à avoir beaucoup de données à traiter. Je te laisse deviner lesquels choisir, c'est simple, il suffit de voir ce qui se fait autour de toi.

Des différences ? En voilà :
- Méta-données
- Génériques
- Evénements
- Compilation native multi-plateforme
- Typage relativement fort et statique
- Appels bibliothèques natives multi-plateforme et intégré au langage
- De meilleurs perf sans sacrifier la portabilité
- Le versionning des composants
T'en veux d'autre ?

Tant qu'à faire, autant choisir l'original (donc Java) et pas le clone, qui s'est appuyé sur les bonnes idées de Sun pour ré-inventer la roue :-)
Comme si Java avait inventé quelque chose... En s'appelant C#, Microsoft a au moins le mérite d'avoir choisi de rappeler l'origine du langage.

Certains pensent que c'est pas la panacée niveau beauté du code, perso je trouve que c'est un excellent compromis pour ne pas se coltiner des XML de mapping à la main.
Ahahah, le coup des méta-données pour faire du mapping... Ils l'ont piqué sur qui Java déjà ? :-p

Bon bah lache l'affaire. Sachant que tous les langages modernes ont besoin d'un environnement d'exécution pour proposer des services de sécurité et d'abstraction, il ne te reste plus grand chose. Désolé, mais c'est pas en s'arrêtant à l'origine d'un langage que tu vas réussir à faire des choix pertinents en informatique (à mon sens). Bon ben il te reste plus que le C/C++, c'est vieux, c'est pas productif, mais ca marche et c'est performant. Amuses toi bien :)

Et ?
Avec Mono tu peux faire un binaire standalone qui inclu tout ce qu'il faut sans rien de nécessaire au préalable.

C# ou Java.
C'est pas interprété, c'est multi-plateforme et c'est plus moderne (et plus productif surtout) que C/C++.
Ma préférence : C#.
http://monofrance.free.fr

Il swappait comme un malade sans raison
Dis plutôt que tu ne sais pas pourquoi il swappait. Il avait sûrment ses raisons.

Vu que tout les dégroupés en bénéficient, on peut supposer que ce n'est pas problématique pour Free.
Les dégroupés sont tout simplement prioritaires.

Apparemment, toutes les freebox ont un IP fixe
Faux. N'ont une adresse IP fixe que les lignes dégroupées (Freebox ou pas, là n'est pas la question). Pour les lignes non dégroupées, les adresses IP fixes sont distribués au compte goutte parcque justement c'est pas si simple d'en filer à tout le monde et qu'il faut les commander.

Ce qui d'ailleur est assez studpide, dans un même framework distribué par un même éditeur, filer 2 classes dates différentes c'est moyen. Mais bon c'est pour l'exemple :)

Bref, c'est moins un résumé des améliorations intra-communautaire qu'un communiqué d'un service de vente.
C'est pas faux. Pour un résumé intra-communautaire, cela va peut être te convenir :
http://tirania.org/blog/archive/2005/Nov-17.html
Peut être qu'une traduction va suivre :)

MDI a un haut poste technique dans la boîte et a de ce fait une vue assez globales, comme il le fai très bien remarqué dans l'interview d'ailleur :)

Oué j'ai hésité, mais bon j'ai eu la flemme :) Cela dit si j'ai rien à faire demain soir je m'y collerais.

Ah non, Novell fait parti du consortium de normalisation à l'ECMA et a son mot à dire.
Et les spécif de .NET (tout comme les brevets virtuels toujours pas validés) sont depuis le départ coécrites par HP, Intel et MS. Donc même en amont MS n'est pas seul à décider.

Vi enfin le travail ne doit être fait qu'une fois, ca reste automatique comme processus... Qt# est pas écris à la main de A à Z :)
Pour les slots :
"Connecting and disconnecting C++ signals and slots requires some additional C++ support code. The code is contained in libqtsharp. The mechanism used in libqtsharp is a bit cumbersome. However, at the time it was created, it seemed the only way to interact with signals and slots without hacking into the undocumented and possibly non-portable sections of Qt's Meta-Objects."