Octabrain a écrit 1685 commentaires

Non, je parle tous domaines confondus, mais forcément tu refuses de considérer cette situation, elle te donnerait tort.

SELinux c'est POSIX ? Non, alors ne donne pas de leçons de portabilité...

Ah oui, "yaka utiliser une lib"... Non, ça devrait être géré de base dans un langage pas préhistorique.
Il n'y a pas de convention entre les libs de smart pointers, les libs d'introspection, les libs de protection de débordements, etc. Cela impose d'apprendre chacune des libs que tu viendras à rencontrer (et qui pourtant auraient le même rôle, entre 2 libs de smart pointers par ex). Et tu risques vite de te retrouver à utiliser plusieurs de ces libs équivalentes à la fois dans un même programme (par exemple ton prog utilise libsmartfoo, et tu utilises libtoto qui n'a rien à voir, mais qui elle utilise libsmartbar), bonjour l'intégration, la cohérence, et la simplicité (bonjour les bugs aussi)...
Devoir passer par des libs impose aussi que tu n'oublies jamais de l'utiliser en permanence (pour chacun de tes pointeurs pour une lib de smart pointers).

? Tu vas me dire que fortran est le langage majoritairement utilisé aujourd'hui ? N'hésites pas, tu n'es plus à une connerie près.

Je ne faisais que répondre à ton affirmation (fausse). "Il est évident que", ben non c'est pas évident.

Sans binaire ? Avec des définitions aussi simplistes, le C aussi est un langage de script : http://bellard.org/tcc/tcc-doc.html#SEC4 (option -run).
T'as pas une définition un peu mieux de ce que t'appelles un langage de script ?

Plus bas, j'ai dit en gros que C et C++ étaient bien trop utilisés dans des cas injustifiés.

J'ai dit "mort", j'aurais du dire "marginal".

Sauf que C (les 2 autres ils sont morts) (et éventuellement C++) sont encore utilisés dans des cas injustifiés, et c'est un problème.

Là, tu parles de ton cas précis, c'est tout de suite moins objectif et ça permet de tirer moins de conclusions malheureusement.

Pas convaincu, pour cet exemple, la doc MSDN est beaucoup trop verbeuse :
- le topo sur les perfs de la doc MSDN me semble inutile (pas que j'aime pas quand ça parle de perf, mais là ils ne font que dire des trucs à peu près évidents dont n'importe quel programmeur pas trop con se serait passé)
- pas mal d'exemples sur la doc MSDN ne servent complètement à rien
Le truc en plus de MSDN pour cet exemple, c'est le listage des caractères par défaut du split.

A cause du poids de l'existant ? Parce que la plupart des gens sont frileux ?

Personnellement, je navigue bien mieux dans la Javadoc que dans la doc MSDN, je trouve que les hyperliens et la structure des pages sont mieux pensés.

Pour comparer :
http://java.sun.com/javase/6/docs/api/java/lang/String.html
http://msdn.microsoft.com/fr-fr/library/system.string_member(...)
Sur la page MSDN, on doit suivre un lien pour ne serait-ce qu'obtenir les paramètres et le retour d'une méthode, et de là, pas d'accès à la documentation des types des paramètres pour MSDN.

C'est vachement futé de démarrer exactement le même thread ("pourquoi c# ?") à plein d'endroits différents...

C'est pas mal trollesque ce que tu dis là. Nul doute que tu seras plussé.

Merci de ta participation passionnante !

"Dans le cas de Python, qui est un langage de script (donc interprété) il est évident que tu a besoin d'une VM."
Pas vraiment, on ne parle pas de VM pour le shell (qui est du script je suppose) que je sache.

"J'espère que je me suis mieux expliqué cette fois."
On avait très bien compris, et on a déjà répondu.

Il n'est pas compilé ? Au contraire, il est recompilé en interne à chaque fois.
D'ailleurs, il suffirait de rajouter un petit patch pour pouvoir mettre quelque chose comme "#!/usr/bin/javac ; /usr/bin/java" au début de ton .java

T'exclue ce qui t'arrange, d'ailleurs comment définirais-tu "langage de script" ?

Il suffit d'utiliser la bonne class de gestion du soucis dans le langage en question
En français ça donne quoi ?
Ah, et sinon, tu ne réponds pas à toutes ces interrogations.

Quand on veut pas comprendre, c'est de suite plus facile...

Je vais réécrire ce que j'ai écrit puisque tu n'as pas bien lu :
Actuellement, dans les langages multiplateformes sans VM populaires

Le seul avantage de Tk, c'est qu'il est dans la lib standard de Python. Ses inconvénients : bibliothèque très limitée, façon de programmer les interfaces très "années 90", laideur innommable à faire mourir un yéti.

Quel est vraiment l'intérêt d'avoir ces lourdes machines virtuelles qui exécutent du bytecode sur différentes archis ?
Dans le monde du libre, comme le code source est disponible, on en a rien à battre d'avoir cet environnement qui fait abstraction de l'archi ! Dans le libre on prend le source et on le compile directement c'est tout.
Oui, arrêtons aussi tous les langages de script, c'est une honte pour le logiciel libre.

Actuellement, dans les langages multiplateformes sans VM populaires, n'a-t-on pas uniquement des langages préhistoriques, sans véritable gestion automatisée et intégrée de la mémoire, avec des problèmes de taille différente de nombres et d'endianess selon la plateforme, avec des horreurs sur les pointeurs à portée de main, etc. ?

Pour les débutants il n'y a pas plus facile que Python/QT ou Python/GTK. Mono nécessite de comprendre tout un tas de concepts ainsi qu'un environnement de dev particulier avec compilateur et toute l'artillerie.

Quelle putain de subjectivité... (comme la comparaison Qt/GTK vs. Mono de patrick_g)