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
La différence est de taille : le bulgare est alphabétique et supporte un encodage 8bits (via le KOI8 - ergo, il n'impose pas l'emploi de facto de l'UTF-8).Envoyé par stailer
Pas grand chose à voir avec l'encodage des écritures non alphabétiques tels que chinois ou japonais.
Je suis d'accord avec toi la dessus, mais certainement pas dans le même sens.Je pense que la comparaison C# (enfin, asp.net quoi) et PHP n'a pas de sens.
Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...
Une réponse vous a aidé ? utiliser le bouton
"L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel
WinRT n'est rien d'autre que le "nouveau" nom du framework .Net.
Les langages C# et VB.Net ne sont pas mort. Le WPF est juste le framework UI introduit par .Net 3.5. Son principe (accelération graphique, introduction du XAML, binding, etc.) est juste intégré à WinRT. Il est donc utilisable depuis C++ maintenant.
De plus, WinRT est "callable" depuis JavaScript.
Microsoft fait de l'oeil aux dev web/JS tout en conservant les acquis de .Net.
La seule différence est que toutes les API .Net ne sont pas exposées dans WinRT. Les APIs filesystem, sockets, etc. existent mais ne sont pas directement accessibles.
Ceci dans le but d'avoir des applications plus stables et moins sensibles. On ajoute à ca tous les mécanismes de sécurité, sandboxing, d'appels asynchrone...
Bref, tout ca pour rentrer dans le moules des "Stores".
Mais bon, créer une UI "wpf" avec C++/C#/VB/J#/? ou appeler des API .Net en JS et faire l'UI en HTML5, je vois pas ce que vous voulez de plus...
http://tirania.org/blog/archive/2011/Sep-15.html
oui oui j'avais bien compris. Et le sens que tu sous entends , je le trouve stupide.Je suis d'accord avec toi la dessus, mais certainement pas dans le même sens.
J'ai eu de nombreux accrochages à ce sujet : il est stupide de mettre un langage au dessus d'un autre... Il y a tellement de choses qui rentrent en compte :
- les développeurs eux-mêmes et leur goût pour tel ou tel langage
- la portée de l'appli , web , pas web
- le prix de l'appli, voir le client qui paye l'appli
etc etc... il y aurait des centaines de choses à dire, qui montre que dire :"C# plus fort que PHP" ou "java plus fort que c#" , c'est juste stupide.
.o0o__St@iLeR__oOo.
Lead Developer
ASP.NET MVC - MCP/MCSD ASP.NET
PHP Zend Framework / PhalconPHP
Cordova/Xamarin IOS/Android
Kendo UI - ExtJS - JQwidgets
SQL Server / MySQL
Non, pas du tout. WinRT est l'API qui permet le développement d'applications Metro. C'est basé sur COM, et c'est utilisable depuis différentes technos (C++, .NET, Javascript...). Ça ne remplace absolument pas le .NET Framework.
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : Les nouveautés de C# 6 - Accès aux données avec Dapper - Extraction de données de pages web à l'aide de HTML Agility Pack - La sérialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
C'était un raccourcis. Ce que je veux dire c'est que la majeur partie des API .Net sont intégrés à WinRT. Je vois pas pourquoi un développeur .Net serait déboussolé par un changement de nom. Le développement d'une application Métro n'aura rien de compliqué pour un développeur C#/WPF.
Je parle bien du développement, pas du portage.
Tout ce discours sur un changement total de paradigmes, je l'ai déjà entendu il y a quelques années alors que Windows Vista et .NET se confondaient dans un projet nommé Longhorn. On nous bassinait alors avec un soit-disant nouveau modèle d'application et une toute nouvelle API. WinRT peut effectivement être vue comme une évolution du framework.NET pour un programmeur C# ou comme une amélioration du binding vers le framework pour un programmeur C++ et Metro n'est pas aussi différent du Windows "classique" qu'il semble l'être à première vue. Pas de boîte de dialogue modale dans Metro? Non, et alors? Il y a des "panels" qui le sont... Windows 7 n'utilise pas non plus les même widgets que Windows 3.1. Et en fait, en y regardant bien, on pourrait même dire que non seulement il n'y a pas de rupture, mais que Windows 8, Metro et WinRT ne sont qu'une incarnation du projet Longhorn...
Pour ma part ce n'est pas le bruit autour de HTML5/Javascript qui m’inquiète.
Mais c'est plutôt le 'non' bruit sur le retour de C++ avec Xaml le tout en mode compilation statique.
Les périphériques mobile sont lents, le code s’exécutant dans des vm est également lent (même si les PC moderne compense avec leur puissance).
En revanche le code C++ est performant, et largement + que tout le reste.
Donc si je dois construit une stratégie de développement d'application pour mobile et tablette :
je choisi C++/Xaml pour les applications.
Pour les petites 'tuile' je fait du HTML/Javascript connecté à un bon serveur de web service.
Et Dotnet, et ben dotnet je le garde pour les web services et les applications PC.
Bref, moi je refais du C++.
En effet, on peut se poser la question du devenir de .NET, mais microsoft en tire pourtant de gros bénéfice (formation, tools, services, produits, ...).
C'est un domaine ou apple et google est absent, je ne pense donc pas qu'ils vont le détruire si vite.
Par contre qu'ils soient obliger de l'adapter aux nouveau besoin, oui!
En fait ce que l'on remarque c'est que microsoft a tenté un pari, proposer une unique solution a tous les problèmes. Code rapide, lourds, léger, web sevices, interface, script/compilé, UI : .NET
La vérité, personne ne veut donner toutes les cartes a microsoft, donc on se rabat sur les technos "libre", même si techniquement elles semblent désavantagées.
A ce petit jeu HTML/CSS/JS pour le web.
C++ pour les client lourds.
C pour l'embarqué.
mais il y aura toujours des société pour proposer quelques chose de différents (pour se faire de l'argent), ce n'est qu'une question de temps.
Par contre aujourd'hui, investir sur les plateformes sûres (C++, JS, HTML) c'est ce donner une sécurité, car ils seront toujours là dans 5 ans.
C'est un peu le combat DX vs OGL, l'un paraît mieux mais instable dans le temps lorsque l'autre semble en retard mais fonctionne toujours.
Par contre je rejoints totalement l'amalgame qui est fait entre W8 métro et .NET.
Tout n'a pas vocation à se retrouver dans une tuile :/, heureusement.
Ben, c'est simple, une application WinRT sera faite en C++/CX avec WinRT, et donc compilé dans code natif de la plateforme cible.
Donc le développeur C# doit apprendre le C++/CX, vive les shared_ptr, unique_ptr, etc...
A mon sens sa fait une différence de taille.
Effectivement, il est possible de faire du C#/WinRT qui s’exécute dans la CLR. Mais les API WinRT utilisées seront du code non managé, donc il y aura également des problèmes de ressource à libérer comme aujourd'hui lorsque l'on utilise dans la CLR des API Win32.
@ash.ice.loky
La grille de lecture libre/proprio me semble totalement fausse.
* C/C++ connaissent un regain du fait des besoins en performances.
* Html/Js/Css étendent leurs usages d'une part du fait des besoins en performances et stabilité (abandon des plugins, une seule plateforme - oui, parler de perfs à propos de Js est bizarre mais c'est bien la raison invoquée contre Flash & co et c'est finalement le navigateur qui assure souvent les services autrefois fournis par Flash) et d'autre part et surtout parce que beaucoup de développeurs connaissent cette plateforme (pas de barrière d'entrée) et qu'un nombre non-négligeable ne connaissent finalement que ça.
* OGl vs Dx ? Mais pendant plusieurs années aucun jeu n'était développé en OGl justement parce que ce standard était à la ramasse, et je n'ai pas entendu dire que cela avait changé. C'est différent dans le domaine applicatif mais soit on parle de besoins peu exigeants, soit de solutions clé en mains avec matériel spécifique et proprio.
@BertonF
Je suis convaincu que les développeurs dotnet n'auront absolument pas besoin de migrer vers le C++ pour les applis PC et que l'API de WinRT a été conçue pour être utilisée en C# comme un objet dotnet natif et en JS comme un objet JS natif. A vérifier mais le contraire m'étonnerait beaucoup. Je présume que c'est plutôt le dév C++ qui risque de bouffer du COM à longueur de journée.
EDIT: Confirmé. Pov C# / Pov C++
Totale transparence en C#, extensions du langage en C++ avec génération auto de wrappers. La programmation WinRT en C++ ressemble fortement à du C++/CLI.
Microsoft commencerait il à virer vers l'utilisation de HTML5/JavaScript/CSS ? personnellement je n'ai rien contre et j'apprecie au contraire et suis d'avis!
Je pense que MS veut virer de technologies pour de question de restrictions dues à une mauvaise conception de langages C# et VB beaucoup moins puissants qu'un Javascript ou un Dart structurellement mieux faits et qui permettent de faire plus de chose avec moins de framework. En somme, ils voudraient rebondir et reconsolider leurs bases. Leurs développement à toujours été incrémental chez microsoft... rarement du développement de scratch. Dommage, moi aussi j'aimais le .NET mais j'ai toujours senti ses limites : La nécessité d'un framework assez lourd.
Mais ça m'étonne pour silverlight et wpf... Ils n'arriveront pas à nous imposer du HTML5. Le Xaml est beaucoup mieux fait... :lil:
De plus, microsoft perd des clients dans l'applicatif de gestion.
Aucun de nous n'est seul, Même l'air que nous expirons est inspirés par d'autres...
Tu peux ajouter un semblant de démonstration à ce délire hallucinatoire ?
Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...
Une réponse vous a aidé ? utiliser le bouton
"L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel
Là, ça mérite que tu détaille tes arguments quand même, parce que parler de mauvaise conception pour .Net, on en le fait pas sans argumentation solide.
Au contraire, ça semble plus logique, Silverlight et WPF n'ont jamais pris à la hauteur de ce qu'attendait Microsoft. Technologies prometteuses mais qui n'ont pas séduit.
Perso, j'aurais dit le contraire.
Aux vues des articles de presse, offres d'emploi, etc, SQLServer semble gagner tous les jours plus de parts de marché, la gamme Dynamics semble ne pas trop mal se porter (je n'entend d'ailleurs plus parler du possible abandon de la CRM, au contraire, il y aurait une forte orientation cloud dans les prochaines versions), Sharepoint est en train de s'imposer comme un acteur majeur, Office se porte toujours bien, ....
Certes, ça fait quelques années que l'on a perdu Money déjà, à mon grand regret
--- Sevyc64 ---
Parce que le partage est notre force, la connaissance sera notre victoire
Merci pour ce poisson d'avril qui m'aura bien fait rire.
Cela étant dit, rappelons que dotnet n'est absolument pas abandonné et que JS ne vise en aucun cas à le remplacer (seul un suicidaire irait utiliser JS pour une appli de bureau complète) mais simplement à attirer les développeurs web vers les plateformes windows.
J'aurais plutôt dit "un peu moins mal fait". C'est quand même le gros point faible des solutions WPF/SL/WinRT, partir sur du XML était une fichtrement mauvaise idée. Syntaxes à la noix (espaces de noms en XAML vs C#), verbosité, etc... Quand on compare avec Qt Quick par exemple...Ils n'arriveront pas à nous imposer du HTML5. Le Xaml est beaucoup mieux fait... :lil:
Pour WPF je pense que c'est une question de temps: les applis WPF sont insupportables sur XP mais très satisfaisantes sur de bonnes machines sous Seven. Quant aux vices de conception, ils ont été à peu près palliés par les System.Windows.Interactivity et une évolution des pratiques (abandon des convertisseurs, etc). Je vois mal des solutions purement JS ou JS/C++ (avec grosse plomberie sous le plancher) s'imposer. Ce qui se fait aujourd'hui en WPF se fera demain en WinRT + dotnet, voilà tout.Au contraire, ça semble plus logique, Silverlight et WPF n'ont jamais pris à la hauteur de ce qu'attendait Microsoft. Technologies prometteuses mais qui n'ont pas séduit.
A part quelques cas particuliers, ça m'étonnerait... Les grosses applis de gestion ne passeront jamais en WinRT, parce que l'interface Metro n'est pas adaptée à ce type d'application. A mon avis WPF a encore de beaux jours devant lui pour les applis professionnelles, qui resteront sur le bureau classique, et WinRT sera plutôt utilisé pour des applis "gadgets", ou du moins relativement simples.
cf. cet article qui résume assez bien ce qui va (probablement) se passer
Oui, exact, j'avais oublié que WinRT était réservé aux UI métro. Donc effectivement WPF a de beaux jours devant lui et dotnet pourrait bien continuer à y gagner des parts (notamment vis-à-vis du C++ avec lequel la création d'UI modernes est fastidieuse, sauf si Qt Quick ou autre s'adapte au bureau).
Oui, mais ma diatribe ne portera pas sur mes connaissances en .NET.
Voilà ... rHum, rhum... Vous savez tous que JScript de MS a échoué. Et bien pour ne pas faire double emploi, ils veulent un langage apte à faire du multimédia avec peu de code. Metro étant orienté front end, le C# et le VB ne sont pas à la hauteur à ce niveau là. J'entends que structurellement on aura beaucoup de peine à faire un "jQuery" like avec ces langages. Du moins, cela me ferait rigoler.
Le C# c'est du C like, je dirais à ce niveau qu'ils sont passé à coté de leur objectif : Le langage de .Net c'est pas C# mais VB... et c'est beaucoup trop verbeux à mon goût.
Seul un langage comme le JS permet de faire des appli réactives et des librairies lisibles à la volée de manière performante. Voilà
Aucun de nous n'est seul, Même l'air que nous expirons est inspirés par d'autres...
Si tu le dis
Je pense pas que tu aies fait beaucoup de C# ou de VB pour dire un truc comme ça...
Je vois pas pourquoi on pourrait pas, mais de toutes façons ça ne servirait à rien : jQuery n'est utile si tu fais du HTML ; en XAML on n'a pas besoin d'un truc comme ça, il y a d'autres méthodes plus adaptées pour arriver au même résultat.
Première nouvelle
Les 2 langages sont quasiment isofonctionnels, tout ce que tu peux faire avec l'un, tu peux aussi le faire avec l'autre. Et s'il n'y en avait qu'un, le langage de .NET serait plutôt C#, qui a été spécialement conçu pour ça (alors que VB.NET n'est qu'une adaptation de VB6 pour .NET)
Encore un avis super objectif et argumentéSeul un langage comme le JS permet de faire des appli réactives et des librairies lisibles à la volée de manière performante. Voilà
Là tu te plante complètement.
C# ne rivalise pas avec C, ce n'est un C like. Il n'a pas grand chose à voir avec le C, si ce n'est la syntaxe de base du langage.
Il a été développé, sur une inspiration de Java qu'il cible (tout au moins au départ) comme principal concurrent. Le C# est un peu le Java de Microsoft (après que le projet J++ est fait un gros bide)
Non, pas du tout. Le .Net est un framework, d'autres, sous d'autres langages, appellent ça machine virtuelle. C'est, en gros, un ensemble d'api qui peuvent être utilisées par n'importe quel langage, pour peu qu'il y soit adapté.
VB et C# sont les 2 principaux et les fers de lance, mais il en existe d'autre. Un temps on pouvait faire du .Net avec Delphi, je sais pas si c'est toujours possible. Il me semble aussi que Windev sait interfacer .Net.
VB n'est pas .Net. L'idée de Microsoft en 2000 quand .Net a été conçu, était de faire disparaitre VB à terme. Le C# avait pour un des but d'amener les vbistes sur cette nouvelle programmation (puisque globalement ils étaient réfractaire au C++). Sauf que ce qui s'est passé, et que Microsoft n'avait pas prévu, c'est que les C#piens au départ ont été essentiellement des anciens de C et de C++.
Désormais, depuis 2008, VB et C# on un avenir commun sur .Net, enfin tant que .Net existera.
--- Sevyc64 ---
Parce que le partage est notre force, la connaissance sera notre victoire
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager