Discussion :

[djibril]

salut à tous,

Pouvez vous donnez vos avis et retour lorsque vous avis conçu une application Perl/Tk distribué à un utilisateur tierce ou un client.

Supposons que vous souhaitiez créer un logiciel (payant ou non), qui aura pour but (je ne sais pas trop pour l'instant) d'effectuer certaines tâches (comme gestions de site web, analyses de fichiers de données, administrations réseaux, analyses de données biologiques, finance, ou autres).
Est il judicieux de le faire complètement en Perl?
Perl permet de faire tout (tous les traitements) et même l'interface graphique via TK. Mais d'après vous, est ce suffisant?
Certaines personnes disent que les interfaces Perl ne sont pas jolies par rapport à java par exemple, mais est ce vraiment uns raison suffisante?

Question de portabilité :
Cela pose t- il un souci du faite que le client devrait installer Perl, ainsi que les modules nécessaires?
Y a t il moyen d'automatiser l'installation de perl et les modules nécessaire au logiciel?
Par rapport à java où il est certe simple de creer des fichiers jar, en quoi java ou d'autres langages seraient ils plus utilisables que perl vu qu'il faudra toujours faire des installations préalable (en dehors de la maintabilité du code)?

Y aurait il des problemes de gestions de mémoires? est ce que cela ne dépends pas tout simplement du code bien écrit et de la machine?

En ce qui concerne la gestion des processus ou parallelisme des taches, il est souvent dit que java permet cela, mais pas perl. Mais cela dépend plus de la becanne non? car je crois qu'il existe des modules perl le faisant!!!

Question sécurité et contrainte:
Comment ensuite sécuriser son code? Car la création des exe en perl reste toujours plus ou moins evidente en fonction des modules chargées. Ce n'est pas toujours tres efficaces. en JAVa, on peut aussi également passer des .class au .java.

Avez vous rencontrés des problèmes lié à activePerl sur les machines clients?

Avez vous rencontrés des problèmes liés aux packaging de vos codes (PAR)?

Bref, en gros faut il être fou et dingue ou bien est ce logique si on le souhaite de se lancer dans la conception d'un logiciel (mini ou pas) écrit complètement en perl?
Ou bien est ce plus raisonnable de cumuler plusieurs langage comme perl et java ou autre?

Niveau interface graphique, peut on s'arrêter à TK ou gtk, ou faut il le faire en swing par exemple?

voilà tant de réflexions à votre disposition, j'attends vos raisonnement

Merci

[Jedai]

Trop de questions à la fois !!!

Déjà pour répondre à ta question sur les GUI : Tk n'est pas si laid, on peut même faire des choses assez impressionantes avec des modules comme Tk::Zinc, mais c'est sûr que ce n'est tout de même pas le plus beau GUI toolkit du monde... Néanmoins Gtk2 ou WxWidgets sont utilisables en Perl et sont nettement plus puissant, tout à fait au niveau de Swing (du Swing actuel parce que Swing a eu son lot de problème, fut un temps je n'aurais pas placé Swing au-dessus de Tk...).

Question portabilité, il est fortement recommandé si on veut avoir un marché sous Windows de créer des binaires, ou du moins des paquetages .par . Ca peut même être une bonne idée sous Unix pour s'éviter des questions de compatibilités et de versions des modules. Il est tout à fait envisageable par contre de laisser son source disponible, ainsi que de le distribuer sur le CPAN en parallèle pour ceux qui peuvent l'utiliser. Avec un binaire pour Windows, un .par et les sources, on s'assure une très bonne portabilité.

Perl est gourmand en mémoire, mais si vous l'utilisez proprement il n'y a pas trop de raisons pour que ce soit un problème, surtout vu la mémoire disponible sur les ordinateurs actuels . Si vous avez de grosses quantités de données élémentaires à manipuler, il peut être intéressant d'utiliser PDL, qui fournit d'excellentes facilités pour manipuler des matrices, faire du calcul scientifique, ... et offre des tableaux légers (pour les types numériques).

Pour ce qui est des threads (processus légers), ils sont maintenant mieux supportés par Perl, mais il reste préférable de les éviter, ne serait-ce que pour s'assurer la compatibilité avec les versions plus vieilles de Perl (encore très présentes sur le marché des serveurs et des stations de travail). L'utilisation des fork() reste une alternative privilégiée, mais selon le problème la meilleure solution pourrait bien être d'utiliser POE, un framework pour l'asynchrone très bien fait et disposant déjà d'un grand nombre de composants. A terme, avec l'avènement de machines massivement multicore, la question se reposera, mais à vrai dire pour l'instant il y a bien peu d'applications qui profitent réellement de ce surcroit de puissance (et si vous écrivez une telle application en Perl, vous avez un problème de choix du langage.... )

Question sécurité du code, franchement seule une bonne licence peut vous aider de ce côté là, avec peut-être un petit obfuscateur pour rendre douloureux tout vol de code. Côté sécurité du logiciel, il est inutile de se mettre martel en tête, le seul schéma qui assure une véritable sécurité est celui où une partie du logiciel n'est pas sur la machine utilisateur mais plutôt sur Internet, et ceci quel que soit le langage, ensuite, tout est question d'effort requis du côté du cracker.

--
Jedaï

[mobscene]

OUlala que de questions :

Question de portabilité :
Avec perl il n'y as pas trop de soucie de ce coté par contre sous bien des distrib linux perl est installé par défaut sous windows ce n'est pas le cas le meilleur moyen de faire cela avec windows est d'installer perl pour windows sur une machine puis d'y installer tout les modules néçéssaire au fonctionnement de l'appli du client et ensuite de créer un installeur , ne biensur pas oublier de refaire l' association des fichiers et l'enregistrement de perl.exe dans le path de windows, et hop sa fonctionnera je le sais car je le faisait a une époque



Question sécurité et contrainte:
Heu faut dire qu'en perl ce n'est pas vraiment possible les paquetages .par sa foire une fois sur deux.

[djibril]

merci pour vos réponses. Mais bon c'est toujours bien de se poser pleins de questions car on est tellement à la mode java, appli java j2ee qu'on se demande si perl a un quelconque intéret. Surtout quand l'appli ou logiciel doit etre envoyé chez un client par exmple.
Sinon mobscene, tu connais des logiciels ecris en perl TK.
Tu faisais quoi toi chez tes clients avec perl (juste par curiosité)?

[mobscene]

Mouarf java on nous le sort a toute les sauces tout les 4 matins il y a un nouveaux truc j2se, j2tutu, j2bobo, j2caca enfin bref moi je n'y comprend plus rien.

Je fait plutôt de la programmation en C# depuis quelques mois vue que les softs que je développe ( pour un projet perso ), sont tous multithread et que perl pèche sévèrement de ce coté.Néanmoins certains progs reste en perl.

Pour ce qui est de mon histoire d'intalleur je faisait cela pour simplifier le déploiement de perl sur plusieurs bécanes.

[Arioch]

Je vais juste donner mon avis perso car j'ai depuis quelques années dans l'idée de concevoir un logiciel à base de Perl + Tk.

Le but et l'utilité de ce programme n'ont rien à faire ici, donc je n'en parlerai pas. Je dirai juste que l'appli n'exploiterait rien qui nécessite des déviations pour certains systèmes (comme si j'utilisais certains packages spécifiques Windows ou Unix, ce qui n'est pas le cas).

Question portabilité donc, mon code serait exploitable sur les OS les plus usités.

La question se pose principalement pour Tk, ainsi que Perl. Obliger les personnes à qui je destinerais le programme d'installer Perl sur leur machine ? Hors de question ! La plupart sont habitués à double-cliquer sur une icone, le bazar s'ouvre à l'écran et basta. Hors de question de leur imposer le téléchargement de Perl, son installation et tout ça, "juste" pour un script qui l'exploite.

Et si je prend exemple sur Perl2Exe, hormis la version payante que je ne connais pas, la version shareware a ses limites. Certains codes sont mal reconnus lors de la création du soit-disant binaire, j'en ai déjà fait la triste expérience justement avec Tk. De plus, comment proposer la version binaire pour MacOS lorsqu'on n'a personne autour de soi qui utilise cet OS pourtant sympathique ?

Eh bien, le fait de ne pas pouvoir exploiter pleinement Perl2Exe (par exemple) ni de ne pas avoir envie de contraindre les futurs utilisateurs d'installer Perl = le programme reste là où il est. Nulle part.

A côté, Perl me sert quotidiennement. A la maison pour le jeu que je gère sous Linux, au travail sur AIX ou sur nos postes qui sont sous Windows 2000 ou XP. Mais en dehors, ben

[ours_en_pluche]

désolé de depoussierer ce thread.

je participe a un logiciel tournant uniquement sous linux.

fan de Perl depuis plusieurs années,

j'ai developpé a titre personnel plusieurs applets externe en perl pour ce logiciel.

applets fonctionnant parfaitement.

MAIS

Aucun n'a jamais été publié sous sa forme originale, ils ont soit été réécrit en python, soit abandonné.

CAR

Perl est effectivement tres puissant et tres facilement prenable en main, mais ce qui en fait sa force en est d une certaine maniere sa faiblesse.

pour moi, le CORE n'a pas assez de module inclus.

dans la conception de notre logiciel, nous essayons d'éviter l'ajout de module externe.

hors des qu'on fait quoi que ce soit ( ou presque ), necessite l'installation de modules CPAN.
principalement, le soucis que j ai eu, le fait que LWP ne soit pas inclus dans le CORE me pose enormement de soucis de deploiement comparé a python par exemple, qui a son equivalent d installé de base hors le WEB est a l'heure actuelle une bonne partie des déploiements logiciel ( l user-friendly inutile donc obligatoire ).

je prefere faire a fonction identique, un programme qui ne necessite aucune installation supplementaire...

alors la solution serait de faire un module en python qui me recupere la page web, mais autant tout faire en python, ce qui est malheureusement la solution qui a été choisie.

quand un module est mettable sans installation particuliere dans le dossier du programme, pas de soucis, mais quand on doit s'attaquer a des modules plus lourd, ce n est plus gerable.

imaginez :

le client installe le logiciel
doit lancer cpan
installer les dependances
le logiciel fonctionne

ou

le client installe le logiciel
le logiciel fonctionne

quel est le choix le plus logique ?

mes 2 cents

cordialement

Ours

[Peps16]

Salut je n'ai pas réponse à touts mais avec ces questions ci-dessous:

Question de portabilité :
Cela pose t- il un souci du faite que le client devrait installer Perl, ainsi que les modules nécessaires?
Y a t il moyen d'automatiser l'installation de perl et les modules nécessaire au logiciel?

Je dirais que cela dépend de ton client.

Dans l'entreprise ou je travail et pour des projets développés en interne cela pose un réel problème si le client ne souhaite pas installer perl.

Avez vous rencontrés des problèmes liés aux packaging de vos codes (PAR)?

La plupart des setup sont crées avec Inno Setup (réelle personnalisation du setup pour lé déploiement). Le module par-parcker génère des setup beaucoup plus gros qu'avec IS