TImaniac a écrit 6420 commentaires

Quels étaient les parts de marchés d'iOS et d'Android deux années après leur lancement ?

2 ans après son lancement, Android était à 4.7% : tu considères que c'était un bide ? On verra à la fin de l'année où en sera Windows Phone, mais c'est clairement dans le même ordre de grandeur. Un écosystème OS/Fabriquants/Editeur, ca prend pas 6 mois à se construire.

http://pocketnow.com/smartphone-news/android-captures-47-market-share-in-2009

Si je suis le seul à croire que Microsoft risque de lancer son propre smartphone Windows Phone 8

Tu es surtout le seul à prétendre que ca sera pour la fin de l'année quand tout le monde dit que ca ne sera pas avant 2013.

. En juillet 2011 Steve Balmer déclarait lui même « En ce qui concerne Windows Phone, nous sommes passés de très petit à très petit ».

Soit 9 mois après la sortie du système. J'ai pas trouvé de stat d'Android pour juillet 2008 (Android est sorti fin 2007), mais vu qu'il était qu'à 4,7% fin 2009, il devait également être "très petit".

Ah, drôle de compilateur. C'est un choix un peu étrange pour un langage de haut niveau.

Drôle de programmeur plutôt. C'est effectivement complètement con, c'est bien pour ça que c'est pas le cas le plus courant : dans les cas les plus courants où le typage est utilisé, le compilateur peut faire son boulot de garde fou.

En l'occurrence, l'outil automatique t'oblige à utiliser un autre langage (Typescript) pour lequel l'expérience est beaucoup moins répandue que pour Javascript. Ce n'est pas un inconvénient mineur.

On est d'accord, c'est un inconvénient. Mais on gagne : une sémantique clair pour la programmation OO que tout le monde comprend, un typage fort et tous les avantages qui vont avec : détection d'erreurs, inférence de type, complétion dans l'IDE.

ta bagnole ne refuse pas de démarrer si tu ne mets pas ta ceinture de sécurité, et ne s'arrête pas de rouler si tu passes un sens interdit.

Tout comme le compilateur t'empêche pas de compiler si tu décides de tout foutre dans des types 'object' et que tu mets des cast partout, et tout comme le flic t'empêche de rouler si tu grilles un sens interdit.

Tu ne réponds pas à mon objection, à savoir qu'un compilateur n'est pas ce qui te prémunit contre des bugs.

Ca te prémunis contre certains bugs. Pas tous les bugs, c'est évident. S'en passer, c'est déporter le problème sur une autre phase de la qualif (tests unitaires, tests fonctionnelles, tests du singe), et c'est perdre un bel outil automatique qui ne coûte pas grand chose.

Ils font le même genre d'erreurs, simplement ils « corrigent » à qui mieux-mieux quand le compilateur les envoie bouler.

C'est toujours mieux que de pas être averti et de ne rien corriger.

Pour ma part, je pense qu'il est tout à fait raisonnable de maîtriser du code qu'on n'a pas écrit (et même parfois mieux que le programmeur original), mais ce serait intéressant que tu assumes ton opinion, si elle est contraire.

La question n'est pas de savoir si c'est possible ou pas, je pars juste d'un constat : devant un code inconnu et donc non maîtrisé, un développeur à tendance à remplacer par son propre code plutôt que de chercher à maîtriser le code d'un autre. Je dis pas que c'est pertinent, c'est juste un constat.

Windows Phone 7 est un cuisant échec, une étude de comScore dit que Windows Phone a perdu 0.4 % de part de marché sur un trimestre aux États-Unis, c'est un secret pour personne

En cherchant, on trouve toujours le chiffre qui nous intéresse.

Moi je te parle d'évolution sur 2 ans, pas d'une tendance sur 3 mois dans un pays en particulier : Windows Phone est sur une pente croissante, certes douce, mais croissante. Ses parts de marchés oscillent entre 3 et 10% suivant les pays (5% en moyenne en europe, http://www.mobiletoday.co.uk/News/22732/windows_phone_verge_overtaking_RIM_OS_Wars.aspx) , pour une plateforme sortie il y a à peine 2 ans, c'est tout sauf un bide. Android faisait pas mieux 2 ans après sa sortie.

D'ailleurs Microsoft risque de lancer son propre smartphone Windows Phone 8 avant la fin de l'année, c'est un signe de grande confiance vis à vis de son partenaire Nokia. LOL

Merci Madame Irma, personne à part toi n'y crois. Les seuls rumeurs qui courent parlent de 2013.

Oui, bien sûr, sauf que le compilateur n'est pas « très important » dans l'histoire.

Il est important parcqu'il est la première barrière que rencontre le programmeur. C'est comme dire que la ceinture de sécurité ou le panneau "sens interdit" ne sert à rien : oui tu peux te mettre la ceinture autour de la gorge, tu peux ignorer le sens interdit, ca ne les rends pas moins utiles pour les gens normaux.

on peut très bien écrire du code buggé à mort, mais qui satisfait les exigences de typage du compilateur.

En théorie on peut tout faire sans le typage, tout foutre dans des types "object". Quand on est décidé à faire de la merde, je te le confirmes, on y arrivera toujours : on peut effectivement être un développeur complètement con, c'est un choix.

Vaudrait mieux qu'il le corrige.

Correction linguistique sur mon anglicisme ? Ou comment se focaliser sur la forme quand on a rien à dire sur le fond.

Heu non, heureusement, on peut maîtriser un code sans l'avoir écrit soi-même (mais peut-être pas en Perl ou Javascript, je l'admets).

C'était juste pour faire sourire : c'est bien entendu exagéré mais pas très loin de la vérité tout de même ;)

J'ai jamais dis que c'était utile en pratique, c'est toi qui a voulu jouer sur les mots et être précis. Je suis précis : TypeScript marche dans les navigateurs web, que ce soit le compilateur en lui-même ou le code généré.

lignes. Quand tu commences à pondre des applications de plusieurs (dizaine de) milliers lignes, fait par plusieurs équipes et qui vont devoir être maintenues sur le long terme (t'écris pas ce genre de trucs pour tout balancer dans 12 mois) c'est vachement moins drôle et tu comprends qu'on cherche à proposer des solutions un peu plus adaptées.

On est d'accord. La logique de Microsoft est juste de surfer sur la vague du JavaScript : beaucoup de développeurs formé depuis ces 5 dernières années ont commencé par ce langage et ne connaissent que ca. Que ce soit un site web HTML5 moderne avec 1000 lignes de code, une appli codé pour Windows 8 en JavaScript (oui on peut), ou encore les OS mobiles avec des frameworks "web", TypeScript répond à ces attentes.

On est d'accord, pour tout le reste, y'a d'autres langages.

Pour le modèle spécifique de Microsoft, je n'ai aucune idée de ce qui sera livré avec. Je suis pas dans la confidence désolé.

Il y a une différence entre la théorie et la vraie vie. Tout ingénieur a une vie et n'est pas amené à maintenir pendant 50 ans toutes les lignes de code qu'il a écrit. Bref, y'a toujours un couillon pour passer derrière toi : avant de maîtriser ton code (traduction technique : tout réécrit), il faut bien qu'il fixe rapidement un bug remonté par le client. Et là t'es bien content d'avoir tout une palanqué de garde fou pour s'assurer qu'il n'a pas casser tout le soft : plan de tests, tests unitaire, documentation… et compilateur.

Comme tous les écrans capacitifs avec un stylet adapté, la réponse est clairement oui.
(testé et approuvé sur une tablette Samsung Slate 7 sous Win8).

Windows Phone a des parts de marché a peu prêt similaire à celles d'iOS ou Android 2 ans après leurs lancement respectifs. Au handicap prêt pour Windows Phone que iOS et Android sont déjà présents. Donc non, c'est loin d'être un échec, bien au contraire.

Oui, si ca te convient, très bien. Mais maintenant tu as le choix : TypeScript marche tout de suite maintenant. Tu as le choix, et c'est très bien.

Pour quelqu'un de motivé, tout peut être développé avec n'importe quoi.
C'est pas pour autant que c'est un bon choix.

et pourtant de "gros" projet ont était fait avec ces langages.
C'est l'histoire : tu choisis avec les outils de ton époque. C'est pas parcque les hommes préhistoriques faisait du feu avec des silex que tu vas continuer : depuis le briquet a été inventé. Ce que tu prétends, c'est qu'il est inutile de remplacer un outil par un autre, en ignorant les avancées et apports des nouveaux outils. C'est de la négation pur et simple de la réalité.

est cool, mais le propre d'un langage dynamique c'est justement de ne pas typer et de laisser d'un coté le développeur réfléchir, de l'autre l'interpréteur faire "ce qu'il faut", c'est un choix c'est tout

Non ca n'a strictement aucun intérêt d'un point de vue ingénierie logicielle. Laisser le développeur faire nawak, c'est produire un code inmaintenable, pas le développeur lui-même : 1 an après il aura oublié son délire dynamique du moment (expérience inside). Idem pour l'interpréteur : faire ce qu'il faut est en fait "faire ce qu'il peut".

On peut faire des gros projets en JavaScript, comme avec n'importe quel langage, et avec autant de facilité et d'efficacité.

Tu prétends, tu affirmes, et t'as aucun argument. C'est impossible de continuer plus loin avec ce genre d'affirmation. A t'écouter, tous les langages se valent, même facilité, même efficacité. C'est soit de la mauvaise foi, soit une véritable ignorance de la vraie vie de développement.

niveau, et vouloir utiliser l'un pour générer du code d'un autre dans l'espoir de ne pas avoir à apprendre l'autre est illusoire, on ne gagne rien

Tu ignores là encore l'apport / avantages que proposes TypeScript. Tu prétends juste qu'on ne gagne rien, mais ton argumentation est totalement vide.

ou ce qu'on gagne on le paiera de toute façon un jour ou l'autre…

Tu as pointé un risque : la bombe à retardement (bug compilo toussa). Dans 99% des cas pratique, c'est à dire un site web avec du code JavaScript, on s'en branle total : la durée de vie d'un script web est tellement ridicule qu'on peut largement négliger la durée de vie sur le long terme des outils afférent et de la fameuse "bombe à retardement". Tu fais un système bancaire prévu pour 20 ans, là OK, tu réfléchi à 2 fois avant d'utiliser tel ou tel outil. Par contre pour faire un script web, tu t'en cognes, tu prends ce qui marche là tout de suite maintenant et qui te fait gagner du temps.

T'as juste rien compris : y'a rien d'idéologique dans TypeScript : c'est purement pragmatique. Microsoft vend des outils de dev, Visual Studio en tête. Ce qui fait la force de Visual Studio, c'est l'intellisense : completion à tous les étages. Tout dépend donc de la sémantique du langage : d'où TypeScript.

Ben non, Typescript n'est pas utilisable dans les navigateurs. Soyons précis.

Ben si, parcque le compilateur TypeScript est écrit en TypeScript (et donc en javascript), ce qui veut dire que tu peux compiler du TypeScript depuis le navigateur lui-même.

Pour s'en convaincre, suffit de tester : http://www.typescriptlang.org/Playground/

Aucun langage n'est conçu pour (ou contre) le dev de gros projets.

Bien sûr que si. Un "gros" projet nécessite de bosser à plusieurs et nécessite des milliers de ligne de code : les caractéristiques d'un langage peuvent grandement aider à gérer ces situations :
- Un langage fortement typé pour valider un maximum d'erreur à la compilation : très important quand l'on modifie un code que l'on ne maîtrise pas, faire du refactoring, générer des diagrammes de classe, ou encore inférer l'arbre des dépendances du projet et comprendre/maintenir un gros projet.
- Un langage défini la façon d'écrire les modules/composants/bibliothèques : il en découle la façon/possibilité de découper l'application en modules distincts et la facilité à comprendre/maintenir le bousin.
- qui dit gros projet, dis aussi performances, répartition de charge, etc. : là encore, des caractéristiques du langage peuvent grandement influencer sur le type de programme que l'on peut réaliser, et intrinséquement limité les gros projets : modèle mémoire, modèle de thread (suffit de voir le modèle de "thread" de Python pour s'en convaincre), gestion des appels synchrones/asynchrones.

C'est la façon dont on l'utilise et la rigueur que l'on s'impose qui permet ou pas de faire un gros dev.

Oui, on peut toujours utiliser le mauvais outil, et avec un peu de rigueur réussir à découper une feuille avec un scalpel ou à l'inverse ouvrir un ventre avec une paire de ciseau pour écolier. C'est pas pour autant que les outils ne sont pas prévus et conçu pour un usage particulier.

Mais générer du code de haut niveau à partir d'un code de haut niveau, c'est juste de la masturbation intellectuelle, c'est marrant sur le papier mais ça ne fait pas avancer le chmilblick.

C'est ignorer/balayer les avantages apportés par ce nouveau langage. Tu n'as aucun argument à part prétendre que ca ne sert à rien. Pourtant le but recherché est louable et les apports non négligeables.

Tout langage est compliqué tant qu'on ne l'a pas appris, c'est vrai avec les langages humains (le chinois, le japonais, le sanscrit, ça vous parait simple ?), et c'est vrai en informatique.

Donc pour toi tous les langages sont aussi dur/simples à apprendre : le mandarin est aussi simple que l'esperanto ?
Il faut plus de 10 ans pour être expert C++, et encore, je suis convaincu que même après ce temps on apprend toujours des subtilités du langages. Alors que d'autres langages (Ruby par exemple) sont beaucoup plus faciles à apprendre.

écrit probablement dans un troisième langage

Faux, il est écrit en typescript lui-même.

c'est de l'utopie que de croire qu'on se simplifie la vie, on ne fait que s'entourer de bombes à retardement.

C'est l'histoire de l'informatique, c'est toi même qui le dit. Si on refuse se risque, on écrit tout en binaire, même l'assembleur est une bombe à retardement.

Sauf que TypeScript est déjà utilisable aujourd'hui, dans tous les navigateurs, sur tous les OS. Pas comme Dart.

La définition des classes n'est qu'un des aspects de TypeScript : le but est d'obtenir un langage fortement typé avec inférence de type pour obtenir tout ce qui fait la force des langages fortement typés : erreurs à la compilation plutôt qu'à l'exe, complétion automatique dans l'IDE.

Ca explique le besoin de développer une solution en interne, mais ca n'explique absoluement pas la précipitation à sortir une version aussi peu complète. Apple le reconnaît lui même qu'il y a encore beaucoup de boulot.

Tu vois Apple dire "eh regardez, en fait notre produit était en fait basé sur l'innovation d'un concurrent et ils sont méchants ils nous lâchent maintenant on est obligé de faire de la merde !"

C'est pas sérieux.

Non, cela serait idiot de la part de Google de laisser tomber Apple, car cela pousserait Apple à créer/aider un concurrent à google map.

Moi je trouve ca au contraire malin : la carto devient un élément de plus en plus différenciable sur mobile de part les services qui en découle (géoloc, guidage auto, RA, etc.). Quoiqu'on en disent, Apple a une image auprès du public de qualité, de haut de gamme là où Google a une image beaucoup moins bonne.
Google sait pertinement qu'Apple ne peut pas construire un équivalent en 5min, c'était l'occasion rêver de descendre Apple de son piedestal sur le terrain de la qualité/haut de gamme tout en promouvant son propre service. Et c'est exactement ce qui se passe : l'info et reprise partout, même sur les médias généralistes habitués à encenser Apple.

Sinon comment expliquer la situation actuelle ? Apple aurait très bien pu continuer à développer sa solution et attendre iOS 7 pour la sortir dans un meilleur état : clairement ca sent la précipitation. Comment expliquer ca autrement que par une pression de fin de contrat du fournisseur Google ?

Bosser sur leur carto et attendre iO7 pour le lancer…
Et donc ne rien avoir dans iOS 6 ?

Mais non, il faut faire "la guerre nucléaire" contre Google

Et si c'était Google qui venait de lâcher une bombe en refusant de renouveler leur contrat ? (Ce qui serait assez logique vu que Google est un concurrent direct).

Il aurait simplement gardé google map un peu plus longtemps.

Euh, tu crois pas que dans l'histoire c'était aussi une volonté de Google de ne plus alimenter le concurrent ? Google a les moyens de refuser les G€ de Jobs…

Ils ont 100 G€ de cash, ils peuvent acheter spot image, tomtom, garmin, etc… Ils ont largement les moyens de faire aussi bien que Google.

Le problème, on le voit, ce n'est pas que les vues satellites, c'est aussi StreetView et toutes les données "non visuelles" (nom des rues, des stations, etc.). Même à coup de G€, ca ne se construit pas en 5min une telle base.

Quelque chose me dit que les acteurs ont pas forcement d'intérêt d'alimenter Apple : Jobs a fait l'erreur de s'appuyer sur Google, il en était dépendant : la cure de désintox est visiblement douloureuse, et je vois pas bien en quoi Jobs y aurait changé grand chose.

En même temps Jobs aurait fait quoi ? Rachter Google ou Nokia pour avoir des données de carto potable ? Pas terrible pour l'image d'Apple qui se contente plutôt de rachter des startups ou des technos sans visibilité publique…
Bref, Jobs aurait probablement pas fait mieux, en l'occurence c'est Google qui mène le jeu.