Je vois qu'il y a des exemples pour me contredire (cf. commentaires plus haut), mais quelle est la nature de ces projets ? Pourquoi est-ce qu'un outil comme Gambas a été retenu plutôt qu'une application RoR / PHP / JavaEE / GWT / etc... ?
Je vais parler de ce qui me concerne : RoR, je connais très mal; JavaEE, je connais mal; GWT, je ne connais pas du tout. PHP, par contre, je connais : berk. Pour moi c'est une horreur cosmique, comme l'ASP. Je ne supporte pas de mélanger le HTML et le code. Qui a dit "javascript" ?!
L'avantage de développer mon application Web sous Gambas, c'est :
Chaque serveur est virtualisé, donc un Linux en mode texte avec 512 Mo de RAM, ça le fait. 512 Mo qui sert surtout de cache disque, les accès disques étant ce qui ralentit le plus. J'admets que cet argument est valable quel que soit le langage.
La table de hachage et le traitement de chaînes de caractères (miam les conversions de casse en UTF-8) est ce qui consomme le plus de temps CPU (merci valgrind). Gambas a l'air assez doué là-dessus.
Nous sommes une petite boite, je suis quasiment le seul à développer et maintenir cette application. Gambas possède un IDE complet, il est interprété, il compile très rapidement, et l'application Web est compilée en un seul fichier. Le temps de développement, de maintenance et de déploiement (une copie de fichier en SFTP) sont réduits d'autant.
Lorsqu'il y a un bug dans Gambas qui impacte le projet, il est fatalement corrigé assez vite. J'ai utilisé dans le passé suffisamment d'outils de Microsoft archi buggés (Visual Basic m'entends-tu ?) pour apprécier de contrôler la chaîne de développement de A à Z. Regardez le bug sur les tables de hachage non "randomisées" : j'ai pu le corriger en 15 minutes (ça a pris un peu de temps car l'article sur linuxfr explique bien le problème, mais moins bien la solution). Pour les applications basées sur un langage où ce bug n'est pas corrigé, elles peuvent trembler...
Le démarrage de l'interpréteur est rapide (disons que pour l'instant je ne sais pas faire mieux). Sachant que mon application Web est un script CGI, c'est important ! Et, en dépit du fait que c'est un script CGI, les temps de réponses sont largement satisfaisants. Si j'ai le temps, je mettrais le serveur HTTP dans l'interpréteur (ou le contraire), pour gagner du temps au linkage dynamique. Là ça devrait dépoter...
J'invite d'ailleurs tous les développeurs qui gèrent un projet et qui ont une petite douzaine d'années devant eux à créer leur propre langage pour leur propre besoin. :-)
[^] # Re: Positionnement de Gambas
Posté par Benoît Minisini . En réponse à la dépêche Gambas 3 est sorti le 31 décembre 2011. Évalué à 2.
Je vais parler de ce qui me concerne : RoR, je connais très mal; JavaEE, je connais mal; GWT, je ne connais pas du tout. PHP, par contre, je connais : berk. Pour moi c'est une horreur cosmique, comme l'ASP. Je ne supporte pas de mélanger le HTML et le code. Qui a dit "javascript" ?!
L'avantage de développer mon application Web sous Gambas, c'est :
Chaque serveur est virtualisé, donc un Linux en mode texte avec 512 Mo de RAM, ça le fait. 512 Mo qui sert surtout de cache disque, les accès disques étant ce qui ralentit le plus. J'admets que cet argument est valable quel que soit le langage.
La table de hachage et le traitement de chaînes de caractères (miam les conversions de casse en UTF-8) est ce qui consomme le plus de temps CPU (merci valgrind). Gambas a l'air assez doué là-dessus.
Nous sommes une petite boite, je suis quasiment le seul à développer et maintenir cette application. Gambas possède un IDE complet, il est interprété, il compile très rapidement, et l'application Web est compilée en un seul fichier. Le temps de développement, de maintenance et de déploiement (une copie de fichier en SFTP) sont réduits d'autant.
Lorsqu'il y a un bug dans Gambas qui impacte le projet, il est fatalement corrigé assez vite. J'ai utilisé dans le passé suffisamment d'outils de Microsoft archi buggés (Visual Basic m'entends-tu ?) pour apprécier de contrôler la chaîne de développement de A à Z. Regardez le bug sur les tables de hachage non "randomisées" : j'ai pu le corriger en 15 minutes (ça a pris un peu de temps car l'article sur linuxfr explique bien le problème, mais moins bien la solution). Pour les applications basées sur un langage où ce bug n'est pas corrigé, elles peuvent trembler...
Le démarrage de l'interpréteur est rapide (disons que pour l'instant je ne sais pas faire mieux). Sachant que mon application Web est un script CGI, c'est important ! Et, en dépit du fait que c'est un script CGI, les temps de réponses sont largement satisfaisants. Si j'ai le temps, je mettrais le serveur HTTP dans l'interpréteur (ou le contraire), pour gagner du temps au linkage dynamique. Là ça devrait dépoter...
J'invite d'ailleurs tous les développeurs qui gèrent un projet et qui ont une petite douzaine d'années devant eux à créer leur propre langage pour leur propre besoin. :-)