[quote=“rolyat, post:40, topic: 55023”][/quote]
Et c’est bien la preuve qu’en terme de performance c’est largement à la hauteur…
Je n’ai pas spécialement peur pour l’avenir de .net, le gain de productivité est tellement important que les SSII .NET ne peuvent pas faire marche arrière et Microsoft ne peut pas se permettre de se mettre tous les développeurs à dos.
HS: ZGoblin: euh, non, non, on ne codait pas les fichiers en dur dedans vu qu’on avait 3 hardware cible: Windows, Linux et un JavaOnChip. C’était principalement des problèmes avec les JVM (et je parle de 2000 à 2004 hein). Le codage était fait avec xEmacs, JBuilder et des éditeurs de texte.
Je ne sais plus quels étaient les problèmes exactement, mais ce n’était pas lié à des codages en dur, et on s’était bien pris la tête à cause de trucs qui marchaient pour un JVM mais pas pour l’autre.
[quote=“Histrion, post:31, topic: 55023”][/quote]
Et leurs collègues qui bossent sur les bonds codent des pricers en macro excel. Donc bon. L’adéquation outil/utilisation chez les banques…
Ça fait un bon moment que je ne dev plus d’applis .Net (mon employeur actuel ne fait que du Java) mais j’utilise encore de temps en temps le framework .NET en écrivant des petits scripts bien utiles sous Powershell. Ça me gaverait trop que ça disparaisse.
[quote=“AnA-l, post:33, topic: 55023”][/quote] Des voisins de trois à quatre mètres de moi quand je bossais en salle de marché. Je n’ai pas les détails de ce qu’ils développaient, si ce n’est que la partie en assembleur était pour les I/O (drivers maison optimisés pour le HFT). Au dessus ils codent en C.
[quote=“GloP, post:35, topic: 55023”][/quote] 100% à côté de la plaque. Relis.
[quote=“Luk, post:43, topic: 55023”][/quote] Je bossais sur une appli de données de marché qui contenait, entre autres choses, un pricer. Il n’aurait jamais du exister… il n’avait rien à faire dans notre application mais quelqu’un un jour l’a fait pour le plaisir, les traders l’ont bien aimé. Il était bien moins complet que le tout dernier pricer Excel, mais il était super rapide.
Ce qu’il faut comprendre en banque d’investissement c’est qu’il y a probablement trois ou quatre outils pour faire la même chose. Chaque équipe de trading (voire chaque trader individuellement parfois) choisissent les outils les plus adaptés à leur situation.
Parfois c’est un pricer en C++ pour sa rapidité, pour des calculs approximatifs ou des estimations ou des trades sans trop de risques. Parfois c’est une macro Excel faite sur mesure. La seule chose qui les intéresse c’est que ça marche et que ça fasse gagner de l’argent. C’est du taillé sur mesure. Et si le seul gars qui sait de quoi le trade parle s’avère ne savoir coder qu’en Excel, bah ça sera du Excel et ça gagnera de l’argent.
Par exemple là où je bossais les fermes de calculs distriués sont en Ada. Au dessus il y a des pricers en Ada, en python, en Excel, en C++…
Allé, je retourne un peu le topic vers l’ASP.NET pour apporter un peu de soleil dans cette discussion plutôt négative et reposant finalement sur assez peu d’éléments tangibles.
Lors de l’OpenSource Panel de la conférence en ligne DotNetConf que Scott Hanselman a organisé fin avril dernier (tous les talks sont dispo sur youtube d’ailleurs), il a été beaucoup question de la visibilité et du support que MS offre (ou plutot n’offre pas) aux projets OpenSource. Scott Hanselman a promis de faire qqch… et sa réponse ne s’est pas faite attendre.
Le site officiel www.asp.net a maintenant une section “Open Source” pour chaque produit, listant les principaux projets complémentaires ou même concurrents des technologies MS:
Ca ne nous avance pas beaucoup au regard de la discussion actuelle, si ce n’est qu’il y a encore des surprises venant de MS dans le monde .NET… alors qui sait?
Pour avoir discuté un peu avec des collègues qui bossent sur les technos .Net dans ma boîte, ils ont du mal à comprendre la stratégie de MS. Même pour des gars qui sont vraiment dans le milieu apparemment il y a beaucoup d’interrogations.
[quote=“Histrion, post:48, topic: 55023”][/quote]
Hormis le commentaire de Glop, c’est exactement ca le point de départ de la discussion. Comme la stratégie n’est pas claire et que MS met a l’heure actuelle l’accent sur des trucs non-.NET (WinRT avec API C++ et HTML5, fin de Silverlight etc.) bah ca fait jaser et tout le monde imagine ce qu’il veut, y compris les scénarios les plus sombres…
Un article que je viens de lire et qu’il m’a semblé utile de vous partager. Il y a de bons projets autour de .net : SignalR, nuget, scriptcs, Roslyn, katana/owin, typescript…
Perso j’ai eu des grosses merdes avec niveau son. Notamment sous linux, on avait une limite de 100 megas pour les sources et que du wav de dispo sous nux pour le multi plateforme. Donc du coup on a du compresser les wav de maniere totalement pourries.
Et en plus quand le compositeur encodait des wav sur son ordi je redevais passer les wav a une moulinette ffmpeg on a pas tout compris la dessus.
Pareil pour la gestion de son avec des sortes de threads j’ai pas tout compris sur comment les finir et bien gérer le son, ca a été a l’arrache parce que l’on a vraiment manqué de doc la dessus.
Mais par contre j’ai decouvert le framework 2 jours avant et j’ai reussis a pondre un truc experimental assez rapidement et le porter sous mac / linux / windows sans trop de soucis.
Il faut que plus de gens rejoignent le projet donc.
Des avancées majeures, y’en a. Des partis pris, y’en a aussi. Je préfère le C# au C++, sauf que mon engine/pipeline est fait en c++, les tools qui vont avec en c#.
Développement sur ps3/ps4/xbox360/xbox one/wii/wiiU : C++. Demande a n’importe quel éditeur/développeur. Pas assez de perfs sur la VM.NET (déjà programmé sur x360 avec XNA ? L’enfer, le compact framework craint). Le C++ est assez low level pour permettre ce genre de perfs.
Le seul langage qui puisse le concurrencer, à mes yeux, c’est Rust(Mozilla), si ils arrivent a en faire ce qui est prévu. Des trucs cools et modernes, mais tu peux toujours virer le GC.
Source : je bosse chez un des grands (top5) éditeurs/dev mondiaux.