Discussion :

[andreditdd]

Skip à dit:

Pouvoir compter sur une puissante communauté, plein d'exemples, de ressources, de composants payants sur le net est une bonne chose à mon sens qui peut éviter de se retrouver assis seul face à un problème.

Ben, à ce propos je dois dire que la communauté ici présente est très réactive et m'a jusqu'a présent sorti de toute les difficultées que j'ai rencontré.

Je tiens ici à tous vous remercier

André

[octal]

Au sujet des dinosaures, oui je confirme.
Combien de réponses as tu eu a ta question sur les ORM qui a motivé ton post ?
Je reconnais que j'aurais pu éviter ma seconde intervention et garder ça pour moi. Modérer c'est aussi une prise de risque, j'assume.

Franchement, pour faire de l'ORM et cibler les SGBD, rien ne vaut plus .NET ou Java.
Delphi est toujours en vie, continue d'évoluer, c'est un excellent langage, héritant d'un pascal plutôt clean .... blablablalaaa ...

On trouvera toujours des éditeurs qui continueront à essayer de continuer à grappiller des parts de marché en vendant des outils (y compris ORM), extension et composants pour Delphi, comme c'est le cas pour Clipper et/ou DBASE, FoxPro ... tant qu'il y a des demandeurs qui n'ont aucun intérêt économique à migrer leur solution, il y aura de la prestation autour (mais à quel prix ).
Pour une nouvelle solution SGBD qui sera amenée à être vendue, utilisée en masse en réseau, je pense que l'idéal est de démarrer sur une solution .NET ou Java. Là où vous trouverez (et vous en trouverez toujours) 3 ou 4 boites qui offriront telle ou telle solutions/prestation/outil pour le support de Dephi, vous trouverez 400 offrant les mêmes prestations pour .NET/JAVA.

C'est la loi du marché, et être FAN de Delphi ne changera pas cela.

[_skip]

Wow, la résurrection de mon vieux post...

Au final j'avais choisi .Net car j'avoue avoir eu peur pour l'avenir de delphi. J'aurai peut être pas du vu qu'il est toujours là. Il n'empêche que je l'ai même reconsidéré récemment pour un nouveau développement qui se fera au final en java avec SWT.

Si delphi avait été disponible pour linux, il aurait été un concurrent de choix car ses performances sont intéressantes, spécialement quand on vise des vieilles brouettes low-cost comme hardware. Malheureusement je pouvais pas attendre.

Pas envie de faire du C++, trop de soucis de productivité, mono est trop lent et trop pauvre en composant, restait plus tant que java.

[Gilbert Geyer]

Bonjour,

Octal : Là où vous trouverez (et vous en trouverez toujours) 3 ou 4 boites qui offriront telle ou telle solutions/prestation/outil pour le support de Dephi, vous trouverez 400 offrant les mêmes prestations pour .NET/JAVA.

... une bonne solution même unique si elle est bonne c'est quelle est meilleure que les 400 autres puisqu'elle bonne (lol).

Occam (XIVe siècle), disait :

« Les multiples ne doivent pas être utilisés sans nécessité » (pluralitas non est ponenda sine necessitate) ... aussi connu sous la variante « Entia non sunt multiplicanda praeter necessitatem », littéralement : « Les entités ne doivent pas être multipliées par delà ce qui est nécessaire »

Vive Delphi.

A+.

[octal]

@Gilbert
Je ne parle pas de la qualité des développement, parce que à ce niveau là, il y a aussi plein de librairies et de composants tout crad pour Delphi aussi.

Cela se voit que vous n'avez jamais eu à gérer une boite de développement. Quand on utilise un outil, on prend toujours l'outil qui a le plus de support sur me marché, et c'est généralement l'outil qui a le plus de succès: vous y trouverez plus de prestataires, plus d'experts, plus d'assistance, plus de librairies et de bibliothèques, ...
Un gestionnaire fait toujours attention à la pérennité de l'outil dans lequel il investi, et actuellement .NET/JAVA font mieux que Delphi à ce niveau là.

Allez demandé aux chef de projets/gestionnaires qui ont misé sur la pérennité et la robustesse de COBOL+AS400 et vous comprendrez !!!

[Gilbert Geyer]

Re-bonjour,

Octal : Cela se voit que vous n'avez jamais eu à gérer une boite de développement.

... mieux encore : j'ai surtout évité de prendre une profession de développeur bien que j'aie pris le virus de la programmation en 1967 (Fortran)
mais quand la micro-informatique a pointé son nez il y a eu la valse du Pascal, Turbo-Pascal, Turbo-Pascal-pour-Windows, Delphi-1, Delphi-2, Delphi-3 et ainsi de suite : un Binz style casse-tête chinois de mises à jour et de formations de re-mise à niveau et de recommencement de codes devenus totalement ou partiellement obsolètes.

Par contre j'admire les types qui font cela comme boulot : Développement le jour et formation la nuit pour rester au top : un métier quasi-infernal.

Je comprends fort bien les types qui continuent à utiliser le cobol et comme il s'agit généralement de types qui bossent dans de grosses administrations, lorsqu'ils partent à la retraite on les remplace par d'autres ... mais l'administration conserve son Cobol dans les applis lourdes.

A+.

[chaplin]

Allez demandé aux chef de projets/gestionnaires qui ont misé sur la pérennité et la robustesse de COBOL+AS400 et vous comprendrez !!!

Il faut dire Amen, se mettre à genoux ? Qui prend les décisions stratégiques de l'entreprise, le client ou le fournisseur ?

[andreditdd]

@octal
Développes tu avec Delphi ?
Si oui, quelle version utilises tu ?

Ne vois rien de désagréable à mes questions.

André

[octal]

@andreditdd
Professionnellement je ne développe plus avec dephi depuis plus de 3 ans!
j'ai travaillé avec delphi depuis la V1 (pour l'historique j'ai connu borland depuis qu'ils avaient sorti Turbo Pascal 3 ). La dernière version que j'ai utilisé profesionnelement est la 2007.
Là je développe principalement en PHP (changement de poste).
J'utilise encore Delphi pour faire mes propres applications (surtout pour le contrôle industriel et pour piloter mes cartes à microcontrolleurs).
J'ai commencé à délaisser Delphi sérieusement au profit de C++ depuis que Nokia a mis QT en LGPL. Rien ne vaut C++/QT surtout pour le contrôle industriel.

Pour les applications de gestion sous windows, je préfère utiliser maintenant C#/.NET.

Voilà

PS. GLCD Font Creator sur http://www.pocketmt.com est 100% fait en Delphi

[_skip]

Rien ne vaut C++/QT surtout pour le contrôle industriel.

Dans ce cas tu dois regretter les temps de compilation de delphi si t'as une grosse base de code. Perso c'était un argument en sa faveur lorsque je l'ai évalué.

[octal]

Dans ce cas tu dois regretter les temps de compilation de delphi si t'as une grosse base de code. Perso c'était un argument en sa faveur lorsque je l'ai évalué.

Oui effectivement Delphi rebuild l'intégralité d'un projet rapidement, mais avec un bon gestionnaire de make c'est pas la mort en C++ non plus. Il suffit d'avoir les bonnes pratiques:
-ne pas inclure bêtement n'importe quel fichier header,
- éviter l'inclusion bourinnes de fichiers globaux et utiliser uniquement les fichiers contenant les classes nécessaires au module courant
- Apprendre à utiliser la déclaration précoce (ou en forward si vous voulez)
...
Tous cela évite des temps de compilations fous, et surtout si vous faite de la compilation C++ en professionnel je ne saurais vous conseiller 2 choses qui changeront votre vie:
1- Si vous utilisez VisualC++ activez la compilation parallèle dispo sur les processeurs dual core
2- SUPER SUPER IMPORTANT: Donnez vous les moyens d'avoir un serveur d'intégration (de compilation).

Tous cela associé à une bonne dose de Test-Units vous permettra de gagner des jours de compilation.

Ce qui m'a fait délaisser Delphi au profit de C++/QT (en dehors de la portabilité) est aussi le fait que la plus part des algorithmes et librairies (en source code) que l'on trouve pour le domaine industriel sont tout le temps en langage "C". Devoir réécrire (et tester) des centaines de lignes de code en Delphi est fatiguant à la longue.
De plus, le fait d'avoir certains code en "C" permet de réutiliser le même code sur les microcontroleur eux même (genre calcul de CRC, cryptage AES, ...).

Voilà