caelacanthe : je ne sais plus quel est le soft fourni par défaut à la place de Gimp sous Ubuntu pour "le dessin", mais c'est forcément mieux que Gimp. De toute façon, un mec qui a vraiment besoin de Gimp saura trouver ce paquet et l'installer en 30 secondes. Quand au monsieur lambda (et pour une fois ça s'applique à moi), il pourra enfin faire 2-3 modifs basiques comme découper un morceau d'image sans s'y reprendre à 5 fois.
Quant au nombre de logiciel, une dizaine suffisent : gestionnaire de fichier, navigateur web, messagerie instantannée, client mail, visionneur de vidéos, lecteur de musique, éditeur de texte, éditeur d'images, gestionnaire de paquets, émulateur de terminal, gestionnaire de téléchargement (torrent). En gros, j'ai à peu près fait le tour.
Pourquoi ? Est-ce que des langages comme C# ne te vont pas ? On ne perds quasiment pas de performance avec le JIT compiling (il y a même des papiers qui vont dans le sens d'un possible gain de performance (je ne dit pas pour .NET, mais pour du JIT compiling en général) grâce à des possibilité d'optimisation inconnue à "compile time"). Et ces perfs sont largement compensé par les facilité de manipulation des programme, des dll, etc.
Un compilateur AOT peut se permettre bien plus de passes qu'un compilateur JIT
Y'a qu'a voir OCaml, dont on sait tout le bien que j'en pense, mais dont la compilation est assez fastidieuse à gérer.
Il n'y a théoriquement pas d'incompatibilité à avoir les facilité d'un langage managé avec un programme compilé, mais, en pratique, on ne le voit jamais.
D'ailleurs, rien ne t'interdit de précompiler les programme .NET si tu veux améliorer un peu le temps de chargement (mais il faut toujours démarrer le framework).
Et là tu as un langage à haute productivité, compilé. Si tu considère que le framework est déjà de trop, dis toi que c'est précisémment lui, avec les bibliothèques et le GC qui font de C# (ou autre) des langage à haute productivité, et que c'est le cas de tout langage de ce type.
Donc je ne vois pas trop ce que tu cherche comme genre de langage (ou ce que tu reproche à C# et Cie).
Oups, mon message ci-dessus a été posté contre ma volonté alors que je le rédigeais, je reprends :
Pourquoi ? Est-ce que des langages comme C# ne te vont pas ? On ne perds quasiment pas de performance avec le JIT compiling (il y a même des papiers qui vont dans le sens d'un possible gain de performance (je ne dit pas pour .NET, mais pour du JIT compiling en général) grâce à des possibilité d'optimisation inconnue à "compile time"). Et ces perfs sont largement compensé par les facilité de manipulation des programme, des dll, etc.
Un compilateur AOT peut se permettre bien plus de passes qu'un compilateur JIT qui est tenu d'assurer une certaine réactivité malgré tout. A part ça j'ai récemment du écrire une routine à la fois en java et en C++ pour comparaison (clustering multi-thread). Malgré toutes mes connaissances en java (j'en fait depuis 6 ans) je n'ai pas pu battre la version C++ qui restait 1.6x plus rapide et nettement moins gourmande en mémoire.
Les JVM sont certes très optimisées (hotspot et autres), mais sur des algos de calcul ça ne bat pas du code natif. La faute aussi et surtout aux tests effectués automatiquement par le runtime.
""D'ailleurs, rien ne t'interdit de précompiler les programme .NET si tu veux améliorer un peu le temps de chargement (mais il faut toujours démarrer le framework).
Et là tu as un langage à haute productivité, compilé. Si tu considère que le framework est déjà de trop, dis toi que c'est précisémment lui, avec les bibliothèques et le GC qui font de C# (ou autre) des langage à haute productivité, et que c'est le cas de tout langage de ce type.
Ca amène au moins autant de problèmes que ça en résout, de plus tu devrais normalement relancer cette compilation sur la machine utilisateur au moindre changement d'environnement ce qui est très contraignant dans la pratique.
""Donc je ne vois pas trop ce que tu cherche comme genre de langage (ou ce que tu reproche à C# et Cie).
Quelque chose comme D, qui possède les avantages des langages managés en terme d'écriture de code, mais qui laisse le développeur réaliser beaucoup d'optimisation et se passer de GC pour certaines parties de son code s'il le désire.
Pour parler de ce qui existe, il y a d'excellents toolkits en C++ tel que Qt qui proposent un écosystème de librairies complet et cohérent, des outils RAD, un système de test unitaire etc... Grâce au pattern copy-on-write de ses objets, tu peux te décharger de 95% des problèmes de fuites de mémoire et ça reste du C++, donc un langage compilé.
Son problème est malheureusement que... c'est du C++. Donc double déclarations chiantes pour les classes, pas de properties, langage long à compiler parce qu'extrêmement dur à parser etc...
«Quand au monsieur lambda (et pour une fois ça s'applique à moi), il pourra enfin faire 2-3 modifs basiques comme découper un morceau d'image sans s'y reprendre à 5 fois.»
T'es pas doué, n'accuse pas le logiciel. La découpe d'image se fait littéralement en quatre clics avec GIMP
Un clic pour glisser-déposer l'image à manipuler sur l'icone de gimp.
Un clic sur l'icone de l'outil découpe.
Un clic pour tirer une sélection rectangulaire.
Un clic dans la sélection pour confirmer la découpe.
L'apanage de monsieur lambda, c'est qu'il est pétri de mauvaise foi.
moi non plus, je ne le sais pas: je ne l'ai pas trouvé
il est vrai que Gimp requiert un peu d'habitude! mais une fois qu'on a le coup de main...
je vois pas ce qu'ils ont pu mettre à la place du gimp pour continuer d'avoir une archive pleine à craquer. Les thèmes graphiques? J'ai été choqué en arrivant sur le bureau, tous ces trucs transparents, ce look vista
https://www.jeuxvideo.com/forums/1-47-48815-1-0-1-0-cam-msn-fonctionne-plus.htm
d Les gens qui postent ce genre de trucs, je présume que c'est les même qui viennent me voir en disant "Tiens t'es développeur ? Tu bosses dans l'informatique donc ! Tu pourrais pas m'aider j'ai un problème avec mon PC..."
Tu oublies le "tu as msn?" :P
Je suis bien content de ne plus avoir MSN perso.
"GCC begins move to C++"
https://lwn.net/Articles/390016/
Ca va sûrement simplifier pas mal leur base de code s'ils développent effectivement en C++ sans utiliser des artifices C bien dégueulasses.
Ça va bien simplifier la vie des gens qui font de la cross-compilation et qui auront encore plus de mal de bootstraper.
"# Ca va sûrement simplifier pas mal leur base de code s'ils développent effectivement en C++ sans utiliser des artifices C bien dégueulasses. "
Tu parle, ça vas sûrement augmenter le nombre d'extensions infâme du C++ dans gcc qui seront implémentées juste pour leur permettre de mettre des horreurs dans le code du compilateur lui même.
Apparemment, ils prévoient de se restreindre à un subset assez réduit de C++98, genre encapsulation, héritage, polymorphisme... juste assez pour s'y retrouver et pas plonger dans l'infâmie.
AMHA, il y a bien assez de conservateurs dans le développement de GCC pour que les gardes-fous soient solides et teigneux.
AMHA, je m'en fout parce que gcc c'est tellement bullshitesque que je vais bientôt cesser de l'utiliser au profit de tcc pour les petites tâches quotidiennes et clang/llvm pour le gros œuvre.
#
Tu parle, ça vas sûrement augmenter le nombre d'extensions infâme du C++ dans gcc qui seront implémentées juste pour leur permettre de mettre des horreurs dans le code du compilateur lui même.
J'ai pas beaucoup de recul sur g++ que j'utilise peu (trop lent, outil gdb à la rue etc...), mais il était quand même assez repectueux des standards à ce que j'en sais non?
Pour moi s'ils renoncent aux héritages multiples et profitent simplement des bienfaits de base de la POO (encapsulation, gestion des ressources au moyen de destructeurs etc...), ça doit pouvoir simplifier leur base de code par rapport à du pur C.
Ce qui va plutôt faire souci c'est qu'un excellent programmeur C est pas forcément un bon programmeur C++.
"J'ai pas beaucoup de recul sur g++ [...], mais il était quand même assez repectueux des standards à ce que j'en sais non? "
C'est pas le pire de ce point de vue. Mais ça n'empêche pas qu'il implémente plein d'extension pour le langage. Elles peuvent être désactivées si on veut faire un programme "standard" ou elles peuvent être activées. En ce moment il y a surtout des tas d'extension pour le C, généralement parce qu'elles sont utilisé à un endroit ou à un autre dans gcc. Si le compilo est re-codé en C++, j'imagine qu'ils vont inventer plein de nouvelles extensions pour le C++.
Ce qu'il y a maintenant,
pour le C : http://gcc.gnu.org/onlinelinedocs/gcc/C-Extensions.html
pour le C++ : http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Extensions.html
struct maStruct {
char debut:4, fin:4;
}
C'est du C standart?
$ gcc -std=c99 -pedantic -Wall -Wextra -c a.c
a.c:2: warning: type of bit-field ‘debut’ is a GCC extension
a.c:2: warning: type of bit-field ‘fin’ is a GCC extension
J'aurais tendance à dire que non.
heu... de memoire, c'est dans mon K&R ce truc la ! mais je n'ai pas mon K&R sous la main pour verifier.
À ma connaissance, le seul truc standard qui ressemble c'est :
struct toto t = { debut:4, fin:4 };
pour déclarer/initialiser une structure en C++ (et il faut mettre tous les champs, contrairement au C).