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:
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
0 |
0 |
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.
même si moi aussi j'aimerais que la programmation embarquée (appareils mobiles) soit plus à l'honneur.
) et le Win32 fonctionne parfaitement. On est cool pour les 5 prochaines années, le x64 pourrait attendre dans mon cas 
Envoyé par Andnotor
) ? merci pour la leçon.
dur encore quand il s'agit de variables allouées dynamiquement 
