Un IDE entièrement graphique pour Delphi : est-ce réellement utilisable ? [Débat]

[SNatoon]

Un IDE entièrement graphique pour Delphi
Est-ce réellement utilisable ?

Un IDE entièrement graphique, conçu comme un assistant complet de création de classes et de code, est-ce l'IDE parfait ? Ou une impasse ?

Voyez sur cette vidéo : StroyCode Demo

Le site de l'éditeur du freeware en question : http://softconstructors.com/en/applications/stroycode/

Et vous ?
Que pensez-vous de ce genre d'environnement de développement ?

[Paul TOTH]

c'est joli, mais à mon avis loin d'être pratique.

à la rigueur lire un source Pascal pour afficher graphiquement les objets comme ça permettrait peut-être d'en facilité la lecture, de documenter etc...mais pour créer les classes je préfère la complétion de code.

[Charly910]

Bonjour,

Tout cela pour éviter de taper ou de recopier quelques lignes de code. Je préfère l'IDE actuel, qui à mon avis a toujours été le meilleur devant les IDE des autres langages.

Est ce que cela fonctionne dans les 2 sens : si on modifie directement le code ?

A+

Charly

[sevyc64]

Ouais, bof !

Je suis pas expert Delphi, mais ça n'a pas l'air de révolutionner le monde.
Ce n'est rien d'autre qu'un assistant de création de classe (ou équivalent).

Avec un bon plug-in qui va bien, ça doit même pouvoir être greffé à n'importe quel IDE.

Est-il capable de faire l'inverse, à partir d'un .pas, régénérer la version graphique ? Pas sur, il n'a pas l'air d'être directement branché sur le .pas mais de le générer à coté.

[GoustiFruit]

Ça a l'air plutôt sympa. Peut-être que ça n'intéressera pas les hard-coders mais pour les débutants, pour apprendre les concepts, et même pour les programmeurs un peu plus avancés qui veulent avoir un aperçu rapide de leur structure, ça me semble utile et bien pensé.
Et en effet ça serait top si il était possible de reconstruire un graph à partir d'un code existant...

[ShaiLeTroll]

Des outils comme Rational Rose le font déjà pour générer les tables et même du code
Tu as plein d'outil de conception UML qui propose une conversion vers Java ou C#

On peut penser que les outils DB de Embarcadero pourrait amener à ce genre
de chose avec une ré-apparition d'une bibliothèque façon BOLD

La bonne chose c'est que c'est orienté objet mais en tant que pro, je peux témoigner qu'au travers les 6 (petites) sociétés que j'ai traversé, la POO est peu maitrisé, souvent ce n'est que TQuery, TForm, TDataModule ou des compos persos héritant de TCustomEdit\TCustomPanel mais pas une vrai programmation architecturé !
Les Design Patterns c'est encore moins connu, alors que la POO sans Pattern, c'est la foire à l'andouille !

Je n'ai que très peu vu des objets métiers !
En une grosse décénnie :
UML, jamais vu !
Diagramme de Classe (DelphiToDoc les génère à partir du code pourquoi les faire avant )
GANTT, 1 fourni par un client et 1 que j'ai fait !
PERT, Aucun
MOT et Diagramme de Séquence, j'en faisais des tout pourris sous Excel ou Visio quand j'étais apprenti en alternance, j'ai totalement oublié comment on en fait depuis !

[SNatoon]

disent-ils, le compilateur sera au programme. pas besoin de savoir pascal

[Caribensila]

Il semple que cet IDE n'enthousiasme pas beaucoup les professionnels !


Personnellement, je vois pourtant deux bonnes raisons de se réjouir de cette approche :

- D'abord, quitte à utiliser des "objets", autant le faire franco et les manipuler dans l'IDE, plutôt que d'en faire de longues descriptions littéraires à la Balzac. Je suis sûr qu'on y gagnera en clarté et en efficacité car cela synthétisera, rationisera et uniformisera la conception ET l'écriture du code.

- Ensuite, et le plus important à mes yeux, est que cette approche ouvre le chemin à un progrès qui fait encore cruellement défaut à la plupart des IDE actuels, c'est la dimension "temps" dans la structure des applications qui devront être pensées parallèles. Cet aspect ne semble pas abordé dans la présentation, mais on imagine bien, avec cette approche, une interface présentant clairement l'architecture parallèle des applications. C'est du moins plus facile à imaginer avec cette approche et c'est, à mon sens, la seule possible.


En effet, avec l'évolution des machines vers le multicoeur, il faudra bien que très vite les programmeurs se mettent à coder des applications massivement threadées (Intel a annoncé un ordinateur doté de 80 cœurs d'ici cinq ans !).
Et il faut bien reconnaître qu'il est très difficile de "visualiser" le fonctionnement d'une telle application avec l'IDE actuel, lorsqu'il y a de nombreuses parties de code s'exécutant en parallèle.
Je suis d'ailleurs assez étonné qu'on parle si peu de cette évolution sur ce site. Evolution qui sera très vite nécessaire si on veut que l'augmentation des performances de nos programmes tire parti de l'augmentation du nombre de "coeurs" des microprocesseurs. A ma connaissance, je n'ai rencontré qu'une démo de Andnotor traitant de ce sujet. Et encore, ce n'était pas explicite. Toujours est-il que cette démo illustre très bien comment on devra systématiquement tirer parti des architectures multicoeurs dans un avenir très proche.


VOIR: Relever les défis de la programmation multicœur.

[Ph. B.]

Envoyé par SNatoon

Sera-ce un IDE parfait? ou impasse?

ils ont réinventé ModelMaker !

Bon, ils ont encore un peu de travail de finalisation...

[ShaiLeTroll]

Envoyé par Caribensila

quitte à utiliser des "objets", autant le faire franco et les manipuler dans l'IDE, plutôt que d'en faire de longues descriptions littéraires à la Balzac

Faut-il en faire !
C'est juste que la modélisation de classe n'a rien de nouveau !
Cela existe même dans Delphi : Diagrammes UML et Delphi

Synchronisation entre le code source et les modèles UML

UML Visualize With RAD Studio 2010

UML Visualize With RAD Studio 2010

Envoyé par Caribensila

Je suis sûr qu'on y gagnera en clarté et en efficacité car cela synthétisera, rationisera et uniformisera la conception ET l'écriture du code.

Perso, j'ai déjà ma propre couche objet métier persistant, quand tu as créé plus de 200 classes (en 2 ans), c'est vrai, on oubli un peu ce que l'on a fait !
J'ai prévu de faire un Doxygen, j'utilise déjà ce format de notation dans le code par habitude, faudra que je mouline un coup !

Envoyé par Caribensila

c'est la dimension "temps" dans la structure des applications qui devront être pensées parallèles.

C'est pour cela que l'on est censé faire des Diagramme de Séquence, des MOT, MCT... je n'en fais plus, disons que c'est fait au feeling et par habitude de jouer avec TThread, TThreadList, TMREWS, TCS, TEvent, ...
Je fais des applis proche d'un temps réel en intéraction avec notre matériel, il y a toute une partie de programmation basique proche de l'informatique de gestion, là un seul proc suffit pour afficher une pauvre IHM avec des DBEdit ... et des parties serveur bien plus costauds subissant des milliers de notifications à la seconde !

La parallèlisation de traitement inter-dépendant ce n'est pas évident, semble que le programmeur qui je remplace avait de grosse lacune à ce sujet ainsi un gros manque d'abstraction aussi !

Envoyé par Caribensila

Et encore, ce n'était pas explicite. Toujours est-il que cette démo illustre très bien comment on devra systématiquement tirer parti des architectures multicoeurs dans un avenir très proche.

Oui le but étant plutôt de contourner les limites de bande passante pour un téléchargement.
La sollicitation processeur est minime pour ce cas !

Envoyé par SNatoon

disent-ils, le compilateur sera au programme. pas besoin de savoir pascal

Le compilateur ???
Si leur programme génère du code, il suffit d'avoir celui d'Embarcadero ou même celui de Lazarus !
tu pourrais citer tes sources, je n'ai pas vu cela sur leur site

Si l'outil est en plus destiné à des "non programmeurs" qui ne connaissent pas le Pascal\Delphi, cela signifie que l'ensemble des traitements seront décrit par des graphiques, c'est utile dans un processus de développement très normé, je pense en SSII\Outsourcing avec un fort turn-over et donc facilite la reprise du code grace à la modélisation

Je trouve que Delphi est déjà trop utilisé comme un Clicodrome !
Combien ont des difficultés à faire un Create ou affecter un gestionnaire d'évènement par code parce que l'IDE les a aliénés !

Envoyé par Ph. B.

ils ont réinventé ModelMaker !

C'est vrai, je l'avais regardé, il y a un paquet d'année
Je crois qu'il ne fourni pas le support pour C++Builder ! si ?

[Ph. B.]

Envoyé par ShaiLeTroll

C'est vrai, je l'avais regardé, il y a un paquet d'année
Je crois qu'il ne fourni pas le support pour C++Builder ! si ?

Eh non, juste Delphi et C#...

[SNatoon]

non, non, non! Aucune UML! vidéo ne reflète pas l'essence! Vous ne pouvez utiliser le clavier sans souris. C'est tout le texte.
vous devriez certainement essayer le StroyCode programme, à comprendre. Je suis maintenant une fan de ce programme.

[Paul TOTH]

Envoyé par ShaiLeTroll

..
Perso, j'ai déjà ma propre couche objet métier persistant, quand tu as créé plus de 200 classes (en 2 ans), c'est vrai, on oubli un peu ce que l'on a fait !
J'ai prévu de faire un Doxygen, j'utilise déjà ce format de notation dans le code par habitude, faudra que je mouline un coup !
...

j'aimerai voir la tête de cet IDE avec 200 classes

[ShaiLeTroll]

Envoyé par Paul TOTH

j'aimerai voir la tête de cet IDE avec 200 classes

J'ai tenté de voir le support intégré du RAD, mon BCB monte à plus de 650Mo de RAM, sachant que je n'ai que 1Go, j'attends d'avoir mon PC neuf pour voir vraiment ce que cela donne !

Pour cet IDE StroyCode, je pense qu'il souffrira des mêmes problème de charge et d'un fouilli sans nom avec des fleches partout avec des classes comme celle qui suit qui fait appel a plus de 10 classes et 20 interfaces (aux implémentations multiples)

Code c++ :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
//---------------------------------------------------------------------------
//                            TShaïCameraCustom                            -
//---------------------------------------------------------------------------
class /*abstract*/ TShaïCameraCustom : public TShaïHardwareProviderAbstractPersistentObject
{
  typedef TShaïHardwareProviderAbstractPersistentObject inherited;
  friend /*method*/ void __fastcall TShaïCameraCustomManager::EventHandlerPurposeEntityChangeStateEvent(TShaïHardwareProviderManager * Sender, IShaïHardwareEntity* AEntity, int AState, void *Data);
  friend /*method*/ void __fastcall TShaïCameraCustomManager::EventHandlerPurposeEntityErrorEvent(TShaïHardwareProviderManager * Sender, IShaïHardwareEntity* AEntity, int AError, void *Data);
 
private:
  // Membres Privés
  TShaïCameraStates FCameraStates;
  TMultiReadExclusiveWriteSynchronizer *FCameraStatesThreadLock;
  TShaïCameraTestConnectionState FTestConnectionState;
 
  TShaïCameraDirectView* FDirectView;
  TShaïCameraRecording *FRecording;
  bool FForbiddenReload; // Pour éviter que l'on puisse changer de Provider alors des Interfaces se baladent dans la nature
 
  enum TDownloadDirectoryState {ddsNone, ddsSet, ddsNotSupported};
  TDownloadDirectoryState FDownloadDirectoryState;
 
  // Méthodes Privées
  void InternalCreate(); // all constructors must call InternalCreate
  void InternalDestroy(); // all destructors must call InternalDestroy
  void InternalCleanPurposeInterfaces();
 
  TShaïCameraTestConnectionState SetTestConnectionStateFromHardwareCameraState(TShaïHardwareCameraState AState, bool AsyncMode);
 
  // Méthodes Privées (Signalement d'Evènement)
  void NotifyChangeState(TShaïCameraCustomManager * Sender, TShaïHardwareCameraState AState, void *Data);
  void NotifyError(TShaïCameraCustomManager * Sender, TShaïHardwareCameraError AError, void *Data);
 
protected:
  // Méthodes Redéfinies
  /*override*/virtual TShaïHardwareProviderManager* __fastcall GetProviderManagerInstance();
  /*override*/virtual void CleanPurposeInterfaces();
  /*override*/virtual bool AllowLoad();
 
  // Accesseurs (Divers)
  TShaïCameraStates __fastcall GetCameraStates();
  TShaïCameraDirectView* __fastcall GetDirectView();
  TShaïCameraRecording* __fastcall GetRecording();
  TFileName __fastcall GetCameraVideoDirectory();
 
  // Accesseurs (Sensor)
  bool __fastcall GetSensorAvailable() {/* TODO CAM*/};
 
  // Accesseurs (Propriétés Publiques)
  IShaïCameraEntityPurposeDelphiInterface __fastcall GetCameraPurposeInterface();
 
public:
  // Constructeurs Publiques
  /*constructor*/__fastcall TShaïCameraCustom();
  /*constructor*/__fastcall TShaïCameraCustom(TDataSet* ADataSet);
  /*destructor*/__fastcall virtual ~TShaïCameraCustom();
 
  // Méthodes Publiques (Vues)
  TShaïCameraDirectView* CreateDirectView(); // Crée un nouvel objet Vue, l'appelant est responsable de la libération, augmente le compteur de référence sur la Camera
  bool HasDirectView();
 
  // Méthodes Publiques (Enregistrements)
  TShaïCameraRecording* CreateRecording(); // Crée un nouvel objet Enregistrement, l'appelant est responsable de la libération, augmente le compteur de référence sur la Camera
  TShaïCameraRecording* CreateRecordingWithContext(TShaïCameraActionRecordingContext *AActionContext);
  bool HasRecording();
 
  // Méthodes Publiques (Relecture d'Archive)
  TShaïCameraPlaybackView* CreatePlaybackView(); // Crée un nouvel objet Redifusion, l'appelant est responsable de la libération, augmente le compteur de référence sur la Camera
 
  // Méthodes Publiques (Connection)
  TShaïCameraTestConnectionState TestConnection();
  void TestConnectionTimedOut();
 
  // Méthodes Publiques (Sensor)
  bool ActiveSensor(bool Active, bool AsynchronousMode = true)
    {/* TODO CAM - AXIS, devra être async avec vérification par Socket avant de tenter un HTTP, ne pas cumuler les demandes via scsSensorActivating, scsSensorDesactivating, scsSensorActive */
     /* TODO CAM - Dahua, nécessite une connexion permanente pour l'abonnement au système de message de la motion*/
     /* TODO CAM - CamTrace, nécessite une connexion permanente sur le socket de notification*/};
 
  // Propriétés Publiques
  __property Provider; // Augmentation de Visibilité
  __property Model; // Augmentation de Visibilité
  __property Entity; // Augmentation de Visibilité
  __property IShaïCameraEntityPurposeDelphiInterface CameraPurposeInterface = {read=GetCameraPurposeInterface};
 
  // Propriétés Publiques
  __property TShaïCameraStates CameraStates = {read=GetCameraStates};
  __property TFileName CameraVideoDirectory = {read=GetCameraVideoDirectory};
 
  // Propriétés Publiques (Vues)
  __property TShaïCameraDirectView* DirectView = {read=GetDirectView}; // Cherche la vue existante, création si nécessaire !
 
  // Propriétés Publiques (Enregistrements)
  __property TShaïCameraRecording* Recording = {read=GetRecording}; // Cherche l'enregistreur existant, création si nécessaire !
 
  // Méthodes Publiques (Connection)
  __property TShaïCameraTestConnectionState TestConnectionState = {read=FTestConnectionState};
 
  // Propriétés Publiques (Sensor)
  __property bool SensorAvailable = {read=GetSensorAvailable};
};

[SNatoon]

>> j'aimerai voir la tête de cet IDE avec 200 classes

[Paul TOTH]

Envoyé par SNatoon

>> j'aimerai voir la tête de cet IDE avec 200
classes

(photo de 15 classes)

encore 185 et le compte y sera

un truc comme le poster des premiers Delphi (ceux qui étaient vendus en carton)

ou comme QT

[arkhamon]

Bonjour à tous,

grosso modo, et si j'ai bien compris, on est en train de parler d'un générateur de code.
Ce qui veut dire :

• je règle mes fenêtres
• je structure mes données
• je gère "l'intelligence" des fenêtres
• je décris peu ou prou ce qui se passe en cas d'évènement
• le machin me génère du code...

Tout ceci très simplifié bien sur...
Bon, ben c'est pas ce que fait Delphi XE ?

J'ai développe un truc comme ça à l'époque de Tubo Pascal 6.
Je faisais le design des fenêtres à la souris, je créais l’arborescence des menus, je donnais la structure des records, je donnais la liaison entre option de menu/écran, et après ça pondait du code Pascal tout bête. L'avantage : ben à l'époque, y avait pas de concepteurs de fenêtres et de menus. On y gagnait du temps, car en plus les modules de lecture des fichiers étaient pré-codés (grâce à cette fabuleuse directive "Absolute" collée après une définition de variable...).

Mais maintenant que l'EDI est assez puissant, cette couche supplémentaire ne me semble pas super utile, et tendrait plutôt à compliquer les choses. D'autant qu'il restera quand même une partie de code dont on ne pourra pas (encore) s'affranchir : le cœur du programme.

Bon en même temps, à l'époque quand j'ai proposé mon générateur d'applis à mes collègues développeurs, il m'ont ri à la tronche... avant de l'utiliser quelques mois plus tard quand ils ont vu qu'en 2 jours j'avais développé un truc qu'ils avaient mis 2 mois à faire...

[SNatoon]

StroyCode:

nouvelle vidéo

nouvelle vidéo

[Paul TOTH]

SNatoon, quelle est ta relation avec ce produit ? tu en fais manifestement la publicité, as-tu un intérêt personnel pour le faire ? en es-tu l'auteur ?

[SNatoon]

Envoyé par Paul TOTH

SNatoon, quelle est ta relation avec ce produit ? tu en fais manifestement la publicité, as-tu un intérêt personnel pour le faire ? en es-tu l'auteur ?

Je ne suis pas un développeur, je suis juste un fan.
Embarcadero devrait saisir cette idée!