Informatique

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

« 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). »

Certes, ça je sais le faire sans ORM soit dit en passant même. Mais dès que tu veux matérialiser de l'héritage (du vrai) à travers un SGBDR bah c'est la merde, t'es obligé de ruser (enfin j'appelle plutôt ça "bricoler" dans le cas présent) avec des triggers pour gérer l'exclusivité entre certaines clés étrangères (censées matérialiser la relation d'héritage, du moins le lien entre la partie héritée et la partie mère).

"« 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 ?"

PHP et ses frameworks, oui. Pour avoir commencé contre mon gré à travailler avec Symfony, j'ai vraiment l'impression d'essayer d'enfoncer un clou avec une scie à métaux.

Nan, franchement la prog web et moi c'est vraiment plus possible. Je peux plus saquer cette façon de penser et de faire, surtout quand les gens commencent à vouloir faire en web ce qui ne devrait pas l'être...

« 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 »
En attendant non-seulement tu paies de nouveaux serveurs à cause de ton code|interpréteur|VM de merde, mais en prime tu te retrouves avec 20% d'opérations inutiles tout au long de l'uptime, que je compare beaucoup à l'effet joule en électronique. C'est ça qui m'énerve avec le code interprété quand on le fout à grosse échelle... ça se développe vite-fait OK mais derrière ça tient mal la charge à la moindre occasion, et ça bouffe beaucoup pour pas grand-chose.

Faut pas oublier qu'après l'école tu chercheras du boulot, et tu seras content de pouvoir caser symfony sur ton cv, c'est moi qui te le dis ! Même si j'en pense la même chose que toi.

Johnny je sais, c'est ce que les profs nous disent aussi (au moins ils sont honnêtes, ils essaient pas de nous convaincre que ce sont des technos potables et rationnelles, ils nous disent juste que c'est la mode).
Je vais avoir droit au même laïus avec NodeJS l'an prochain je crois. Cette absurdité fait fureur depuis deux ou trois ans, personne ne s'est demandé si ça valait vraiment le coup mais tout le monde se rue dessus donc on pourra pas y couper.

En gros, faut qu'on apprenne à étaler de la merde "d'une façon qui plait aux entreprises", c'est hyper encourageant le marché de l'emploi en développement logiciel...

Qui veut la perle du jour ?

https://www.jeuxvideo.com/forums/1-1000005-1241119-2-0-1-0-important-projet-rom-android-hapogenmod.htm#message_1241187
Changer la licence d'un projet sous Apache.
Changer juste pour un cooking.
GPL commercial.

Kom c tro 1 devlopeur.

« Mais dès que tu veux matérialiser de l'héritage (du vrai) à travers un SGBDR bah c'est la merde » :

Là je suis d'accord avec toi, mais dans ce cas j'ai presque envie de dire, c'est vouloir faire les choses à l'envers, donc normal que ça pose problème.

Dans le sens BDD => objet, ça va (mais oui c'est des objets « castrés », d'une certaine façon).

« Pour avoir commencé contre mon gré à travailler avec Symfony, j'ai vraiment l'impression d'essayer d'enfoncer un clou avec une scie à métaux » :

Le peu de Symfony qu'on a fait en cours m'a donné la même impression (« enfoncer un clou avec une scie à métaux »), tout simplement parce qu'une scie à méteaux est pas faite pour ça (ça veut pas dire que c'est un mauvais outil). Pour info on a fait un site ridicule de trois pages avec un CRUD de base en utilisant Symfony. C'est _pas_ fait pour ça. Dans un cas comme ça on utilise du PHP natif, ou éventuellement Silex (parce que c'est plus pratique d'enfoncer un clou avec un silex qu'à la main).

Je dirais que t'as besoin de Silex quand tu te retrouves à refaire Silex en PHP natif pour organiser ton projet, et t'as besoin de Symfony quand tu te retrouves à refaire Symfony avec Silex parce que ce dernier ne suffisait plus.

« ça se développe vite-fait OK mais derrière ça tient mal la charge à la moindre occasion, et ça bouffe beaucoup pour pas grand-chose »

On est d'accord. Enfin quand c'est « bien » fait ça tient la charge parce que les serveurs sont (sur)dimensionnés en conséquence dès le début, mais c'est qu'une façon de contourner le problème.

Pour autant, comme dit plus haut, c'est rarement à toi de faire ce choix.

--

Node.js, est pas seulement une plateforme à la mode pour hipster, y'a certains concepts qui viennent avec qui sont très intéressant, en particulier la façon dont tout est pensé en asynchrone, depuis le début. C'est tout à fait possible de faire de la merde avec (donc tu risques d'en voir — beaucoup — et aussi d'en faire au début), mais c'est toujours la même histoire ; quand tu l'utilises correctement, pour résoudre les bons problèmes, c'est un outil qui fait très bien son job. Au passage les performances sont loin d'être catastrophiques avec Node.js, et y'a un nombre assez impressionnant de librairies disponibles (ce qui est un avantage — à peu près tout ce que tu veux faire, quelqu'un l'a déjà fait avant toi — mais aussi un inconvénient — tu dois faire du tri).

Après, quand on utilise un truc à la mode juste parce que c'est à la mode, sans réfléchir avant, oui, ça pose souvent problème. Exemple typique avec MongoDB : http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ (le cas de base où quelqu'un essaie de faire du relationnel avec un outil qui fait tout sauf du relationnel).

Quoi qu'il en soit la meilleure chose à faire si tu n'aimes pas le web, c'est de ne pas faire de web (bon, pas de bol, apparemment t'en as en cours ). Ne mets pas Symfony sur ton CV si dans tous les cas ça t'écorche les doigts d'écrire de PHP, y'a aussi des boîtes qui cherchent des développeurs C++, C & asm, là où je suppose que t'auras plus de chances de t'épanouir.

Clairement pour moi le développement web c'est une torture... dans un contexte de crise comme l'actuel je ne suis pas bien placé pour faire le délicat avec les offres d'emploi, mais putain, qu'est-ce que ça me ferait chier de bosser là-dedans.

Et en fait ma vraie passion c'est pas spécialement le développement (mais j'en fais pas mal en cours depuis trois ans), plutôt l'admin système, réseaux, et la sécurité sous-jacente à ces domaines. Mais bon j'aime l'idée d'être polyvalent (et en ce moment je découvre aussi que c'est vachement bien d'être polyvalent entre électronique et informatique... vraiment.

Un Raspberry Pi + un trombone = un émetteur FM pirate très efficace

Je viens de tester, et ma mère s'est demandé dafuq ce qui se passe ?

J'imagine.
Ah tu me rappelles que j'ai un peu de bricolage à faire, enfin pas du bricolage proprement dit mais je dois brancher mon Pi en CPL et à la fois sur la multiprise-onduleur (pas un vrai onduleur) sans que le CPL passe par celui-ci, j'ai dû tout débranché quand j'ai modifié ma tour.
Du coup je pense en faire un serveur cloud Seafile, ou encore un serveur cache-DNS.