De tout, de rien, des bookmarks, du bla bla #42

Posté par CrEv (site web personnel) le 17 octobre 2012 à 10:51. Édité par Davy Defaud, Nÿco, baud123, rootix, Bruno Michel, Florent Zara et patrick_g. Modéré par baud123. Licence CC By‑SA.

Étiquettes :

oct.

2012

NdM : Nous (modérateurs) avons demandé à CrEv s’il souhaitait poster sa série en dépêches plutôt qu’en journaux, car elle nous plaît et elle aura plus de visibilité ainsi. Nous sommes tous preneurs de vos retours, veuillez commenter cette dépêche. D’autre part, l’étiquette « veille technologique » vous permet de retrouver les journaux précédents.

Pour cette première en dépêche, j’ai essayé de faire plutôt soft. Comme d’habitude (mes journaux), vous trouverez pas mal de choses côté développement, essentiellement côté Web et JS, mais aussi deux ou trois petites choses annexes.

Une liste de l’ensemble des liens présentés est accessible à la fin de l’article.

Bonne lecture !

Sommaire

Un peu de contenu
- Développement
- Misc
Liste des liens présentés
- Développement
- Misc

Un peu de contenu

Développement

Vous avez toujours regardé Go, mais n’avez jamais franchi le pas ? Vous ne savez pas faire des choses toutes bêtes en Go ? Alors, Go by Example est fait pour vous. Il vous présente les bases à connaître au travers de petits exemples clairs et documentés.

Chaque semaine, je vois passer des nouvelles migrations vers Go. Ce que je trouve intéressant est que ce sont régulièrement des codes importants, et l’on y retrouve souvent les mêmes arguments : c’est simple, agréable à coder, ça fonctionne simplement bien. Cette fois‐ci ce sont les DNS de la réserve NTP qui viennent de migrer sous Go. Et les sources sont sur GitHub.

Ah oui, et évidemment c’est développé avec SublimeText et GoSublime. ;)

Je suis sûr que vous avez toujours rêvé de pouvoir écrire du code comme vous pensez. C’est désormais une réalité pour les développeurs Ruby (car de toute façon « il y a une gem pour ça ») avec fsck.

Pour illustrer, voici un petit exemple tout simple :

# all i want is to sum the goddamn elements
sum = 0
(1..10).each_fucking_element { |e| sum += e }

Alors, cool, non ? Bon, en fait, c’est pas méga compliqué, ça utilise surtout method_missing, qui va être appelé à chaque fois qu’on essaie d’exécuter… une méthode manquante. Sympa et totalement inutile, donc absolument indispensable !

Restons dans les langages intéressants. Tout d’abord avec The State of JavaScript. Il s’agit d’une présentation sur JavaScript assez intéressante. Ça parle entre autres d’ES 6 (EcmaScript 6). S’il y a plein de bonnes choses, je suis très perplexe quant à son adoption par l’ensemble des navigateurs. Et sans cette condition, ça ne servira pas à grand chose ; en fait, ça deviendra simplement un de plus parmi TypeScript, Dart…

Toujours en JS, j’ai découvert melonJS. Il s’agit d’un framework JavaScript orienté jeux vidéo (par tuile). Plutôt sympa, ça donnerait presque envie de coder des jeux (mais bon, c’est pas trop mon truc les jeux…).

Et côté nouveautés langage, Rust vient de sortir la version 0.4. J’ai l’impression que par certains côtés ça s’oriente vers les mêmes solutions que, par exemple :

Classes are replaced with simpler structs

Après, il y a eu beaucoup de renommage, c’est assez marrant (mais doit être perturbant pour ceux qui ont écrit du code) :

ret became return and alt became match ;
import is now use; use is nowextern mod` ;
extern mod { ... } is now extern { ... } ;
use mod is the recommended way to import modules ;
pub and priv replace deprecated export lists.

Avez-vous déjà essayé Rust ? Un petit retour ?

Si vous utilisez AngularJS et SublimeText, vous serez probablement intéressés par deux extensions permettant d’ajouter le complètement automatique. Tout d’abord AngularJs.tmbundle, qui rajoute simplement quelques snippets. Mais surtout, Sublime-AngularJS-Coffee-Completions, qui rajoute pas mal de complètements, que ce soit en HTML ou en CoffeeScript.

Dans un autre registre, je viens de découvrir Codiad. Il s’agit d’un IDE (bon OK, un éditeur surtout) Web. Il est donc possible de le placer sur un serveur plutôt basique (seul PHP 5.3+ est requis, pas de base de données, entre autres) et pourra donc vous permettre d’éditer vos fichiers, directement depuis votre navigateur.

Même si ça peut être risqué (ne pas le laisser accessible surtout), je trouve que c’est intéressant. Il faut avouer que les éditeurs en ligne commencent à être de plus en plus performants et pratiques à utiliser (voir aussi, par exemple, The ACE Editor, l’éditeur de Cloud9 IDE). À noter que ces deux éditeurs sont libres.

Voici en revanche un nouveau concurrent dans les « forges », dans l’hébergement de dépôts de code source : PikaCode. C’est marrant comme la conception me fait penser à une bibliothèque qu’on rencontre souvent, et à un site très connu dans le domaine. ;) J’ai pas testé non plus, mais un point fort, je trouve, est d’héberger du Mercurial et du Git.

Misc

Évidemment, vous avez suivi l’histoire du gars qui monte très très haut, juste pour sauter dans le vide (bon en même temps ayant déjà sauté, de beaucoup moins haut, je comprends l’intérêt ;))… Voici un petit résumé en vidéo du saut.

Voici, comme souvent, une petite présentation agréable sur How do you build great software? chez GitHub. Pas grand chose à dire, juste que j’aime bien, que ce soit le fond ou la forme.

Liste des liens présentés

Développement

Go : http://www.golang.org
Go by Example : http://gobyexample.com
Les DNS la réserve NTP en Go : http://news.ntppool.org/2012/10/new-dns-server.html
Sources du serveur DNS : https://github.com/abh/geodns/
SublimeText : http://www.sublimetext.com/
GoSublime : https://github.com/DisposaBoy/GoSublime
fsck : https://github.com/thorncp/fsck
The State of Javascript : http://brendaneich.github.com/Strange-Loop-2012
melonJS : http://www.melonjs.org/
Rust : http://www.rust-lang.org/
version 0.4 de Rust : https://mail.mozilla.org/pipermail/rust-dev/2012-October/002489.html
AngularJS : http://angularjs.org/
AngularJs.tmbundle : https://github.com/ProLoser/AngularJs.tmbundle
Sublime AngularJS Coffee Completions : https://github.com/EastPoint/Sublime-AngularJS-Coffee-Completions
Codiad : http://codiad.com/
The ACE Editor : https://hacks.mozilla.org/2012/09/the-ace-editor-hits-v1-0/
PikaCode : https://pikacode.com/

Misc

Résumé vidéo du saut : http://www.youtube.com/watch?v=yFU774q6eVM
How do you build great software? : http://warpspire.com/talks/greatsoftware/

Aller plus loin

Tag « veille technologique » sur LinuxFr.org (369 clics)

# Methode

Posté par Gui13 (site web personnel) le 17 octobre 2012 à 11:20. Évalué à 8.

Mais, comment tu fais pour trouver tous ces trucs de malade? T'es abonné aux top X de GitHub ou quoi?

Sérieusement, j'ai 50 ou 60 RSS que je suis régulièrement, et je trouve même pas la moitié de ce que tu décris.
- [^] # Re: Methode
  
  Posté par CrEv (site web personnel) le 17 octobre 2012 à 11:35. Évalué à 7.
  
  Alors, comment dire… le pire c'est que c'est juste une "petite" news. Entre le moment où j'ai posté la dépêche et le moment où elle est sortie de modération j'ai du retrouvé encore 4 ou 5 liens intéressants (qui seront donc dans le prochain numéro)
  
  Après, comment je trouve tous ces liens ? Ben un mix de rss et de twitter. Lorsque j'étais vraiment actif dessus (en fait je le faisais pour mon taff à la base) j'avais entre 20 et 40 liens par semaine.
  
  Mais par contre non, pas abonné à github, juste en général ce qui me plait et souvent fonction de mon travail. Après, beaucoup de lecture.
  
  Ca pourrait peut-être être intéressant d'ailleurs que j'indique la provenance, pourquoi pas…
# précisions

Posté par CrEv (site web personnel) le 17 octobre 2012 à 11:27. Évalué à 3.

Tout d'abord, merci :)

Sinon, juste une petite coquille :

D’autre part, l’étiquette « veille technologique » vous permet de retrouver les 41 journaux précédents.

Je vous rassure, il n'y a pas 41 journaux précédents ;) le #41 ou #42 étant simplement la semaine courante.

Sinon, comme dit dans le NdM n'hésitez surtout pas à donner votre ressenti, initialement j'étais plutôt journaux (de seconde page) à cause du côté marque-page, donc passer en dépêche était pas quelque chose d'initialement envisagé (mais qui peut être sympa)
- [^] # Re: précisions
  
  Posté par BAud (site web personnel) le 17 octobre 2012 à 12:21. Évalué à 2.
  
  rho, c'était effectivement une petite boutade :-) un peu comme on dirait les ouatmilles journaux précédents.
  - [^] # Re: précisions
    
    Posté par CrEv (site web personnel) le 17 octobre 2012 à 14:28. Évalué à 3.
    
    oups, lapincompris initialement
    Bon, j'aurais du rien dire alors ;)
    - [^] # Re: précisions
      
      Posté par Yves Bourguignon le 17 octobre 2012 à 23:49. Évalué à 3.
      
      Moi les journaux #42, je suis pour.
# Rust

Posté par gasche le 17 octobre 2012 à 11:38. Évalué à 10.
Rust est en effet un langage très intéressant (à mon humble avis ce qui se fait de mieux en ce moment niveau collaboration entre l'industrie, la communauté du logiciel libre et la recherche). Les changements de la 0.4 sont variés et plus intéressants pour la plupart que des renommages de mots-clés. Quelques détails (essentiellement une traduction de mon message reddit à ce sujet):
- comme évoqué dans la dépêche, les développeurs sont en train de s'éloigner de la présentation des langages objets typiques (les valeurs sont la combinaison d'un état privé et des opérations qu'elles gèrent) vers une présentation séparée, avec d'un côté des records pour les données, et un système de "traits", qui correspondent en fait assez exactement aux type classes de Haskell, pour transporter les implémentation. L'idée est qu'on définit des interfaces/traits (mettons Printable) et que chaque type peut dire ensuite "je sais être Printable, voilà comment m'afficher"; ensuite le compilateur passe ces implémentations avec les valeurs de façon implicite, en utilisant les types des valeurs. Il n'est pas encore clair de savoir comment les programmeurs vont s'organiser, mais pour l'instant ça ressemble à un mouvement vers des types abstraits de données plutôt que des objets (selon le sens de l'article On Understanding Data Abstraction, Revisited de William Cook en 2009)
- les développeurs et développeuses de Rust ont pas mal réfléchi aux question d'export de modules, de résolution des noms (à quoi fait référence tel nom ?), et bougent vers un système plus propre avec des séparations entre les différentes étapes de résolution
- l'utilisation de types de méthodes où apparaît explicitement l'argument self, comme en Python, permet de mettre des quantificateurs de type sur cet argument pour indiquer comment la méthode se comporte avec l'état interne de l'objet : si elle le considère comme immutable, le passe en référence, etc. C'est une évolution intéressante.
- les notions d'état mutable / non mutable / const, et de fonctions pure, continuent à évoluer en Rust. C'est un point de conception délicats des langages mainstream qui essaient de combiner effets de bords et bonnes propriétiés (D a eu le mêmes genre d'errances): on essaie de ne pas utiliser un système explicite trop compliqué comme peuvent le faire les chercheurs du domaine, mais d'avoir un truc pas totalement stupide non plus, et le compromis est difficile à trouver—à mon avis on n'a pas fini de voir des changements sur ce front là.
Rust est un langage qui essaie d'apporter des idées nouvelles à la programmation système (… contrairement à Go qui fait un best-of des anciennes idées déjà bien connues, ce qui est très utile en soi mais quand même moins excitant), les concepteurs n'ont pas peur d'expérimenter et de faire encore longtemps des changements fondamentaux. Ça veut dire qu'il ne faut pas vouloir l'utiliser pour des projets sérieux à maintenir sur le long terme aujourd'hui, mais plutôt le voir comme un véhicule en déplacement.
- [^] # Re: Rust
  
  Posté par CrEv (site web personnel) le 17 octobre 2012 à 11:57. Évalué à 2.
  
  Merci pour ce message instructif qui permet de mieux voir les choses.
  
  Par contre, je suis perplexe à la lecture de
  
  Rust est un langage qui essaie d'apporter des idées nouvelles à la programmation système (contrairement à Go qui fait un best-of des anciennes idées déjà bien connues, ce qui est très utile en soi mais quand même moins excitant)
  
  Ben déjà Go n'est finalement plus un langage orienté système (en tout cas pas que). Mais que penser par exemple des goroutines ?
  
  En fait je te trouve assez sévère, et j'ai pas forcément bien compris pourquoi…
  - [^] # Re: Rust
    
    Posté par barmic le 17 octobre 2012 à 12:09. Évalué à 1.
    Ben déjà Go n'est finalement plus un langage orienté système (en tout cas pas que).
    
    Je trouve tout de même que si. D'une part c'est la volonté initiale des développeurs de Go, d'autre part les projets dont j'entends parler en Go c'est :
    - un proxy d'image pour linuxfr
    - les DNS de NTP dont tu parle
    - la gestion du loadbalancing de youtube
    C'est pas un mal (bien au contraire), mais j'ai l'impression que ce langage amène les développeurs Python/Ruby à faire du développement système compilé.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Rust
      
      Posté par CrEv (site web personnel) le 19 octobre 2012 à 11:14. Évalué à 2.
      
      Oui, c'est vrai qu'on voit pas mal de choses du genre.
      Par contre, de là à écrire par exemple un os en go, je sais pas (c'est finalement le summum de la prog système, non ?)
      
      Maintenant, j'ai l'impression que des bindings vers des toolkits graphique arrivent. Mais normal que ce soit plus lent.
      
      Il est vrai que la cible toute trouvée est quand même l'équivalent de pas mal de scripts ruby/pythons mais en compilé, comme tu le dis.
      Mais je ne vois pas en quoi, dans le langage, on ne pourrait pas faire beaucoup plus (contrairement au C par exemple où c'est quand même lourd de faire autre chose que de la programmation système)
      - [^] # Re: Rust
        
        Posté par barmic le 19 octobre 2012 à 11:58. Évalué à 2.
        
        Mais je ne vois pas en quoi, dans le langage, on ne pourrait pas faire beaucoup plus (contrairement au C par exemple où c'est quand même lourd de faire autre chose que de la programmation système)
        
        Je n'ai pas dis le contraire. Ce qui va faire la différence ce n'est pas le langage, mais ce que les gens vont en faire (qu'elles bibliothèques/framework vont arriver ? quels projets à forte visibilité vont y passer ou être construit avec ?). D'après ce que j'ai compris les créateurs de Go l'ont pensé pour les développeurs C/C++ et finalement c'est des développeurs python/ruby qui s'y mettent, mais je ne pense pas que ces derniers vont lâcher leur langage de prédiction pour autant. Ils utiliseront un langage dynamique pour tout ce qui est web et interface utilisateur et utiliseront go pour faire du système.
        
        Mais ce n'est là que mon avis « nostradamusien » et « pifometrique » (reconnu « pif le moins fiable » par meteo France 3 années de suite).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Rust
    
    Posté par barmic le 17 octobre 2012 à 12:13. Évalué à 3.
    
    Et côté nouveautés langage, Rust vient de sortir la version 0.4. J’ai l’impression que par certains côtés ça s’oriente vers les mêmes solutions que, par exemple :
    
    Je pense qu'il manque un mot dans la dépêche (je présume que c'est « Go »).
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Rust
    
    Posté par Thomas Douillard le 17 octobre 2012 à 12:27. Évalué à 1.
    
    Les goroutines, c'est pour gérer des problèmes de concurrence et de parallélisme gérés à bas niveau traditionnellement par des mutex, sémaphores et autres qu'on trouve à la pelle dans le noyau Linux par exemple. C'est des problèmes qu'on retrouve énormément dans la programmation système.
    - [^] # Re: Rust
      
      Posté par Antoine le 17 octobre 2012 à 16:25. Évalué à 3.
      
      Hum je suis pas sûr que les goroutines te dispensent d'utiliser des primitives de synchronisation, sauf dans les cas simples. Si tu veux ordonner l'accès à une ressource partagée (par exemple un cache), il faut bien un mécanisme de synchronisation (fût-il caché au sein d'une file par exemple).
      - [^] # Re: Rust
        
        Posté par Thomas Douillard le 17 octobre 2012 à 16:33. Évalué à 1.
        
        Évidemment, je ne diférencie pas vraiment les goroutines proprement dites des canaux qui vont avec. (cf. http://golang.org/ref/mem#tmp_2 )
  - [^] # Re: Rust
    
    Posté par gasche le 17 octobre 2012 à 14:58. Évalué à 6.
    
    Les goroutines n'ont rien de nouveau dans le sens où elles étaient déjà présentes sous des noms un peu différents dans toute la famille de langages de Rob Pike basé sur le formalisme CSP de Hoare (en gros, avec des canaux; cf. ici pour un historique). Newsqueak (qui a été développé en gros entre 1985 et 1990) avait un mot clé begin qui faisait comme go aujourd'hui, et ces fonctionnalités ont été repris par les langages Alef puis Limbo utilisés sur les systèmes basés sur Plan9. Le fait que ces langages aient bénéficié de moins de publicité que Go ne fait pas des goroutines une idée nouvelle : c'est quelque chose de bien connu des concepteurs de Go qui ont repris dans ce nouveau langage une idée qui marche bien. C'est bien ce mode "best-of" dont je parle, et je ne critique pas forcément, c'est utile d'avoir des langages qui consolident les acquis des développements précédents.
    
    Pour les traitements de la concurrence, j'apprécie personnellement beaucoup ce qui se fait dans le langage Oz/Mozart sorti en 1991, où le mécanisme de communication entre fils concurrents est une unification à la Prolog. Je trouve aussi intéressant ce qui se faisait sur le Join calculus (1995-2000), où on utilise une communication par canaux avec des conditions de réception sur plusieurs canaux simultanés (si machin, truc et bidule ont reçu des données et que l'entrée de bidule est de la forme chose), qui est une primitive expressive et assez intéressante.
- [^] # Re: Rust
  
  Posté par barmic le 17 octobre 2012 à 12:12. Évalué à 2.
  
  […] les concepteurs n'ont pas peur d'expérimenter et de faire encore longtemps des changements fondamentaux. Ça veut dire qu'il ne faut pas vouloir l'utiliser pour des projets sérieux à maintenir sur le long terme aujourd'hui, mais plutôt le voir comme un véhicule en déplacement.
  
  C'est ce qui fait qu'il est si bas dans ma liste des langages à tester. Je comprends bien leur volonté mais ça a tendance à m'exaspérer de voir de gros changements à prendre en compte dans le code.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Rust
  
  Posté par reno le 17 octobre 2012 à 14:50. Évalué à 4.
  
  un système de "traits", qui correspondent en fait assez exactement aux type classes de Haskell, pour transporter les implémentation. L'idée est qu'on définit des interfaces/traits
  
  Euh, tu peux préciser?
  Si j'en reviens à la base(C++) de l'héritage multiple, le problème principal est l'héritage en diamant quand les super-classes ont des variables, donc la règle de codage de C++ est de ne pas utiliser de variable dans les classes utilisée pour l'héritage multiple, en Java ils ont "résolu" le problème en faisant des interfaces sans implémentation ce qui est bien pénible car à chaque fois qu'on implémente une interface on doit l'implémentation, donc retour en arrière depuis on implémente avec des tas de noms différent (trait, mixin, etc) la "régle de codage" de C++: une classe ne contenant que des fonctions.
  
  J'ai bon? Ou c'est autre chose?
  - [^] # Re: Rust
    
    Posté par gasche le 17 octobre 2012 à 15:06. Évalué à 2.
    
    Les traits de rust sont en fait assez éloignés des traits/mixins des langages objets habituels puisqu'ils peuvent s'implémenter sur un peu n'importe quel type. Mais oui il y a l'idée qu'il s'agit d'un ensemble de fonction, que les traits ne portent eux-mêmes pas d'état, c'est le type sur lequel on implémente le trait qui doit porter l'état nécessaire.
    
    Si tu veux te renseigner sur les traits de Rust tu peux regarder la documentation (lire sur "impl" aussi en dessous, c'est lié) mais c'est un peu court en explications, ou alors ce billet qui explique l'état actuel après le changement du système de traits cet été, ou éventuellement ce document de travail qui explique les choix de conception.
# c'est la tuile

Posté par devnewton 🍺 (site web personnel) le 17 octobre 2012 à 12:19. Évalué à 3.

La plupart des frameworks, des jeux et des éditeurs de niveaux sont orientés "tuiles". Ce qui est dommage, car les tuiles sont un héritage des composants graphiques et des mémoires limitées des machines ancestrales.

Aujourd'hui, les tuiles n'ont plus de raisons d'être, elles peuvent même être contre performantes, mais on continue à les utiliser pour plusieurs raisons, l'une des plus importantes, selon moi, étant l'absence d'un bon (et libre) éditeur de niveau générique "non orientés tuiles".

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
- [^] # Re: c'est la tuile
  
  Posté par CrEv (site web personnel) le 19 octobre 2012 à 11:15. Évalué à 2.
  
  N'est-ce pas également plus simple d'utiliser les tuiles ?
  On a une grille et on pose dessus, pas très complexe, alors que ne pas gérer des tuiles est plus compliqué, non ?
  - [^] # Re: c'est la tuile
    
    Posté par devnewton 🍺 (site web personnel) le 19 octobre 2012 à 12:43. Évalué à 2.
    
    Les tuiles, c'est bien si tes niveaux sont tout carré, mais dès que tu veux gérer des formes différentes, c'est vite pénible.
    
    Par exemple dans le niveau sur lequel je travaille pour Newton Adventure, j'ai mis des plateformes qui sont des lignes obliques:
    
    http://opengameart.org/content/color-tileset
    
    Si tu télécharges le tileset, tu verras que pour dessiner une ligne, il me faut 3 tuiles: un pour le corps de la ligne, deux autres pour les raccords.
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Deux merci, un paquet de platitudes, une question sans intérêt, bref c'était complément inutile !

Posté par maboiteaspam le 17 octobre 2012 à 16:16. Évalué à 1.

Merci pour ces liens !

Concernant The State of Javascript, je comprends bien le but recherché. Re structurer ce langage pour faire face aux nouveaux défis qu'on lui demande.
Mais ceci dit, l'autre jour j'ai regardé ceci https://www.youtube.com/watch?v=v2ifWcnQs6M et je ne peux que m'étonné par ce désir, maintes fois exprimé, de vouloir re structurer un langage qui veut être déstructuré/versatil/bordélique[, ou ce qui te plait], le fameux concept du prototypage Vs déclaration de classe.

Bref, ce ES6 n'est il pas plutôt entrain de créer un nouveau langage sur lequel ils vont posé le nom javascript afin de surfer sur la vague ?
Mais bon la relation entre ecmascript et javascript me laisse un peu perplexe depuis longtemps déjà, je n'ai peut être donc pas tout compris.

Rust ou Go, mon désir se déchire au regard du temps disponible pour m'y investir…. Rust j'en avais lu la doc, je m'étais dis super ! Mais lorsque j'ai voulu coder je me suis refroidit devant les IDE disponible (note pour bientôt, chercher un IDE rust).
Go == Java == Javales pas bien… Le goût, la texture, vas savoir. Mais Sublime me fais bander alors je pourrais ptet bien me laisser faire :o

Enfin merci pour ces deux petits liens sur github/StratosJump, c'est bon pour les mirettes, c'est bon pour le moral.
- [^] # Re: Deux merci, un paquet de platitudes, une question sans intérêt, ....
  
  Posté par barmic le 17 octobre 2012 à 16:33. Évalué à 4.
  
  Go == Java
  
  Quel est le rapport entre les deux ? Je comprends bien qu'on puisse les « détester » chacun de leur coté mais je vois pas en quoi ils se rapprochent ?
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Deux merci, un paquet de platitudes, une question sans intérêt, ....
    
    Posté par maboiteaspam le 18 octobre 2012 à 17:10. Évalué à 1.
    
    hmmmmmmmmm la sortie est ici ->[], ça c'est bon, je n'ai pas de doute.
    Pour le go == Java, écoutes je sais pas d'où je sort cette stupidité…. Quelques lecture de surface surement, ou quelques lectures mal renseignées. Bref, je m'en retournes vers ma certitude présente, au passage je salue ta remarque pertinente.
    Me --> []
- [^] # Re: Deux merci, un paquet de platitudes, une question sans intérêt, bref c'était compl...
  
  Posté par maboiteaspam le 18 octobre 2012 à 17:16. Évalué à 1.
  
  Au passage, pour RUST
  -> https://github.com/mozilla/rust/issues/2109
  Et comme la news est bien faite, Sublime semble le supporter, un petit peu -> https://github.com/dbp/sublime-rust
  Le mieux étant de passer par http://wbond.net/sublime_packages/community
- [^] # Deux merci, un paquet de platitudes, une question sans intérêt, bref c'était complément inutile !
  
  Posté par CrEv (site web personnel) le 19 octobre 2012 à 11:19. Évalué à 2.
  
  Mais ceci dit, l'autre jour j'ai regardé ceci https://www.youtube.com/watch?v=v2ifWcnQs6M
  
  Je l'avais déjà inclus à la précédente :) https://linuxfr.org/users/crev/journaux/de-tout-de-rien-des-bookmarks-du-bla-bla-41#toc_7
  
  Bref, ce ES6 n'est il pas plutôt entrain de créer un nouveau langage sur lequel ils vont posé le nom javascript afin de surfer sur la vague ?
  
  Afin de surfer sur la vague je ne sais pas, mais oui c'est un peu ce que je pense en le voyant : un langage de plus, même s'il s'appelle pour le coups EcmaScript.
  A ne pas oublier dans tous ces langages ActionScript, qui basé sur ES permet déjà les classes et interfaces.
  
  Bref, comme toi je suis perplexe car je ne vois pas super bien l'intérêt. Javascript est étrange pour beaucoup, mais c'est surtout que ce n'est pas un langage à classe. Et vouloir à tout pris en faire un langage à classe me parait dommage.
  
  Par contre, j'ai pas compris non plus le rapprochement Go et Java. Si tu veux nous en dire plus…
# Bout de code en ruby

Posté par Oles le 17 octobre 2012 à 16:48. Évalué à 0.
Pour le bout de code en ruby :
```
# all i want is to sum the goddamn elements
sum = 0
(1..10).each_fucking_element { |e| sum += e }
```
C'est exactement le cas d'utilisation de la méthode #inject :
```
(1..10).inject(&:+)
```
Pour expliquer :
- (1..10) est une énumération des entiers de 1 à 10
- On applique la méthode inject est bien expliquée dans la doc mais en résumé :
  - on a un accumulateur (qui correspond à la variable sum du code précédent) et on fait une opération avec cet accumulateur et les valeurs du tableau.
  - Quand on ne précise pas la valeur de l'accumulateur, elle vaut le premier élément du tableau (1 ici)
  - On peut donc faire : (1..10).inject { |accu, val| accu += val } qui peut être condensé en (1..10).inject(&:+)
PS : Un matheux aurait dis que c'est

"Never trust a statistic you haven't faked yourself."
- [^] # Re: Bout de code en ruby
  
  Posté par Maz (site web personnel) le 17 octobre 2012 à 17:24. Évalué à 1.
  Le bout de code était là pour illustré la bibliothèque fsck. Il vient d'ailleurs du README.
  
  L'exemple suivant est d'ailleurs :
```
# inject rocks!
(1..10).awesome_inject_is_awesome(&:+)
```
  L'idée est de pouvoir écrire la méthode comme on veut, et la bibliothèque se débrouille pour appeler la bonne.
  Àma, à part pour le PoC, ça ne sert à rien :)
  - [^] # Re: Bout de code en ruby
    
    Posté par Oles le 18 octobre 2012 à 02:57. Évalué à 1.
    Oui, je pense qu'il ne trouvera pas les méthodes par magie non plus, par exemple :
```
`(0..10)`.fucking_transform_that { |i| i**2 }
```
    Après ça peut être amusant d'écrire des scripts avec des "fucking" partout.
    
    "Never trust a statistic you haven't faked yourself."
  - [^] # Re: Bout de code en ruby
    
    Posté par CrEv (site web personnel) le 19 octobre 2012 à 11:20. Évalué à 2.
    
    Àma, à part pour le PoC, ça ne sert à rien :)
    
    C'est bien pour ça que c'est absolument indispensable !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.