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

[philnext]

Je voulais rajouter : bravo pour la traduction !
Même si j'ai trouvé l'article un peu 'frustrant' je suis content de l'avoir eu à disposition !

[octal]

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

le commentaire est erroné, le .bytes(2) retourne le 3eme byte !

super cool. depuis la nuit des temps (je pensais que c'était depuis que l'on écrivait les parentheses_point pour les arrays : ) ? merci pour la leçon.

Tu fait comment pour modifier le 3eme octet d'un quad sans recourir aux mask et rotations? (je sais que le compilo le fait de cette manière là "sur certains processeurs", mais j'aurais aimé avoir de telles fonctionnalités en natif pour plus de confort).


cordialement
octal

[Andnotor]

Code :

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

le commentaire est erroné, le .bytes(2) retourne le 3eme byte !

3ème byte d'un word, difficile.

Dans le cas d'un dword, tu peux faire ceci:

Code :

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

1
2
3
4
5
6
var
  dw :dword;
  b :array[0..3] of byte absolute dw;
begin
  b[2] := $FF;
end;

[octal]

Dans le cas d'un dword, tu peux faire ceci:

Code :

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

1
2
3
4
5
6
var
  dw :dword;
  b :array[0..3] of byte absolute dw;
begin
  b[2] := $FF;
end;

Super !
on fait comment alors quand on a plusieurs tableaux de variable structurées parmis lesquel on voudrais récupérer ou modifier certain bit? le "mappage" d'addresse n'est pas trop évident, à moins de se taper un calcul d'adresse par rapport à l'origine de la première variable dur encore quand il s'agit de variables allouées dynamiquement

Bref !

Je le redis ! le commentaire est eronné! l'écriture Bytes(2) retourne le 3eme byte. je n'ai pas dis que l'exemple fonctionnait ou que l'on pouvait avoir le troisieme byte d'un word! Si tu veux change l'exemple en Bytes(1) et qu'on en parle plus.
Ce n'etaient que des exemple rapidement ecrit pour fixer les idées sur ce que l'on voudrait avoir dans un futur Delphi.

Relis mon premier post!
Encore une fois le but c'est d'avoir de tel outils intégrés dans le compilo, et non de le faire via du cast ou "mem map" !
J'utilise un tas de routines que j'ai développé il y a un certain temps pour faire du mask-age, faire de l'arithmetique binaire et toutes les transformations binaires possibles. Cela n'est pas le pb. L'interret c'est d'avoir un niveau de confort plus élevé et surtout un range checking et un controle de types evolué en utilisant les fonctionnalités native du langage.

PS. Je trouve que l'on a trops pollué ce post (comme d'hab). Je ne voudrais que ce post se transforme en commentaires/débats stérile et inutiles autour d'éléments syntaxiques. On peut tout faire avec delphi est c'est tant mieux. on n'a plus besoin que du 64 bit.

Cordialement
octal

[Paul TOTH]

allez, j'ajouterais que j.Bytes() n'existe pas sur les Delphi que j'utilise

[octal]

@Paul TOTH

[octal]

Parmi les nouvelles fonctionnalités que je voudrai aussi voir dans Delphi, et à laquelle Borland ne semble jamais donner d''importance/chance, c'est la possibilité de faire de la programmation paralelle. La vectorisation automatique du code et sa distribution quand on est sur des machines massivement paralelles (un peux comme c'est fait dans le nouveau compilateur C++ d'INTEL).

Le parallelisme jumelé au 64bit et au milticoeurs (ou/et au multiprocesseurs) ouvrira plein de porte à Delphi dans le domaine scientifique et technique.


Cordialement

[Aos]

Hello,

Vous êtes certains que l'article n'est pas un fake ?
J'ai jamais lu quelque chose de si peu instructif.

Bref...
Parler de (*...*) ou des array ect... J'ai trouvé ça un peu ringard.
De plus, il serait assez aisé de faire un refactoring directe pour ce genre
de code des l'ouverture de celui ci.
Transformer le "vieux" code en "nouveau" code.

Vraiment, je ne comprend pas trop l'utilité d'une déclaration à la limite de la plaisanterie : "On avance pas beaucoup dans Delphi parce qu'on se préoccupe de la compatiblité ascendante...". (Meme si ce ne sont pas les mots utilisés, c'est le message que j'en ai compris).


"Delphi c'est super ! y'a les génériques" (arrivé sur la version 2009... Moi qui venait d'acheter la version 2007, je n'allais pas rajouter je ne sais combien de centaine d'euro pour avoir uniquement cette fonctionnalité supplémentaire, il est clair que les générique sont arrivé TRÈS (voire trop) tardivement).

Je dois réécrire une application vieille de 8 ans pour des raisons disons "technique", c'est dommage de toujours se poser la question : Est-ce vraiment raisonnable, à long terme, de l'écrire sous delphi... ?

[octal]

Hello,
...
"Delphi c'est super ! y'a les génériques" (arrivé sur la version 2009... Moi qui venait d'acheter la version 2007, je n'allais pas rajouter je ne sais combien de centaine d'euro pour avoir uniquement cette fonctionnalité supplémentaire, il est clair que les générique sont arrivé TRÈS (voire trop) tardivement).
...

Les centaines d'euros de plus à cause des génériques, je vous assure que ça les vaut (encore faudra t-il avoir une bonne expérience avec les génériques et les design patterns). Le problème c'est que les génériques ont été introduit avec la 2009 qui a en même temps introduit l'UNICODE, donc une difficulté supplémentaire pour la migration

...
Je dois réécrire une application vieille de 8 ans pour des raisons disons "technique", c'est dommage de toujours se poser la question : Est-ce vraiment raisonnable, à long terme, de l'écrire sous delphi... ?

100% d'accord avec cela. D'ailleur, pour certaines appli (métier), je ne me pose même plus la question

cordialement
octal

[SpiceGuid]

Je suis d'accord avec les précédents intervenants.
Il n'est pas bon de sous-entendre qu'on va annoncer des décisions si au final on ne dit pas lesquelles, c'est la pire des communications possibles.

Ou bien on dit "on a commencé le dev mais on ne vous dira rien avant le moment opportun".
Ou bien on dit "on a décidé de certains changements et on vous explique lesquels".

Là on en est réduits à spéculer sur le contenu d'une soit-disant annonce.
Dans le meilleur des cas on aura le meilleur de Delphi32 avec le support du 64bits, la compatibilité avec dotnet et mono, ainsi qu'une version native pour Linux.
Dans le pire des cas on nous colle un front-end Delphi.net à un back-end C++Builder pour ne pas avouer que Delphi32 a disparu.
Comme la vérité est sans doute quelque part entre les deux on ferait mieux de nous la révéler tout de suite, dans le cas contraire on ne fait qu'alarmer les plus pessimistes tout en trahissant les attentes des plus optimistes.

Maintenant voici mon interprétation personnelle, ou ce que j'ai cru devoir être censé comprendre :

• la version D2010 est une version de transition dont le principal intérêt est le passage au 64bits, sans ajouts de fonctionnalités au langage
• à partir de la D2010 il y aurait deux syntaxes Delphi, l'une pour la compatibilité et qui permet toutes les manipulations de bas niveau, et une autre "épurée" qui ressemblerait plus à un langage managé auquel les versions ultérieures pourraient ajouter des services de "haut niveau" tels que le GC ou la sérialisation ou le chargement dynamique de modules de façon sécurisée, en gros le genre de services qui reposent sur un typage fort (et en particulier la certitude qu'un pointeur désigne toujours un objet), ce qui n'est pas forcément vrai en Delphi32 mais qui peut le devenir si on l'émascule violemment, par exemple à la façon component pascal

J'ai bon selon vous, ou pas ?

[chaplin]

Avec les outils Embarcadero, je pense que la partie base de données va avoir droit à pas mal d'outils interessant qui s'interfaceront avec delphi. Il y avait le MDA avec Borland, pourquoi pas une approche semblable avec Embarcadero.
Je verrais bien un garbage collector avec Delphi, c'est peut être mal vu par certain mais ça enlève pas mal d'épines dans certains cas.

[rt15]

Je te plussois SpiceGuid :

What if we created a new compiler front end that gives you the choice between a new, non-legacy syntax and the older way of coding?
...
new code in new modules

C'est écrit là en fait. Je t'avoue que je l'avais pas compris avant d'avoir lu ton post. On ne lit que ce qu'on veut bien finalement.

Deux modes de compilation donc. Ce n'est pas sans rappeler le côté "safe" introduit dans le C++ (Une dotneterie. Sans intérêt.).

Un mode bridé permettant au compilo de mieux comprendre ce que l'on fait, pour permettre de nouvelles fonctionnalités, tant sur le plan de la compilation que de l'IDE (Débogage...)
Un mode compatibilité ascendante.

Avec bien sûr comme ça se produit dans ces cas là, une "légère" incitation pour les développeur de ne plus faire du unsafe, et de passer au safe. Parce que le unsafe n'évoluera plus ou presque (Comme en M$ C++). Parce que le unsafe c'est "dangereux".

Ca va finir en Java/C# qui compile en natif en somme. Plus d'abstraction, langage de plus haut niveau, plus "sécurisé".

Ca sera peut être pas mal.
Mais heureusement que les vieux débris réfractaires dans mon genre pourront encore utiliser une Delphi 6 ou 7 et presser ctrl + alt + c pour se dire qu'on aurait fait pareil si on avait codé en assembleur.