Cher journal,
Je suis actuellement en pleine hésitation.
Je désire coder un démon de gestion de mes fichiers musicaux utilisant gstreamer.
Par dessus viendrait se greffer une inteface Gtk2 indépendante (le démon pouvant tourner sans l'interface).
Le démon doit être efficace, il gêrera en effet toute la base de donnés de mes fichiers musicaux.
Quel langage choisir ?
J'hésite en C, C++ et Python.
C :
pro : - gstreamer et GTK2 sont nativement fair pour le C
- efficace et rapide
- je l'ai beaucoup utilisé cette année
- bonne documentation C/Gstreamer
cons : - pas facile à implémenter
- pas facile car j'ai une approche assez "objet" de la chose.
C++ :
pro : - orienté objet
- gtkmm pour l'interface
- plus facile que le C
- possibilité de reprendre du code du projet longplayer (notemment la BD)
cons : - plus utilisé depuis un an
- aucune idée de comment utiliser avec gstreamer
Python :
pro : - le plus intuitif et le plus simple
- existence de bindings gtk2/python
- existence de bindings gstreamer/python
cons : - je connais à peine (mais c'est l'occasion de s'y mettre)
- Performances ? Est-ce vraiment plus lent ?
Je peux aussi faire le démon dans un langage et l'interface dans un autre, bien évidemment.
Au niveau de la base de données (qui doit contenir uniquement certaines infos pour chaque fichier ), me conseillez-vous d'implémenter le tout moi-même (genre un fichier texte et une recherche avec hashtable ou qqch du genre) ou bien d'utilisez une BD déjà existante ? (aucune idée de comment faire ça simplement).
Merci pour les conseils et les infos.
Journal Quel langage choisir ?
4
avr.
2004
# Re: Quel langage choisir ?
Posté par Ph Husson (site web personnel) . Évalué à 0.
enfin c'est ce que je penses
apres j'ai pas d'arguments :)
# Re: Quel langage choisir ?
Posté par tanguy_k (site web personnel) . Évalué à 1.
> cons : - plus utilisé depuis un an
> - aucune idée de comment utiliser avec gstreamer
Le C++ et le C ca se marie tres bien, je vois pas pourquoi ca serait un probleme pour utiliser gstreamer. Pareil pour Gtk, tu n'es pas oblige d'utiliser gtkmm, tu peux directement utiliser Gtk en C dans ton code en C++ ca pose aucun probleme (sauf celui de melanger les genres). Si tu es plus a l'aise en C++ qu'en C alors utilise C++ puisque tu pourras toujours utiliser les memes outils et librairies qu'en C.
Au fait qu'es ce qui n'est plus utilise depuis 1 an ?
Bon apres mon avis personnel, si tu programmes en C utilise Gtk mais si tu programmes C++ alors utilise Qt.
Pareil avec Python, malgre que je n'ai jamais programme en Python, j'ai toujours entendu dire que l'on pouvait tres facilement utiliser du code programme en C.
[^] # Re: Quel langage choisir ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Mes livres CC By-SA : https://ploum.net/livres.html
# Re: Quel langage choisir ?
Posté par Snark_Boojum . Évalué à -2.
Ca c'est un vrai langage objet: http://www.cetus-links.org/oo_eiffel.html(...)
Snark sur #gnomefr et #gnomemeeting
# Re: Quel langage choisir ?
Posté par Mickaël Rémond (site web personnel) . Évalué à 2.
Ensuite, le gros intérêt pour ce que tu veux faire est qu'ensuite tu peux utiliser la base de données Erlang intégré à l'environnement (Mnesia). Mnesia s'utilise très simplement et tu évites ainsi la mise en oeuvre et le déploiement d'une base de données.
L'interface graphique utilisateur peut ensuite être faite, avec les outils que tu souhaites, en communiquant avec le démon.
Mickaël
# Re: Quel langage choisir ?
Posté par Olivier Grisel (site web personnel) . Évalué à 7.
Plus rapide à développer et maintenir que C/C++
Pour les perfs :
Pour ce type d'appli tu n'as pas besoin de performances extra-ordinaires et python est largement assez rapide. Au pire tu "profiles" ton appli si elle commence à rammer afin d'identifier quelles parties du code sont en cause et en repenser l'algo et/ou les écrire en C/C++ (http://www.python.org/doc/current/lib/profile.html(...) )
Pour la partie réseau (entre le client et le démon), xmlrpc est un protocole haut niveau géré de base par python. Sinon y a aussi la lib twisted qui fait du bon travail. Et enfin y aussi SOAP via ZSI par exemple mais pour ce type d'appli XML-RPC qui plus léger et intégré de base à python, me semble plus adapté).
Pour la partie DB :
- au choix du xml (très bien géré par python via http://pyxml.sourceforge.net/(...) )
- sqlite avec les bindings python qui vont bien.
Pour l'interface, j'aime bien wxPython (et wxGlade pour générer facilement le code). Sous linux ca fait du GTK1 ou 2 (et même du motif pas bo sur demande), du windows natif sous win et du mac natif sous mac (voir audacity pour un exemple d'appli utilisant wxWidgets). Mais GTK2 directement est aussi un bon choix si la portabilité n'est pas une priorité absolue.
Pour apprendre python y a :
- les bouquins Oreilly (vérifier la date de parution pour en prendre un récent qui traite de python 2.x et pas 1.5) :
http://www.amazon.fr/exec/obidos/ASIN/0596002815/qid=1081089385/sr=(...)
(Tbien mais en anglais)
http://www.amazon.fr/exec/obidos/ASIN/2841772942/qid=1081089385/sr=(...)
(connais pas mais a l'air bien et en francais)
- le python cookbook est dispo en ligne ou en bouquin:
http://aspn.activestate.com/ASPN/Python/Cookbook/(...)
- yet another tutorial for python :
http://www.python.g2swaroop.net/(...)
et le site python.org avec la doc de reférence.
[^] # Re: Quel langage choisir ?
Posté par Troy McClure (site web personnel) . Évalué à 4.
et http://diveintopython.org/toc/index.html(...)
[^] # Re: Quel langage choisir ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Quel langage choisir ?
Posté par Olivier Grisel (site web personnel) . Évalué à 2.
Je redécouvre en ce moment avec bonheur DiveIntoPython qui s'adresse à un publique de programmeurs (assez) expérimentés qui veulent passer à python. Le contenu évolue au file des versions. La partie sur le unit testing, code refactoring et regression testing est vraiment très intéressante.
Merki beauçoup de m'avoir fait redécouvrir cette doc :o)
[^] # Re: Quel langage choisir ?
Posté par bobert . Évalué à 1.
Pour le stockage de tes données SQLite est un excellent choix ; regarde aussi du côté de ZoDB (http://www.zope.org/Products/StandaloneZODB(...)), le SGBD objet de Zope.
J'ai pas bien saisi les fonctionnalités que tu veux implémenter, mais peut-être peux-ti t'inspirer vaguement, du moins pour démarrer, de Music Server (http://sourceforge.net/projects/musicserver/(...))
# Re: Quel langage choisir ?
Posté par 0xDEADBEEF . Évalué à -2.
MS Access rulez
# Re: Quel langage choisir ?
Posté par calandoa . Évalué à 1.
Je te conseille de rester au C. C'est un peu chiant parfois de se taper la réinvention de la roue à chaque fois avec ce langage, mais en utilisant la glib tu peux t'éviter pas mal d'effort, et rien ne t'empêche de faire de l'orienté objet en C... il faut juste un peu plus de rigueur dans l'architecture de ton programme...
[^] # Re: Quel langage choisir ?
Posté par tanguy_k (site web personnel) . Évalué à 1.
Je suis pas d'accord du tout. La STL est un modele du genre, il y a tres peu de methodes a connaitre. Tout fonctionne de la meme facon et la logique derriere est toujours la meme. Bref on peu faire des choses tres puissantes avec tres peu d'investissement.
La doc de la STL (par SGI) est certainement pas des plus clair et encore moins les messages d'erreurs causes par les templates. Mais ceci ne remet certainement pas en cause la qualite de la lib elle-meme.
> par ex, l'utilisation intensive de références au lieu de pointeurs
Justement les references ca simplifie le code donc ameliore la lisibilite et la maintenabilite et evite beaucoups de bugs/fuites memoires. Que demande le peuple ? Ah oui il faut apprendre le concept en lui-meme pour pouvoir l'utiliser. D'ailleurs c'est comme ca que fonctionne Java et C# mais ils ont surement tort mdr
Bref 2 exemples et 2 argumentations bidons
[^] # Re: Quel langage choisir ?
Posté par M. Vandemar . Évalué à 0.
[^] # Re: Quel langage choisir ?
Posté par calandoa . Évalué à 1.
Quand je dis que c'est "un sacré bordel", j'entends par là le coté assez ésotérique de la documentation, et non une éventuelle incohérence. Par ex:
template<typename _CharT, typename _Traits>
basic_ostream< _CharT, _Traits > & std::basic_ostream< _CharT, _Traits >::operator<< ( __streambuf_type * __sb ) [inherited]
issu de la doc de la stdc++ gnu (peut être s'agirait-il de la standard library et non de la standard template library? encore une subtilité pas évidente...) est pour moi assez imbitable, en tout cas bien plus que ce qu'on peut trouver dans la bibliothèque C standard. Il n'y a pas de doute que cette dernière est assez limitée mais elle reste efficace dans pas mal de cas, et en lui ajoutant la glib, on peut faire beaucoup de chose plus rapidement qu'en C++ (en comptant le temps d'apprentissage des subtilités de ce langage).
Pour les références, le problème n'est pas le principe mais la façon dont c'est implémenté en C++. Quand tu programmes en java, tu n'as pas de pointeurs, donc tu utilises forcement des références et tu n'as d'ailleurs pas à t'en soucier vu que la mémoire est gérée par le système grâce au garbage collector. Quand tu es en C++, tu dois jongler avec les variables dans la pile et dans le tas, les pointeurs et les références (le '&' pour les références n'aurait pas pu être plus mal choisi, bonjour la confusion avec le '&' "adresse de" et les 'et' logique et binaire), avec les types simples et complexes (tu passes une classe en argument, mais va tu passer un pointeur ou un bloc de 512 octet? tu fais une copie, mais va tu avoir une copie 'shallow', 'deep' ou 'copy-on-write'?) et ça n'est pas intuitif pour un codeur C. La doc du c++ le dit clairement : un référence est implémenté par un pointeur, mais celà doit être caché au programmeur. Je n'aime pas vraiment qu'un langage me cache des choses même si c'est pour mon bien. À chaque fois que j'utilise une chaîne en C++, je ne peux m'empécher de penser : mais va-t-elle être bien désallouée? (mauvaise habitude du C? peut être mais c'est ainsi...)
Ce sont effectivement des choses que l'on peut apprendre et qui deviennent très efficaces une fois maîtrisées, mais ça n'est pas évident lorsque l'on vient du C et que l'on a l'habitude de manipuler des types clairs. Le problème est que Stroustrup a voulu gardé la compatibilité entre le C et le C++, c'est l'un de ses avantage car ça a facilité sa propagation, mais c'est aussi l'un de ses inconveniants, car c'est devenu un langage syntaxiquement crade.
Enfin pour l'aspect objet (je répond aussi au msg dessous), on peut faire de l'objet avec n'importe quel langage, même assembleur. On profitera moins de la syntaxe qui guidera une architecture objet et des vérifications faites par le compilateur, mais ça n'a rien de particulièrement difficile, n'importe quel fichier C++ peut par exemple être entièrement traduit en C.
[^] # Re: Quel langage choisir ?
Posté par M. Vandemar . Évalué à 1.
Tu lis une doc qui ne correspond pas à ce que tu cherches. Il s'agit d'une référence là où il te faut un tutorial ou une documentation basique.
peut être s'agirait-il de la standard library et non de la standard template library? encore une subtilité pas évidente...
Le C++ a pour bibliothèque la Standard Library (SL). La STL c'est SGI. La SL a repris beaucoup de la STL. Il n'y a jamais eu de subtilité particulière.
Quand tu es en C++, tu dois jongler avec les variables dans la pile et dans le tas, les pointeurs et les références
Pas spécialement, on utilise le plus adapté, en évitant les pointeurs au maximum. En C il faut beaucoup plus jongler puisqu'on ne peut pas éviter les pointeurs.
tu passes une classe en argument, mais va tu passer un pointeur ou un bloc de 512 octet?
Il n'y a aucune ambiguïté, que ce soit pour le concepteur ou l'utilisateur.
La doc du c++ le dit clairement : un référence est implémenté par un pointeur, mais celà doit être caché au programmeur. Je n'aime pas vraiment qu'un langage me cache des choses même si c'est pour mon bien. À chaque fois que j'utilise une chaîne en C++, je ne peux m'empécher de penser : mais va-t-elle être bien désallouée?
Manifestement une doc destinée à ceux qui connaissent déjà les pointeurs. Le C++ n'est pas responsable de cette mauvaise explication (une référence s'explique parfaitement sans pointeurs).
À chaque fois que j'utilise une chaîne en C++, je ne peux m'empécher de penser : mais va-t-elle être bien désallouée?
Alors il y a un problème de connaissance du langage, ça ne pose vraiment aucun problème, une chaîne est désallouée dès que l'on sort du scope où elle a été définit, ou dès qu'on détruit l'objet dont elle est un attribut, etc.
Ce sont effectivement des choses que l'on peut apprendre et qui deviennent très efficaces une fois maîtrisées, mais ça n'est pas évident lorsque l'on vient du C et que l'on a l'habitude de manipuler des types clairs.
Les types tableau et chaîne de caractères sont certainement plus clairs et simples en C++. Je crois que le seul problème est la mauvaise foi et le manque de volonté pour apprendre le langage.
Enfin pour l'aspect objet (je répond aussi au msg dessous), on peut faire de l'objet avec n'importe quel langage, même assembleur. On profitera moins de la syntaxe qui guidera une architecture objet et des vérifications faites par le compilateur, mais ça n'a rien de particulièrement difficile, n'importe quel fichier C++ peut par exemple être entièrement traduit en C.
Prétendre que « faire de l'objet en assembleur n'a rien de particulièrement difficile » résume tout. Et avec ça la STL serait peu abordable ? Ces jugements sur la difficulté de l'un et de l'autre sont pour le moins subjectifs...
Ah oui, les cas d'école où on fait de l'objet en n'importe quoi existent. Mais s'il y a des langages orientés objet, c'est bien parce que ce ne sont pas des solutions satisfaisantes.
[^] # Re: Quel langage choisir ?
Posté par M. Vandemar . Évalué à 1.
C++ est nettement plus facile que le C si on suit un bon cours, par exemple inspiré de Accelerated C++. C'est-à-dire quand on apprend les strings, les streams et les conteneurs dès les premiers chapitres, et que des choses plus difficiles à manipuler (comme les pointeurs et l'allocation dynamique) viennent après. Dans ce bouquin par exemple, on voit « * » comme opérateur de déréférencement des itérateurs (cette notion d'itérateur étant bien expliquée) bien avant que les pointeurs soient introduits. Tout simplement parce que ce sont les éléments de base du C++ (les éléments de base ne sont pas du tout ceux du C).
Evidemment le C++ parait moins simple si on ne suit pas un ordre logique dans son apprentissage, par exemple en focalisant trop sur le C. Ce n'est pas forcément un inconvénient de bien connaitre le C quand on fait du C++ mais il faudrait savoir s'en détacher quand l'approche C++ est bien différente.
Et je ne suis pas très convaincu par ce que tu dis quand d'un côté tu trouves la SL (ou seulement la STL) bordélique, et qu'en même temps le C te convient pour faire de l'objet...
# Re: Quel langage choisir ?
Posté par tgl . Évalué à 2.
Ou mieux, si tu pouvais t'incruster dans ce projet pour couper leur bébé en deux (démon/interface), et donc permettre le dévelopement d'autres interfaces par la suite, tu aurais au moins un fan chez les end-users... Mais bon, c'est peut-être complètement en dehors de leur objectifs, aucune idée.
Enfin voilà, qlqs idées au cas où tu ne veuilles pas partir de zéro (ce qui peut être ton souhait ceci dit, ce serait très compréhensible aussi).
# Re: Quel langage choisir ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
# Re: Quel langage choisir ?
Posté par Jiba (site web personnel) . Évalué à 1.
La vitesse de C / C++ n'apporterais rien : pour le démon, c'est GStreamer qui va bouffer la quasi-totalité du temps utilisé par ton programme, et pour l'interface, ce sera GTK.
Par contre Python te permettra de coder beaucoup plus vite qu'en C et donc éventuellement de passer plus de temps à optimiser le code (par exemple des cache à base de dictionnaire, ...).
Pour la base de donnée, tu peux utiliser un dictionnaire, ou un "shelve" (un dictionnaire python par dessus un base de donnée type BSDDB) ; ça sera beaucoup plus simple qu'une base en SQL.
# Re: Quel langage choisir ?
Posté par TSelek . Évalué à 2.
Mais j'avoue ne pas avoir regardé le support de GTk sous ruby, étant plutôt porté Fox et le coté multiplateforme, celà dit ruby est mieux supporté sous Linux que doz.
A voir absolument.
(ruby-lang.org ?)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.