Discussion :

[dba01]

Bonjour.
Je crois que personne n'a compris ma précédente question. Je l'ai donc fermée pour la poser autrement.

Je cherche quel serait le langage le mieux adapté pour une petite application personnelle spécifique selon les critères suivants :
- Très peu de données enregistrées, en fichiers plats uniquement, peut-être 200 lignes de 5 champs. Pas de bases.
- Des calculs assez alambiqués, une cinquantaine de formules algébriques s'appelant les unes les autres, parfois strictement séquentielles.
- Des affichages variés, sous forme de tableaux, de listes déroulantes, de fenêtres multiples simultanées, scroll vertical ou latéral.
- Formats et positions d'affichage très contrôlés (alignements, polices, chiffres, mise en page, ...), avec impressions à l'identique.
- Aucune image graphique.
- Pas besoin de liaison Internet, mais éventualité de téléchargement de l'application elle-même.
- A réaliser dans mon PC
- Et surtout transportable dans une clef USB et exécutable dans n'importe quel PC Microsoft (préférence donc pour un exécutable monobloc).

Si quelqu'un possède une expérience globale des différents types de langages et pouvait m'en expliquer brièvement les grands avantages/inconvénients, et sans céder à une mode trop passagère, ça m'éviterait de perdre du temps dans des directions inutiles.
Note : et si c'est du gratuit, ce n'est pas plus mal !

En vous remerciant par avance.
.db.

[souviron34]

je ne rentrerais pas dans l'énoncé avantage/inconvénients, beaucoup trop complexe et discutable..

Avec quel outil/langage es-tu le plus familier ?

Cela peut se faire dans à peu près tous les langages, que ce soit C++, Java, Qt, VB, etc etc...

[dba01]

On peut tout faire avec un ordinateur, et du temps, et des sous. Je sais, je leur ai servi ça pendant une dizaine d'années.
On peut aussi faire les courses au super marché avec une Lamborghini ou un Caterpillar, mais c'est plus pratique avec une 4L.

Si je comprends bien, il n'y a pas de systèmes/langages plus adapté à tel ou tel type de traitement, mais plutôt des informateux plus ou moins sensibles à tel ou tel style de codage. Je regardais pour cela une autre discussion sur le sujet "quel langage utilisez-vous et pourquoi". En général la réponse est plutôt "parce que j'aime ça".

Pas grave !
Je le laisse encore trois jours et je ferme.
Merci.
.db.

[souviron34]

On peut tout faire avec un ordinateur, et du temps, et des sous. Je sais, je leur ai servi ça pendant une dizaine d'années.
On peut aussi faire les courses au super marché avec une Lamborghini ou un Caterpillar, mais c'est plus pratique avec une 4L.

WTF ????

Désolé ici on est sur un forum de professionnels...

Quand on répond à une question, on ne s'attend pas à se faire jeter par une soi-disant ironie qui tient plus de la condescendance et du mépris...

Si je comprends bien, il n'y a pas de systèmes/langages plus adapté à tel ou tel type de traitement

Si, si les traitements sont spécialisés ou compliqués..

Pour ce que tu décris, non il n'y a pas de langage/système plus adapté que tel ou tel... car ce que tu décris est assez élémentaire, donc presque tous peuvent le faire...

je regardais pour cela une autre dscussion "quel langage utilisez-vous et pourquoi". En général la réponse est plutôt "parce que j'aime ça".

Parce que ceux qui répondent à ce genre de discussions sont des jeunes ou relativement jeunes, qui sont motivés par leurs goûts..

Notre métier fait qu'avec de l'expérience on utilise des dizaines de langages et de plateformes, et que donc le langage utlisé est plus imposé par le projet que un choix ...

[Melem]

dba01, ce que tu n'as pas compris c'est que comme Jean (souviron34) l'a dit, ce que tu cherches à faire est tellement élémentaire que n'importe quel langage fait l'affaire. Ce n'est pas comme si tu nous demandais quel langage était le mieux adapté pour faire un OS, auquel cas on t'aurait très certainement proposé le C même si on peut faire la même chose en Java, en Cobol ou en PHP. Mais ici c'est différent : tous les langages sont réellement de bons candidats pour ton projet et dans ce cas, le meilleur choix devient donc le langage que tu maîtrises le mieux. Cependant, si tu n'as pas encore d'affinité avec un langage particulier, je te propose donc le C. En effet :

Très peu de données enregistrées, en fichiers plats uniquement, peut-être 200 lignes de 5 champs. Pas de bases.

La manipulation des fichiers et le formattage et la lecture formattée de données en C est très aisée. C'est même l'une des vocations du C. Sur ce point, Java, Pascal et VB6 se trouvent parmi les gros perdants.

Des calculs assez alambiqués, une cinquantaine de formules algébriques s'appelant les unes les autres, parfois strictement séquentielles.

Ici, tous les langages sont adaptés. On pourra cependant noter que les langages orientés calcul scientifique comme Matlab/Scilab offreront plus de simplicité de codage que les langages classiques comme C, Fortran ou Java..

Des affichages variés, sous forme de tableaux, de listes déroulantes, de fenêtres multiples simultanées, scroll vertical ou latéral.
Formats et positions d'affichage très contrôlés (alignements, polices, chiffres, mise en page, ...), avec impressions à l'identique.

Ici, VB6, Delphi, C++/Qt, C++/WxWidgets sont les plus simples à programmer après les pages web ...), mais ce n'est pas vraiment l'horreur non plus en C, avec GTK+ ou même directement l'API Windows.

Et surtout transportable dans une clef USB et exécutable dans n'importe quel PC Microsoft (préférence donc pour un exécutable monobloc).

Ici, le grand gagnant c'est indiscutablement le C car les exécutables créés avec le C sont très petits (en espace occupée sur le disque) et autonômes : pas besoin d'installer une machine virtuelle ou autres runtimes pour les faire tourner.

[el_slapper]

Juste, je dirais que la contrainte d'install rapide via clef USB exclut quand même .NET(qui nécéssite le framework), voire Java(si c'est pour installer une machine qui n'a pas d'accest internet et donc pas de machine java à jour).

Pour la gestion de Fichier, certes VB6 n'est pas optimisé dans ce sens, mais il n'est quand même pas bien dur de faire un print sur longueur fixe. Je peux même fournir un tutorial(et je suis loin d'être le seul en ces murs).

Pour l'espace disque demandé : une interface un poil lourde plus une cinquantaine de calculs, même complexes, ça casse pas trois pattes à un canard. Même si le C est optimisé, je ne vois pas ça comme un point positif.

Non, je crois que le seul point réellement un peu demandeur, c'est l'interface. VB6, Delphi, ou les C améliorés, tous peuvent faire l'affaire. Windev aussi, mais il n'est pas donné(delphi non plus, il me semble).


==>Conclusion : pas de vraie conclusion. Certaines solutions à éviter(sauf à se farcir le téléchargement du framework .NET à chaque nouvelle install), mais pour le reste, rien de transcendant qui impose tel ou tel langage. Le plus important, et ça a déjà été dit, c'est de le faire dans un langage que l'on apprécie. VB6 si on aime le verbeux, C si on aime pas. VB6 si on aime la mémoire managée, C si on préfère la gérer à la main. Windev si on aime le Français. etc...

[dba01]

Merci Melem, c'était le genre de commentaire que je recherchais, slapper aussi. Et franchement, je n'aurais pas pensé au C. J'imaginais aussi le java capable de tout, mais c'est loin d'être le cas. J'avais déjà été déçu (au boulot) par les écrans et les temps de calcul, et maintenant j'élimine complètement.
Je vais donc de ce pas chercher de la doc en C et C++ pour confirmer.
Je laisse encore le sujet un moment si quelqu'un avait d'autres commentaires.

Note : les 50 formules, faut pouvoir les mouliner toutes au moins 500 fois par seconde. L'affichage du calendrier d'une année, quelle qu'elle soit, doit flasher instantanément.

Merci.
Bonne soirée.
.db.

[souviron34]

Note : les 50 formules, faut pouvoir les mouliner toutes au moins 500 fois par seconde. L'affichage du calendrier d'une année, quelle qu'elle soit, doit flasher instantanément.

note : le temps de calcul est négligeable. 5000 opérations es quantité négligeable avec les processeurs à 2 Go et audessus... (<< 1 milliseconde)

Ce qui fera la différence sera le temps d'affichage..

Enfin il vaut mieux travailler en mémoire (cacher le widget) puis afficher le widget rempli, ou alors il faut optimiser l'affichage..

C'est cette partie qui sera la plus consommatrice et donc la limite..

[dba01]

Merci.

J'avais surtout peur que mes formules en cascade (50 x 500 = 25 000), s'appelant les une les autres en se refilant ou non une partie des résultats provisoires, ne dégradent les performances d'un système "objet" qui n'a pas cette structure habituellement. Et quand ce n'est plus qu'un outil dans le calcul d'autre chose, vaut mieux savoir à quoi s'attendre que de découvrir à la fin qu'on a pris le mauvais outil.
Le vieux Basic n'a pas tellement la même écriture que le Java. C'est pourquoi j'aimais mieux annoncer la chose.

Ici encore, c'est une question d'option : il est plus rapide de tout calculer puis ensuite d'afficher, mais le client s'impatiente et souhaiterait voir tout de suite quelque chose que, de toutes façons, il ne lira que lentement. C'était le reproche que je faisais aux quelques développements Java que je devais homologuer : cette impression désagréable que la machine ne répond pas. A l'inverse, voir les trucs défiler donne aussi l'impression que ça ne va pas vite. Et les barres de défilement sont des bouffeuses de temps pas possibles.
Faut voir, selon les cas !

Bonne journée.
.db.

[el_slapper]

Java permet de tout faire. tout. Juste, tu ne peux pas garantir la présence de machine virtuelle java à niveau de ce que tu as fait sur une machine de la sorte.

Pour ton calcul, ça semble dérisoire, quand même. Le plus probable pour tes ralentissements en Java, c'est que c'était du au réseau. Ou aux référentiels. Deux choses que tu n'auras pas à gérer au vu de l'appli que tu décris. tu fais du calcul pur. A moins de passer un paquet de millions de fois dans le même calcul complexe, ça sera un temps de calcul invisible. Comme le dit souviron, seul l'affichage prendra du temps.

Pour l'objet : l'objet n'est qu'une manière de ranger son code. Au lieu de mettre les données ici et le code là, on met le code associé à une donnée juste au même endroit que la donnée. C'est tout. C'est tout et c'est énorme, parceque l'on pense alors son programme complètement différement, mais si on code bien, on fait exactement la même chose qu'en procédural. Suivant les applications, l'un ou l'autre sera plus facile. Pour ton appli, l'objet n'est pas obligatoire(lire : il n'apporte pas grand chose, et si tu n'as pas l'habitude, autant t'en passer), mais ne pose pas de problème particulier. Ca n'est pas un no-go.

Ce qu'il te faudra bien penser, c'est :
1)l'ordre des calculs(parceque dans le mauvais ordre, tu auras quand même des problèmes de performance).
2)L'interface.

Ca n'est pas assez complexe pour qu'un mauvais choix d'architecture logiciel soit lourdement pénalisant.

[souviron34]

A l'inverse, voir les trucs défiler donne aussi l'impression que ça ne va pas vite. Et les barres de défilement sont des bouffeuses de temps pas possibles.
Faut voir, selon les cas !

Le remplissage de listes, de tableaux, de labels, etc peut prendre beaucoup plus de temps par exemple si on laisse les dimensions s'adapter.. Chaque nouvelle insertion demande le recalcul de tous les précédents...

De même, comme tu le signales, les barres de défilement..

Il faut donc adapter..

Si on a énormément de lignes à afficher, comme je l'ai dit, le plus optimal est de cacher le widget et de ne l'afficher qu'une fois rempli..

Mais aussi de calculer avant de le remplir les dimensions , et dimensionner à la main en taille fixe, et aussi les tailles des barres de défilement et des ascenceurs et des marges..


Si on n'a qu'un nombre "normal" de lignes dans un widget correct, pas besoin de se soucier de ça..


Mais quand on fait même une présentation simple mas avec beaucoup de contenu, il ne fait jamais oublier ce qui se passe dans un widget quand on lui rentre des choses dedans.. Un comportement "tout intégré" et "super" peut aussi avoir ses (mauvaises) contreparties dans certains cas...

En bref, en programmation comme en IHM, il faut savoir ce qu'on fait... et ce qu'on veut..

[dba01]

Bon, je vous remercie tous. Je crois qu'on a fait le tour du sujet "choix". Il me reste maintenant à me tourner vers la doc correspondante.
J'ai constaté qu'il y avait déjà beaucoup de choses à lire sur le site.
On peut donc fermer ce fil.

Bonne journée.
.db.

[Madmac]

Question portabilité rien ne battra un programme en Javascript. Et comme les navigateur arrivent avec des interpréteurs de plus en plus performants, je commencerais par regarder de ce coté.

[souviron34]

Question portabilité rien ne battra un programme en Javascript. Et comme les navigateur arrivent avec des interpréteurs de plus en plus performants, je commencerais par regarder de ce coté.

Aller... Un peu de sérieux svp..

[Madmac]

Aller... Un peu de sérieux svp..

Une question toute simple:

En excluant le temps de compilation, pourriez-vous m'expliquer pourquoi une machine virtuelle faite pour le Javascript serait beaucoup moins performante qu'une machine virtuelle pour le Java ?

[Melem]

Madmac, non seulement Javascript n'est pas aussi portable que tu l'avances (on peut facilement faire des scripts qui fonctionnent dans un navigateur mais pas dans un autre ...), mais il reste un langage interprété et ne sera jamais aussi rapide qu'un langage compilé comme Java. Et Java lui par contre est très portable.

pourriez-vous m'expliquer pourquoi une machine virtuelle faite pour le Javascript serait beaucoup moins performante qu'une machine virtuelle pour le Java ?

Javascript ne s'exécute pas sur une machine virtuelle. Il est interprété par le navigateur. Les langages interprétés sont, de façon générale, plus lents que les langages compilés.

Java de son côté est compilé en bytecode. Actuellement, la plupart des machines virtuelles java compilent le bytecode en code natif avant de l'exécuter, ce qui confère aux programmes java une performance comparable à celles des langages nativement compilés.

Javascript est un bon langage pour écrire des scripts dans des pages web, ce que java ne permet pas, mais pour du développement applicatif de bureau, java est de loin plus adapté.

[Madmac]

[quote]

Madmac, non seulement Javascript n'est pas aussi portable que tu l'avances (on peut facilement faire des scripts qui fonctionnent dans un navigateur mais pas dans un autre ...), mais il reste un langage interprété et ne sera jamais aussi rapide qu'un langage compilé comme Java. Et Java lui par contre est très portable.

Javascript ne s'exécute pas sur une machine virtuelle. Il est interprété par le navigateur. Les langages interprétés sont, de façon générale, plus lents que les langages compilés.

Historiquement c'était vrai, mais quand je regarde les performances de Javascript, j'ai de plus en plus l'impression que certains navigateursne sont doté de compilateur interne qui fonctionne en 'just-in time'.

Il existe encore de vieille sources de compilateurs Pascal qui fonctionnait avec du bytecode, dont la taille est généralement plus petite qu'un plug-in.

Alors avant d'affirmer que Javascript n'est toujours qu'un language interprété, je me demanderais, à votre place, si c'est une avenue que vous auriez pu envisager pour accélérer du Javascript ...

[souviron34]

ma remarque et mon ironie était surtout que comme ça peut se faire par un exécutable Windows, que ce soit via VB, Gtk, C++, ou n'importe quoi d'autre, les trucs du style "Javascript" n'ont pas plus de "portabilité décisive" que le reste, et que ton intervention ressemble plus à ce que dénonçait le PO plus haut

Je regardais pour cela une autre discussion sur le sujet "quel langage utilisez-vous et pourquoi". En général la réponse est plutôt "parce que j'aime ça".

Et que ce n'était donc pas le sujet de la discussion...



Donc avant de dire "c'est ça qui est le mieux parce que c'est ce que j'utilise", il faut argumenter plus que

Question portabilité rien ne battra un programme en Javascript

Sur Windows, en terme et de portabilité et de vitesse, rien ne battra un exécutable...


Maintenant, Java et son bytecode, c'est bien portable et rapide, de même que tout un tas d'autres choses..

[Melem]

@Madmac : Je ne savais pas qu'il existait des compilateurs javascript. Pour ne pas dévier le sujet, j'ai donc rien dit en ce qui concerne les perf de Javascript, lorsqu'il est compilé, par rapport à Java si on exclut le temps de compilation, même s'il y a de quoi discuter. Mais je maintiens que Javascript n'est pas un langage aussi portable que Java et encore moins aussi adapté au développement d'applications de bureau que ce dernier.

[Madmac]

Je n'ai pas la certitude que javascript est compilé dans tous les navigateurs, mais les gains de performances de plusieurs version le suggère fortement

Je suis d'accord pour dire que ce n'est pas un langage pour fabriquer des applications. Mais ici, il n'était question que de calcul.