Discussion :

[Jeweller]

C'est juste pour jeter un pavé dans la mare

..desole!

[RDM]

Forcément, on ne peut que y penser. Seulement, reprendre l'activité IDE de Borland ne consiste pas seulement a faire l'interface d'un outil de développement mais aussi a maintenir et faire évoluer le compilateur Delphi Win32, Delphi .NET et éventuellement un Delphi 64 sans compter peut être Kylix.
même chose pour le compilateur C++.
Et maintenir un compilateur n'est pas une chose aisée, ca demande une très bonne équipe R&D qui ne fait que cela. Borland avait déjà du mal a maintenir une équipe comme celle là.
Pour JBuilder... la concurrence Eclipse est rude, même borland laissait entendre qu'Eclipse était incontournable.

Bref, je pense pas que Delos soit capable de soutenir une telle activité en face de Sun, Microsoft ou IBM.

[Jeweller]

C'est sur! Mais derrière cela, on peut se poser aussi la question de la stratégie de Delos face cette annonce... le framework lui meme de XMLRAD va -til resté "Delphi" ? Pourrons-ils réécrire une framework aussi puissant intégralement sous VS ou autre?... même si ces questions ne me semble pas à l'ordre du jour j'imagine qu'elles auront aussi frolées vos esprits
Cela touche de pres nos appli, d'un peu plus loin certes si on ne travaille pas avec Delphi directement...

Michael

[Pierre FORAZ]

Mais derrière cela, on peut se poser aussi la question de la stratégie de Delos face cette annonce

Elle vient d'où cette annonce ? (si annonce il y a !)

[Jeweller]

La mise en vente des IDE par Borland, pas l'achat de ces IDE par Delos !

Voir la rubrique Delphi : http://delphi.developpez.com

et une vision obtimiste:
http://www.components4programmers.co...ndsdecisio.htm

[RDM]

oui, la question de fond est bien celle là !
Tant que l'on a pas de vision plus correcte de l'avenir de Delphi il est difficile d'arreter un choix. Tout est encore possible.
Dans le pire des cas, certaines options restent possible.
L'indépendance face a Delphi a déjà été soulevé en interne chez Delos (Corp comme France). Une voie possible serait de passer sous FPC (Free Pascal Compiler). Certains sont très attachés au pascal en tant que langage clair et facile à maintenir. L'avantage de cette approche outre le langage, c'est une possible maitrise sur le compilateur, c'est à dire a faire des propositions d'ajouts, ou de soumettre des modifications. Avec Borland il était plus difficile d'obtenir certaines fonctionnalités du langage. D'autre part, FPC supporte déjà le 64 bits (au moins pour linux).
D'autres pense qu'une migration vers un langage comme le C++ serait à envisager pour être le plus indépendant possible et le plus cross-platform. ce serait au moins pour le framework, pour les développeurs, ca ne changerait rien a ce qu'il y a aujourd'hui.
Ces alternatives risquent, peut être, de revenir à l'ordre du jour plus vite que prévu en fonction des orientations que va prendre Delphi.

pour l'instant, wait and see...

[powerlog]

Et pourquoi pas en pure JAVA ?

[Sylvain James]

Le framework en Java, je suis curieux de voir ce que ça donnerait en termes de perfs, malgré les performances vantées des dernières générations de compilos JIT. Sachant que selon le compilo JIT utilisé sur le serveur, les écarts de perfs pourraient être étonnants.

Concernant FPC, je crois aussi que c'est une solution intéressante, d'autant que le compilo est capable de sortir sur pas mal de plateformes, même sur PowerPC. La communauté FPC semble être assez active et quelques projets périphériques sont assez connus (Lazarus par ex).
Je fais partie aussi des développeurs attachés au langage pascal, surtout pour le framework !
Le C++ offrirait les mêmes avantages, mais le prix à payer serait la complexité de compréhension du framework pour la plupart des XMLRadieuse s et XMLRadieux .

Une voie possible et forcément pérenne : C# sur plateforme .NET sous Windows et Mono sous Linux.
Là aussi il faudrait voir les perfs. Avec la version 2 du framework, les perfs sont meilleures.

à suivre, passionnant....

[RDM]

il est actuellement hors de question de passer entièrement le framework dans un langage managé ! La tendance est au contraire de faire le maximum en natif pour des quetions de performances.
Le niveau d'optimisation sur lequel la team R&D travaille n'est pas accessible a un lanage comme Java ou C# (trop haut niveau). Pour une utilisation par des développeurs oui, pour les arcanes du framework non.
actuellement pour .NET le framework est en pur .NET (avec Delphi .NET) mais à terme il va passer comme pour Java, en une partie Native, et une exposition du modèle objet en .NET pour l'utilisation dans les gestionnaures d'événements.

Il faut savoir que ces choix ne sont pas dictés que par XMLRAD en lui même mais aussi par l'application Delos.