Version imprimable
C'est un atout intéressant je trouve? De pouvoir modifier le langage et l'orienter à sa convenance pour par exemple coder plus vite (cf javascript et ses "tiny" librairies). Mais bon, je te remercie pour ta précision quant à l' "eval" du code. C'est que structurellement, le lisp est aussi mal conçu :mrgreen:Citation:
Envoyé par MiaowZedong
En gros, oui. Ça veut dire qu'on manipulera WinRT via des API .NETCitation:
Envoyé par zulad
Pour compléter, il y a un petit schéma ici http://blog.objetdirect.com/dotnet/w...e-futur-du-netCitation:
Envoyé par tomlev
Html 5 ne remplacera pas les plugins. SL et Flash iront de l'avant dans des domaines que le browser ne pourra jamais atteindre, à savoir le multimédia de haut niveau. Les browsers se limiteront aux spec de la w3c. C'est comme ça.Citation:
Envoyé par npuzin
Si IE ne prends plus de plugin, c'est un choix commercial ou stratégique pour saborder la concurrence. Apple avait fait la même chose.
Quant à l'avenir de SL, ça dépend de l'investissement de microsoft. Mais certainement pas d'un lack technologique ou de concurrence. :mouarf:
Ouais mais comme tout va passer par un navigateur et qu'à terme "c'est fini les plusgins", je vois mal comment on pourra lancer du Flash ou du SL :aie:Citation:
SL et Flash iront de l'avant dans des domaines que le browser ne pourra jamais atteindre, à savoir le multimédia de haut niveau. Les browsers se limiteront aux spec de la w3c. C'est comme ça.
Tant qu'à : "SL et Flash iront de l'avant"... Ben didonc quel optimisme, que j'aimerais partager. Malheureusement aux dernières nouvelles, SL est archi mort et on est pas près d'avoir une version 6.
Y a qu'à voir les améliorations de la 5 : quasi passée inaperçu.
Intéressant? Oui.Citation:
Envoyé par zulad
Nécessaire? Non.
Utile? Selon le projet.
Je te signale d'ailleurs que le LISP n'est pas du tout mal conçu, certains dialectes souffrent de la décentralisation qui fait que c'est un peu le désordre niveau fonctionalités "standard" mais le language lui-même et les dialectes bien gérés sont très bien conçus.
Par contre la conception du LISP répond à des besoins très différents du C#, ou pour prendre des languages créés vers la même époque, du FORTRAN (calculs physiques) ou du COBOL (gestion financière). Le LISP est un language issu du domaine de l'intelligence artificielle, c'est pourquoi la capabilité du code à se modifier soi-même était indispensable.
Sous bien des aspects, le LISP est aujourd'hui encore un language génial, mais il n'a jamais été conçu pour faire tourner des applications client/serveur sur un extranet de gestion.....le C#, le Java répondent bien mieux à ce besoin.
On peut bien sûr concevoir un language universel, mais je pense que la plupart des codeurs ne voudraient pas voir une telle usine à gaz.
Peux-tu en dire plus sur ces "tiny" libraries et en quoi elles permettent de modifier le langage s'il te plaît ? Je ne vois pas à quoi tu fais référence et tu m'intrigues.Citation:
Envoyé par zulad
Ce point n'est pas exact : LISP s'est révélé être bien adapté par la suite aux problèmatique de l'IA, mais l'IA n'a pas été la source d'inspiration initiale.Citation:
Envoyé par MiaowZedong
C'est hors-sujet mais ça m'intéresse: il me semble que le LISP a été conçu à la fin des années 50 par John McCarthy alors que celui-ci travaillait sur la logique mathématique comme base de l'IA. S'il y a une autre histoire que j'ignore, fais-m'en part :)Citation:
Envoyé par Bluedeep
Ca m'étonnerait que le web se contente longtemps de pure html5... Ca me fait penser à l'engouement pour les UI ajax vs XUL d'il y a 5 ans. Le web aura toujours besoin d'être enrichi par des plugins. Au pire, l'absence de SL ou Flash aura durée une génération de browser ou deux. Maintenant ce qui ne m'étonnerait pas ce serait qu' IE 11 fasse du XUL Like ou que les browsers aient des addons du genre dans leur market places 8-).Citation:
Envoyé par stailer
Je pensais juste à des petits moustiques comme "prototype.js" mais ça ne modifie pas le langage... oops :)Citation:
Envoyé par DonQuiche
Compte tenu du fait que HTML 5 est développé précisément pour combler les limitations de HTML 4 dans le domaine de la création d'interfaces utilisateur, du graphisme et du multimédia, ce serait vraiment étonnant qu'un Silverlight ou un Flash soit encore nécessaire. Je pense que "primitives" du HTML 5 telle que le canvas par exemple sont suffisamment générales pour construire à peu près n'importe quoi. Reste à voir cependant comment la recommandation évolue et ce qu'elle sera une fois finalisée...
L'avantage des Plugin est que tout ce que HTML 5 peut faire, SL le fait depuis longtemps. Et plus encore. On peut suivre les évolutions plus vite. Évidemment avoir un standard c'est pas mal non plus. Le prix a payer est une évolution plus lente. Et je vous d'ici venir les "moi j'implémente DRM avec la norme xxx". "Ben moi j'implémente avec zzz". Enfin ça rappelle de bons souvenirs au vieux briscards du net ;)Citation:
Envoyé par ptah35
Ok, merci pour ta réponse.Citation:
Envoyé par zulad
Une question me vient en revoyant le nouveau schéma :
Le C/C++ a l'air moins bas niveau avec le WinRT qu'avec le Win32, je me trompe ?
Par ailleurs, faudra-t'il se taper du xaml à tous les coups ?
Oui et non. Ca reste du C++ traditionnel non managé, tu peux utiliser la plupart des librairies existantes (Boost ou autres). Par contre certaines fonctionnalités sont interdites pour passer sur le marketplace (genre ouvrir un fichier de manière synchrone, il faut passer par l'api asynchrone de WinRT).Citation:
Envoyé par zulad
Non, tu peux tout faire avec du DirectX. Par contre, non il n'y a pas accès aux contrôles classiques (genre faire apparaitre une MessageBox)Citation:
Envoyé par zulad
A noter que comme pour Windows Phone, il y a plein de choses qui sont réalisables sur le poste du développeur mais qui ne passent pas les certifications du MarketPlace (seul moyen de diffuser l'appli).
Je viens de faire le point sur la faisabilité d'un portage flash>html5 et je ne suis vraiment pas convaincu. N'importe quoi, demande beaucoup trop de travail. Comment travailler avec des fontes ? Comment avoir une taille relative du canvas. Comment streamer du son ou composer avec les vidéos, faire des clips, etc ? Je croix que ça nous ramène à l'aube de flash cette techno. Virer le plugin n'est pas un choix technologique, c'est à mon avis stratégique. Pour le re-come back des plugins proprios, évidemment...Citation:
Envoyé par ptah35
Les canvas ne permettront pas de rivaliser avec flash 11 ou unity, du moins pas pour ce que j'en ai vu. Quelle drole d'époque.
Edit : J'ai testé les fontes et ça marche bien :aie:
Il faut savoir que notre facon de travailler va évoluer et ce qui est nécessaire aujourd'hui sera inutile demain.Citation:
Envoyé par zulad
Exemple d'actualité: Windows 7 + antérieures => Windows 8
Autre exemple: Datagrid disparu ou devenu beaucoup plus difficile a utiliser en .Net.
Je ne penses pas que parier sur des technos qui meurent soit vraiment stratégique, meme Adobe le dit et s'implique tete baissé maintenant dans le HTML5.
Silverlight + Flash restent pour le moment cantonnés a du contenu spécifique (notamment la 3D), pour le reste il y a dans la plupart des cas une alternative (ou cette alternative arrivera demain).
De toute maniere Flash est en fin de vie quoi qu'il arrive, si ce n'était pas HTML5 qui l'aiderais a finir ses jours ce serait les applications natives en mode Cloud qui "l'acheverait".
Je ne suis pas de cet avis. Flash n'est pas en fin de vie, comme Silverlight la majorité de ces fonctions sont réalisables en HTML5, ce qui va le diminuer sur le web mais le tag object existe encore. De plus l'aspect "opensource" de l'html5 fera toujours des nostalgiques de l'aspect "embedded" des plugins. Le HTML n'est qu'un truc en plus pour moi.Citation:
Envoyé par alex_vino
J'ai du mal à concevoir la disparition des formats clients et portables comme swf. Il y en aura probablement encore d'autres, c'est l'essence du web "Out of Browser". Les agrégateurs de moustiques à la volée et autres interpréteurs de browsers ne pourront pas rivaliser avec des mini-frameworks comme SL, FlashPlayer et Unity, car c'est de l'orienté métier. Pour rivaliser, les browsers développeront leurs plugins qu'ils appelleront add'ons :lol:.L'arrêt provisoire de ces technologies dans le nouvel IE n'est que stratégique, le temps de revenir à la planche à dessin... Du moins c'est ce que je pense.Citation:
Envoyé par alex_vino
Edit : ... et de réintroduire leur JScript like :)
Une chose me turlupine et j'aimerais avoir une réponse de ceux qui ont testé Windows 8 svp.
Voici comment j'imagine les choses : si demain je veux écrire une appli dispo sur le store pour les tablettes, c'est obligatoirement via WinRT. Mais si je veux que mon appli soit également dispo pour le desktop, mes utilisateurs ne voudront pas d'une expérience métro. Donc je ne pourrai pas utiliser Metro pour la version bureau, si bien que je devrais pour une même appli sur tablettes et desktop créer deux versions différentes de l'UI, l'une avec WinRT et l'autre avec WPF.
Ai-je raison ? Ou bien les utilisateurs pourraient-ils finalement désirer une expérience métro sur le desktop ? Et si oui, pensez-vous que le store pourrait finir par rencontrer du succès sur le desktop et devenir aussi central sur desktop qu'il l'est sur tablette ?
2 versions différentes, ou une version intégrant les 2 interfaces. Ce qui est en préparation d'ailleurs pour IE10, Firefox, et surement les autres navigateurs aussi