JavaScript est devenu un langage omniprésent dans WinRT, la plateforme utilisée par Microsoft pour les téléphones et la partie tactile de Windows 8.
Or, ce langage n'a pas été conçus pour le développement de gros projets et Microsoft veut remédier à cela avec le langage TypeScript.
http://www.typescriptlang.org/
Contrairement à des projets comme Dart (le langage de Google) qui cherche à remplacer JavaScript, TypeScript propose un compilateur qui génère du code javascript (c'est à la mode en ce moment on dirait de faire des langages qui génère du code dans un autre langage…).
Pour l'exemple, vous pouvez jouer sur cette page à modifier du code TypeScript et voir le résultat en JavaScript.
http://www.typescriptlang.org/Playground/
Le projet est sous licence Apache 2.0:
http://typescript.codeplex.com/SourceControl/changeset/view/fe3bc0bfce1f#LICENSE.txt
# EEE
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à -5.
De l'open-source chez mirosoft ? Ils sont vraiment si mal que ça ?
Ou bien ne s'agirait-il pas de la sempiternelle trilogie « Embrace, extend, extinguish » ?
Du coup, même si à l'instant tout semble ouvert et compatible avec les standards, les utilisateurs téméraires auront bien intérêt à prendre garde aux évolutions ultérieures qui risqueraient de faire écho aux propos de S. McNeally sur le coût des barrières à la sortie ; coût qui ne manquera vraisemblablement pas de grimper ultérieurement.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: EEE
Posté par Emmanuel C . Évalué à 9.
Microsoft est une entité composite dont tous les composants ne pensent pas de la même manière…
[^] # Re: EEE
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à -2.
Mais dans un corps n'est-ce pas la tête qui décide relativement indépendamment des « appréciation » des organes exécutants ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: EEE
Posté par ckyl . Évalué à 5.
T'as déjà mis les pieds dans une grosse boite ?
[^] # Re: EEE
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à -2.
La plus grosse de France !
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: EEE
Posté par fmaz fmaz . Évalué à 1.
L'éducation nationale ?
[^] # Re: EEE
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 1.
Oui, même si les artisans prétendent nous dépasser. Toujours est-il que je ne vois pas bien le rapport entre cette question et le schmilblick.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: EEE
Posté par ckyl . Évalué à 2.
Ton assertion supposant qu'une entreprise était un tout dirigé par une tête pensante me paraissait déconnectée de la réalité. Tu le confirmes ;)
[^] # Re: EEE
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 0.
Nonobstant les possibilités d'initiatives locales, dès qu'un projet atteint une amplitude suffisante, je ne doute guère que la tête pensante se charge de l'orienter et de définir les stratégies. Imagineriez-vous les grands cadres exécutifs laisser libre cours aux vagabondages de leurs subordonnées si ceux-ci devaient impacter significativement l'image et les bénéfices de la société ?
D'où mon commentaire. l'EEE est une stratégie usuelle des éditeurs de logiciels privateurs. Et ma candeur me pousse à fantasmer que, dans d'éventuelles conditions favorables, elle pourrait bien être employée à nouveau ici. Sans doute s'agit-il là d'une vision trop naïve. Après tout, quand microsot parle d'open source, il s'agit évidemment de vrai open source garantissant les libertés des utilisateurs et des développeurs sur le long terme, comme le soulignait un prospectus publicitaire cité par la revue de presse de l'April.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: EEE
Posté par windu.2b . Évalué à 6.
Pôle Emploi !
[^] # Re: EEE
Posté par Serge Julien . Évalué à 1.
Il y a bien longtemps que Microsoft fait de l'open source. Microsoft a même déjà contribué à Linux (le noyau).
[^] # Re: EEE
Posté par liberforce (site web personnel) . Évalué à 10.
Sous la contrainte, rappelons-le, car Microsoft enfreignait la GPL en ne diffusant pas le source.
# dart et js
Posté par CrEv (site web personnel) . Évalué à 10.
Hum, presque. Car, même si tu as raison le but est de remplacer javascript, dart peut aussi être compilé en javascript.
# Une autre possibilité que l'opensource ?
Posté par mazarini . Évalué à 1.
Je ne connais la part que représente IE dans les navigateurs, mais je pense qu'un langage qui resterai cantonné à IE n'aurai pas d'avenir.
Le langage et le compilateur pourront être opensource, ca n'empêchera pas Microsoft de vendre un Visual-Typescript bien au contraire.
[^] # Re: Une autre possibilité que l'opensource ?
Posté par ckyl . Évalué à 3.
Ça pourrait ne pas être open source tout en visant tout les navigateurs. Ca compile vers du Javascript. Rien ne t'empêche de vendre le produit.
Après si tu veux pousser ton langage, dans ce domaine et actuellement c'est juste suicidaire de ne pas le rendre le Open Source. Trop de compétition et trop dirigé les webdevs pour réussir actuellement réussir ce tour de force sans leur aide.
# Classes
Posté par Damien Thébault . Évalué à 2.
À première vue, ça semble surtout changer la définition des classes, le reste restant en javascript classique.
C'est plutôt intéressant à mon avis, car effectivement la définition de classes en javascript n'est pas très jolie. De plus ça permet à un IDE de détecter les classes et donc de simplifier l'écriture de code (complétion, etc.).
[^] # Re: Classes
Posté par CrEv (site web personnel) . Évalué à 6.
Oué enfin ça c'est plutôt normal, javascript n'est simplement pas un langage à classe. C'est un langage à prototype.
Donc que les "simili-classes" en javascript ne soient pas jolies reste tout à fait normal.
[^] # Re: Classes
Posté par coïn . Évalué à -1.
D'après toi, on ne peut pas être belle et intelligente. intéressant concept :)
[^] # Re: Classes
Posté par CrEv (site web personnel) . Évalué à 2.
lapin compris le rapport avec le commentaire.
Personne ne parle d'"intelligence" dans l'histoire, le commentaire parlait juste de jolie.
Et oui, les classes en javascript ne sont ni belles, ni intelligentes, elles n'existent simplement pas.
[^] # Re: Classes
Posté par TImaniac (site web personnel) . Évalué à 4.
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.
# haXe
Posté par animal_omega . Évalué à 10.
Connaissez-vous haXe ?
C'est un langage moderne, fortement typé, et une bibliotheque multiplateforme.
Le compilateur peut générer du c++, php, javascript, flash, c# et java (bientôt).
c'est un vrai bonheur de pouvoir partager le code d'une classe coté serveur et coté client (par exemple validation d'un formulaire).
haXe contient aussi un mécanisme de communication client-serveur très efficace.
Tout ça en opensource, et avec une mailing-list réactive.
Bref, ça vaut le coup d'y jeter un oeil.
http://haxe.org/doc/features
# Compilateur
Posté par barmic . Évalué à 10.
Ça fait une cinquantaine d'années que c'est la mode.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par Marotte ⛧ . Évalué à 1.
Effectivement, ça s'appelle la métaprogrammation.
Et en LISP il arrive même que l'on fasse du code qui génère du code dans ce même langage, me semble-t-il.
[^] # Re: Compilateur
Posté par barmic . Évalué à 10.
Pas forcément, c'est la définition d'un compilateur :
Compilateur
Donc on parle d'un peu avant encore fortran, cobol et A-0 (en 52).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par calandoa . Évalué à -1.
Et sinon, les mouches, c'est si bon que ça ? Moi je prefère en rester aux chèvres. Ahhhh… Daisy….
[^] # Re: Compilateur
Posté par ckyl . Évalué à 1.
Oui enfin il y a eu un changement assez fondamental ces dernières années. Les contraintes d'interopérabilité, de gestion de l'existant, de disponibilité de la compétence sur le marché du travail, de contraintes d'ecosystème, des efforts pour industrialiser et optimiser une plateforme etc. font qu'il devient très difficile de pousser une nouvelle technologie.
C'est le cas ici avec le langage de programmation côté client pour les webapps. Vouloir remplacer Javascript est un doux rêve. Il y a 10 ou 15 ans on aurait totalement pu imaginer qu'un acteur arrive avec son langage en tant que plugin et prenne le marché. Actuellement pas grand monde n'imagine pouvoir réussir ce tour de force. Donc on travail à fournir des outils qui vont compléter ou améliorer le socle de base que l'on considère comme acquis.
Tu constates le même schema avec Java. C'est là, la VM est là personne ne veut lutter de manière frontale alors on vise l'existant comme plateforme cible.
Bref avant on faisait soit du fait d'un choix technique ou de la facilité (juste un frontend à coder), maintenant c'est bien plus une obligation.
Et ca se produit dans beaucoup de domaines (combien de système d'exploitation de recherche ces dernières années ?).
[^] # Re: Compilateur
Posté par barmic . Évalué à 4.
Je n'ai pas dis le contraire. J'ai juste dis que sous-entendre que le fait d'écrire des compilateurs n'avait rien d'un effet de mode.
La nouveauté comme tu dis c'est que le langage cible est un langage de (très) haut niveau.
C'est un peu différent. Rare sont les compilateurs qui génèrent du Java. Il est plus simple est agréable de générer du bytecode pour la JVM que de faire une double compilation (nouveau langage -> Java -> Bytecode).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par ckyl . Évalué à -3.
D'autres portes ouvertes à enfoncer en se forcant à lire les choses au premier degré ? ;)
Exactement la même chose: Tu es obligé de cibler la plateforme cible s'est imposée. Là encore tu lis ce que tu veux lire.
[^] # Re: Compilateur
Posté par barmic . Évalué à 4.
Non, je cherche juste à amener de la précision. Critiquer c'est bien quand on critique quelque chose de précis. Si on critique quelque chose de vague (comme l'ensemble des compilateurs), ça n'a plus de sens (et ça ne sert plus à rien). Au contraire se forcer à faire la démarche de se demander ce qui nous gène (ou nous surprend) exactement dans une solution est quelque chose qui me semble plus important.
Par exemple je trouve bien plus pertinent quelqu'un qui va dire que pour lui laisser sa gestion des données à une entreprise est mauvais plutôt que de dire que le cloud c'est nul.
J'apportais une précision rien de plus. Le bytecode java est une forme d'assembleur (il existe des projets pour écrire des CPU qui décodent du bytecode, c'est pour ça que je me permet de le rapprocher d'un langage machine). C'est la même chose que de se focaliser sur l’architecture i386 (et ça n'a toujours rien de nouveau donc).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par ckyl . Évalué à -1.
Tu vois tu veux lire le truc au premier degré. Tu veux utiliser la définition stricte de compilateur, que tout étudiant qui à mis les pieds en première année connait au passage, pour occulter le message intéressant de sa phrase.
JS pose un paquet de problèmes, mais comme on personne n'espère pouvoir le virer et que les VM JS ont fait des progrès phénoménaux ces dernières années on a en ce moment énormément de propositions de langage qui ciblent le JS comme langage cible. On cible par dépit et non par choix ce qui influence grandement le design des solutions (interaction entre les langages, possibilité de debugging etc.).
Et lire comme ca c'est vachement plus intéressant que de tuer toute discussion utile en sortant "Un compilateur de toute façon ca compile d'un langage A vers un langage B rien de nouveau". Certes mais après ?
Encore une fois c'est enfoncer une porte ouverte, tout le monde le sait ca. Par contre réfléchir à pourquoi tant de projets visant la JVM comme cible ont éclos ces 5 dernières années alors que la plateforme n'a pas été conçue pour cela et qu'auparavant on préférait (ou avait la possibilité de) se réécrire toute sa stack ca c'est intéressant.
Et c'est encore plus intéressant de voir qu'il y a autant d'arguments techniques qu'une évolution profonde du marché de l'informatique. Ce qui était possible il y a dix ans ne l'est souvent plus.
[^] # Re: Compilateur
Posté par barmic . Évalué à 3.
Je cherche à ce que les mots gardent du sens, en quoi c'est un problème ?
Tu vois c'est pas si difficile d'expliciter le fond de sa pensée et c'est la différence entre un troll moisi et une critique constructive.
Justement tu m'a vu dire plus haut que ce qui a changé c'est que maintenant on écris des compilateur vers des langages de haut niveau. Tenter d'interpréter surtout sur internet c'est la base d'un tas de quiproquo parfaitement inutile. Donner une critique précise amène une discussion, sortir des généralité sans la moindre argumentation ça n'a pas plus d'intérêt que de sens.
Parlons de fond.
Ce sont des technologies largement déployées (que ce soit java ou javascript). On ne peut pas critiquer un langage d'avoir trop de succès. Ni l'un ni l'autre n'ont étaient obligatoires. C'est juste qu'ils sont arrivé au moment opportun pour répondre à un besoin de manière suffisamment correct pour être accepté par tous. Pour le cas de la JVM je ne suis pas sûr que la plupart des langages qui tournent dessus n'aient pas fait un choix intentionnel d'utiliser java pour profiter des bibliothèques et autres technologies annexes. C'est évidement le cas de jython, mais je ne sais pas ce qu'il en est de scala et grrovy. Je pense qu'il est par exemple agréable de profiter d'un environnement d'exécution déjà disponible et qui t'abstrait des spécificités du système d'exploitation (ça apporte d'autre contraintes, c'est un choix à faire).
Ouai c'est pas forcément plus mal. Multiplier les runtimes c'est pas pratique pour l'utilisateur et ça rend l'ensemble bien moins fiable. Actuellement il y a un tas de monde qui bossent pour améliorer les environnements javascript pour améliorer les performances mais aussi la sécurité par exemple. Si tu crée 15 environnements différent, il faudra porter les 15 sur 4 OS, qui peuvent chacun avoir leur faille et leur problème de performance. De la même manière tu divise les bibliothèque (chacune doit faire son choix). Bref réinventer la roue tout les 4 matins, ça empêche de mutualiser les développements.
C'est aussi bien plus pratique pour l'utilisateur, c'est déjà trop d'avoir flash, silverlight et java qui peuvent s'exécuter dans le navigateur si tu ajoute dart et typescript ça deviendra infernal pour l'utilisateur.
C'est aussi pas plus mal pour les développeurs qui peuvent faire vivre leur application sans avoir à les ré-écrire from scratch tout les 2 ans quand les modes changent.
Tout cela pour dire qu'il faut vraiment avoir un apport important pour qu'il devienne intéressant de changer. Avoir des classes un peu plus jolies ou un peu plus de performances c'est loin d'être suffisant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par pasBill pasGates . Évalué à -1.
si tu ajoute dart et typescript ça deviendra infernal pour l'utilisateur.
Visiblement tu n'as pas compris ce qu'est typescript. typescript genere une seule chose : du javascript, que n'importe quel browser moderne peut executer.
Typescript est la pour les developpeurs : leur permettre d'ecrire de gros softs de maniere plus robuste en rajoutant des annotations et autres elts syntaxique, mais en sortie c'est du javascript pur et dur.
[^] # Re: Compilateur
Posté par Anonyme . Évalué à -2.
Je crois que c'est toi qui n'a visiblement pas compris que personne n'est en train de dire dans cette discussion que typescript ne genere pas du javascript.
[^] # Re: Compilateur
Posté par pasBill pasGates . Évalué à -2.
C'est aussi bien plus pratique pour l'utilisateur, c'est déjà trop d'avoir flash, silverlight et java qui peuvent s'exécuter dans le navigateur si tu ajoute dart et typescript ça deviendra infernal pour l'utilisateur
Visiblement j'ai bien compris au contraire.
[^] # Re: Compilateur
Posté par barmic . Évalué à 1.
Je me suis mal exprimé. Je disais que si dart et typescript avaient leur propre runtime ce serait invivable pour les utilisateurs.
Je sais que c'est l'objectif de dart mais pour le moment il génère juste du javascript.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par gasche . Évalué à 4. Dernière modification le 04 octobre 2012 à 10:30.
Je trouve qu'il y a un problème dans votre discussion qui vient en partie de toi. cykl est venu sur ce topic avec une remarque pertinente et intéressante qui voulait dire ce qu'elle voulait dire. Ensuite vous vous êtes chamaillés pour des raisons de forme sans grand intérêt, jusqu'à qu'il répète ce qu'il voulait dire en encore plus détaillé, et tu lui réponds :
En plus dans tout le fil ses messages (qui sont ceux qui apportent réellement du contenu, au moins jusqu'à ton "Parlons de fond") sont à des notes négatives et les tiens à des notes élevées, ce qui rend les siens plus difficile à lire et donne une fausse impression que la partie intéressante de la discussion est de ton côté—mais ça tu n'es pas responsable, ce sont les lecteurs de LinuxFR qui notent comme des branques.
Je ne sais pas si on peut dire que ton comportement pose problème : tu es de bonne fois, et si on cherchait à distribuer des blâmes on commencerait par accuser cykl d'avoir réagi de façon agressive. Mais on a un problème quand le contenu intéressant est noyé dans les remarques purement réthoriques, et quand les gens se mettent à penser qu'une argumentation n'est pas valide ou "constructive" tant qu'elle n'est pas explicitée dans le moindre détail. Je suis désolé mais le passage que tu cites comme "explicitant le fond de [sa] pensée" n'apporte pas grand chose par rapport à sa formulation initiale que tu sembles pourtant qualifier de "troll moisi".
Il faut arrêter d'avoir une attitude passive-agressive vis-à-vis des messages d'autrui, c'est aussi à nous, lecteurs et lectrices, de réfléchir à ce qui est dit et faire un effort pour comprendre l'argumentation en profondeur, au lieu de juste répondre des platitudes pour forcer l'intervenant à dérouler son propos et nous éviter tout effort de réflexion. Ta remarque a un ton de "tu vois, j'ai bien fait de chipoter et nous en avons tous profité", mais je pense que c'est une erreur est qu'en réalité cette discussion a été alourdie par des messages moins pertinents que nous aurions pu éviter.
Ce n'est pas une attaque contre toi en particulier et je ne dis pas que ton comportement dans ce fil de discussion est particulièrement désagréable—au contraire, je vois très souvent des façons de discuter bien pire sur LinuxFR. Mais j'utilise cet exemple pour souligner un problème qu'a ce site à mon avis, où les discussions ne peuvent souvent pas se dérouler normalement et de façon intéressante. L'ambiance n'est pas très agréable et ça n'invite pas au contenu technique pertinent.
D'ailleurs très peu de choses intéressantes ont été dites sur ce fil; je vous invite à comparer avec les discussions du même sujet sur Reddit (et encore ce n'est qu'un des fils de discussion, il y a aussi celle-ci par exemple. Alors certes, c'est un forum anglophone donc il y a plus de monde et donc plus de compétences ce qui amène à plus de discussion technique, mais il y aussi des francophones bien informés sur ces sujets, et s'ils évitent de discuter sur LinuxFR à mon avis c'est en partie liée à l'ambiance souvent hostile présente ici.
[^] # Re: Compilateur
Posté par barmic . Évalué à 1.
J'en suis bien désolé (ou pas). Je n'ai pas voulu faire de remarques sur ce qu'a dis cykl (sur le fond on est d'accord depuis le début), mais sur la forme de la remarque dans le journal. C'était l'objet de ma remarque initiale et ça l'est resté jusqu'à ce que je dise que je parle du fond.
Oh. Et alors ? Dès le départ je parle de la forme si quelqu'un voulait parler du fond il aurait mieux était avisé de créer un autre fil (c'est l'une des grande force de linuxfr autant s'en servir).
Pourquoi j'ai réagis comme ça ? C'est simplement comme je l'ai déjà dis plus haut que je pense qu'une critique est constructive surtout si elle est précise, car c'est comme ça que l'on va au fond des choses et qu'on met le doigt sur le vrai problème au lieu d'avoir des discussions de comptoir sur des lieux communs. J'ai tout à fait compris ce qu'il voulais dire, mais je craignais que lui même ne soit pas allé plus loin dans la réflexion. Ça ne coûte pas bien chère d'être précis, mais ça demande à avoir soit même mis au clair ces idées.
Mon message initial aurait aussi pu être plus constructif. J'aurais pu directement dire que le problème n'est pas d'avoir des compilateurs mais d'avoir un appauvrissement de l'écosystème du fait que le compilateur vise javascript comme langage cible. Je le reconnais volontiers. C'est le ton du journal qui ne m'a pas donné envie d'en faire plus.
Tu remarquera qu'au final j'ai donné une liste d'arguments qui explique en quoi ce n'est pas si mal.
La comparaison avec Reddit est foireuse. Le journal n'a que peu de ressemblance avec celui de reddit. Sur ce dernier il parle technique et montre des aspects concrets de typescript (je ne suis pas certains de savoir comment fonctionne ce site), l'histoire nous montre que des journaux (ou dépêches) qui parlent technique ont des commentaires techniques. Au contraire un journal qui s'amuse à lancer des petites piques à droite à gauche (surtout quand ce n'est pas approfondis) génère généralement du troll. Dis autrement « on récolte les commentaires que l'on sème ».
Tu prend le problème à l'envers (même si je suis d'accord qu'il y a un coté cercle vicieux). Les contenus techniques amènent des discussions techniques. Les dépêches du noyau, la dépêche sur les builders aussi, les journaux de CrEv « De tout, de rien, des bookmarks, du bla bla », … en sont des exemples. Les journaux/dépêches orientent la discussions c'est un fait qui me semble indiscutable.
Maintenant si vous le voulais bien monsieur le professeur, je m'en vais arrêter de nourrir ce troll déjà bien trop gros et vous convie à en faire de même.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par gasche . Évalué à 3.
Excuse-moi, ma formulation était fausse. Je voulais dire que peu de choses intéressantes avaient été dits dans l'ensemble des commentaires de ce journal.
Je ne suis pas du tout d'accord avec cette vision des choses. Pour moi ce type de journal est là avant tout pour amener la discussion sur un sujet donné (ici Typescript). On ne va pas refaire un nouveau journal TypeScript pour dire "ici le journal technique, là-bas c'était le journal pour les trolls". Pour avoir une discussion intéressante il faudrait que les participants se sentent incités à contribuer des commentaires pertinents, intéressants et constructifs sur le sujet du journal.
D'ailleurs je ne vois pas en quoi le journal présent "s'amuse à lancer des petites piques de droite à gauche", au contraire le message de gnumdk est très neutre et en reste aux aspects objectifs sans aucun commentaire sur la politique sous-jacente ou quoi. Le journal est concis et n'entre pas dans les détails techniques mais je comprends ça comme "je lance la discussion avec le minimum, je vous encourage à apporter votre contenu en commentaires".
Du coup je ne sais pas trop quoi penser de ton idée selon laquelle il y a des journaux qui orientent vers de la technique et d'autre qui orientent vers le troll. Quand je parle de technique ce n'est pas pour glorifier les aspects les plus informaticiens ou de recherche, c'est à prendre au sens large (un journal sur le cinéma je m'attends à trouver une discussion intéressante sur le cinéma, donc "poussée, approfondie, constructive, intéressante" serait plus adapté que "technique" pour qualifier la discussion que j'aimerais trouver). Est-ce qu'il y aurait sur LinuxFR des journaux amenant à ce genre de discussion, et d'autres servant de défouloir parce qu'ils "lancent des piques" et donnent donc un signal que c'est le journal où on peut se chamailler un peu dans le vide ? Dans ce cas là peut-on discuter de la proportion entre les journaux "intéressants" et les journaux "défouloir" ? Laquelle est-elle aujourd'hui, et peut-on la faire évoluer ?
Moi mon dada principal c'est l'étude des langages de programmation. Je viens voir les discussions sur les langages de programmation (Coffeescript, Go, TypeScript, Ceylon, whatever) quand elles ont lieu sur LinuxFR, et je suis systématiquement déçu. Peut-être que ces discussions envoient des signaux ambigus aux gens qui, comme tu l'expliques, s'auto-modèrent en fonction du ton qu'ils observent dans le contenu existant, et voient surtout du troll là où il y aurait de la place pour du contenu intéressant.
[^] # Re: Compilateur
Posté par ckyl . Évalué à 1.
Perso quelque soit le sujet je trouve le ratio signal/bruit de plus en plus mauvais. Très peu de discussions techniques, factuelles, objectives ou de bonnes blagues pour beaucoup de cours de recrée et de je critique tout. Je crois que ceux qui codaient vraiment sont majoritairement plus ou moins partis…
[^] # Re: Compilateur
Posté par calandoa . Évalué à 1.
Au contraire ! C'est à ça qu'on reconnait les meilleurs codeurs : ils ont le souci du détail et ils ne lâcheront jamais l'affaire même sur un point ridicule :^ )
[^] # Re: Compilateur
Posté par gasche . Évalué à 3. Dernière modification le 04 octobre 2012 à 13:55.
N'ayant été que très irrégulièrement actif sur LinuxFR, je ne pourrai pas commenter sur l'aspect "c'était mieux avant", mais je suis d'accord sur le fait que le rapport signal/bruit pose problème aujourd'hui, et c'est pour ça que j'essaie d'en parler un peu plus.
[^] # Re: Compilateur
Posté par calandoa . Évalué à 2.
« J'apportais une précision rien de plus. Le bytecode java est une forme d'assembleur »
N'importe quoi, c'est un non sens total et j'ai du réfléchir au moins 3h18 et 42 secondes pour comprendre ce que tu voulais dire ; forcement, lorsqu'on utilise des mots qui ne sont pas les bons alors qu'on se la joue grand expert de la sémantique, on ne peut plus se faire comprendre.
L'assembleur, c'est un langage lisible pour l'humain, avec des mnémoniques et des labels qui est transformable en code binaire par une translation direct, sans que l'outil n'ai à faire de choix au niveau du code à générer. Un compilo java ne produit pas d'assembleur du tout, loin de là, vraiment, faut vraiment être à la ramasse au niveau des compilos pour croire une absurdité pareille !
(Bon, ça y est, tu as compris pourquoi c'est pas bien d'enculer les mouches et de monter sur des grands chauves hauts parce que un mot dans une phrase n'est pas strictement le bon alors que le sens est tout à fait compréhensible ?)
Ah, et au passage, histoire d'ajouter une anecdote utile à ce thread vain : les premiers compilos C++ généraient du C.
[^] # Re: Compilateur
Posté par barmic . Évalué à 1.
Tu as raison, j'ai utilisé un raccourcis. Dommage tout de même que tu n'es pas lu la phrase jusqu'au point, ça t'aurais évité d'avoir à interprété.
Je dis juste que je n'aime pas quand on lance des piques avec tellement peu de précision que la phrase n'a plus de sens. Ça pourrait s'apparenter à du FUD. Mais bon je l'ai déjà dis 3 reprises, je présume que si mon message devait être compris ce serait déjà le cas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par brendel . Évalué à 1.
Heu pas trop compris, il est bien possible de passer du bytecode Java (version mnémonique (addi, ect)) à sa forme binaire? Dans ce cas la c'est un assembleur, surtout que comme dit il y a des processeurs qui décode la forme binaire du bytecode…
[^] # Re: Compilateur
Posté par gasche . Évalué à 2.
Sans reprendre le ton contestataire du précédent message, l'auteur a raison: on ne peut pas trop considérer le bytecode JVM comme "un assembleur" parce qu'il est trop spécialisé à certains langages de programmation bien particuliers (Java) et pas une bonne cible généraliste pour tous les langages (contrairement aux vrais jeux d'instruction des processeur qui, malgré une légère tendance à favoriser ce qui ressemble à du C (pile d'appel tout ça), sont très polyvalents). L'existence d'immondices technologiques qui interprètent le bytecode directement en hard ne justifie pas trop cet amalgamme, ou alors avec une notion de "code machine" très large qui passe à côté de distinctions importantes (celles que faisait cykl dans son message initial).
Le fait de se forcer à viser la JVM comme langage cible d'une étape de compilation est donc bien un choix pragmatique entre base de support utilisateur et réelle pertinence technique, comme le choix aujourd'hui de viser Javascript. Et dans les deux cas on a des gens qui font pression pour intégrer peu à peu à la plateforme de quoi en faire de meilleures cibles polyvalents.
[^] # Re: Compilateur
Posté par brendel . Évalué à 1.
C'est pas parce que c'est un mauvais assembleur que ce n'est pas un assembleur. Un assembleur c'est une forme lisible d'un langage machine, c'est a dire directement exécuté par un CPU. Donc le bytecode java est un assembleur. Après si c'est une mauvaise idée de l'utiliser en tant qu'assembleur, ça j'en sais rien. Mais du peu que j'en connais, ça semble pas très éloigné (pile, data, code, registres…).
[^] # Re: Compilateur
Posté par gasche . Évalué à 2.
Je ne comprends pas ce que tu essaies de faire en faisant le sophiste sur un point de la définition du mot "assembleur". D'avoir raison ? Quel est l'intérêt ?
Les définitions des mots sont flexibles, mais le but c'est de pouvoir communiquer et faire comprendre des concepts intéressants avec. cykl a écrit un message pour souligner la différence entre la compilation vers du code machine et les méthodes, de plus en plus populaire, consistant à viser un langage de destination pas prévu pour ça à la base (JVM ou Javascript). Dans ce contexte il est important de différencier "langage machine" de "langage pas prévu pour ça à la base", sinon le propos n'a plus de sens et on ne peut plus transmettre d'information.
En quoi le bytecode Java serait-il "directement exécuté par un CPU" ? La question de savoir si un langage est ou non un assembleur est l'existence d'un CPU qui le fait tourner en te faisant croire que c'est son mode de base ? Un CPU qui existe dans le monde réel, ou une expérience de pensée te convient ? Puisqu'il existe des Lisp Machines, Lisp est un assembleur aussi ? Encore une fois, quel est l'intérêt ?
[^] # Re: Compilateur
Posté par barmic . Évalué à 1.
Bon j'ai mal utilisé le terme d'assembleur tout simplement parce qu'il n'existe pas de logiciel assembleur qui va traduire le bytecode de la JVM en langage machine. J'aurais du ne parler uniquement de langage machine car il existe des machine qui décodent directement le bytecode JVM.
Pas trop quand même. Sinon ça ne sert plus à rien de chercher à ce comprendre.
Tu peux tout à fait dire que le bytecode JVM est ignoble et que le faire décoder directement par le matériel est une ineptie, que même son existence est déjà une insulte à l'intéligence. Par contre modifier les définitions à ta sauce pour qu'il entre ou non dans le cadre des langages machines, non.
C'est bien pour ça que j'ai commencé ce thread, pour utiliser des termes précis qui ont une définition et pas balancer des contre-vérité ou des imprécisions pour à peu près faire comprendre ce qu'on veut dire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par gasche . Évalué à 3. Dernière modification le 04 octobre 2012 à 15:41.
Je ne trouve pas le bytecode JVM spécialement immonde, c'est un bytecode raisonnable (bien qu'un peu miné par les problématiques de compatibilités) pour représenter du code Java ou ayant la même sémantique qu'un programme Java, et des gens (Scala par exemple) sont arrivés, au prix de beaucoup d'efforts, à lui donner un peu plus de flexibilité.
Par contre je ne suis toujours pas d'accord pour l'appeler un "langage machine"; c'est au mieux un "langage pour machine virtuelle" (ce qui indique bien qu'il s'agit en fait d'une représentation intermédiaire). Je pense que dans le désaccord entre cykl et toi sur "peut-on dire que la compilation vers la JVM relève du même genre de victoire de l'existant au dépend de la pertinence technique absolue que Javascript", il a raison et tu as tort, et que ta contre-argumentation sur la question ("mais non, le bytecode JVM est une forme d'assembleur"), une fois passée la confusion de vocabulaire entre "compiler vers un source Java" ou "compiler vers un bytecode JVM" (il voulait bien entendu dire vers la JVM), est incorrecte.
Mais visiblement nous sommes en désaccord et, au bout du bout, toute la question repose sur le sens qu'on choisit de donner ou pas au terme "langage machine", donc ça n'a pas grand intérêt. Par contre la remarque de cykl (on se force à viser la JVM ou Javascript alors que c'est souvent malcommode) est juste, intéressante et tient toujours, quoi que les amateurs de "java processors" en disent.
(Et pour moi la question de dire que tu as tort sur ce point technique particulier est relativement indépendante de la critique que j'ai formulée avant, sur la façon dont vous avez discuté. Enfin je l'ai pris en compte quand j'ai dis que tes messages n'apportaient pas de contenu technique : on pourrait considérer la distinction "JVM langage machine ou non" comme un point technique, mais comme je pense que tu as tort¹ je ne l'ai pas vraiment pris en compte comme un apport qualitatif à la discussion.)
¹: il y a des débats où on peut tirer des informations très intéressantes de gens avec qui on n'est pas d'accord ou qui pensent des choses partiellement fausses, je ne dis pas que par définition une personne avec qui on est en désaccord n'apporte rien, pour nous, à la conversation; c'est en poussant les deux côtés du débat à avancer des arguments précis qu'on apprend des choses. Mais ici le débat porte sur une question de terminologie, sans vraiment d'argument précis puisque ça reste au final assez subjectif, donc on n'a pas gagné grand chose.
[^] # Re: Compilateur
Posté par barmic . Évalué à 0.
Désolé je ne dois pas être très malin pour penser qu'un langage machine est un langage qu'une machine (au sens matériel du terme) est capable de comprendre. Je suis aussi assez neuneu pour, quand je ne suis pas sûr de la définition exacte, d'aller voir sur wikipedia. M'enfin bref.
Ce qui est intéressant (c'est à dire pas le débat sur tes définitions que tu utilise sans les présenter avant), c'est que le fait de ne pas réinventer la roue et avoir une vision pragmatique qui consiste à réutiliser ou cibler l'existant dans chez les utilisateurs cibles n'est pas nouvelle (on parlait de l'architecture x86) ni forcément mauvaise (vous voulais vraiment revoir des plugins comme Java, flash ou silverlight dans vos navigateurs ?). Donc oui je remet en cause le terme d'effet de mot dont parle l'auteur du journal.
Le reste (se battre sur des définitions floues ou que je ne trouve pas) n'apportera rien ni à toi ni à moi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par gasche . Évalué à 4.
Je ne comprends pas le rapport entre le choix de cibler Java ou pas et le choix de cibler l'architecture x86 ou pas. Tu as déjà souvent rencontré des auteurs de logiciels qui te disent avec passion "ah ma vie serait tellement plus simple si tout le monde utilisait tel modèle de SPARC" ? À l'extrême rigueur je pourrais l'imaginer pour le Cell (mais en réalité c'est l'inverse, les gens fuient cette archi jugée trop difficile à bien programmer) ou quelques machins exotiques, mais ça m'a l'air assez anecdotique. Au contraire les gens qui visent la JVM vont pouvoir te fournir une longue liste des problèmes que ça leur pose (sauf bien sûr s'ils reprennent exactement la sémantique dynamique de Java, comme en gros Kotlin ou Ceylon).
(Quand au jeu de qui a raison en regardant wikipédia, je t'envoie à la page anglaise correspondante qui dit explicitement "Machine code should not be confused with so-called "bytecode", which is executed by an interpreter." dans l'introduction. Malheureusement cette explication n'est pas au dessus de toute critique et je suis convaincu que ça ne règle pas le débat; peut-être que la mention proéminente et cohérente de la JVM dans l'article Bytecode t'en dira un peu plus, et sinon on en est limité aux arguments d'autorité : bien que non expert dans le domaine, je connais relativement bien la compilation, et je peux t'assurer que si je parle du bytecode JVM comme d'un "langage machine" aux gens que je connais et qui eux sont experts, ils ne vont pas être d'accord; il me semble que c'est avant tout l'usage qui prime et l'usage, en tout cas chez les spécialistes, est très clair sur ce sujet.)
[^] # Re: Compilateur
Posté par barmic . Évalué à 0.
Je ne suis pas certain que ce soit parce que l'architecture leur conviens ou si c'est parce qu'ils manquent de compétence ou d'esprit critique à ce sujet. Avec un peu plus de 20 ans de domination et une part de marché aussi large plus personne n'est en mesure de la remettre en cause.
Par contre tu as failli m'avoir avec ton biai (bravo) d'un coté tu parle des « auteurs de logiciels » et de l'autre des « gens qui visent la JVM » (sous-entendu ceux qui écrivent des compilateurs je présume ?). Je ne doute pas que l'écriture d'un compilateur n'est pas tout rose dans les deux cas (par exemple en x86, on évite d'utiliser l'ensemble des instructions pour se contenter de celles qui sont le plus proches des RISC, tu parlais du faible nombre de registre de cette architecture, etc). Si tu parlais des développeurs qui codent des logiciels pour la JVM, je ne sais pas jamais connu quelqu'un qui codait en groovy ou scala par exemple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par gasche . Évalué à 3.
Je voulais bien sûr parler des "auteurs de compilateurs", désolé du lapsus idiot—et merci d'avoir su comprendre tout de même ma pensée en corrigeant cette erreur évidente… en fait non. S'il était possible d'éditer ses messages sur LinuxFR, je corrigerais le mien avec joie pour qu'il soit plus facile à comprendre pour les lecteurs qui vont suivre, tout en mettant en bas un petit message pour te remercier de la correction.
Les auteurs de compilateurs que je connais ont écrit des backends plusieurs architectures non-x86, et sont donc au courant des différences entre architectures (et ont leurs petites préférences personnelles sur tel ou tel sujet) même si le grand public n'utilise presque pas les autres. Dans le cas de Compcert par exemple, si je me souviens bien le backend PowerPC a été écrit en premier.
Mon argument tiens donc toujours : dans le cas d'une compilation vers la machine, j'ai l'impression que le support de telle ou telle architecture a souvent une influence assez limitée sur le design d'ensemble du langage, contrairement aux auteurs de compilateurs qui visent des formats pas vraiment prévus pour ça comme le bytecode JVM ou le Javascript. (Après il reste la question de la FFI et de la compatibilité de l'ABI, et ça peut aussi être important et galère selon les systèmes. Et les problématiques sont toutes autres quand on compile vers des choses exotiques comme un GPU.)
Une remarque qui n'a pas grand chose à voir : pendant ma première intervention je me plaignais du peu de contenu technique dans les commentaires, j'ai l'impression que la tendance a un peu changé… En contrepartie, j'ai l'impression d'avoir perdu mon temps et d'être frustré, mais je me le reproche à moi-même, pas aux autres.
[^] # Re: Compilateur
Posté par reno . Évalué à 5.
SPARC non, mais MIPS oui: il a des instructions pour faire un TRAP en cas de débordement entier: hop, une cause de trou de sécurité qui disparaît sans quasiment aucun impact en performance.
[^] # Re: Compilateur
Posté par ckyl . Évalué à 1.
Pour te montrer comme être pointilleux quand il n'y a pas d'ambiguïté ne mène nul part.
N'importe quelle JVM fait ca c'est son job (Astuce pour Hotspot par exemple). Autrement pour sortir des JVM standards, GCJ est capable de compiler directement vers du natif. Il y a eu un paquets d'autres projets qui ont fait ca.
Tu arrêtes pas de le ressortir mais on peut faire ca pour n'importe quel bytecode, voir langage si vraiment on s'ennuie. On le fait pas par ce que ca n'a aucun sens. Toutes les tentatives de CPU mangeant du JVML ont été des échecs cuisants.
Y'en a un qui est du soft et l'autre du hard ca n'a rien de comparable.
Pourquoi cibler la JVM ?
- S'intégrer avec l'existant (compétence, compatibilité, bootstraper avec un eco-systeme déjà prêt)
- Profiter des efforts absolument monstrueux qui ont été fait dessus depuis 15 ans
C'est exactement les mêmes raison qui font actuellement fleurir les langages ciblant JS. Et c'est bien là le changement. L'informatique est arrivée à un point où c'est extrêmement difficile d'être disruptif et de pousser de l'innovation. Et c'est pour ca que c'est "la mode". Sauf cas particulier on a plus vraiment le choix, même pour les mastodontes qui quand ils tentent n'arrivent plus à pousser leurs technos. Ça ne marche que si tu es environnement clos.
[^] # Re: Compilateur
Posté par barmic . Évalué à 1.
Et c'est quelle partie du coup qui n'est pas comparable ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par ckyl . Évalué à 1.
Oui bon j'arrête là aucun intérêt.
[^] # Re: Compilateur
Posté par barmic . Évalué à 1.
C'est dommage c'était une vrai question. Aujourd'hui tout le monde utilise x86 parce que tout le monde a un processeur compatible x86 et que des dizaines de milliards d'euros ont étaient investis pour que ces CPU soient performants (Intel et AMD) et que les compilateurs sachent s'en servir au mieux (Intel, toutes les boitent qui contribuent à gcc et llvm).
Ou alors les deux paragraphes ne vont pas ensemble mais je ne vois pas ce qui, dans le fait de le faire au niveau matériel, le rend si différent (le matériel a peut être plus d'inertie que le logiciel, mais en 15 ou 20 ans le parc du se renouveler à plus de 70% je pense).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par gasche . Évalué à 6.
J'ai le sentiment d'avoir déjà répondu à cette question : les architectures CPU n'influent que très peu sur les choix de design du langage, alors que le choix d'une machine virtuelle contraint beaucoup l'espace de design possible. Si demain tout le monde passe à du PowerPC, les compilateurs ne changeront pas des masses. Par contre prendre un langage .NET et le faire tourner sur la JVM ou inversement, et ce alors que ce sont pourtant des machines virtuelles assez proches (je ne parle pas de Parrot ou quoi), c'est très difficile (par exemple il y avait eu des essais de porter Scala sur .NET, ça n'a pas été un franc succès et depuis Scala a encore évolué pour mieux supporter l'interopérabilité avec Java).
[^] # Re: Compilateur
Posté par brendel . Évalué à 0.
J'ai lu la discussion et je comprend ce que veux dire cykl mais je répond à calandoa et toi qui disent qu'on ne peut appeler assembleur le bytecode Java, alors qu'il me semble bien que si. C'est donc une réponse sur la forme, si tu y a lu autre chose, tu t'es trompé.
Comme dit précédemment on retrouve les même concepts que dans les asm conventionnels et c'est normal, le but étant d'être d'être compilé vers différents assembleur (ou interprété, certes), c'est normal qu'il en soit très proche.
Ben on peut le voir comme ça, mais je ne sais pas comment fonctionnent les machine Lisp :)
[^] # Re: Compilateur
Posté par barmic . Évalué à 1.
Je ne crois pas que c'est la distinction qu'il faisait vu qu'il défini un langage d'assembleur ainsi :
A mon avis tu confond une propriété avec la définition d'un langage d'assemblage.
C'est pas ce qui se passe aussi depuis les 20 dernières années avec le x86 ? C'est pas nécessairement la meilleure architecture (tout du moins pas la plus adaptées) mais on l'utilise parce que ça représente 95% du parc. Je cherche pas à troller je demande réellement qu'elle est la différence dans la démarche d'un coté (bytecode JVM) et de l'autre (jeu d'instructions x86).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Compilateur
Posté par gasche . Évalué à 6.
x86 est chiant à implémenter en hardware parce que trop complexe, le problème des CISC ne se pose pas du côté du software (enfin x86 spécifiquement a très peu de registres ce qui casse les pieds pendant la compilation, et il se trouve que la plupart des RISC en ont plus mais c'est une question indépendante). La solution pour les ingénieurs côté hard a été de traduire au vol les instructions x86 vers un microcode RISC bien choisi (qui peut changer selon le modèle du CPU) qui permet de faire des optims au vol; en gros c'est comme ça que x86 est resté un peu compétitif par rapport aux architectures RISC. Mais tout ça ne concerne pas trop l'auteur de compilateur.
Dans le cas de la JVM c'est l'auteur du compilateur (machin -> JVM) qui souffre (enfin les implémenteurs de machine virtuelle aussi mais pour d'autres raisons). Je connais assez mal la JVM mais les exemples que j'ai retenus sont les suivants : pas de support des appels terminaux, un modèle de dispatch très particulier qui convient bien à Java mais pas forcément à tous les langages OOs, tu as intérêt à avoir un modèle d'exceptions qui ressemble à celui de Java, etc. Enfin on a un peu le même genre de problèmes quand on compile vers du C d'ailleurs.
[^] # Re: Compilateur
Posté par Antoine . Évalué à -1.
Tu disais ?
# Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la réponse à dart ?
Posté par hitmanu . Évalué à 4.
Pire il y a IE
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: la réponse à dart ?
Posté par TImaniac (site web personnel) . Évalué à 3.
Sauf que TypeScript est déjà utilisable aujourd'hui, dans tous les navigateurs, sur tous les OS. Pas comme Dart.
[^] # Re: la réponse à dart ?
Posté par Antoine . Évalué à 1.
Ben non, Typescript n'est pas utilisable dans les navigateurs. Soyons précis.
[^] # Re: la réponse à dart ?
Posté par TImaniac (site web personnel) . Évalué à 1.
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/
[^] # Re: la réponse à dart ?
Posté par Antoine . Évalué à 1.
Avec ce genre de raisonnement, n'importe quel langage interprété en Javascript « est utilisable dans tous les navigateurs ». Par exemple Python : http://www.skulpt.org/ (je n'ai pas vérifié si l'implémentation était complète, mais on voit l'idée)
On admettra aisément que cette définition de « tourner dans un navigateur » n'est pas très utile en pratique.
[^] # Re: la réponse à dart ?
Posté par gasche . Évalué à 4. Dernière modification le 04 octobre 2012 à 15:56.
Je voudrais souligner que, indépendamment de la définition qu'on donne à "tourner dans un navigateur", la remarque de Timaniac (sur le fait que ça différence TypeScript et Dart) est fausse : si l'on considère que ça veut dire "peu se traduire en JS" c'est aussi le cas de Dart (comme l'a fait remarquer Barret Michel), et si on considère comme toi une notion très stricte de "est prévu prévu directement comme type de script dans la norme HTML" ce n'est le cas d'aucun des deux comme tu le fais remarquer.
[^] # Re: la réponse à dart ?
Posté par TImaniac (site web personnel) . Évalué à 1.
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é.
[^] # Re: la réponse à dart ?
Posté par Antoine . Évalué à 1.
Tu as dit que Typescript était « utilisable dans tous les navigateurs ». Être utilisable dans un navigateur implique que tu fasses tourner le compilateur Typescript (écrit en Javascript) à la volée lors du chargement d'une page Web, ce qui ne me paraît pas franchement désirable.
[^] # Re: la réponse à dart ?
Posté par pasBill pasGates . Évalué à -1.
Du tout, tu fais tourner dans les navigateurs le resultat d'une compilation par TypeScript.
Et vu que le compilateur est lui-meme ecrit en JavaScript,ben tu sais que tant que ton code final JavaScript a une chance d'etre execute, il peut etre compile, pas de probleme de disponibilite du compilateur.
[^] # Re: la réponse à dart ?
Posté par Antoine . Évalué à 0.
Ce serait bien de lire le fil de discussion avant de répondre.
[^] # Re: la réponse à dart ?
Posté par barmic . Évalué à 6.
Un peu comme dart avec dart2js.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# "Cachez ce JavaScript que je ne saurais voir"
Posté par jigso . Évalué à -3.
Aucun langage n'est conçu pour (ou contre) le dev de gros projets. 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.
Personnellement je trouve absurde les initiatives à la TypeScript (ou autres, il y a des choses similaire en Java). Passer par un langage de haut niveau pour générer du code d'un niveau plus bas est tout à fait justifiable et c'est comme ça que fonctionne l'informatique depuis le début. 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.
Certains disent que JavaScript est compliqué, pénible, etc : faux débat. 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.
Et malheureusement pour les fainéants, Javascript EST le langage des navigateur. Peut-être qu'un jour on aura un <script type="text/cobol">, mais pour l'instant c'est "text/javascript". Et le jour où un bug se présentera, ou bien qu'une fonctionnalité ne sera pas présente dans le fabuleux framework, il faudra non seulement se plonger dans le fonctionnement de ce traducteur (écrit probablement dans un troisième langage…), mais en plus comprendre le JavaScript sous-jacent : c'est de l'utopie que de croire qu'on se simplifie la vie, on ne fait que s'entourer de bombes à retardement.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par TImaniac (site web personnel) . Évalué à 8.
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.
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.
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.
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.
Faux, il est écrit en typescript lui-même.
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.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par jigso . Évalué à -3.
Mouarf. Pour quelqu'un de motivé, tout peut être développé avec n'importe quoi.
Remonte un peu le temps informatique, et tu verras de nombreux "gros" projet écrit avec des langages qui ferait fuir plus d'un développeur actuel ("Quoi ? écrire mon code entre la 7eme et la 72eme colonne ? Gérer moi-même la mémoire et des pointeurs ?"), et pourtant de "gros" projet ont était fait avec ces langages.
Et c'est là qu'on est pas d'accord : JavaScript a des caractéristiques particulières, mais troquer ces caractéristiques contre d'autre n'apporte rien, si ce n'est de retrouver des concepts peut-être plus classiques, mais pas plus puissants. Par ex le typage des données : c'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, c'est ni supérieur ou inférieur à d'autres techniques, ni dangereux. Mais ça ne présage en rien de la qualité ou de la taille du développement.
On peut faire des gros projets en JavaScript, comme avec n'importe quel langage, et avec autant de facilité et d'efficacité. Et comme dans un navigateur c'est JavaScript, autant utiliser un "outil prévu et conçu pour un usage particulier"…
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par Dr BG (site web personnel) . Évalué à 2.
Et alors ? Ça ne change rien au fait que certains sont plus adaptés à certains usages que d'autres.
Le développement peut-être plus ou moins pénible. Pourquoi ne pas tout écrire directement en code machine tant qu'on y est ?
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par jigso . Évalué à -1.
Ce n'est pas parce que j'ai dit qu'on pouvait développer avec tout type de langage qu'il faut systématiquement reprendre l'exemple de l'assembleur ; mon propos est de dire que JavaScript est adapté pour le développement d'interface dans un navigateur, et qu'il n'est pas nécessaire de l'encapsuler pour des raisons idéologiques.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par TImaniac (site web personnel) . Évalué à 4.
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.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par TImaniac (site web personnel) . Évalué à 5.
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".
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.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par jigso . Évalué à 0.
On s'entoure de bombe à retardement quand on empile les couches en espérant cacher une complexité intrinsèque au sujet : oui le développement c'est compliqué, JavaScript / Java / C++ / Perl / Python / Ruby / TypeScript même combat, ce sont des langages de haut 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 - ou ce qu'on gagne on le paiera de toute façon un jour ou l'autre…
( En revanche ne me faites pas dire ce que je n'ai pas dis : passer de l'assembleur à un langage de plus haut niveau est une bonne chose, on change évidemment le niveau de d'abstraction et de complexité. )
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par gasche . Évalué à 2.
Je ne suis pas d'accord. Pour moi on peut cacher une couche inférence si l'interface de communication entre les couches est propre (ce n'est pas une "leaky abstraction"). Par exemple ce qui se passe en interne dans un processeur est extrêmement complexe, personne ou presque ne connaît le microcode qui est réellement exécuté, on ne voit que le jeu d'instruction "haut niveau" qui correspond essentiellement à l'assembleur utilisé, et je ne pense pas qu'on puisse dire que cette isolation est "illusoire" (sauf dans certains cas très, très spécialisés qui ne concernent qu'une poignée de personnes dans le monde).
John Regehr a un billet à ce sujet : It's All About Interfaces.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par jigso . Évalué à -2.
il dit qu'il a plus de jambe.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par TImaniac (site web personnel) . Évalué à 2.
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.
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.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par jigso . Évalué à 0.
Du JavaScript donc : ce qui existe et marche bien.
Je retourne coder mon js
/me -> []
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par TImaniac (site web personnel) . Évalué à 2.
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.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par ckyl . Évalué à 2.
Sans avoir d'avis sur Typescript vu que j'en ai actuellement rien à dire sauf sa fiche de spec., je ne suis pas d'accord avec ton deuxième argument. Il me semble clairement viser les devs autres que les scripts. Javascript c'est effectivement cool quand tu en codes 200 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.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par TImaniac (site web personnel) . Évalué à 0.
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.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par Michaël (site web personnel) . Évalué à 3.
Si l'objectif est effectivement de vouloir éviter à tout prix d'apprendre un autre langage, c'est effectivement assez idiot (à mon avis, le jeu n'en vaut pas la chandelle).
Cependant, tous les langages que tu cites sont des langages différents, voire très différents. En plus des caractéristiques inhérentes au langage qui vont en faire un bon outil pour ŕepondre à tel ou tel problème d'architecture logicielle, il faut aussi tenir compte de l'environnement de développement (outils de gestion de projet, exploration de code source), de la performance du compilateur (pour le langage cible) ou de la machine virtuelle, voire de la disponibilité tout court d'un compilateur ou d'une machine virtuelle.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par Shuba . Évalué à 1.
Pour ce qui est de l'environnement, on peut aussi considérer la qualité du débugeur, ou de tout autre outil facilitant la recherche d'erreurs (stack traces, etc.).
D'ailleurs je me demande si TypeScript est facile à débuger du coup, ou si la traduction rend ça plus difficile? Bon après j'ai jamais fait de javascript, donc je sais même pas comment ça se passe le debug en pratique.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par Antoine . Évalué à 2.
C'est une bonne idée, ça, de modifier un code que l'on ne maîtrise pas, et de compter sur le compilateur pour éviter de faire des conneries.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par TImaniac (site web personnel) . Évalué à 4.
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.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par Antoine . Évalué à 1.
Oui, bien sûr, sauf que le compilateur n'est pas « très important » dans l'histoire : on peut très bien écrire du code buggé à mort, mais qui satisfait les exigences de typage du compilateur.
Vaudrait mieux qu'il le corrige.
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).
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par TImaniac (site web personnel) . Évalué à 4.
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.
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.
Correction linguistique sur mon anglicisme ? Ou comment se focaliser sur la forme quand on a rien à dire sur le fond.
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 ;)
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par Antoine . Évalué à 1.
Ben justement, c'est une très mauvaise analogie : 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. En d'autres termes, la sécurité routière dépend du bon comportement des conducteurs, pas d'automatismes coercitifs.
Désolé, mais la plupart du mauvais code ne l'est pas à cause de mauvaises intentions.
Tu ne réponds pas à mon objection, à savoir qu'un compilateur n'est pas ce qui te prémunit contre des bugs. Tes programmeurs qui produisent du mauvais Javascript, produisent-ils du bon C++ et du bon Java ? J'en doute fortement. Ils font le même genre d'erreurs, simplement ils « corrigent » à qui mieux-mieux quand le compilateur les envoie bouler.
Eh bien, faut savoir : c'est exagéré ou c'est proche de la vérité ?
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.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par ckyl . Évalué à 4.
On s'en fou. La question est un bon programmeur il fait plus ou moins d'erreurs ? Sa vie est plus ou moins facile ? Est il plus ou moins productif ? C'est un outil et plus l'outil joue pour toi, meilleur il est. Et ca se joue sur tout le cycle de vie, pas l'infime pourcentage que représente le développement initial.
Dans la vraie vie c'est souvent 10 mecs pour maintenir plus de 500 000 lignes de codes écrites sur X années (et je suis gentil). Alors plus la base de code est facile à suivre mieux tu te porte. On dit souvent que le code est fait pour être lu avant d'être fait pour être exécuté, c'est pas totalement faux…
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par TImaniac (site web personnel) . Évalué à 4.
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.
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.
C'est toujours mieux que de pas être averti et de ne rien corriger.
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.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par Antoine . Évalué à 0.
Ah, drôle de compilateur. C'est un choix un peu étrange pour un langage de haut niveau.
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.
[^] # Re: "Cachez ce JavaScript que je ne saurais voir"
Posté par TImaniac (site web personnel) . Évalué à 3.
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.
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.