Wonderfall > bah en fait si tu lis les conventions définies par la communauté, t'as moyen de resserrer le tout assez fortement. Couples-ça à un minimum de bon sens et la solution peut paraître plus logique.
Genre y'a une bonne douzaine de façons différentes d'itérer une collection quelconque (et une demi douzaine de façons spécialisées pour chaque type de collection ), mais les conventions en écartent la moitié parce qu'elles sont dépassées, le quart parce qu'elles sont moins lisibles/intuitives et le reste en fonction de la situation
Caletlog : Je ne sais pas ce que valent ces sites, à vrai dire ça me paraît être un bon point de départ pour voir grosso modo à quoi ça ressemble, et m'amuser un peu avec.
Je trouve déjà ça jouissif de one shot les 3/4 des méthodes de Rails dans le tuto sans y avoir touché avant.
Si je suis convaincu à la fin (c'est bien parti), je passerai aux choses séieuses avec un bouquin ou un cours un peu plus approfondi oui.
Dans tous les cas je suis aussi censé en avoir en cours l'année prochaine, mais vu comment on a massacré PHP/Symfony cette année je crains le pire.
Après j'aime aussi beaucoup Python, qui est aussi très agréable à écrire, mais semble aussi plus performant, surtout avec une approche fonctionnelle (et apparemment ça poutre sévèrement quand on passe par Cython).
Caletlog Concrètement c'est quoi des avantages par rapport à Python ? Pourquoi Ruby et pas Python ? Je pose la question car ce sont tous deux des langages à "scripts", avec l'un on peut faire avec l'autre normalement.
Wonderfall > exactement. Ruby/Python c'est du pareil au même, les perfs sont grosso merdo équivalentes suivant les cas, la syntaxe est très similaire, le style de programmation est semblable (même si Ruby intègre 2 notions un peu plus 'originales', les symboles et les blocks), ... Ça reste des préférences persos, je pense. Dans mon cas j'ai choisi Ruby parce que je le trouve plus souple que Python dans la syntaxe, parce que j'ai horreur de l'indentation forcée du python, et parce que le langage est vraiment fait pour être agréable à être utilisé donc ça m'a tenté
Ah et, Rails/Sinatra/Rack >>>>>>> Django/Grock
L'écosystème Ruby est aussi très sympathique, je trouve. La communauté est top, même si un brin prétentieuse et nombriliste...
« La communauté est top, même si un brin prétentieuse et nombriliste... »
Ouais, comme les Pythonistes, les Javascripteux, et autres amateurs de langages du genre
Je l'ai déjà dit mais la seule fois de ma vie où j'ai assité à une conférence organisée par des devs Python... cet intégrisme de merde et ces arguments à deux francs pour descendre les autres langages, sérieux, faudrait qu'ils se regardent un peu à un moment...
Du côté de "l'intégrisme de merde" et "des arguments à deux francs pour descendre les autres langages", je te suis pas sûr que tu sois très objectif
nounoursheureux c'pas comme si les mecs descendaient Javascript parce qu'ils codaient comme des culs avec
Et pourtant j'affectionne pas plus JS que Python hein, mais là pour le coup leurs arguments étaient vraiment merdiques (quand il y en avait, car en gros en général tu disais "JS" et ils répondaient "cacaaaa", simplement).
Je crois que JS ça reste l'une des pires communautés
Bon après le Ruby ça va encore, la commu est vraiment gentille en général, ça aide bien, c'est juste qu'ils ont tendance à lancer des 'Regardez, y'a pas ça chez les autres, sont-ils trop bêtes pour voir que c'est génial chez nous ?' à tout bout de champs parfois...
C'est sûr que quand on compare à la commu du Haskell par contre, y'a pas photo
+ Après la popularité du langage joue beaucoup, aussi. Genre en Java/C/C++/PHP c'est assez dur de définir les commus, parce que y'a vraiment de tout. Pour des langages à petites communautés, y'a pas vraiment la place pour la discorde et tout le monde est sur la même antenne, même si vu de l'extérieur ça plaît pas.
Hum.
Je viens d'avoir un écran TTY qui ressemble à un kernel panic, mais sans kernel panic. On aurait dit des adresses mémoire en hexa, empilées sur tout l'écran. Aucun contrôle ne répond (mais le clavier ne clignotait pas comme lors d'un kernel panic).
J'ai coupé de force, et au reboot il m'a nettoyé mon FS ext4 sur / et /home... et m'a dit que mon /var (reiserfs) 'is NOT clean. fschk died with exit status 1'
Pourquoi j'ai gardé cette merde de reiserfs ?
murderfs does his job very well
Je suis ent rian d'essayer s'apprendre le haskell est c'Est quand même très intéressent. SA change pas mal du Java. Mais... elle a quoi sa communauté?
Même si c'est pas une configuration optimale, je suis en EXT4 partout.
J'aime pas les mauvaises blagues et spécialement, lorsque ça peut être en relation avec mes données
Zeite > elle est extra.
L'été dernier je suis allé sur un irc XMonad (donc soft en Haskell, mais pas un IRC haskell officiel). En posant une question là-bas, 3 gars m'ont guidé pas à pas à la résoudre en m'expliquant en détails le code qu'ils me donnaient et comment m'en sortir tout seul après.
Puis une demi douzaine a tenté de me refiler le Haskell
Et sur les IRCs/forums c'est vraiment top. C'est une petite communauté, avec pas mal de fanatiques du langage, et c'est vraiment un régal. Les gens sont polis, s'aident avec plaisir et on a vraiment de quoi apprendre vite avec tous les bidouilleurs qui testent des trucs fous et mettent leurs démarches détaillées en ligne.
G_B > haha
Non mais il marchait très bien, c'est juste que faut un checkdisck spécial reiserfs... Et là j'ai peur qu'il me fasse chier si jamais y'a besoin d'outils qui sont dans /var, parce qu'on peut pas faire des checks/réparations reiserfs depuis une partition reiserfs sur elle-même
J'ai failli basculer vers btrfs quand il a été mis en avant par je ne sais plus quel Linux Mag, puis on m'a parlé des perfs parfois moins bonnes qu'ext4 et dans la mesure où je n'ai pas excessivement l'utilité des apports de btrfs j'ai laissé tomber.
Pour ce qui est du haskell j'ai vue de grosse discussion par rapport a ses performances. Certaint dise qu'il est ridiculement lent d'autre prétende qu'il est aussi rapide que le C/C++. C'est parfois dur de s'y retrouver.
Zeite > ah, perso j'ai vu de partout qu'il était monstrueusement rapide.
G_B > ouai, moi le reiserfs je l'avais pris parce que j'avais vu de bons benchmarks sur les /var, puisque son algo est optimisé pour bosser avec plein de petits fichiers (comme dans /var).
Et effectivement, la navigation dans aptitude n'a jamais été aussi rapide.
Mais si c'est si chiant laisse tomber.
+ Pour mon 'kernel-panic codes mémoires', y'a moyen de trouver un log ou un truc qui m'aiguillerait pour savoir d'où ça vient ? J'étais en train de voir plusieurs vidéos à la fois (oui, pas bien ) sur des sites bourrés de pub (je testais quelque chose) sans adblock, mon proc était apparemment saturé à un peu plus de 3 de charge et le ventilo tournait un max, et là, boom, écran noir avec juste ces codes mémoires alignés. Ça vous dis quelque chose ?
Coucou
Même si je suis décidé à utiliser Fedora j'aimerais bien tester gNewSense,c'est simple d'utilisation ?
« + Pour mon 'kernel-panic codes mémoires', y'a moyen de trouver un log ou un truc qui m'aiguillerait pour savoir d'où ça vient ? »
Bah, si Dargor était là il t'aurait dit de passer à un vrai OS, qui te permet de passer dans un genre de mode de récup / analyse / débogage en cas de plantage, contrairement au kernel Linux qui te chie tout son log à l'écran (souvent trop petit pour tout afficher ), et te laisse avec ça en guise d'infos.
Mais en fait j'en viens à me demander si c'était pas juste la machine qui criait et pas l'OS. Y'avait vraiment aucune info liée au kernel ou au système si je me souviens bien, juste des emplacements mémoires (enfin je présume) en hexa et des groupes de 2 paires en hexa, alignés.
Comme je forçais un peu sur le proc et la CG, c'est peut-être qu'il a planté ?
Ça peut faire un écran de ce type dans ce cas-là ?
Un exemple de où j'ai lue qU'il était lent. https://groups.google.com/forum/?_escaped_fragment_=topic/comp.lang.functional/_RGoYHD2Kpg#!topic/comp.lang.functional/_RGoYHD2Kpg Sauf que sa date de 2009 et c'est dû a un bug du compilateur selon les commentaires.