Discussion :

[Nono40]

Nick Hodges, responsable des produits Delphi et C++ Builder chez CodeGear, partage avec nous les dernières nouvelles du front concernant la direction prise pour l'avenir des compilateurs Delphi et C++ Builder.

Lisez Le futur du compilateur Delphi traduction de son article The Future of the Delphi Compiler.

Traduction réalisée par Eric GASPARD (Aka Guymelef).

[Telemak]

Bonjour,
Je n'utilise plus Delphi depuis quelques temps, on peut dire quelques années..
La raison est que j'ai migré de système d'exploitation.
Je suis passé de windows à linux...
Bien entendu je possède Kylix..la version linux de delphi...mais comme il n'y a jamais eu de suite, je me suis tourné vers d'autres langages..par exemple java avec netbeans..etc..

J'ai un peu lu en diagonale l'article et le fait de faire évoluer delphi et j'en suis très content...Mais néanmoins aucune annonce concernant des sorties sous linux... A moins que quelque chose ne se prépare de ce côté.. Je n'attends que celà...
a+

[octal]

Bonjour,
Décevant !!! (je parle de l'article, désolé).

Le Future du Compilateur Delphi;

tout un article pour, au final, nous apprendre qu'ils sont entrain de réécrire le compilo (front-end et back-end) à partir de zero, en conservant la compatibilité.
Franchement les choix de borland me semblent vraiment bizarre ces derniers temps.
En écrivant un Delphi2009, passage à l'UNICODE oblige, on casse une bonne partie des applications MODERNES écrite dans les règles de l'art, et n'utilisant que des constructions et fonctionnalités modernes du compilo (ce n'est pas une critique, je connais la problématique migration UNICODE et je la trouve dans D2009 très réussie). Par contre, Je ne vois pas trop pourquoi maintenir dans un compilo pareil, lors de migration (ennorme) pareille, pourquoi maintenir une notation en parenthèse_point ou même les trigraphes (pour C)... Cela n'a aucun sens. A la limite, de telles notations peuvent être simplement transformée via un rechercher/remplacer ou (pour les plus complexes) via le module de Refactoring (c'est censé utiliser la structure et la sémantique du langage ce trucs là pour y appliquer des transformations, n'est ce pas ) .
Borland (ou CodeGear ou Embarcadero, pardonnez moi cet abus de language, mais j'utilise les outils depuis DOS, plus précisément depuis TurboPascal3 - quand les array (.1..50.) étaient encore d'actualité). Des fois les choix fait par Borland sont étonnant. Je pense que les équipes de dév chez Borland doivent un peu oublier, de temps à autre, qu'ils ont été le STANDARD en pascal, l'ultime choix pour les outils de dev, qu'ils se retroussent les manches et qu'ils bossent sérieusement en prenant en compte qu'il y a un certain Visual Studio, NetBeans et/ou Eclipse. Le temps où les gens étaient étonnés de voir des menus déroulant dans un IDE est révolu!

Ce que personnellement, j'ai bien aimé dans D2009, c'était surtout le rajout des générique. Je pense que Borland devraient surtout se concentré sur le rajout de fonctionnalité pareils dans Delphi, des outils qui améliorent le confort dans la création de code réutilisable, des outils de modélisation beaucoup mieux intégrés et gérant le two-way-tools d'une manière plus sympa (plutot que des usines à gaz).
Le rajout du 64 bits est certainement très important. L'intégration de librairies standard le seraient plus, comme notamment rajouter une encapsulation (sous forme de composant VCL ou autre) d'une certaine OpenGL ou DirectX (principaux outils qui nécessitent du 64Bits à mon avis)...

Le aussi le rajout de la possibilité de générer du Code ARM (pour les PDA et autre milliers d'ordinateur embarqué ARM9) serait la bienvenue.

Ne me prenaient pas mal, le rajout du 64 bit pourrait être intéressant, mais pour nous les développeurs de solutions d'entreprises (de gestions principalement), que, je pense être majoritaires (en tous les cas plus important en nombre que les développeurs d'appli scientifiques), on s'enfoue un peu que le back end ou le front end soient réécrit ou pas, qu'ils deviennent compatible avec un C++ builder ou autre (je ne connait pas trops de sociétés utilisant les deux outils en parallel pour le meme projet - l'interet majeur était de pouvoir réutiliser la VCL dans C++ builder).
Ce que nous voulons c'est plus d'outils pour maintenir en vie nos appli existantes sans pour autant devoir les réécrire ou porter vers .NET (qui semble être une fatalité). C'est plus de fonctionnalité dans le langague pour faire du remoting, de l'accès sécurisé dans des appli multitiers sans devoir recourir à des usines à gaz développée par des tiers et mal entretenues ou migrées au fils du temps.
Le rajout de l'UNICODE ou des génériques en sont de très beaux exemples. Le maintien d'anciennes (très anciennes) fonctionnalité n'as aucun sens. je pense que pour du très vieux code, s'il est migré vers du 64bit, les parentheses_point ne sont absolument rien devant la gestion de l'unicode, de la taille des pointeurs (64bit oblige - ouilllee les getmem ou dispose ...), les variables integers qui changent de taille, ...
Le rajout de fonctionnalités (au seins du compilo) genre LINQ serait super (filtrer et recherche multicritère sur n'importe quel enumerable).
le rajout de fonctionnalités pour la gestion des champs de bits/byte/word comme dans les langages de l'embarqué serait un plus. Ce que j'entend par là c'est des outils pour accéder et modifier n'importe quelle section de bit d"un entier directement sans devoir recourir à des fonctions externes. Par exemple, pour changer le 6eme bit d'un nombre il serait sympa de pouvoir faire un truc du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
var i : Integer;
    j  : Word;
    k : byte;
begin
  i.Bits(6) := 1;  
  k := j.Bytes(2) //le second byte du word
end

Tout cela sans devoir recourir à des fonctions externes, et sans devoir jongler avec les record (cast vers des types record) et leur champs variants. Ca serait très utile et sympa.

Actuellement je continue à utiliser Delphi pour pas mal de projets, notement pour les appli s'interfaçant avec le matériel (l'électronique), pour les services windows, ... Pour ce genre de développement, je n'aime pas utiliser du code managé, surtout à cause du déploiment (les applis delphi n'utilisant pas de bdd sont un régal en déploiement)
J'espère ne pas avoir à switcher complètement de language (comme je l'ai déjà fais pour les appli de gestions depuis deux ans).

Cordialement.
octal

[philnext]

J'avoue que j'ai rarement vu un article aussi vide de sens.
Annoncer que l'on sort un nouvel IDE en gardant la compatibilité, c'est un peu une évidence.
Par contre quid de nouvelles fonctionnalités ? à part le 64 bits : pas grand' chose !
Bref : décevant !

[VLDG]

ça me rappelle les modules de compilation quand j'étais jeune...

je ne pense pas que c'est avec ça que CodeGear fera vendre plus de Delphi mais sans ça : Delphi n'a pas d'avenir...

On peut donc encore espérer

[Andnotor]

Pour info (et ceci depuis la nuit des temps)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
var
  j :Word;
  k :byte;
begin
  k := j.Bytes(2) //le second byte du word
end

égale

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
var
  j :Word;
  k :byte;
begin
  k := hi(j) //le second byte du word
end

Dés que Delphi sera estampillé x64, les ventes vont grimper d'office même si moi aussi j'aimerais que la programmation embarquée (appareils mobiles) soit plus à l'honneur.

J'ai testé certains de mes soft sur Seven (32) et le Win32 fonctionne parfaitement. On est cool pour les 5 prochaines années, le x64 pourrait attendre dans mon cas