Discussion :

[PatteDePoule]

pérennité? Ça existe en informatique?

[Guulh]

pérennité? Ça existe en informatique?

Microsoft est réputé pour maintenir la compatibilité ascendante à tout prix. Windows est farci de patchs servant à faire fonctionner des vieilles applis qui faisaient un peu trop d'hypothèses sur la mécanique interne de windows et recourraient à trop de comportements non garantis par l'API. Ca explique en grande partie pourquoi les API ne sont pas homogènes, ou pourquoi il existe 25 façons de faire la même chose.
Après, ceux qui ont trop misé sur Visual Basic l'ont dans l'os, certes

What ?

La pérennité de dot net n'est pas en question.

Tu disais à raison que les clients (quoi que ça dépend lesquels...) craignaient les effets de mode. Je voulais juste dire que .Net n'en est pas un, vu son âge.

[B.AF]

10 ans c'est le temps qu'il a fallu à Delphi pour mourrir : de 1995 à delphi 2005.
(Et encore , je ne sais pas si la vraie dernière version ne fut pas la 8 tellement 2005 est bourré de bug)

Donc on peut dire que .Net plus résistant que Delphi.

[od.dev]

pérennité? Ça existe en informatique?

Ben ouai hein
Moi je dirais que 10 ans de vie pour une appli avant de devoir la migrer vers le nouveau truc à la mode qui n'apporte strictement rien sur le plan fonctionnel , je trouve cela bien.

Ok Guulh, il est évident que dot net n'est pas une mode, mais il est présenté comme le remplaçant du système win32.
Mais d'après les différents sons de cloches, je commence à me demander si win32/64 ne survivra pas à dot net.
Qu'en est-il, par exemple, de la différence, systémique, de performances entre un développement natif et un développement dot net ?

[Guulh]

Les apports des nouveaux outils ne sont pas forcément fonctionnels. Ce sont la plupart des gains en termes de productivité qui sont mis en avant. Une appli business bien typique, avec des grilles et des champs texte partout, est quasiment la même qu'on soit en mode DOS, et win32 ou en WPF.

Ok Guulh, il est évident que dot net n'est pas une mode, mais il est présenté comme le remplaçant du système win32.

Non, pas vraiment. C'est une techno recommandée pour tout un ensemble d'applis, notamment les applis business, mais je n'ai lu nulle part que ça deviendrait à court ou moyen terme la seule API de windows.

Ne serait-ce que le legacy, les drivers, les jeux, ... L'os principal de Microsoft sera peut être un jour tout managé (il y a des projets chez MS research en ce sens), mais je doute que ça soit une évolution de windows.

Puis il suffit de regarder ce qui s'est passé les dernières années : les nouveautés de windows vista et 7 sont accessibles via les api win32, pas dans .Net. Il faut encore des tas de p/invoke pour bénéficier des jump list, de la transparence, ... dans les winforms (j'ignore ici WPF qui autant que je sache est un monde à part tout managé, très peu lié aux primitives des API windows)

[od.dev]

(Et encore , je ne sais pas si la vraie dernière version ne fut pas la 8 tellement 2005 est bourré de bug).

Ben ouai, mais c'est l'éternel problème des nouveaux trucs. Il me semble que D2005, c'est à dire D9, était la 1ère version d'un nouvel EDI dont j'ai la 2e version, BDS2006, et qui me donne toute satisfaction, du moins au niveau Delphi, parce que si on retire les outils aujourd'hui obsolètes, ben y reste pas grand chose mon vieux.
Il ne faut jamais investir dans les 1ère versions, elle ne sont jamais terminées et sont vendues en l'état pour financer les 2e versions à peu près terminées.
Je suppose qu'il en va de même pour D2010 dont le successeur XE est déjà présenté
Celui là m'intéresse (juste pour voir), parce qu'à mon avis, le multi-plate-forme dont tout le monde parle, ce sera pour 2012, 1ère version, 2013 version réelle . Pourquoi j'ai mal au ventre ?

[cinemania]

guulh est un peu hors sujet

effectivement, la pérennité de dotnet n'est pas remise en cause. quand au fait que cette technologie à 10ans, cela sert juste à affirmer qu'elle à atteint la maturité et qu'on peut l'utiliser pour des projets de très grosse envergure, et que l'on peut envisager le portage d'autres applicatifs vers cette technologie.

od.dev tu peux également te poser la question de savoir vers où va l'applicatif actuel... si tu va vers des technologies très accès architecture de service... Dotnet est évidemment plus facile à gérer de ce côté là.
En plus la société Portugaise qui a racheté Inprise et donc borland, pour ce qui est de Delphi, il y à quelques années, fait du grand n'importe quoi, et saborde ses propres produits... à croire qu'ils veulent faire faillite

[od.dev]

D'accord sur tout.
Y compris sur la vision orienté services de dot net. Je vais peut-être arriver à trouver une place dans mon monde pour ce dot net.

[cinemania]

guulh pour WPF effectivement, c'est un monde à part qui lui est plus basé sur DirectX, et le gentil monde du graphisme vectoriel...

toutefois le problème de transparence de la fenêtre principale, ou du moins étendre le "aeroglass effect" à toute la fenêtre, ou les parties non utilisées nécessite quand même l'utilisation de P/Invoke, et ce même en WPF.

le but n'est pas de totalement arrêter win32 ou 64 loin de là, mais quand à parler des différences de performances, à part pour les jeux et tout particulièrement le moteur 3D et le moteur physique... où la performance est indispensable... (bien que parfois en voyant comment certains jeux sont développés on serait tenté de ce poser la question.) je dirais que souvent la différence est imperceptible.
en fait ce que beaucoup semble oublier, c'est que la CLR, exécute (comme java avec le jbc) un code IL, mais en arrière plan, un compilateur JIT compile en code natif tout le code IL de l'application, en commençant par les sections "critiques" grâce au profilage de l'application...
en procédant du plus urgent au moins urgent, pratiquement l'intégralité de l'application au delà d'un certains temps est entièrement compilé en code natif et tourne avec le dit code, ce qui faut qu'au final les différences de performances auraient tendances à disparaître...
maintenant il est vrai qu'il faut un certains temps pour que l'application arrive à se stade, mais bon.