Bah le truc c'est que j'avais déjà entendu parler du D comme d'un "C++ amélioré", et comme j'en avais jamais entendu reparler et donc j'ai vu que c'était pas si mainstream que ça (oui, j'ai un très gros coté hipster ) je me suis dit que m'y mettre serai une bonne idée. Et pour l'instant ça m'a l'air assez logique. Pour l'instant.

D'ailleurs G_B, tu as pris en compte ce que je t'ai dit en MP ? Si t'as pas le temps pour le moment, ou que t'as juste pas envie, c'est pas grave

Runny Ah bah moi je commence la bas-niveau avec le C++.
Mais je me suis également intéressé à D et à Rust, je me suis dit que j'allais regarder à côté quand j'aurais terminé la partie "théorique" de C++ (et sans le savoir une grande partie de C).

Mais comment ça se passe pour les bibliothèques tierces sur des langages tels que D ?

Runny j'ai lu mais pas encore fait non (mais ça me coûte rien donc je peux le faire hein ), là je suis juste un peu occupé à d'autres trucs

C++ amélioré, ça sonne de travers dans ma tête. Je veux dire le C++ est très pur et bien foutu, je ne vois pas ce qu'on peut vouloir changer dessus sans le bloater comme jamais

Wonderfall euh... C++ & bas niveau? Ya un truc qui sonne faux là aussi

Quoi ??? Bon alors moyen-niveau ?
Bien sûr rien à voir avec de l'assembleur.

Mais un peu plus complexe que les langages interprétés dans la syntaxe.

Ah sinon j'ai également commencé sur TI-Basic, je trouve ça très bien pour commencer, même si c'est des programmes rudimentaires.

En même temps les trois quarts des langages interprétés auxquels je pense visent un public de singes savants (grand maximum), donc faire plus simple ça devient compliqué (ya bien la programmation "visuelle" avec des langages graphiques... mais là je préfère même pas en parler tellement ça m'énerve ).

C++ c'est du haut niveau, c'est juste que le langage est très pur (pas de VM, pas de runtime dégoulinant... encore une fois tout ce que t'as dans les mains ce sont des mots-clés et des types, grosso merdo), le plus "fat" que tu puisses trouver pour te simplifier le travail dans les libs standard, c'est la STL et quelques jouets du genre.
Bon après c'est sûr que si tu te lances dans Qt ou d'autres frameworks bien costauds, t'auras de l'intelligence cachée derrière, mais c'est pas comme dans les langages à la Java ou tout est déjà "planqué". (pour te dire, je ne sais toujours pas ce que deviennent les instances de classes dans certains bouts de code de mes projets Java)

Ah d'accord. Mais ça ne m'étonne pas.
Sinon que penser des langages qui se veulent être les "héritiers de C++" ? Je vois pas, déjà que c'est un langage très pur et peu bloated comme tu le dis...

Faudrait demander aux habitués du forum prog, mais je ne vois même pas pourquoi il devrait avoir des héritiers: c'est un langage encore vivant, la dernière norme date tout juste de 2011 et ils comptent sortir une version intermédiaire cette année si je ne dis pas de conneries (la future "grosse" version étant prévue pour 2017 il me semble)

Des héritiers, on en veut quand des langages qui avaient de bons concepts finissent par crever de vieillesse / manque de mises à jour.

Perso je me suis mis au C++ pour deux raisons :

-j'ai quelques idées de petits jeux vidéos / mods / remakes.
-j'ai commencé il y a 10 ans et j'ai jamais fini. Revanche personnelle.

Le but ultime c'est un mod Outlaws pour CS:S. Pour ceux qui connaissent pas, Outlaws c'est un FPS western développé par LucasArts en 1997 et qui a introduit deux éléments majeurs dans le fps : le rechargement de l'arme et la visée sniper. Il a aussi rameuté une sacrée communauté, avec en 2014 encore 200 membres plus ou moins actifs sur le forum. Je fais l'impasse sur les milliers de maps créées par les fans. Ah ! Et la musique était grandiose !

La fiche du jeu avec des screens : https://www.jeuxvideo.comm/jeux/pc/00000702-outlaws.htm

Le forum toujours actif :
http://outlawsgame.50.forumer.com/index.php

Pour jouer en réseau :
http://www.e-warzone.com/

Le projet OutlawsXL, même si j'y crois plus trop.
http://xlengine.com/forums/viewforum.php?f=11

-y'a un mod Outlaws pour HL1 avec des bots mais sans le mod solo.
-Smokin Guns, anciennement Western Quake 3, est clairement inspiré de Outlaws et existe en natif sur Linux.
-Y'a aussi le mod Fistful of Frags pour HL² qui est sympa même si plus très actif il me semble...

Quant à Outlaws sur Linux, y'a des précédents comme quoi il tourne avec Wine mais d'après mes essais avec une machine virtuelle sur Arch Linux le mois dernier, la souris est ingérable... reste l'option manette et clavier...

Heu... voilà.

G_b > je te trouve bien réducteur. Le principe de pas mal de langages interprétés n'est pas d'etre accessible au plus grand nombre, c'est d'accelerer le dvpt en simplifiant des routines repetitives quand on peut se permettre de se taper un interpreteur qui ralentit le tout

Calet j'ai pas dit qu'ils servent à rien mais clairement des langages comme Python sont insérés dans les programmes scolaires à coup de forceps pour les raisons que je cite. Je pigerai jamais, ça ne leur coûte rien d'expliquer le principe du compilateur aux gamins lors de la première leçon (c'est la seule chose dont ils ont besoin pour comprendre #include <stdio.h>), et au moins à partir de là ils savent ce qui se passe réellement dans leur programme.
En Python, il y a énormément de mécanismes "bizarres" (et je viens du C pour dire ça...), je trouve qu'on s'y retrouve VRAIMENT moins avec la syntaxe que dans les langages C-like (OK "ça oblige à indenter", mais en même temps les mecs qui n'indentent pas leur code C sont à classer au rang des sous-merdes et personne n'a de raisons de lire leur code, donc bon... mauvais prétexte)...
C'est sûr que pour coder un petit automatisme vite-fait c'est sympa d'avoir Python sous le bras (même si entre nous, <foo>sh était déjà là avant pour faire ça), mais pour moi ça s'arrête là.

Ah oui, le forceps des langages simplifiés pour l'éducation je trouve ça débile aussi. Dans le même genre, j'ai mes profs qui nous ont fait un semestre de PHP sans utiliser le mot 'objet'... Et qui à côté nous font des cours de BDD relationnelle en utilisant les tables comme des classes
Par contre je pense qu'il faut aussi prendre compte des facteurs extérieurs pour chaque projet, et qu'à partir du moment où on a pas besoin d'applications à la gestion de mémoire/vitesse critique, il est tout à fait raisonnable de choisir un langage, interprété ou non, parce qu'il est plus 'simple', plus 'amusant' ou plus rapide à développer. Je prends l'exemple du Ruby parce que c'est le langage interprété que je connais le mieux : si j'ai une application pas bien ambitieuse type gestion de cours ou de playlist, j'ai pas besoin de me faire "chier" avec du C ou du C++ ; au final la plus grosse couche c'est Qt ou GTK, et le code ça sera du pareil au même avec l'un ou l'autre. À côté, ça veut pas dire non plus que de tels langages sont ultra simplifiés ; le Ruby, là encore, permet des notions de métaprogrammation et de design pattern extrêmement poussés. Si t'en as jamais fait avant dans des langages compilés éprouvés, ça sert à rien, tu seras paumé. Et pourtant ils sont là : ces mécanismes sont pas là pour apprendre la métaprogrammation avancée à des lycéens, c'est bien pour simplifier la vie de développeurs qui la maitrisent déjà autrement pour des projets moins contraignants.

Vu comment les environnements évoluent, on avance de plus en plus vers des langages interprétés qui simplifient au maximum les routines répétitives. C'est pas forcément une mauvaise chose : d'un point de vue économique, c'est vraiment avantageux de développer des apps et/ou webapps en 3 fois moins de temps (et de moyens) parce qu'on peut se permettre de perdre un peu de performances. Là encore faut pas que ça tombe dans l'extrême en se disant que les cimetières de performances seront compensés par le hardware, mais d'un point de vu global c'est toujours plus pratique.

« j'ai mes profs qui nous ont fait un semestre de PHP sans utiliser le mot 'objet' »
Pour le coup je les comprends, la couche objet de PHP n'est bonne qu'à finir aux chiottes à 70% (sans parler des bugs qui montrent bien à quel point elle a été greffée à l'arrache en plein vol, chose qui ne se fait JUSTE PAS sur un langage... ou pas par des développeurs aussi cons que ceux de chez PHP).

« Et qui à côté nous font des cours de BDD relationnelle en utilisant les tables comme des classes »
Là c'est du crime par contre putain, le relationnel c'est probablement le truc le moins compatible avec le paradigme objet que j'aie rencontré (j'en fais les frais en ce moment sur un projet de webdev d'ailleurs)... putain mais ils fument quoi tes profs?

Je suis d'accord pour les petits projets, moi aussi j'utilise de petits langages de merde quand j'ai besoin de gagner 5 minutes pour faire un truc très simple.
Mais cette condition n'est JAMAIS respectée, aujourd'hui on voit des projets monstrueux reposer sur de l'interprété et ça fout la gerbe tellement c'est peu justifié.

« d'un point de vue économique, c'est vraiment avantageux de développer des apps et/ou webapps en 3 fois moins de temps (et de moyens) parce qu'on peut se permettre de perdre un peu de performances. »
ça coûte moins cher en développeurs (de merde*), mais derrière quand tu déploies ton appli en grande échelle, bah ce code interprété gaspille de la ressource sur les machines et tu perds l'économie que tu faisais en devs, en énergie requise pour faire tourner tout ce merdier.
L'an prochain on aura de la sensibilisation là-dessus d'ailleurs (dans un effort de développement durable... oui, ça existe en écoles d'ingés en info / élec, c'est pas du fake! ).

• je dis de merde, car dans la moitié des cas le "choix" de PHP / Python / <random-interpreted-language> n'en est pas vraiment un: ils font un tour de table, constatent que le meilleur dev présent dans la pièce sait tout juste faire du Java en guise de "langage bas niveau" (donc C / C++, je ne t'en parle même pas), et de ce fait les langages-jouets (comme je les appelle) deviennent l'unique solution viable, car c'est tout ce qu'ils "maitrisent" vraiment.

Mais là encore, je te trouve violent quand tu parles de langages jouets.
La programmation ne se concentre pas autour du C/CPP/Java
Tu peux très bien avoir à faire des grosses applications, massivement distribuées, qui n'ont pas besoin de gestion critique de la mémoire ou des performances. Dans de tels cas, est-ce que ça vaut le coup de passer plus de temps sur des langages plus bruts quand des langages interprétés te proposent un boilerplate un minimum robuste ?
Parce que des devs de merde, on en a aussi beaucoup en C/CPP/Java qui considèrent leur langage comme infaillible et à côté de ça se glandent magistralement avec les points délicats du langage, à un niveau pire que ce qu'ils auraient fait avec un langage interprété qui a au moins l'avantage de procurer ce 'filet de sécurité'
(et je pense même pas forcément à l'erreur Heartbleed )

Ce que je veux dire, c'est que prendre ce genre de langages directement parce que c'est la référence, c'est robuste, ... ça marche que si on les maîtrise absolument. Des projets complètement dégueulasses en Python/Ruby mais qui restent convenables grâce à l'interpréteur qui maquille tout ça, je suis bien content qu'ils soient pas faits en C/CPP souvent parce que ça serait complètement immonde

Après je maintiens, quand le choix du langage interprété est, à l'inverse, juste motivé par 'je maîtrise que ça et c'est plus facile', oui, évidemment, c'est complètement stupide.

Et puis si après on se tourne du côté du web, là c'est complètement le postulat inverse parce que la vitesse de développement et la maintenabilité sont super importants.

« Des projets complètement dégueulasses en Python/Ruby mais qui restent convenables grâce à l'interpréteur qui maquille tout ça »

C'est tout ou rien ça, des fois ça pallie un peu l'incompétence des devs mais des fois ça ne fait que la renforcer (« coucou Minecraft, alors comment ça va avec la JVM? »). Bon et encore là on est dans du précompilé, Minecraft en Python/Ruby/JS je préfère pas penser à ce que ça aurait pu donner

« Et puis si après on se tourne du côté du web, là c'est complètement le postulat inverse parce que la vitesse de développement et la maintenabilité sont super importants. »
En attendant le web souffre énormément des choix technologiques débiles qui le composent. Quand je vois la tronche des outils utilisés par les développeurs web, j'ai sincèrement l'impression de voir un boucher couper sa viande avec un tournevis, tout content de lui car il a appris à "le faire efficacement"...

Bon, qui utilise le noyau Linux 3.14

Pas moi, je reste en 3.2 pour l'instant (j'ai refait ma Debian récemment). Je verrai quand j'aurai à nouveau la foi de me faire une config aux petits oignons

Google_Bot « Pour le coup je les comprends, la couche objet de PHP n'est bonne qu'à finir aux chiottes à 70% » :

Tu t'es arrêté à quelle version de PHP ? Perso j'ai pas connu PHP < 5.3, mais du moins à partir de cette version je trouve le modèle objet très solide, et ça s'améliore encore avec les versions supérieures.

« le relationnel c'est probablement le truc le moins compatible avec le paradigme objet que j'aie rencontré » :

Je ne suis pas d'accord, je bosse souvent avec des ORM, que ce soit Doctrine, Propel ou autre en PHP, ou l'ORM de Django en Python, je trouve ça tout à fait adapté pour manipuler une BDD relationnelle avec des objets.

La classe correspond au schéma d'une table, et une instance de cette classe correspond à une lingne de la table (y'a une certaine logique).

Les relations se matérialisent par une propriété qui contient une autre entité ou une collection d'entités selon le type de relation (propriété qu'on peut retrouver des deux côtés de la relation). Ça permet de passer les colonnes/tables de liaison en arrière plan et de manipuler directement les entités en relations sans se soucier de l'implémentation. C'est un comfort non négligeable.

Je reconnais que c'est moins performant que de faire directement des requêtes SQL, un ORM ne peut pas remplacer du SQL dans des cas où la performance est critique. Quoique dans certains cas, lorsque couplé à un bon système de cache, l'ORM peut passer presque inaperçu en terme de performances.

« ça coûte moins cher [...], mais derrière [...] ce code interprété gaspille de la ressource sur les machines et tu perds l'économie que tu faisais en devs » :

Ça dépend du contexte. En web cette affirmation est fausse dans la plupart des cas, on perd moins en investissant dans de nouveaux serveurs qu'en passant du temps à optimiser le code (surtout s'il s'agit de tout refaire en C, et par conséquent se passer des librairies & frameworks haut niveau des langages interprétés, sans même parler des CMS). J'ose pas estimer le montant du devis pour un client qui voudrait son Magento en C pour réduire les coûts serveur...

« Quand je vois la tronche des outils utilisés par les développeurs web, j'ai sincèrement l'impression de voir un boucher couper sa viande avec un tournevis, tout content de lui car il a appris à "le faire efficacement" »

Tu penses à un truc précis en disant ça ?

Nhexus Moi \ /

Archlinux powaaa