CGI & co, si c'est possib' !
Bonjour selzig,
Je reviens juste sur les CGI/FastCGI &co. Et je dirai : si c'est possible. Et supportable tant que tu n'as pas 200 appels simultanés dans la seconde.
J'ai vu chez un hébergeur un qui comptait faire du Haskell via CGI pour tâter de manière motivante la chose. J'ai aussi lu des témoignages avec du ADA derrière ce CGI. J'ai aussi lu... d'autres langages de programmation, derrière le CGI (Lisp & co, C, Basic, Erlang…).
Maintenant, c'est vrai qu'il faut considérer une triangulaire : les données et leur structuration (et même stockage), le langage et l'environnement, et l'interface. Côté langage et environnement, c'est le choix que tu veux, et tu produis une lib ou un exe.
Côté interface, si c'est du web, il y a une forte probabilité de devoir connaître et fournir du html/css/js, quel que soit ton choix de langage de développement pour le côté métier. Mais là, le problème, c'est surtout que tu dois, selon le langage, "réinventer" le framework web minimal. Et dans les langages considérés comme exotiques que j'ai pu mentionner (et du point de vue web, le Pascal en fait partie), c'est bien là le principal problème. À toi de voir si tu peux n'en programmer que le strict nécessaire pour ton besoin.
Je n'oublie pas les autres arguments cités, mais pour les CGI, jusqu'à une certaine échelle, c'est tout à fait jouable.
Bonne continuation, et tiens nous au courant dans quelques mois !
Est-ce la bonne question ?
Bonjour à tous,
je suis aussi un inconditionnel du Pascal, c'est un langage très facile à relire et qui par conséquent ne nécessite pas (ou peu) de commentaires dans le code. C'est un atout de productivité non négligeable.
J'ai aussi commnecé il y a très longtemps sur un VAX/VMS, puis continué avec TurboPascal (chouette, il y avait un debugger !), puis découvert Delphi avec son concept RAD (génial !) et premier palier important pour un développeur, j'ai du me mettre à la POO. C'était l'époque ou le terme PC avait encore un sens : 1 développeur pouvait crée une application qui tournait sur 1 ordinateur, avec 1 language.
Maintenant cette époque est révolue, on est dans un monde connecté où la moindre application se doit d'être Client/Serveur. Donc un écrit plus 1 application, mais 2, 1 côté Client, 1 côté Serveur.
La question est donc : peut-on écrire une application, côté Client ET côté Serveur avec le même language, en particulier le Pascal.
Côté Serveur c'est Microsoft (donc OUI avec Delphi) ou Linux (donc apparament OUI avec Lazarus, que je ne connais pas). Côté Client, que se soit des PC, des Tablettes, des SmartPhones, des TV, etc., il y a plétore d'OS différents, bien plus que de bons compilateurs Pascal... je dirais Non !
Une dernière chose concernant les sociétés commerciales, que ce soit Embarcadero ou Sun (ou autre). Lorqu'on choisis d'utiliser un de leur produit pour créer une application on est TOTALEMENT tributaire de leur choix et de leur éventuelle faillite (ou moins grave leur mise à l'écart). En effet il faut se rappeler que Apple a voulu bouder Java, puis s'est rétracté...
En conclusion, pour ma part, comme j'aimerais aussi travailler avec un seul language, je devrai abandonner le Pascal et me mettre au C++, avec regrèts.
rester objectifs et ne pas chercher de fausses raisons
bonjour,
Les retards d'Embarcadero sont en effet regrettables MAIS.
1) il est cohérent de privilégier les plateformes serveurs et clients tels que Windows et MAC OSX.
Pour Linux, Embarcadero pourrait maintenir une solution minimale : en attendant, elle existe sous la forme Lazarus / FreePascal ou encore en C (présent dans RAD STUDIO). Et puis, pour Linux, quel est le marché ?
2) pour les plateformes mobiles, ios comme android gagnent à être servi par la même plateforme avec un IDE le plus proche possible de DELPHI XE (N).
La précédente solution pour ios, trop différente de mac osx, trop difficile ou délicate et n'intégrant aucune solution ANDROID n'était pas viable.
Le développement serveur avec Data Snap et autres techno serveurs et les solutions HTML5 Builder (dont PHP serveur et HTML/javascript client) et la future plateforme mobile studio sont elles de bonnes solutions (en perspective pour la solution mobile...).
Les avancées de la nouvelle platforme sont :
- performances pour FIREMONKEY - FMX ainsi qu'extensions vers WIN 8
- consolidation pour Livebinding
- HTML5 (ex-RAD PHP)
- mobile studio : à condition de tenir la date de début 2013... car sinon ce sera un coche de plus de raté...
pour DELPHI et C++, il n'y a pas d'avancées fondamentales (hormis via FMX et LiveB.) comme c'est normal pour toutes les solutions mures (les bases de données ne changent pas grand chose au support SQL par exemple).
3) pour répondre sur le multiplateforme : il ne faut pas une solution "faute de mieux" qui soit beaucoup moins performante et pratique que la solution native. Il est clair que pour une appli ANDROID classique (sans composant spécifique), il faut faciliter le développement HTML5/JS/JAVA plutôt que s'évertuer à faire du Pascal 100%.
4) pour l'aide en ligne, je ne comprends pas en quoi Eclipse est bon. Si la solution DELPHI XE3 est contestable, au moins donne t elle un accès très complet non seulement à l'aide mais à des exemples de codes y compris sous internet (Embarcadero et autres sites)... donc je vote pour, tout en reconnaissant que dans DELPHI 7 avec WINHLP s'était un peu plus pratique pour l'aide intégrée immédiate (mais pas pour chercher des solutions).
Cordialement
François