Open source et architecture logicielle

Mais comme tu donnes des conseils et distribue les bons et les mauvais points, je me suis amusé à regarder la qualité des articles que tu as produits. Alors quelle ne fut pas ma surprise de constater que tu n'avais rien produit. Même pas une petite source.

Mais ôtes moi d'un doute, tu ne serais pas de ceux qui ne font rien, sans doute faute de compétence ou en raison d'une hypertrichose palmaire et ne vivent que dans la critique systématique de ce qu'entreprennent les autres?

Si tu veux te rabaisser à un tel niveau d'absence d'argumentation, je ne peux rien faire pour toi. Personnellement, mon temps est plutôt consacré à la musique qu'à la veille technologique. Et si un jour il te vient à l'idée de critiquer l'une de mes compositions, je te remercierai d'avance de m'abattre d'une balle entre les deux yeux si la seule réponse qui me vient à l'esprit est "Si tu n'aimes pas ce que je fais tu n'as qu'à faire mieux".

Tu rejoins justement ma principale critique : poster des articles n'est pas une fin en soi. Si tu ne veux pas faire l'effort de rédiger des articles de qualité, fais comme moi, n'en poste pas du tout, tout le monde s'en portera mieux et cela laissera davantage de place à ceux qui font ce travail.

Hello,

Je pense qu'on peut m'appeler un fan-boy de JS, j'en fais depuis plus d'une décennie et ça reste mon langage de prédilection (je précise que j'ai aussi fait du C/C++/C#/Pascal/PHP/Java/Ruby/Python, et que je me suis intéressé à Swift/Dart/TypeScript/CofeeScript).

Pourtant, je rejoins l'avis des autres commentateurs, JavaScript certainement pas "le langage idéal pour le Big Data". Je pense d'ailleurs que la question n'a pas de sens du tout. J'ai eu la chance de pouvoir assister à plusieurs conférences sur le Big Data avec des témoignages de professionnels dans le domaine et ce que j'en ai retenu, c'est que le Big Data, ça peut être tout et n'importe quoi. Outils d'analyse, de visualisation, de "Business Intelligence", de machine learning, de topologie... Il faut déjà se mettre d'accord sur de quoi on parle au delà du buzzword "Big Data".

Concernant Hadoop, il faut rappeler plusieurs choses. D'abord, que Azure et Hadoop sont clairement pour les petits joueurs dans le domaine du Big Data. En volumétrie, on est à plusieurs ordres de grandeur en dessous d'autres secteurs comme la météo ou la recherche scientifique ; ensuite, que JavaScript n'intervient uniquement que comme couche présentée au client final pour effectuer ses requêtes sur le serveur distant Hadoop. C'est la partie émergée de l'iceberg, voire la couche de peinture sur la maison. On est très, très loin de couvrir tout le périmètre du Big Data.

La question peut alors être reformulée en quel est le langage idéal pour permettre à des utilisateurs non initiés d'effectuer (basiquement) des map reduce ? Et là, la réponse est effectivement : JavaScript, langage aujourd'hui le plus populaire et démocratisé, conçu pour être haut-niveau, multi-paradigme et simple d'accès aux débutants. Seulement, cette réponse est totalement déconnectée du thème du Big Data. Il n'y a rien dans les fondements du langage qui le prédestinent au Big Data. L'immense majorité des environnements JavaScript s'exécutent en single thread. Et le garbage collector en JS est extrêmement consommateur (mais tellement pratique).

Même pour le tout petit usecase de l'interface de requête de Hadoop, cet article semble indiquer que HiveQL est nettement supérieur en performances à la couche JavaScript. Ce genre de bench est toujours à prendre des pincettes, car on peut optimiser de maintes manières un code écrit en n'importe quel langage. Quoiqu'il en soit, c'est une manière de contrer très rapidement l'argumentaire exposé ici.

@sodium

Visiblement nous nous sommes dit tout ce que nous avions à nous dire.
Il est évident que nous ne partirons pas en vacances ensemble.

Donc dans la mesure où tu ne souhaites pas émettre la moindre critique sur le fond de mon article, comme sylvain vient de le faire de manière aussi intéressante que pédagogique, je te demanderai de ne plus intervenir sur ce fil.

Bonne soirée

Sylvain,
Merci pour ce cours express sur le Big Data. Une fois encore tu réussis à vulgariser pour nous un sujet aussi récent que complexe.
En effet tu as raison, j'aurais dû adopter pour le titre quel est le langage idéal pour permettre à des utilisateurs non initiés d'effectuer (basiquement) des MapReduce.
Ça aurait restreint le champ d'analyse et mis la barre à un niveau compatible avec ce langage.
Je viens de terminer de lire l'article que tu conseilles, et c'est vrai que ce qui y est exposé est antagoniste de mon billet. Donc coté perf je m'incline, JavaScript n'est pas le langage idoine pour cette plateforme.

Je suis assez d'accord avec Sodium.

Tu mentionnes souvent des "faits" en les présentant comme des vérités démontrées alors que ce n'est souvent que ton ressenti. Et sur certains points que je connais plus particulièrement, je pense que tu te trompes complètement.

De plus, je pense que tu devrais plutôt remercier Sodium d'avoir pris le temps de faire ses remarques. Personnellement, je ne lis généralement même plus tes articles.

Envoyé par groharpon42

Et sur certains points que je connais plus particulièrement, je pense que tu te trompes complètement.

Tu peux préciser car là je ne suis pas soufflé par la logique de ta démonstration.

[QUOTE=autran;bt2529]Tu peux préciser car là je ne suis pas soufflé par la logique de ta démonstration.[/QUOTE]

Ni moi de tes démonstrations encore une fois...

Par exemple la dernière phrase de ton article : "Je conclurai mon propos en faisant remarquer que l'implémentation des modèles de conception big data, voire machine learning, sont largement aussi faciles à implémenter en JavaScript qu'en C++ et Java."

Il se trouve que j'ai utilisé pas mal d'outils de machine learning récemment, et ce n'est vraiment pas ce que j'ai constaté. Maintenant, je n'ai pas la patience de Sodium donc vérifie par toi-même et tu verras vite.

Envoyé par groharpon42

Ni moi de tes démonstrations encore une fois...

C'est pour ça que j'ai posté une démonstration sur l'algorithme MapReduce en JavaScript ainsi que des mesures très précises de célérité qui visiblement n'appellent pas de commentaires !

Gardez à l'esprit que Microsoft propose TypeScript qui permet de générer du Javascript.
https://www.typescriptlang.org/play/index.html

Un statisticien va trouver que le meilleur framework BigData est R (oui, c'est plus un framework qu'un language = syntaxe R + toute les API de stats disponibles)

Dans tous les cas, il faut toujours garder à l'esprit que JavaScript reste et restera un langage qu'on utilise par défaut, parce que l'on a pas le choix et pas parce qu'il est plus performant ou efficace qu'un autre.
Il a d'énormes faiblesses qui rendent son utilisation problématique et est dépendant dans la majorité de ses usages du client, chaque client ayant sa propre manière d'interpréter le JavaScript.
Il suffit de remonter aux origines de JavaScript pour se convaincre qu'il s'est construit au petit bonheur la chance, avec des ajouts par ci, des retraits par là, des harmonisations mais jamais totales.
Ca me rappelle un peu la norme MIDI utilisé en musique depuis des décennies, elle est clairement à la ramasse et gagnerait à être remplacée par quelque chose de plus pratique et performant, mais elle est tellement implantée que sa suppression parait difficilement envisageable.

@rthomas
[Introduction pour ne pas que Sodium gueule]
Oui pour R je constate également que les mathématiciens (statisticiens) développent sur cet outil depuis quelques temps. Dans la mesure où ce sont bien les mathématiciens qui vont écrire le Big Data de demain ça vaut le coup de se demander si R ne va pas s’imposer comme le langage back office de ce domaine.

[Thèse : sinon sodium va dire que je n’ai pas de plan]
En plus, si les mathématiciens choisissent un langage, il y a des chances qu’il ait une durée de vie plus longue que les langages habituels. En effet, dans le Big Data, c’est plus les équations qui sortent de leurs cerveaux que la technologie dans laquelle ils l’implémentent qui apporte de la valeur.

[Antithèse : là Sodium va me dire que ça n’en est pas une, il me dira encore qu’une anti-thèse est systématiquement opposée à la thèse]
Sans vouloir jouer au papy, je me rappelle que dans les années 80 j’étais obligé de faire du Fortran car toutes les bibliothèques mathématiques et scientifiques y étaient portées.

[Conclusion en forme de question : pour que sodium puisse dire que je ne synthétise pas l’argumentaire supra donc que le travail et bâclé et que je devrais aller jouer au billes]
Devrions-nous faire face à un phénomène similaire ? R serait-il le fortran de demain ?

Envoyé par Sodium

Dans tous les cas, il faut toujours garder à l'esprit que JavaScript reste et restera un langage qu'on utilise par défaut, parce que l'on a pas le choix et pas parce qu'il est plus performant ou efficace qu'un autre.
Il a d'énormes faiblesses qui rendent son utilisation problématique et est dépendant dans la majorité de ses usages du client, chaque client ayant sa propre manière d'interpréter le JavaScript.

C'est faux, je fais du JavaScript par choix. On a le choix du langage, il y a des centaines de langages compilant en JavaScript, et pourtant JavaScript est le langage le plus populaire actuellement. Comment expliques-tu cela ?

Aussi, Node.js s'avère plus performant pour certaines applications back que les équivalents Java. Il y a une raison pour laquelle il est utilisé par Walmart pour gérer les pics d'utilisateurs au Black Friday (des centaines de millions d'utilisateurs concurrents). J'ai pu le vérifier expérimentalement avec des benchmarks, et mes résultats ont été confirmés par d'autres équipes dans ma boîte. Ce qui fait qu'on a plusieurs projets de migration d'applications en cours vers du Node.js.

Sur la question du support, aujourd'hui les navigateurs modernes ont un excellent support de JS, uniforme et vérifié par tout un panel de tests génériques. On peut en plus se servir d'un transpilateur et d'un service comme Autopolyfiller pour venir élarger son support. L'époque IE6 est révolue.

Envoyé par SylvainPV

C'est faux, je fais du JavaScript par choix. On a le choix du langage, il y a des centaines de langages compilant en JavaScript, et pourtant JavaScript est le langage le plus populaire actuellement. Comment expliques-tu cela ?.

Je l'explique tout simplement par le fait que JavaScript reste incontournable quand on fait du web. Même si l'objectif est de passer par la suite à un langage compilant en JavaScript, connaître ce dernier est un minimum, ne serais-ce que pour comprendre 95% du code rédigé par d'autres développeurs.
Venons-en ensuite à ces fameux langage compilés : c'est tout d'abord une complication supplémentaire puisque que l'on rajoute une couche entre son travail et le navigateur. Aucun d'entre eux ensuite n'est suffisamment établi et de manière durable pour devenir un standard qui mérite que l'on s'y consacre à plein temps.
TypeScript etc c'est bien joli, j'y ai touché un peu, mais reste que personne ne peut avoir la certitude qu'ils seront encore en place et pertinents dans cinq ans.
Je terminerai par le fait que ce n'est pas parce qu'une technologie est populaire qu'elle est un bon choix, quel que soit le domaine et l'époque (rappelons-nous le duel Edison-Tesla).

Envoyé par SylvainPV

C'est faux, je fais du JavaScript par choix. On a le choix du langage, il y a des centaines de langages compilant en JavaScript, et pourtant JavaScript est le langage le plus populaire actuellement. Comment expliques-tu cela ?

Aussi, Node.js s'avère plus performant pour certaines applications back que les équivalents Java. Il y a une raison pour laquelle il est utilisé par Walmart pour gérer les pics d'utilisateurs au Black Friday (des centaines de millions d'utilisateurs concurrents). J'ai pu le vérifier expérimentalement avec des benchmarks, et mes résultats ont été confirmés par d'autres équipes dans ma boîte. Ce qui fait qu'on a plusieurs projets de migration d'applications en cours vers du Node.js..

Encore faut-il qu'on t'autorise à utiliser un langage qui compile vers JS, après il est dit le plus populaire mais pas le plus apprécié, c'est surtout ça son problème un langage qu'on utilise beaucoup mais qu'on apprécie pas forcément (à part pour certains, mais la majorité des dev web que je connais essayent au maximum de ne pas en faire tellement ils le détestent), toute façon ça devrait enfin changer dans quelques années grâce à Webassembly.

Et je pense que la différence de perf entre node et java est surtout du à la lourdeur du framework et de tous les outils nécessaire au fonctionnement du WebService, sinon le JS est un langage assez lent vu qu'il est interprété.

Pour en revenir au sujet, je pense que si Microsoft ou d'autres acteurs utilisent JS, c'est parce que JS (ES5) est un langage simple et que HTML5 a démocratisé ce langage.
Une autre raison pour Microsoft serait peut-être parce que ce dernier a effectué des efforts pour mettre en place TypeScript (qui est une surcouche de JS ES6).
Pour moi le langage le plus simple pour requêter une base de données est sans conteste le langage SQL, syntaxe beaucoup plus simple que le map/reduce, par contre je ne doute pas du fait que c'est beaucoup plus difficile à implémenter que R ou JS.
Bref, vu la tournure actuelle des choses (Angular2 en TypeScript qui est un clone de ActionScript/Java/C#, démarrage de WebAssembly, intégration des annotations de typage de ES7), le JS tel qu'on le connait actuellement (cf: ES5) n'existera plus vraiment même si la rétrocompatibilité est assurée.

Considéré qu'un langage soit idéale pour le Big Data à mon avis c'est considérer qu'il s'agit d'une problématique unique or le Big Data c'est des problématiques aussi diverses que variées. Il faut prendre un cas spécifique pour pouvoir dire la techno qui lui soit idéale mais pas une seule techno pour tous les cas de figures possibles.

Envoyé par youtpout978

mais la majorité des dev web que je connais essayent au maximum de ne pas en faire tellement ils le détestent).

On ne doit pas fréquenter les mêmes sphères Voilà de quoi ouvrir tes horizons : il existe bel et bien un grand nombre de passionnés de JS, qui se rencontrent lors des nombreuses conférences et meet-ups locaux, et contribuent à des projets open source (JS 1er langage sur Github).

Je trouve ça idiot de venir ici faire du bashing d'un langage de prog alors que vous savez pertinemment qu'il y a des professionnels et des passionnés de ce langage en face. C'est de la provocation bête et méchante, et je ne pense pas que ça mènera à quelque-chose de constructif. Bref, mieux vaut s'arrêter là.

Envoyé par SylvainPV

On ne doit pas fréquenter les mêmes sphères Voilà de quoi ouvrir tes horizons : il existe bel et bien un grand nombre de passionnés de JS, qui se rencontrent lors des nombreuses conférences et meet-ups locaux, et contribuent à des projets open source (JS 1er langage sur Github).

Désolé mais encore une fois, la seule conclusion que l'on peut tirer du fait que des gens utilisent une technologie est que ces gens utilisent cette technologie, pas qu'ils l'apprécient particulièrement ou qu'elle est réellement performante et efficace.
Il est heureux qu'il y ait de nombreux projets JavaScript vu que JavaScript est le seul langage supporté côté client sur pratiquement tous les navigateurs.
JavaScript est également probablement le langage qui a donné naissance au plus grand-nombre de proto-langages et langages alternatifs faisant la compilation. Les jQuery, TypeScript, Dart, Angular etc sont là parce que les développeurs n'ont pas envie de faire du JavaScript, parce que JavaScript est un frein dans leurs développements.

Si l'ont voulait faire un parallèle idiot, nous respectons tous les lois de la gravité. Cela signifie-t-il que nous apprécions particulièrement cette dernière, qu'elle est idéale ? Personnellement, si je pouvais de temps à autre l'ignorer et aller faire quelques figures aériennes à toute vitesse, je trouverais ça très bien.

Vu que la discussion arrive sur les inconvénients de JS... Voilà qui illustre une partie de la haine de certain :

Devoir faire ça :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
for (var i = 0; i < beaches.length; i++) {
    var beach = beaches[i];
    $("#toto").text(beach["name"]);
    var marker = new google.maps.Marker({
     ...
    });
    (function fuckJS(beach)  {
       google.maps.event.addListener(marker, 'mouseover', function() {
       marker.setIcon(get_marker_from_business_id(beach["business_id"]));
     });
    })(beach);

À la place de ça :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
for (var i = 0; i < beaches.length; i++) {
    var beach = beaches[i];
    $("#toto").text(beach["name"]);
    var marker = new google.maps.Marker({
      ...
    });
    google.maps.event.addListener(marker, 'mouseover', function() {
       marker.setIcon(get_marker_from_business_id(beach["business_id"]));
     });

Vous pouvez appeler ça une feature, mais pour les gens qui viennent du monde C-like, ça s'appelle "un inconvénient".

@kabaman

Oui tu as raison il serait intéressant dans l'absolu de différentier les différents types de Big Data. Mais j'ai peur qu'un tel découpage ne soit d'une part un peu arbitraire, et d'autre part ne colle pas à la réalité des besoins.

Arbitraire car il faut se choisir des axes de différentiation. Alors certains diront que l’élément discriminant est le volume des données, d'autres penseront que c'est multiplicité des sources (et les données multimodales !)
De ce classement, on essaiera de définir des architectures, des plateformes et bien entendu des langages. Mais comme le Big Data est vraiment le domaine où les exigences changent à la vitesse de la lumière, j'ai peur que l'architecture idoine en juin ne soit plus en adéquation avec les nouveaux besoins de septembre.

Alors mon propos est de dire que si une propriété caractérise ce nouveau domaine et qu'un langage intègre bien cette propriété alors il est probablement un bon vecteur de résolution des problématiques du domaine.
Or je remarque que 2 dimensions importantes du Big Data sont le web et la mobilité. Je remarque également que JavaScript est nativement dédiés à ces 2 dimensions.
Voila pourquoi j'évoquais le JavaScript comme un langage que l'on ne doit pas écarter du nouvel écosystème Big Data.

Néanmoins, peut-être (sans doute même) que pour la partie calcul à haute performance sur des cluster de Zseries d'autres langages comme R lui seront préférés.