Un IDE entièrement graphique pour Delphi : est-ce réellement utilisable ?
Les pros sont sceptiques

Réseaux sociaux

 Discussion forum

Le 07/02/2013, par SNatoon, Membre du Club
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 ?


 Poster une réponse

Avatar de Paul TOTH Paul TOTH
Expert Confirmé Sénior
le 01/02/2013 6:09
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.
Avatar de Charly910 Charly910
Membre chevronné
le 01/02/2013 8:33
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
Avatar de sevyc64 sevyc64
Modérateur
le 01/02/2013 10:52
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é.
Avatar de GoustiFruit GoustiFruit
Membre éprouvé
le 01/02/2013 11:16
Ç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...
Avatar de ShaiLeTroll ShaiLeTroll
Expert Confirmé Sénior
le 01/02/2013 11:58
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 !
Avatar de SNatoon SNatoon
Membre du Club
le 01/02/2013 12:38
disent-ils, le compilateur sera au programme. pas besoin de savoir pascal
Avatar de Caribensila Caribensila
Membre expérimenté
le 01/02/2013 16:15
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.
Avatar de Ph. B. Ph. B.
Expert Confirmé
le 01/02/2013 16:30

Citation:





Envoyé par SNatoon
Voir le message

Sera-ce un IDE parfait? ou impasse?

ils ont réinventé ModelMaker !

Bon, ils ont encore un peu de travail de finalisation...
Avatar de ShaiLeTroll ShaiLeTroll
Expert Confirmé Sénior
le 01/02/2013 16:58

Citation:





Envoyé par Caribensila
Voir le message

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




Citation:





Envoyé par Caribensila
Voir le message

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 !


Citation:





Envoyé par Caribensila
Voir le message

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 !


Citation:





Envoyé par Caribensila
Voir le message

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 !


Citation:





Envoyé par SNatoon
Voir le message

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 !


Citation:





Envoyé par Ph. B.
Voir le message

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 ?
Avatar de Ph. B. Ph. B.
Expert Confirmé
le 01/02/2013 17:46

Citation:





Envoyé par ShaiLeTroll
Voir le message

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#...
 Poster une réponse  Retrouvez la suite de la discussion

 
 
Developpez.com

Nous contacter

Participez

Informations légales

 
Services

Forum Delphi

Blogs

Hébergement

 
Partenaires

Hébergement Web