Le 27/06/2018 à 11h 57

Zerdligham a écrit :



Ce que tu décris est un manque de perfectionnement de la librairie de parsing plus qu’un défaut du langage lui-même. Des librairies plus performantes existent.

Sinon si tu valides pas tes inputs avant de les traiter, il y a un problème à chercher ailleurs que dans le langage utilisé " />

 





Ah, alors comment le parseur pourrait deviner les informations de type? Je ne vois pas comment ce serait possible puisqu’elles disparaissent au runtime. On est obligé de se refrapper un second typage custom propre au parseur (comme avec la lib que j’ai citée plus haut, type-check), qui vient s’ajouter aux types définis en typescript. C’est juste lourdingue à utiliser. (Mais s’il existe d’autres solutions je serais heureux de l’apprendre)



Tandis que dans d’autres langages le parser connaît le type (par exemple en java, on fournit un .class concerné, en go il se débrouille avec juste la référence de l’objet)

 





Zerdligham a écrit :



Je ne suis pas trop d’accord. Si tu mets du any partout c’est par facilité, le langage offre tous les outils pour ne pas avoir à le faire.

Rien ne t’empêche de faire toi-même quelques définitions, ou de caster proprement les résultats ‘garantis’ de la lib, comme on cast les résultats void* de tout un tas de fonctions C génériques (pas toujours explicitement d’ailleurs).





Ben ça c’est dans un cas merveilleux où les devs javascript d’une lib donnée ne mettent pas tout et n’importe quoi dans un objet. Va définir un type pour un objet complètement polymorphe, qui peut recevoir des valeurs, ou pas, dans 30 champs différents, où un champ donné peut représenter tour à tour un nombre, une string, une fonction… C’est pas impossible mais tu te retrouves  avec tellement d’optionnels et d’union types que tu ne seras certainement pas avancé à la fin. Je pense par exemple à “d3”, lib bien connue des amateurs de graphes. Même dans les tests des définitions de types c’est bourré de “any” : GitHub .



Sans compter qu’à la moindre mise à jour d’une lib qu’on aurait typé soit-même il faut de nouveau tout revérifier.

 

Le 26/06/2018 à 16h 52

Je suis d’accord tu peux faire des cast dégueulasses en C, mais ce genre

de choses se voit dans le code. Le comportement par défaut est safe, si

tu veux être unsafe tu dois le rendre explicite => pour moi c’est la

bonne façon d’appréhender les choses.



 Typescript règle une

bonne partie des problèmes du javascript mais malheureusement pas tout. Un exemple simple: tu récupères du JSON d’un appel HTTP. Ce json va être désérialisé avec quelque chose du genre JSON.parse . Là, avec typescript tu définis le type de l’objet reçu. Tu n’as aucune garantie à la compilation que le json matche le type indiqué. Si ça pète ce sera au runtime. Tu me diras, c’est exactement pareil avec n’importe quel langage quand on parse du texte. Sauf qu’avec un autre langage, c’est à la déserialisation que ça va échouer, donc immédiatement (donc “fail fast”) tandis qu’avec typescript, le compilo a beau avoir les informations de typage, au runtime (JS) il n’y en a plus aucune donc JS/TS ne peut pas reporter d’erreur rapidement, ce qui fait que l’erreur risque de se propager bien plus loin dans les appels et sera potentiellement beaucoup plus difficile à détecter. (il y a des libs qui existent pour ce genre de chose, comme “typecheck” si mes souvenirs sont bons, mais assez relou à utiliser).



Ça peut paraître lointain ce genre de préoccupation mais perso je l’ai vue et revue cette situation.



Sinon y’a aussi le fait que pour s’interfacer avec bon nombre de libs JS il faut encore utiliser du “any” à tout bout de champ (donc l’intérêt de typescript s’envole).

Le 26/06/2018 à 16h 20

Ben oui, je trouve que typescript est un super langage, sa plus grande faiblesse c’est qu’au runtime ça reste du javascript donc toutes les erreurs de typages peuvent “leaker” malgré tout.

Le 26/06/2018 à 16h 15

th3squal a écrit :



Ce n’est plus le petit langage de scripting pour apprendre sur une page web, c’est un langage qui actuellement possède beaucoup d’atouts vis à vis d’autres langages plus évolués (Class, Prototyping, Closures, etc)





/troll on

Le jour où il y aura du typage statique et que les erreurs ne te pèteront plus à la figure au runtime on pourra dire que c’est un langage sérieux :-)

Le 08/01/2018 à 22h 49

Ils disent aussi:

 “Because microbenchmarks like netperf/uperf, iozone, and fio are designed

to stress a specific hardware component or operation, their results are

not generally representative of customer workload. Some microbenchmarks

have shown a larger performance impact, related to the specific area

they stress.”

 

Ou encore:

  “If an application is running on a system that has consumed the full

capacity of memory and CPU, the overhead of this fix may overload a

system payload, resulting in more significant performance degradation.”



 Bref, ces tests ne correspondent pas exactement à des cas d’utilisation concrets.

A priori, les PC personnels n’ont pas grand chose à craindre (mais nous verrons bien), ce sont plutôt les solutions d’entreprises (cloud/virtualisation/etc) qui pourraient souffrir. A noter qu’un provider cloud a intérêt à utiliser au maximum les capacités de ses machines pour les rentabiliser. C’est là où ça peut faire mal.

Le 11/12/2017 à 09h 48

Sauf que si tu veux faire tourner les algos de machine learning pour améliorer la prédiction, tu vas pas le faire sur le petit snapdragon de ton smartphone. Je ne sais pas si ai.type fait du machine learning, mais ce ne serait pas déconnant.

Le 06/12/2017 à 13h 04

Non mais faut pas exagérer, mettre un mot de passe sur une base mongo (on parle pas de chiffrer le contenu hein, on parle juste de mettre un mot de passe) c’est pas ça qui coûte de l’argent, n’importe qui peut le faire en 2 minutes. Il n’y a aucun intérêt à ne pas le faire, vraiment j’en vois aucun, ou alors faudra m’expliquer plus en détail. A part l’ignorance, je vois pas.

Le 06/12/2017 à 12h 20

Va savoir… J’ai trouvé ça un peu gros aussi comme gaffe, au premier abord… puis je suis allé voir leur linked-in qui recense 12 employés, on peut deviner plus de la moitié en marketing, bref, ça n’a pas l’air d’être si pointu techniquement. Surtout du bla-bla. Je parierais plutôt sur de l’amateurisme :-)

Le 06/12/2017 à 12h 13

Bah non c’est sans doute pas intentionnel, en tout cas je vois pas l’intérêt. Ils peuvent même pas revendre les données puisqu’elles sont librement accessibles. C’est juste de l’amateurisme.

Le 06/12/2017 à 10h 40

anagrys a écrit :



 



En tout cas elles ne sortent pas de chez Apple (ou Google pour Android).

Ou pas…? " />





Difficile à dire, mais au moins elles ne se retrouveront pas sur un serveur MongoDB librement accessible sans authentification ni chiffrement!

Le 06/12/2017 à 08h 45

FlamingFlowair a écrit :



Hmm, en même temps, la présence des contacts dans les prédictions du clavier sont utiles bien que pas indispensable.





Exact. De même, l’enregistrement des séquences de mots sera utilisée pour les prédictions futures.

Reste que ça donne aux claviers virtuels un rôle ultra sensible qui nécessite une attention toute particulière de google/apple.

Le 06/12/2017 à 08h 21

Quoi de mieux qu’un clavier virtuel pour faire un keylogger? " />



Les apps permettant de remplacer le clavier virtuel devraient

systématiquement être auditées par google/apple avant d’atterrir sur les

stores.

Le 08/12/2017 à 11h 20

ra-mon a écrit :



Si ça se trouve, ils demandent aussi à Google, en contrepartie de l’intégration rémunératrice en tant que moteur de recherche par défaut, de scrupuleusement respecter la vie privée, au moins des utilisateurs de Firefox qui cherchent par défaut chez eux " />





C’est beau de rêver  " />

Mais je crois que dans ce domaine, Google n’est prêt à aucun compromis.

Le 07/12/2017 à 08h 04

Ce que tu dis vaut aussi pour les champs avec auto-completion, je vois mal comment on pourrait faire le distingo entre les deux, dans les deux cas on transmet au serveur des données non validées. Ce n’est pas la technique en elle même qui est répréhensible, mais sa finalité.

Le 06/12/2017 à 15h 09

NaviStone ne fait pas de l’auto-completion , elle fait du ciblage comportemental. Donc il y a fort à parier qu’en effet, elle collecte un maximum d’informations pouvant traduire les centres d’intérêts des utilisateurs.

Le 10/01/2017 à 16h 46

Ceci dit il y a fort à parier que parmi les bases piratées, il y a un bon pourcentage de déchets, des bases abandonnées ou utilisées pour des choses tout à fait secondaires, qui expliqueraient un tel laxisme.

Le 10/01/2017 à 16h 42

CryoGen a écrit :



Non mais là c’est pas le problème, il s’agit d’un problème de config, aucune mise à jour ne peut régler çà simplement en général. A moins d’y aller à coup de diff ou autre, ca ne peut être fait en automatique… on parle de solution pro tout de même.





Non seulement ça, mais en plus pour sécuriser il va bien falloir mettre un mot de passe, ou configurer quelque chose… je vois pas comment ne pas passer par la case “config”.

Le 20/08/2015 à 14h 39

“En clair, l’éditeur espère faire de Go la plateforme de développement à

tout faire, réduisant pour les développeurs le besoin de recouvrir à un

trop grand nombre de langages différents. Un créneau déjà assez

concurrentiel, avec notamment Xamarin pour faire le lien vers

l’environnement .NET.”

 

Je dirais qu’au contraire, en faisant des ponts vers C/C++ Google encourage la fragmentation: il s’adresse aux développeurs qui maintiennent une appli legacy C/C++ et qui souhaitent évoluer en douceur vers un langage plus moderne sans devoir tout réécrire en one-shot.

Le 20/08/2015 à 14h 27

Si on devait comparer Go à un autre langage ce serait plutôt Rust: des langages proches de C/C++, orientés performances (quoique encore en deçà de C/C++) mais également orientés déploiement (une des “philosophies” de Go étant le packaging monolithique, l’appli Go contient en elle-même toutes ses dépendances, pas de library externe). Il en résulte moins de soucis de dépendances, mais des livrables plus encombrants.

 



Par contre ce qui est moche dans Go, c’est que tous les concepts modernes passent à la trappe, en ce qui concerne la programmation fonctionnelle. Tout ce que peuvent apporter des langages comme Scala / Haskell / Java 8 (streams) etc. De ce point de vue, Go est très “old school”.

Le 10/09/2014 à 08h 47

Leynas a écrit :



facepalm



Pour arriver à faire un raccourci pareil faut vraiment… non, je ne vois même pas comment on peut y arriver en fait.



Leynas.







Raccourci? Quel raccourci? Je dis simplement que je ne vois pas comment on peut légiférer de façon globale sur les “algorithmes prédictifs”, c’est un terme qui englobe beaucoup plus de choses que ce qui est visé politiquement. Ce sont les domaines d’application qui doivent être ciblés, pas les “algorithmes”, ça ne voudrait rien dire.

Le 10/09/2014 à 07h 17

Hem.. est-ce que le conseil d’état sait ce que signifie “algorithme”? La définition est très large, n’importe quel programme informatique contient des algorithmes qui vont effectuer des choix sans intervention humaine, c’est même la base de l’informatique…. le Conseil d’Etat voudrait lutter contre l’informatique?

Le 27/08/2014 à 17h 30

Jed08 a écrit :



En quoi avoir deux modes de jeux différents totalement indépendant est mauvais pour le jeux ?







Vu le passif de la boîte, y’a de quoi être inquiet quant à la qualité du mode solo. Alors si en plus y’a des signaux négatifs envoyés sur le multi, on peut présager du pire…