Octabrain a écrit 1689 commentaires

Boost n'est pas la standard lib malheuresement. Wikipedia dit qu'une partie en fera peut-être partie dans C++0x, ce sera donc peut-être en partie le cas un jour.

Et moi je pense - et je peux me tromper, mais depuis un moment on n'arrive même pas à s'accorder sur la nature du sujet duquel on parle, donc pour discuter le vrai contenu... - que, sur la somme des développements actuels, tous domaines confondus, et proportions gardées, fortran est marginal.
Ces 2 liens suivants ne font que rapporter la quantité de discussion autour des langages de programmation sur internet, ce n'est pas une preuve, mais ça vaut un peu quand même : http://langpop.com/ et http://www.tiobe.com/index.php/content/paperinfo/tpci/index.(...)

Mais bon sang, j'ai pas dit "embarqué", j'ai dit "tous domaines confondus".

Ah, tu ne veux pas reconnaitre qu'elle est tellement imprécise qu'il est impossible de discuter ?

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...