Forum debian-fr.org

Bonsoir à tous,
J'ai besoin de vos lumières pour choisir dans quel langage me lancer à fond pour accoucher d'un projet de logiciel que je voudrais libre.
Il s'agit d'un logiciel qui permettra de classer des techniques de construction en fonction de leur impact écologique (oui c'est dans l'air du temps) en fonction de la hiérarchie imposée par la maitrise d'ouvrage.
En gros y'a une (ou plusieurs) base de donnée regroupant les dix indices donnés dans les Fiches correspondant aux différents matériaux de construction. Ces fiches sont dispo gratuitement sur le net. Donc la base est facile (et longue) à constituer.
Ce que je veux c'est une interface graphique qui permette de :
- Choisir le matériau de construction
- Indiquer la quantité nécessaire
- Eventuellement rentrer d'autres critères
- Enregistrer le scénario et refaire la même chose pour un autre choix de matériau.

A la fin on rentre les critères de pondération choisis par la maitrise d'ouvrage et ça donne le matériau répondant le mieux aux critères. (avec beaux graphiques même ça parle mieux)

La cible de ce logiciel sera l'enseignement. Il existe un seul logiciel actuellement, payant, ne tournant que sous windows. Perso ça me gêne. Déjà que pour les logiciels d'archi j'ai pas le choix alors je le veux pour ce genre de logiciel. Je suis prêt à mettre les mains dans le camboui pour avoir ce que je veux. Et le rendre libre pour que d'autre puisse évidemment l'améliorer, le corriger et en profiter gratos.

Pardon pour ce long message mais vaut-il mieux quoi? C, Python, Ruby, C++, VB ?

_________________
Ah ça y’est, j’viens de comprendre à quoi ça sert la canne. En fait ça sert à rien… Du coup ça nous renvoie à notre propre utilité : l’Homme face à l’Absurde !

salut
tu oublie:
le délait du projet, si tu débutes,
car sa va faire lourd a apprendre:
1.- c++, syntax,algo,poo,stl etc., (si c est une autre ,python,vb,java etc . Et bien cela va avidement changer hein:)
2.- sql, syntax, algo. obligatoire attention a ne pas assimiler le sql avec celui du gestionnaire de base de donnée.
3.-le gui de ton choix qt/gtk etc, c'est donc une lib ou il faut apprendre la syntax....
4.- les spécialité de base de donnée,postgresql,mysql, autre , celons le choix , voir une lib ou faire la tienne.
5.- la rapidité a apprendre .....

_________________
pq5 se plus proc 3.4 ghz 8 go de ram
ssd 1 dd 90 go ext4
nvidia 460
debian 64 bits wheezy beta 1
Enjoy

C++/boost/qt tu engloble pas mal de chose (me sert de qt pour tout ce que boost ne sait pas faire)

Le délai ne sera pas un souci. Le but n'est pas de le faire pour la rentrée. Et j'aurai des testeurs (mes élèves au pire). Le truc pour lequel je ne sais vraiment rien c'est les bases de données. Déjà vous m'avez aiguillé vers le postgresql (libre il me semble).
C++ soit ça va le faire j'ai déjà les bases faut les dépoussiérer et construire dessus.
Algo ça va.
Les librairies Qt et boost je ne connais pas du tout donc faudra que je me sorte les doigts du c.. et ça le fera. Je sens que je vais passer de bonnes vacances.

_________________
Ah ça y’est, j’viens de comprendre à quoi ça sert la canne. En fait ça sert à rien… Du coup ça nous renvoie à notre propre utilité : l’Homme face à l’Absurde !

Le gros avantage de Qt c'est que si tu l'utilises correctement ton programme sera immédiatement cross-platform Linux/Mac/Windows sans aucune modification, tu n'auras qu'à recompiler sur la bonne plateforme pour que ça marche. Il faut juste bien veiller à n'utiliser aucune API spécifique à une plateforme donnée, mais c'est justement pour ça que Qt fournit des services équivalents.

Quant à la base de données, ça dépend ce que tu veux faire précisément. Des moteurs comme PostgreSQL ou MySQL sont assez puissants mais lourds à mettre en place pour les utilisateurs. Une solution comme SQLite pourrait peut-être te convenir mieux : pas de serveur de base de données à installer, et toute ta base tient dans un seul fichier donc déploiement très facile.
Bien entendu Qt fournit une API cross-platform pour l'accès aux bases de données (PostgreSQL, MySQL, SQLite et bien d'autres), ce qui ne gâche rien.

_________________
testing/unstable (amd64) sous KDE4
github/syam44 - De la bonne manière de poser les questions - Wiki debian-fr
Just because you're paranoid doesn't mean they aren't after you. -- J.Heller

Je suis pas certains qu'il soit nécessaire d'utiliser du relationnel pour son cas. Sa description laisse immédiatement à du no-sql type orienté document. Mais j'avoue que je ne connais pas de solution qui permettrait le requetage simplifier. Je pense qu'il faut de toute manière commencer par créer le DAO pour voir de quel manière on souhaite accèder aux données avant de choisir la manière de persister.

_________________
Je suis Pitta, cartésien, irritable, irritant et névrosé (de plus je fais de l'entrisme pour zsh), si l'un de mes messages vous insupporte essayez d'y voir de l'ironie ou de ne pas en tenir compte. Bonne journée et gardez le sourire.

T'as probablement raison pour le côté relationnel vs. no-sql, mais en fait mon argument était plutôt base de données externe vs. in-process.
Pour le type d'application que michel_vi veut faire, je pense que de l'in-process est plus adapté car ça simplifie énormément les choses (aucun serveur à configurer, base de données dans un seul fichier).

Vu ses besoin à mon avis c'est "moins pire" d'utiliser une base relationnelle in-process (SQLite) plutôt que du no-sql qui dépend d'un serveur externe (Mongo, Couch, ...). L'idéal étant bien sûr du no-sql in-process, mais vu que je ne connais pas vraiment les produits no-sql je sais pas ce qu'il y a de disponible dans ce genre là.

_________________
testing/unstable (amd64) sous KDE4
github/syam44 - De la bonne manière de poser les questions - Wiki debian-fr
Just because you're paranoid doesn't mean they aren't after you. -- J.Heller

Je serais plus pour l'utilisation simple de la base de donnée. Donc plutot du style fichier genre feuille de calcul toute bête. Je ne veux pas avoir à installer un serveur car la très grande majorité des profs qui voudront utiliser ce logiciel ne connaissent rien à ça et si on leur complique la vie en disant "attention il vous faut installer une base de donnée sur serveur" ils cliqueront sur annuler et point barre ils iront voir ailleurs. En plus la base de fiche n'est pas énorme, ça contient juste une centaine d'entrées au maximum. Donc du nosql orienté document me parait pas mal et je pense que ça va me simplifier la vie .
Je récapitule : C++ et Qt. C'est déjà pas mal à cogiter.

_________________
Ah ça y’est, j’viens de comprendre à quoi ça sert la canne. En fait ça sert à rien… Du coup ça nous renvoie à notre propre utilité : l’Homme face à l’Absurde !

Donc effectivement il va te falloir chercher un produit qui fonctionne in-process. Tiens nous au courant si tu trouves du nosql qui satisfait ce critère, ça peut m'intéresser aussi...
Si tu n'en trouves pas il sera toujours temps de te rabattre sur SQLite, ça te forcera à structurer ta base un peu plus qu'avec du nosql mais ça changera rien pour l'utilisateur final : dans les deux cas il aura juste à installer ton application et tout fonctionnera "automagiquement".

_________________
testing/unstable (amd64) sous KDE4
github/syam44 - De la bonne manière de poser les questions - Wiki debian-fr
Just because you're paranoid doesn't mean they aren't after you. -- J.Heller

Je ne sais pas si tu a arrêter ton choix mais un conseil pour le langage que tu cite dans ton dernier message.
Le C/C++ a des avantages indéniable (performances, possibilités), mais il a le désavantage certain de ne pas avoir d'exécutable portable. C'est à dire qu'a partir de tes sources il te faudra les compiler autant de fois que de plateforme que tu souhaite supporter (si tu fait du code POSIX, donc portable).
Quitte à choisir je te conseillerais plutôt de partir sur du Java ou .Net (C# ou autre), voir même du Phyton qui s'interface parfaitement avec QT (http://dosimple.ch/articles/Python-PyQt/) ou GTK (http://www.siteduzero.com/tutoriel-3-93860-pygtk.html).

Et je ne peut qu'appuyer le choix d'un BDD embarqué pour ton soft. Un serveur de BDD type Oracle, PostgreSql ou même MySQL sont surdimensionnés et trop encombrant pour ton appli. SQLite suffit amplement.

En quoi est-ce un problème ? Linux a tous les outils de cross-compilation dont tu peux avoir besoin, il suffit d'intégrer les cibles désirées à ton processus de build. Les 3 plate-formes principales (Linux, Windows, MacOSX) sont très bien supportées.


Pas d'accord du tout. Les 3 sont des sources de prise de tête à n'en plus finir, pour des raisons totalement différentes. Sans rentrer dans les détails :
- Java est un langage extrêmement verbeux et peu souple, très douloureux à utiliser (oui, même par rapport à du C++).
- .Net est bourré de trucs propriétaires pas du tout compatibles avec Mono (l'implémentation Linux/MacOSX), on peut pas dire que la portabilité soit excellente.
- Python est plutôt sympa mais les APIs ne sont pas stables même d'une version mineure à l'autre. Ça veut dire que tu es coincé avec la version de Python choisie initialement, et il faut que toutes tes libs tierce-partie soient également compatibles avec cette version précise. Bon courage pour déployer ça sur une plate-forme hétérogène comme Linux (perso j'ai laissé tomber, je pense réécrire HLM en Perl au moins c'est un langage fiable).

_________________
testing/unstable (amd64) sous KDE4
github/syam44 - De la bonne manière de poser les questions - Wiki debian-fr
Just because you're paranoid doesn't mean they aren't after you. -- J.Heller

Python j'aime bien parce que je connais déjà un peu et est intuitif pour moi.
Je me suis collé au C++ avec le site du zéro (heureusement qu'ils sont là) et c'est un peu plus prise de tête je trouve mais je m'accroche. Je vais quand même le faire avec C++ parce que voilà c'est mon choix. En fait je ne saurais pas dire pourquoi. Peut être pour me la pêter plus tard devant les collègues
En fin pour l'instant je suis en apprentissage, heureusement que c'est les vacances qui commencent.

_________________
Ah ça y’est, j’viens de comprendre à quoi ça sert la canne. En fait ça sert à rien… Du coup ça nous renvoie à notre propre utilité : l’Homme face à l’Absurde !

Merci j'avais rien à me mettre sous la dent pour un vendredi.

Java a un paquet de qualité sur face au C++. Son manque de souplesse vient surtout de la rigueur et des conventions qu'imposent le langage. Sa verbosité c'est parce qu'il a moins de code cryptique que le C++ (je te propose de voir aussi des bibliothèques récentes comme guava https://code.google.com/p/guava-libraries/). Mais il arrive avec une bibliothèque standard bien plus complète que la bibliothèque standard et la STL du C++ ainsi qu'un paquet d'outils de très bonne facture (je pense à maven/gradle en particulier).

Ensuite d'un point de vu souplesse, java a de l'introspection ce qui est bien moins amusant à faire en C++, sa généricité est peut être moins souple que celle du C++ (pas de génération de code => pas de métaprogrammation), mais elle est plus puissante (du moins elle l'était avant le dernier C++) avec la possibilité de typer une méthode en fonction du type de retour attendu.

Le C++ en a d'autres d'avantages (outre la métaprogrammation qui n'est pas forcément utile). Par exemple il peut s'avérer plus simple a déployer MacOSX se coltine une version spécifique de Java sans mise à jour, donc pas de Java 7 sur un Mac un peu ancien, mais il faut pouvoir gérer le problème des dépendances à une bibliothèque et bien connaître l'architecture cible (ou pouvoir tester). La souplesse du langage lui permet d'avoir boost (boost en lui même est un argument important). Par contre ne me parlez pas de Qt que je vomis allègrement (une bibliothèque qui m'impose un système de build particulier est à gerber).

_________________
Je suis Pitta, cartésien, irritable, irritant et névrosé (de plus je fais de l'entrisme pour zsh), si l'un de mes messages vous insupporte essayez d'y voir de l'ironie ou de ne pas en tenir compte. Bonne journée et gardez le sourire.

Tu dirais de prendre quoi alors pour une interface graphique? Qui va avec C++ bien entendu

_________________
Ah ça y’est, j’viens de comprendre à quoi ça sert la canne. En fait ça sert à rien… Du coup ça nous renvoie à notre propre utilité : l’Homme face à l’Absurde !

De rien...

Malheureusement j'ai pas envie de débattre longuement de Java, je ne l'apprécie ni ne le hais assez pour ça. Pour moi c'est juste un langage qui n'est pas assez productif pour être intéressant (sérieux, je viens de me faire un script Perl en quelques jours ; j'avais essayé de faire l'équivalent en Java il y a quelque temps, j'avais laissé tomber après plusieurs semaines de boulot c'était totalement ingérable).

Question introspection, franchement, t'en as souvent besoin ? J'utilise la métaprogrammation très régulièrement, mais je n'ai jamais eu ne serait-ce que l'envie, sans parler du besoin, d'utiliser de l'introspection. Bon cela dit faut être réaliste, quand on n'a qu'un marteau tous les problèmes ressemblent à des clous (ça vaut aussi bien pour Java que pour C++ hein ).


Il ne faut pas oublier que Qt n'est pas qu'une lib, c'est aussi une plate-forme complète au même titre que Java. Le système de build qmake assure non seulement la cohérence d'une plate-forme à l'autre, mais permet également de rajouter des fonctionnalités qui font sérieusement défaut au C++, notamment un système d'évènements producteur/consommateur. Pour ça y'a pas vraiment le choix, le C++ ne suffit pas, il faut des builtins supplémentaires.
Bref, il faut voir Qt plutôt comme un langage (un sur-ensemble de C++ avec l'environnement qui va avec) que comme une simple bibliothèque de fonctions.


En C++ tu ne trouveras pas plus portable que Qt.
Si tu veux t'amuser avec GTK, tu n'auras que le toolkit graphique. Il faudra donc aussi te trouver des libs portables pour le réseau, pour les accès au filesystem, bref, pour tout. Et je doute que le résultat soit très homogène, tu vas devoir t'amuser à réconcilier l'ensemble... (sans même parler du fait que l'architecture de GTK est une vaste blague, mais je m'égare )

_________________
testing/unstable (amd64) sous KDE4
github/syam44 - De la bonne manière de poser les questions - Wiki debian-fr
Just because you're paranoid doesn't mean they aren't after you. -- J.Heller

Donner un cas où le Perl est plus pertinent que le Java n'indique une différence de qualité entre les deux. D'une part chaque langage à sa spécialité, d'autre part c'est lourdement influencé par ta connaissance des deux langages. Je pourrais te parler des webservice qui se font en un rien de temps en Java et qui prennent plus de temps en perl sauf si tu as déjà choisi un environnement ou un framework pour le faire.

Pour ce qui est de l'introspéction c'est très utile pour la sérialisation et la deserialisation d'objet. Mais tu peut aussi en voir l'utilité quand tu vois les pthread et le void* que tu passe en paramètre à tes threads (bien sûr en C++ ça doit pouvoir se régler avec de la généricité). En fait une partie de la métaprogrammation et de l'introspection adressent les même problématiques (garder la cohérence de type). Dans ces cas là la métaprogrammation me paraît plus propre (tu spécifie le type en amon), mais ce n'est pas toujours possible.

Pour le système de slot tu parle de quelque chose comme ça ? http://www.boost.org/doc/libs/1_50_0/do ... gnals.html

Chez trolltech ils ont probablement fait le bon choix, il y 15 ans. C'est maintenant plus le cas et c'est désespérant de voir qu'ils continuent à utiliser ça (ils ont déjà prévu de garder un outil du genre pour qt5). Il est claire que c'est la meilleure bibliothèque (ou plutôt les meilleures) pour gérer la portabilité. Mais moi quand je fait du C++, ce que j'aime c'est faire du C++ pas du qt. De plus j'aime avoir un découplage entre mon interface graphique et le reste de monde code (avoir un système en couche). Dès que tu fais le choix de qt tu as un très fort couplage avec. Tant qu'ils perdureront là dedans je n'arriverais pas à me mettre à utiliser leur truc, si un jour ils comprennent qu'ils ne sont pas seuls au monde ça deviendra le gral. En attendant faute de grives on mange des merles.

_________________
Je suis Pitta, cartésien, irritable, irritant et névrosé (de plus je fais de l'entrisme pour zsh), si l'un de mes messages vous insupporte essayez d'y voir de l'ironie ou de ne pas en tenir compte. Bonne journée et gardez le sourire.

Certe mais il est bien plus facile d'avoir 1 seul et unique éxécutable a donner que de fauire choisir suivant l'OS ...


Ca permet de ne pas faire autant de connerie que C/C++ le permet


Je ne suis pas fan non plus mais il existe une implémentation libre sur Nux, qui convient très bien si l'on ne fait pas quelquechose de trop évolué. Et il existe qeulques projets libre qui sont sur cette thecno.


Je suis d'accord sur le fait que Perl est rétro compatible alors que Python loin de là, mais Perl n'est pas réputer pour les GUI.

Moi je trouve que choisir un exécutable en fonction de la plate-forme est bien moins compliqué que d'obliger les utilisateurs à installer un runtime supplémentaire, mais chacun son truc.

_________________
testing/unstable (amd64) sous KDE4
github/syam44 - De la bonne manière de poser les questions - Wiki debian-fr
Just because you're paranoid doesn't mean they aren't after you. -- J.Heller

pourquoi pas en Perl ?

pour l'interface il y a pas mal de module qui permettent de lancer une page web... ou tk si tu veux vraiement du graphique...

le web est pratique car il permettra un accès par beaucoup de monde de partout sans rien installer sur les machines, juste un navigateur web. Une mise à jour du serveur permettra de mettre à jour tout le monde en une seule fois...

Il est plus simple de se mettre à Perl je pense qu'au C++ de mon humble avis, pas de compilation, beaucoup de librairies existante, langage de haut niveau...

Pour faire de l'objet, la lib moose est pas mal.

Comme framework web tu as catalyst ou dancer qui sont sympa (intègre un serveur web si tu n'as pas d'apache2 sous la main).

_________________
Pourquoi vendre alors qu'il y a tant à donner... JJG