Un langage non objet n'est pas industriel ? C'est vrai que plus personne ne fait du C...Envoyé par ugo-sans-h
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Un langage non objet n'est pas industriel ? C'est vrai que plus personne ne fait du C...
D'accord avec toi pour tes réflexions sur Javascript, par contre pour les compilateurs tu as tort: cela fait déjà plus de 20 ans que les bons compilateurs produisent de l'assembleur plus performant que l'humain
D'accord, merci pour les éclaircissements !
C'est pas faux.Moi je me demande quel est l'intérêt de coder en autre chose qu'en assembleur, puisqu'au final le compilateur ou la machine virtuelle convertit tout en langage machine...
Javascript est l'assembleur du web
Pour une fois je suis plutôt voir entièrement d'accord !
Je suis de l'autre côté de la barre (j'adore, j'aime JavaScript. Je le maitrise ? Je ne sais pas vraiment, personne ne m'a "testé" et puis il faut que je progresse encore plus mais bon ...)
C'est encore une fois (c'est d'ailleurs toujours le cas) une question du goût. Tu aimes, tu n'aimes pas. Du côté de la machine, on en trouve des tas, C, C++, C#, Java, Python ... donc on peut choisir. Il est vrai que côté web client, il n'y a que JavaScript. Alors trouver une alternative, pourquoi pas, mais ne dénaturez pas pour autant ce langage !
Faire de la POO en Javascript, c'est tellement long et désagréable.
j'espere vraiment que DART va prendre beaucoup de place dans les prochaines années.
Si il peut l'être, je trouve simplement que Javascript n'évolue pas assez avec sont temps et l'utilisation que l'on en fait aujourd'hui. Sont approche n'a pas changé depuis des années, hors, notre approche du web elle a beaucoup évoluée. Hier javascript servait à gérer trois onclick, aujourd'hui on développe des Web App qui concurrencent directement les applications lourdes.
Enfin, si nous collectionnons les framework, les sur couches (CoffeeScript, TypeScript et j'en passe) signifie bien que l'on cherche à résoudre des problématiques que Javascript n'est pas nativement capable de gérer. De nos jours on développe même en GWT pour réaliser des applications html/css/js.......
Enfin...
Il y a quelque temps j'ai codé un petit projet perso en javascript...Evoluant dans le monde merveilleux du Java, ou tout est typé, objet et immédiatement compilé...J'ai pris une sacret baffe! Il est clair que javascript est très différent...pour ma part je m'en suis rendu compte lorsque j'ai tenté de remplir un tableau avec des variables
Aujourd'hui j'ai quelques années d'expériences en développement et je suis capable de prendre du recul sur mon travail. Mais il y a quelques temps, quand j'étais encore un jeune débutant, je pense que cela aurait été bien plus compliqué. C'est pourquoi je pense que la venu de framework comme GWT et de langage comme DART sont les bien venu et vont facilité le développement d'application web.
Un langage pas objet industrialisé à mort ? Le C. Plus du tout utilisé ? Ah ah.
JavaScript n'est pas un langage objet ? Ah bon. Apprends vraiment le JS et tu verras qu'en réalité, en JS, tout est objet (bon ok, à part quelques mots-clés)
Pas de design pattern en JavaScript ? Encore une fois : ah bon ? Ici j'en compte 27 parmi les grands classiques http://addyosmani.com/resources/esse...patterns/book/
Allez, bisous
Il existe aujourd'hui un nombre incalculable de langages de programmation, mais les paradigmes et les concepts qui sont mis en œuvre dans ces langages sont en nombre limités et la plupart ont été inventés entre la fin des années 50 et le début des années 70. Le fait de "ne pas évoluer avec son temps" est donc une critique que l'on pourrait adresser à n'importe quel langage.
Le fait que JavaScript ait été utilisé pour gérer "trois onclick" n'implique pas qu'il ait été développé avec cette seule ambition. En effet, JavaScript, qui devait à l'origine s'appeler LiveScript, était destiné à devenir un langage de script pour le serveur http "Netscape Entreprise Server" et si son nom contient le terme "script", ce n'est pas parce qu'il s'agit d'un langage de programmation au rabais, mais parce qu'il est destiné un environnement d'exécution particulier (en l'occurrence un navigateur). Le fait que des applications concurrençant des « applications lourdes » aient pu être réalisées, montre d’une part les progrès qu’ont fait le html et les navigateurs et, d’autre part, que JavaScript est un vrai langage de programmation.
Tous les langages de programmation ont été développés pour permettre la création d'abstractions pour que les programmeurs puissent plus facilement gérer la complexité des programmes. Les variables, les procédures, les fonctions, les modules, les classes sont autant de moyens permettant la création d'abstractions. JavaScript n'utilise ni classe ni module, mais cela ne signifie pas qu'il ne dispose pas de moyens puissant pour créer des abstraction. En JavaScript, le principal moyen d'abstraction est la fonction qui est, dans ce langage, un objet de première classe (first-class citizen) et une fermeture (closure).
Si l'on aborde JavaScript en espérant y trouver les même concepts qu'en Java ou qu'en C#, il est évident que l'on risque d'être déçu, et je pense que si ce langage a une si mauvaise réputation, ce n'est pas tant à cause de ses défauts bien connus, mais plutôt à cause de programmeurs déçus de ne pas trouver dans ce langage ce qu'ils espéraient y trouver et qui n'ont pas voulu ou pas pu faire l'effort de regarder ce qu'il avait à offrir.
Même si un autre langage remplace un jour JavaScript dans les navigateurs, il reste pour l’heure le lingua franca des navigateurs et en tant que tel, le seul langage utilisable pour réaliser la partie cliente d’une application Web, il convient donc de l’apprendre lorsque l’on se considère comme un professionnel du Web. Cela étant dit, puisque tous les langages de programmation Turin-complet sont équivalents, il es possible de compiler n’importe quel langage en JavaScript et c’est une très bonne chose que de tels compilateurs existent. Si donc vous êtes plus à l’aise avec un autre langage, utilisez-le, mais ne dénigrez pas JavaScript parce qu’il ne correspond pas à vos attentes.
« Tout le monde est un génie. Mais si vous jugez un poisson sur ses capacités à grimper à un arbre, il passera sa vie à croire qu’il est stupide » (Albert Einstein)
Le fait d'avoir recours à un framework pour développer une application dans un langage n'implique pas que le langage ne soit pas adéquat (cela n'implique pas non plus qu'il le soit). Si c'était le cas, alors ni Java, ni C++, ni la plupart des langages couramment utilisé dans l'industrie du logiciel ne le serait. Les framework, comme les langages de haut niveau, servent à améliorer la productivité en évitant à chacun d'avoir à réinventer la roue.
CoffeScript, TypScript ou GWT ne sont pas des sur-couches, ce sont simplement des langages, comme Dart, qui disposent d'un compilateur vers JavaScript. GWT, va simplement plus loin en permettant le développement de la partie cliente et de la partie serveur de l'application (car oui, il n'est sans doute pas inutile de le rappeler, une application Web est une application client-serveur dont le processus client est un client http, le plus souvent un navigateur Web étendu avec un programme en html/JavaScript), mais une fois la compilation effectué, il y a peine plus de traces du langage de développement dans le programme en JavaScript qu'il n'y en a dans un programme en langage machine.
J'ai jamais dis que le C n'étais pas utiliséUn langage pas objet industrialisé à mort ? Le C. Plus du tout utilisé ? Ah ah.
JavaScript n'est pas un langage objet ? Ah bon. Apprends vraiment le JS et tu verras qu'en réalité, en JS, tout est objet (bon ok, à part quelques mots-clés)
Pas de design pattern en JavaScript ? Encore une fois : ah bon ? Ici j'en compte 27 parmi les grands classiques http://addyosmani.com/resources/esse...patterns/book/
Allez, bisous
Et non désolé je trouve pas que le JS soit nativement Objet.
je fais de l'objet avec javascript, mais faut être honnête, utiliser la syntaxe {} ou les "function" pour créer une classe, c'est juste profiter d'un langage qui permet tout et n'importe quoi avec les mêmes mots clés. Ce langage est bien trop permissif.
Ok les framework sont très utiles je dis pas le contraire mais TypeScript, CoffeeScript pour moi c'est des langages crées avant tout pour combler des lacunes du JS ou apporter un peut de confort au développeur.
Je crois que voilà déja un problème, le prototypage n'étant pas (ou peu) enseignée contrairement aux classes c'est sur que les gens qui veulent aller plus loin dans javascript ont du mal au départ.
D'où l’intérêt d’être hyper rigoureux. Ce qui finalement n'est pas un mal. Ton idée me ferait presque dire que tes outils doivent te guider ta façon de pensée, que tu dois être souple à tes outils et non adapter tes outils à ton besoin.
Il y avait, il y a encore il y a quelques années le même débat avec PHP, ça c'est un peu tassé, sauf dans les gros nids à trolls. Depuis PHP a fait connaitre sa capacité à s'industrialiser, ses tares sont connues, ses forces aussi et on continue comme ça en faisant évoluer le langage. Pourquoi pas pareil avec le JS ? Plutôt que de réinventer la roue chacun de son coté, on ferait mieux de se concentrer sur la bonne évolution. EcmaScript 6 semble être particulièrement bien partie, non ?
C'est une partie du problème je pense.
JS est un langage basé sur le prototypage, mais aujourd'hui on fait de l'objet avec.
Je ne connais pas les spec de EcmaScript6, c'est possible en effetD'où l’intérêt d’être hyper rigoureux. Ce qui finalement n'est pas un mal. Ton idée me ferait presque dire que tes outils doivent te guider ta façon de pensée, que tu dois être souple à tes outils et non adapter tes outils à ton besoin.
Il y avait, il y a encore il y a quelques années le même débat avec PHP, ça c'est un peu tassé, sauf dans les gros nids à trolls. Depuis PHP a fait connaitre sa capacité à s'industrialiser, ses tares sont connues, ses forces aussi et on continue comme ça en faisant évoluer le langage. Pourquoi pas pareil avec le JS ? Plutôt que de réinventer la roue chacun de son coté, on ferait mieux de se concentrer sur la bonne évolution. EcmaScript 6 semble être particulièrement bien partie, non ?
Cependant l'évolution de php est, je trouve, plus dynamique que l'évolution de js.
C'est là que je vois bien le problème. Il n'y a pas fondamentalement de problème à faire de l'objet à base de prototype. c'est juste une autre manière et c'est pas "aujourd'hui on fait de l'objet avec".C'est une partie du problème je pense.
JS est un langage basé sur le prototypage, mais aujourd'hui on fait de l'objet avec.
Je ne connais pas les spec de EcmaScript6, c'est possible en effet
Cependant l'évolution de php est, je trouve, plus dynamique que l'évolution de js.
Cela te gène certes mais c'est un autre débat.
Note : pas de souci pour reconnaitre tout un tas d'autres problèmes à JS pour information.
Pourquoi comparer des pommes avec des bananes ?
La comparaison me semble inappropriée. Le PHP est un langage serveur, et, malgré les actuels développements dans ce sens, JavaScript est à la base un langage client. Or, dans les méthodes actuelles de développement, on préconise, à juste raison me semble-t-il, la séparation des couches afin de faciliter la maintenance. Donc on sépare aussi strictement que faire se peut la partie client de la partie serveur. Il n'est donc pas vraiment justifié de comparer le développement du PHP avec celui du JavaScript.
JavaScript est un langage qui n'a pas souvent la faveur des développeurs en général, entendons par là les développeurs en langage serveur. La syntaxe n'est pas fondamentalement très différente, mais la manière de programmer en JavaScript n'est en revanche pas franchement comparable.
Si on en revient au sujet de départ, l'initiative de Google avec Dart tend à vouloir présenter justement une manière de programmer plus proche de telle sorte que ce que les développeurs, tels que je les ai présentés plus haut, aient moins de difficultés à développer la partie client des applications sur lesquelles ils ont à travailler.
J'ajouterais un autre élément en faveur de Dart : lorsque Rasmus a créé le PHP, il était tout seul. Le développement de Dart avait Google comme socle. Je n'irai pas jusqu'à dire que Rasmus ne fait pas le poids, ne charrions pas, mais les ressources techniques de Google ne souffrent pas beaucoup de comparaisons. On ne peut, à mon sens, pas vraiment craindre de voir l'évolution de Dart tourner en bazar infâme, les développeurs de Dart disposant de ressources autrement plus lourdes que celles dont disposait Rasmus. On a par exemple beaucoup moins de chance de voir apparaitre différentes syntaxes dans le nommage des fonctions natives, certains privilégiant le « _ » (underscore) alors alors que d'autre sont en CamelCase. Et ce n'est qu'un exemple franchement mineur, même s'il présente un des défauts du PHP (qui est malgré tout mon langage de programmation au quotidien). En outre, le simple fait que Google ait lâché d'entrée de jeu un compilateur permettant de générer un code JavaScript pour pallier aux manques existants des navigateurs qui n'ont pas adopté Dart me laisse à penser que l'idée de fond qui a prévalu au soutien de ce projet est solide et posée sur des bases qui n'ont absolument rien d'un bricolage sommaire.
L'évolution de JS est moins dynamique que celle du PHP ? Je ne parierais sûrement pas ma chemise là-dessus.
My 2¢
Pourquoi comparer des pommes avec des bananes ?
La comparaison me semble inappropriée.
My 2¢
inappropriée dis-tu ?
On sépare les couches client/serveur, je suis tout à fait d'accord. Mais les deux reste lié, quand je compare les deux, je prends plus large.
De plus, aujourd'hui avec Nodejs on fait du client ET du serveur avec Javascript.
Tout comme le propose Dart et son très très bon package IO, donc oui je me permet de comparer les langages
Aujourd'hui on travail de plus en plus avec les socket, l'asynchrone et nous nous orientons vers la programmations évènementielle sur une plateforme initialement en mode déconnecté (client/server).
Les requêtes deviennent transparentes, plus de rechargement de page, le même langages côté client et serveur.
Je ne pense pas que la comparaison avec un langage serveur soit inappropriée, bien au contraire. Un langage client/server (Javascript/Nodejs, Dart...), qui propose des Api pour travailler avec des outils de cache (redis/memcache) des bases de données ou des services type LDAP ou autres, permettra justement de se dispenser d'un second langage exclusivement serveur.
Conclusion, si demain nous avons un seul et unique langage proposant des outils et Api pour travailler aussi bien côté client que serveur avec une syntaxe et une philosophie proche des langages préférés des Dev Web, je pense, en effet, que celui-ci possède un fort potentiel pour être adopté.
Ce qui revient à dire qu'on remplacerait à terme PHP par une version serveur du JavaScript ? et qu'on programme donc l'intégralité de l'application en JS ? J'ai quelques doutes, mais pourquoi pas ...
Ce qui revient à dire qu'on remplacerait à terme PHP par une version serveur du JavaScript ? et qu'on programme donc l'intégralité de l'application en JS ? J'ai quelques doutes, mais pourquoi pas ...
Du certaines manière oui, Javascript ou autre. Dart apporte un certains nombre de réponses, Nodejs et très bon en terme de monté en charge. Il y a du potentiel dans ce sens. A présent, il manque le recule et la maturité nécessaire pour aller plus loin.
Dart se prépare pour la conquête du Web
J'ai failli m'étouffer là.
Sérieusement : Je ne crois pas un seule instant à ce langage Quoique Apple à bien réussi à mettre en place un langage du même style, et par style j'entends : Un langage élitiste, dont uniquement une poignée de gourou comprennent le fonctionnement, avec un besoin boulimique d'outils propriétaire pour faire tournée le machin, je n'ai qu'un seule demande, si ce machin surpasse une bon vieux Notepad avec de l'HTML et du JS : Filez moi un coup sec derrière la nuque ! On à déjà assez avec l'Objective-C...
Répondre avec citation
Partager