Cher journal,
je m'adresse à toi aujourd'hui, parce que j'ai besoin de tes conseils. En effet ça fait plusieurs années que je pratique le xhtml, css, php et mysql pour créer des applications web dynamiques.
J'aimerais maintenant créer des applications systèmes n'ayant pas besoins d'un navigateur, ou d'un serveur pour fonctionner. Même si la plus part des mes applications se serviront d'une base de données, ou d'une connexion internet. La plus part de mes applications possèderont une interface graphique.
Je cherche donc un langage libre, et utilisable sur les principaux os: gnu/linux, ms windows, et mac os. J'aimerais que ce langage me permette de créer des applications compilées, donc sans devoir utiliser un interpréteur pour que l'application fonctionne.
Quel langage me conseils tu ? le C et C++ ? car à part ceux-ci je ne vois pas d'autres langages possibles pour faire ce que je souhaite.
Journal Quel langage, pour cette utilisation ?
21
nov.
2005
# Original
Posté par Dr BG . Évalué à 5.
Voilà ce qui me passait par la tête. Ensuite, tout dépend du type d'application que tu veux faire.
[^] # Re: Original
Posté par Thomas Douillard . Évalué à 5.
Java aussi peut faire l'affaire, avec un compilateur et gcj par exemple (pour la portabilité sue autre chose que linus, là je sais pas)
Pour ce qui est de l'interface graphique, les toolkits sont souvent disponibles dans pas mal de langages, sauf peut être swing pour java. D'autres ont des langages de prédilectiion, QT le C++ par exemple, mais des Bindings doivent être disponible pour d'autres langages.
J'aurais tendance à déconseiller le C, qui est AMHA un peu dépassé, même si on peut améliorer son utilisation avec de bonnes bibliothèques. Les langages objets sont à mon avis un meilleur investissement.
C'est sympa aussi de voir des langages style OCaml, dans lesquels on peut programmer, en plus de l'iteratif et de l'objet (comme les autres), en fonctionnel, ce qui permet de faire des choses un peu différemment, plus simplement dans certains cas.
Voila, je suis pas sûr de t'avoir aidé, mais le monde des langages compilés se limite pas à C/C++ ;) Au passage, n'importe quel langage est potentiellement compilé, il existe sans doute des compilateurs pour des langages à priori uniquement interprétés.
[^] # Re: Original
Posté par Rodolphe E. . Évalué à 2.
Le jour où y'a plus la structure, y a plus le langage !
Merci ;)
[^] # Re: Original
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
http://www.freepascal.org/
Lazarus si tu veux un ide pour faire une appli rapidement:
http://www.lazarus.freepascal.org/
Un langage comme Python peut se compiler si je ne m'abuse (je commence seulement à m'y intéresser, les spécialistes confirmeront).
Java avec gcj est effectivement un bon choix aussi.
Il y en a tant d'autres ! Tu n'as que l'embarras du choix, il faut tester pour faire son choix... Regardes les pages wikipédia sur les différents langages: les avantages/inconvénients sont souvent décrits.
[^] # Re: Original
Posté par Moonz . Évalué à 9.
Mon avis personnel: Python + PyGTK permet de faire des chose vraiment étonnantes en quelques lignes de code avec un peu d'entraînement. Sous Linux, c'est relativement rapide (tu vas pas faire une application de calculs dessus, mais pour une application "normale", c'est largement suffisant). Sous Windows, tu as py2exe pour failiter la distribution. Bref, c'est le pied
J'ai également pendant un moment fait du GTK(mm/+)/C++, mais une fois que tu as goûté à la souplesse du python, tu ne peux plus t'en passer.
Pour être totalement subjectif, je vais te raconter mon expérience. J'ai eu à faire (pour besoins personnels) une application qui comportait un TreeView structuré de cette manière: 4-5 éléments de base qui contient chacun 1000 éléments fils qui contienent chacun 10 éléments fils. Soient 50 000 élements. J'ai commencé en GTK+/C++ par la méthode bourrin: on remplit tout d'un coup, et on laisse GTK+ se débrouiller avec le dépliage et toussa. Ca ramait à mort, et ça bouffait toute la RAM. Je me suis dit que je devrais calculer uniquement les éléments fils lors du dépliage. Ca ramait environ 2-3 secondes pour les gros dépliages (quand je dit que chaque racine à 1000 éléments, c'est très hétérogène: une en a 500, une autre 3000), mais c'était correct. Mais c'était ingérable en fait. Puis je suis passé en Python+PyGTK et je me suis dit "vu comment ça rame en C++, ça va pas être utlisable". Mais j'ai quand même essayé. Et là ça a été la révélation: grâce à la souplesse de Python, j'ai pu faire en sort que le calcul des sous-éléments se fasse uniquement lors de l'affichage [1]. En fait, contre la lenteur de Python, j'ai largement gagné par le fait que sa souplesse me permettait une architecture très peformante (en C++, ça aurait été facilement 5x plus de classes, méthodes, lignes de codes et erreurs possibles; en C, n'en parlons pas ;)). Ca ne ramait pas au démarrage, quelques millisecondes (à peine visble) aux énormes dépliages (en fait, je me suis permis 10 000 sous éléments et ça a pas ramé plus d'une demi-seconde). Ca saccadait légèrement lorsqu'on descendait rapidement, mais c'était tout.
[1] En entrant dans les détails techniques, je possédais un fichier XML à parser, possédant 5 gros éléments, qui possédaient quelques milliers de sous éléments (variable, de 500 à 10 000 en fait ;)) (qui eux même possédaient des sous éléments, mais ça n'a pas grande importance).
Première architecure: on parse tout, on fait tout dans le TreeView, et basta (ça rame horriblement au démarrage, et je vous explique pas l'occupation mémore...)
Seconde (C++): dès qu'on déplie on élément, alors seulement on crée ses éléments fils. Lorsqu'il y a 500 elems ça va, mais dès qu'on dépasse les 2000, ça rame. Et c'est déjà "lourd" de faire comme ça en C++
Troisième (Python): on dépliant un élément, on lui ajoute le nombre de fils qu'il possède (connus), mais vides: pas la peine de parser et de tout replir. On remplit que ce qui n'est visible, et lorsque la vue change (on scrolle, on redimensionne la fe,être), on renseigne les éventuels nouveaux éléments. Inmaintenanble en C++, une 100aine de lignes en Python, et drolement efficace pour un langage interprété...
Bon, j'arrête là de m'étaler
[^] # Re: Original
Posté par Rodolphe E. . Évalué à 2.
D'ailleur j'aimerais bien savoir comment tu as géré le fait de savoir quel élément du tree view est vu ou non lors d'un redim d'une fenetre par exemple.
[^] # Re: Original
Posté par Moonz . Évalué à 1.
Pour le principe, c'était simplement que lorsque la fenêtre intérieure bougeait, les coordonnée actives du treeview changeaient aussi (j'utilise surement pas le bon vocabulaire, désolé...). Il y a un callback pour surveiller cet événement. Dès que ces coordonnées changent:
- je retire le premier élément (il y a une fonction pour obtenir un élément à partir de ses coordonnées), et le replit
- je remplit l'élement suivant tant qu'il est dans la zone d'affichage (en calculant ses coordonnées)
Ca nécessite uniquement de connaitre la position de l'élément. Je dois l'avouer que ça, je l'ai fait "à l'arrache" (j'ai fais une colonne invisible "position" et je la remplissait dès le dépliage de l'élément parent). Il y avait sûrement plus rapide avec les fonctions de GTK, mais je venais de passer deux jours dans la doc pour réaliser ce que je te décrit, j'en avais marre ;)
[^] # Re: Original
Posté par manatlan (site web personnel) . Évalué à 3.
qques correctifs :
-ironpython est loin d'être mort ... il est juste hébergé chez microsoft directement (jim s'est fait embauché chez ms)... et y a une release toutes les 2 semaines ... mais ça targette dot.net v2
pour un prog "ironpython", y a juste une petite DLL "ironpython" à trimballer avec l'exe, (en plus du runtime dot.net), et c'est bon
[^] # Re: Original
Posté par fmaz fmaz . Évalué à 2.
ET en fonctionnel.
Les deux styles de programmations sont utiles et on ne s'en rend
compte qu'après avoir vraiment goûté aux deux.
Deux exemples (à la con car trop simple):
- pour programmer un produit de 2 matrices, l'approche impérative
me semble très efficace;
- pour programmer un tri, l'approche fonctionnelle a beaucoup plus
de sens.
[^] # Re: Original
Posté par Ontologia (site web personnel) . Évalué à 3.
Lisaac possède une interface graphique, from scratch, multiplateforme. La gestion de l'interface est vraiment simple (une dizaine de ligne pour faire un éditeur simple de texte). Pour le réseau c'est pas encore la joie, mais il suffit de faire quelques binding en C.
Je mettrais bientôt la lib graphique sur le site, quand on aura repris certaines incohérences et décidé de certains choix.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# python
Posté par manatlan (site web personnel) . Évalué à 10.
et puis un jour, j'ai voulu refaire des GUI, des scripts, et des programmes qui renvoi autre chose que des flux ... naturellement j'ai taté le phpgtk, mais ça ne m'a pas trop branché ...
je voulais un langage libre, multi plateforme, puissant et bien documenté (un peu comme le php ;-), en qques sortes) ...
Et c'est tout naturellement que je me suis tourné vers le python ...(et pour l'anecdote, c'est un client bittorrent en python, avec un beau GUI, le tout en 3mo : qui m'a fait tilter, c'est là que j'ai vu que c'était possible)
il existe des LIBS/api pour quasiment tout ce qui est imaginable, ce n'est que du bonheur ...
au jour d'aujourd'hui, je suis un accroc, je ne conçois même plus développer dans un autre langage (car tu peux tout faire avec .... ironpython -> dot.net, et jython -> java) . Même mes applis web "à flux", sont en python ... je suis possédé
il m'a owné, comme on dit ....
[^] # Re: python
Posté par Rodolphe E. . Évalué à 2.
[^] # Re: python
Posté par Louis Nyffenegger . Évalué à 4.
- un peu lent sur les gestions de la BD et pas de gestion bd aussi réutilisable que sous java (jdbc).
- la gestion fine des variables (gestion au niveau du bit) est un peu compliquée
Par contre pour une appli rapide (à créer) et pas trop consommatrice de mémoire , c'est ce qu'il faut : la facilité du perl avec le bonheur de l'objet ;)
[^] # Re: python
Posté par manatlan (site web personnel) . Évalué à 6.
Juste pour qu'il n'y ai pas d'ambiguité ... autant, il est facile d'avoir rapidement un resultat (dev rapide), autant le python permet aussi, pour peu d'être un peu méthodique, de batir des cathédrales ...
le langage étant simple, et plutot assez lisible (à cause de sa structuration innée), permet d'être très scalable aussi ...
pas qu'on associe python a petits développements rapide pour le fun ;-)
[^] # Re: python
Posté par Franck . Évalué à 4.
Une critique toutefois (mais qui n'est pas inhérente uniquement au langage) : la facilité de développement provoque une ré-invention constante de la roue. Peu de standardisation des outils, comme en Java. Un lien intéressant :
http://dirtsimple.org/2005/07/reinvent-no-more-forever.html
[^] # Re: python
Posté par Louis Nyffenegger . Évalué à 3.
Cependant, au bout de quelques miliers de lignes de code, le programme n'est plus accessible à toutes les machines...
Mon plus gros regret est bien sur la gestion des bases de données où il manque vraiment une bonne couche d'abstraction à la jdbc.
Sinon il est vrai que c'est peut-être l'avenir du script (troll : même Microsoft voit que l'avenir du script doit être dans l'objet ;) ), la présence d'objet éclaircit le code et le rend de plus en plus réutilisable mais c'est de plus en plus dur de faire un script diretement sur la ligne de commande.
Pourquoi ma comparaison avec Perl. Perl a tendance avec son "there is more than one way" a généré (chez moi en tout cas) du code difficilement maintenable. De plus la gestion objet de perl est présente mais n'est pas une base du langage comme le sont les listes ou les hachages. Cependant cela reste un excellent langage qui permet de toucher de l'octet au robot web avec énormément de faciliter. De plus, le CPAN est vraiment un gros atout de Perl.
Pour finir, le site de python est python.org (et non .com malheureusement ;) )
[^] # Re: python
Posté par manatlan (site web personnel) . Évalué à 3.
> de données où il manque vraiment une bonne couche
> d'abstraction à la jdbc.
t'as essayé SQLobject ? en matière d'abstraction db, y a pas mieux, non ?
[^] # Re: python
Posté par Mouns (site web personnel) . Évalué à 1.
belle tentative de lancé de troll.
Par contre, une explication précise sur ce point m'interesse. j'ai jamais réellement compris pourquoi python etait plus objet que perl au niveau de sa grammaire ...
[^] # Re: python
Posté par Franck . Évalué à -2.
Parce qu'en perl on sent que la couche objet a été rajoutée à l'arrache ("bénédiction" de tes références pour en faire des objets, c'est rigolo mais bon...)
Parce qu'en Python tout, sans exception, est objet ?
Parce que Python a été pensé comme un langage objet ?
[^] # Re: python
Posté par fredix . Évalué à 10.
Tu confonds avec Ruby
[^] # Re: python
Posté par Charles-Victor DUCOLLET . Évalué à 0.
c'est rare ! la plupart du temps on vois des truc du style : "mon truc a moi il est bien c'est le meilleure, le reste capucestpas(libre/bien/rapide/ergonomique/puissant/etc...)
ca au moins c'est un commentaire vantant les merite de ton outils sans pour autant oublier ses faiblesse !
et ÇA c'est bien !
[^] # Re: python
Posté par wilk . Évalué à 3.
Si ça peut te rassurer je bosse régulièrement sur des grosses bases oracles et postgresql, python ne pose aucun problème particulier... Mais généralement quand on à un problème de perf à cause de "gros résultats sql" c'est que l'analyse n'est pas bonne et qu'il faut déléguer plus de taches au moteur de la bdd.
[^] # Re: python
Posté par TImaniac (site web personnel) . Évalué à -1.
[^] # Re: python
Posté par wilk . Évalué à 3.
Oubien on parle simplement de quantité de données à traiter, mais alors ça n'a rien à voir avec une bdd, d'où l'ambiguité de la question.
Google utilise copieusement python par ex, mais ça ne nous apprend rien sur les perfs de python !
[^] # Re: python
Posté par manatlan (site web personnel) . Évalué à 8.
- en python, tu peux freezer une appli (grouper ses scripts et son runtime, dans un fichier unique, par exemple) pour tous les OS, avec pyinstaller (sinon, py2exe/win, cx_freeze/nux, py2app/mac ...). Avec le widget WX, tu peux avoir un "exe" de 3mo avec du GUI
- avec ironpython, en targettant la clr2 (voire mono), tu peux créer des "exe" (necessitant le runtime dot.net)
- avec jython, tu peux construire tes class java (mais necessitant la jvm)
- et avec shedskin, tu devrais pouvoir produire du binaire sous peu (le projet avance vite)
- sinon la techno "pypy" : python quasiment entièrement interprété en python (le serpent qui se mort la queu), devrait amener à un runtime quasi nulle à terme ...
mais bon l'interprété a plutôt le vent en poupe ...
# C# ou Java.
Posté par TImaniac (site web personnel) . Évalué à -2.
C'est pas interprété, c'est multi-plateforme et c'est plus moderne (et plus productif surtout) que C/C++.
Ma préférence : C#.
http://monofrance.free.fr
[^] # Re: C# ou Java.
Posté par Franck . Évalué à 2.
En plus, SWT a le vent en poupe et permet de réaliser des clients lourds avec widgets natifs.
Et puis Eclipse (à condition de bosser en Java) apporte une productivité jamais atteinte jusque là AMHA.
Quelques lectures sur les designs patterns pour pondre du code bien structuré, et le tour est joué.
Pour la persistance des données, tu peux coupler Hibernate (couche d'abstraction par rapport à toutes les BDD du marché) et XDoclet pour avoir un code du style :
Et hop, tu peux directement et automatiquement sauvegarder tes instances Java en base (mapping objet relationnel). Pratique.
Certains pensent que c'est pas la panacée niveau beauté du code, perso je trouve que c'est un excellent compromis pour ne pas se coltiner des XML de mapping à la main.
Enfin, toujours est-il que pour réaliser des clients lourds multi-plateformes, avec des IHM sympa, Java+SWT est l'idéal. Le nombre d'outils dispo répondront à tous tes besoins tiers.
[^] # Re: C# ou Java.
Posté par TImaniac (site web personnel) . Évalué à 1.
Comme si Java avait inventé quelque chose... En s'appelant C#, Microsoft a au moins le mérite d'avoir choisi de rappeler l'origine du langage.
Certains pensent que c'est pas la panacée niveau beauté du code, perso je trouve que c'est un excellent compromis pour ne pas se coltiner des XML de mapping à la main.
Ahahah, le coup des méta-données pour faire du mapping... Ils l'ont piqué sur qui Java déjà ? :-p
[^] # Re: C# ou Java.
Posté par Dr BG . Évalué à 3.
Je pense qu'il inclut les machines virutelles dans "interpreteurs". Il veut du portable, ok, mais au niveau du code, et qui ne nécessite rien d'installé au préalable.
[^] # Re: C# ou Java.
Posté par TImaniac (site web personnel) . Évalué à 2.
Avec Mono tu peux faire un binaire standalone qui inclu tout ce qu'il faut sans rien de nécessaire au préalable.
[^] # Re: C# ou Java.
Posté par Boke Bocadillo (site web personnel) . Évalué à 1.
j'ai un peu googleisé, mais rien de clair...
Quelles en sont les limites?
[^] # Re: C# ou Java.
Posté par TImaniac (site web personnel) . Évalué à 3.
Limitations ? Que sous Linux, et n'embarque pas Gnome :) Permet en tout cas d'exécuter une appli sans avoir Mono et ses libs d'installé.
[^] # Re: C# ou Java.
Posté par Rémi Hérilier . Évalué à 1.
[^] # A si tu compares a C/C++, forcement...
Posté par Erwan . Évalué à 2.
La principale difference que j'ai vu c'est que la gestion des chaines de characteres ou des listes est nettement plus simple avec Python ou Ruby qu'avec Java ou C#.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par Matthieu Moy (site web personnel) . Évalué à -1.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par Serge Julien . Évalué à 1.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par Sylvain Sauvage . Évalué à 4.
Tu peux aller faire un tour sur http://fr.wikipedia.org/wiki/Langage_de_programmation
http://fr.wikipedia.org/wiki/Typage_fort
http://fr.wikipedia.org/wiki/Typage_statique
http://fr.wikipedia.org/wiki/Typage_dynamique
[^] # Re: A si tu compares a C/C++, forcement...
Posté par Franck . Évalué à 2.
Pas forcément, c'est le charme (ou le défaut, au choix) de Python. Contre-exemple:
[^] # Re: A si tu compares a C/C++, forcement...
Posté par Moonz . Évalué à 1.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par Franck . Évalué à 2.
Des assert au milieu du code c'est particulièrement laid :-)
Une solution intéressante selon moi :
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/4261(...)
Un exemple tiré de la page :
@takes(optional(int, long))
def foo(i = None):
Cela dit le futur Python (nom de code Python 3000 si ma mémoire est bonne) devrait bouleverser tout ça (il me semble avoir lu des articles expliquant la future déclaration optionnelle de types dans les signatures de méthodes).
[^] # Re: A si tu compares a C/C++, forcement...
Posté par TImaniac (site web personnel) . Évalué à 2.
- Méta-données
- Génériques
- Evénements
- Compilation native multi-plateforme
- Typage relativement fort et statique
- Appels bibliothèques natives multi-plateforme et intégré au langage
- De meilleurs perf sans sacrifier la portabilité
- Le versionning des composants
T'en veux d'autre ?
[^] # Re: A si tu compares a C/C++, forcement...
Posté par manatlan (site web personnel) . Évalué à 3.
c'est pas pour feeder un début de trolls ... (et puis on s'est déjà pris la tête dans d'autres posts, on va pas recommencer ;-) ...)
si tu comparais à python, une grande partie de tes "différences" n'en sont pas ... réellement ...
- Méta-données
en python : no prob ...
- Génériques
les "génériques" (terme pompeux de crosoft) sont nativement dans python depuis des lustres (cf ses propriétés de typage dynamique)
- Compilation native multi-plateforme
python compile aussi le py en pyc, c'est natif et multi plateforme ...
- Typage relativement fort et statique
c'est une différence, mais est-ce un avantage ?!?
(d'ailleurs, l'inférence de type dans dot.net (donc mono), c pour la V3 de la clr ;-)
- Appels bibliothèques natives multi-plateforme et intégré au langage
en python aussi ... non ? ;-)
...
je ne crache pas sur mono ou sur dot.net, j'en mange beaucoup au boulot ... et j'en suis même très satisfait, et très content .... pk je peux faire du "python" avec, soit avec boo, soit avec ironpython ;-)
[^] # Re: A si tu compares a C/C++, forcement...
Posté par TImaniac (site web personnel) . Évalué à 2.
Ahahaha. Les génériques ont justement l'avantage de proposer un typage statique pour éviter d'éventuelles couilles à l'exécution et au passage améliorer les perfs. Alors en Python je vois mal, mais alors très mal comment tu vas t'y prendre. Mais vas-y montre moi puisque t'y crois :)
Allez, propose moi par exemple un morceau de code qui me déclare une pile d'entier, et uniquement d'entier. Bien sûr l'implémentation de la pile est générique.
python compile aussi le py en pyc, c'est natif et multi plateforme ...
"pyc is a compiler that compiles python source code to bytecode"
T'as un processeur qui interprête le bytecode Python en natif toi ?
c'est une différence, mais est-ce un avantage ?!?
Là n'est pas la question. C'est en tout cas une grosse différence.
Appels bibliothèques natives multi-plateforme et intégré au langage
en python aussi ... non ? ;-)
Non. Ou alors j'ai jamais vu. Mais je veux bien que tu me montres encore une fois :)
Python n'a peut être pas toutes les diff que j'ai cités, mais il en a la plupart.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par manatlan (site web personnel) . Évalué à 1.
> qui me déclare une pile d'entier
arghhh ... cassé ... tu m'as eu ... brice ...
j'avais oublié le coté statique des génériques ...
> T'as un processeur qui interprête le bytecode Python en natif toi ?
non, mais on peut en dire de même pour le produit généré par mono, ou dot.net ... ce dernier ne peut marcher qu'avec le runtime qui va bien
(tout comme le pyc, marchera, sur plusieurs plateformes, avec le runtime de python adéquate)
>> Appels bibliothèques natives multi-plateforme et intégré au langage
>> en python aussi ... non ? ;-)
> Non. Ou alors j'ai jamais vu. ...
os, string, ... bref toutes les libs faisant partie de "python" (les batteries included, et il y en a pas mal ...)
non ?!?
mais tout le débat, si on continue, va se finir sur le typage static vs dynamic ... alors autant y aller de suite, non ? ;-)
[^] # Re: A si tu compares a C/C++, forcement...
Posté par Moonz . Évalué à 1.
>>> en python aussi ... non ? ;-)
>> Non. Ou alors j'ai jamais vu. ...
>os, string, ... bref toutes les libs faisant partie de "python" (les batteries included, et il y en a pas mal ...)
Je pense qu'il pensait plutôt à une sorte de dlopen. Et oui, c'est possible (à tout hasard, le module dl ? :)). Par contre multiplatforme je vois pas comment c'est possible, vu que les libs natives ne le sont pas... Oui alors c'est moi qui n'ait rien compris ;)
[^] # Re: A si tu compares a C/C++, forcement...
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben avec Mono par exemple, tu peux wrapper OpenGL, et ce sera les mêmes binaires que tu redistribueras sous Linux et Windows. Evidemment OpenGL sera spécifique, mais ton bytecode sera parfaitement portable. Le gros avantage c'est aussi d'assurer l'intégration dans le langage C#, et donc d'avoir toutes les vérifications de type du compilateur et aussi la sécurité d'exécution qui va avec.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par Moonz . Évalué à 1.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par TImaniac (site web personnel) . Évalué à 2.
Sauf que en C# c'est intégré dans la syntaxe, et ca permet d'invoquer directement une lib native sans wrapper nécessitant un langage intermédiaire comme dans la plupart des langages. Je ne connais aucun autre langage qui permette cela de manière portable.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par TImaniac (site web personnel) . Évalué à 2.
:-p
non, mais on peut en dire de même pour le produit généré par mono, ou dot.net ...
Sauf que Mono/.NET est conçu pour être compilé en natif, ce que fait l'environnement d'exécution. Bref, je reste sur mon affirmation, Python/Ruby ne sont pas compilé en natif de manière multiplateforme. Seule Psycho se rapproche de l'idée, en perdant la portabilité (et donc une partie de l'intérêt).
os, string, ... bref toutes les libs faisant partie de "python"
C'est pas la question.
En C#, je peux déclarer :
[DllImport("opengl")]
public static extern void FonctionNative(string arg1, int arg2);
C'est intégré au langage, c'est compilé en code managé, c'est donc portable sans modification et sans avoir à utiliser le langage intermédiaire.
Bref, t'es cassé sur toute la ligne :)
Oui c'est effectivement en bonne partie du au typage, qui empêche Python d'avoir par exemple une gestion du versionning. Bref, c'est pas pareil, et y'a bien de grosses différences, cqfd.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par Moonz . Évalué à 1.
> public static extern void FonctionNative(string arg1, int arg2);
> C'est intégré au langage, c'est compilé en code managé, c'est donc portable sans modification et sans avoir à utiliser le langage intermédiaire.
http://wikipython.flibuste.net/moin.py/CodeWindows#head-3508(...)
Contrairement à ce qui est annoncé, c'est pas limité à l'API Windows. C'est pas véritablement intégré au langage, mais c'est pas non plus plus complexe que ton truc ;) (je trouve même là syntaxe plus propre - mais c'est strictement subjectif, c'est juste que j'ai été traumatisé à vie par la syntaxe [Truc(bidule)] par l'API windows ;)...)
[^] # Re: A si tu compares a C/C++, forcement...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par Moonz . Évalué à 2.
> ctypes allows to call functions exposed from dlls/shared libraries
(sous-entendu: n'importe quelle librairie)
Dans le tutorial, tu as un exemple avec /lib/libc.so.6... Rien à voir avec COM ou ActiveX ;)
[^] # Re: A si tu compares a C/C++, forcement...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par Moonz . Évalué à 2.
def LoadLibraryPath(lib): search_path = os.getenv("LD_LIBRARY_PATH") if search_path is not None: search_path = search_path.split(os.path.pathsep) else: search_path = [] for p in ["/lib", "/usr/lib"]+search_path: if os.path.exists(os.path.join(p, lib+".so")): return LoadLibrary(os.path.join(p, lib+".so"))Maintenant, il n'y a plus qu'à tester os.name et agir en conséquence (j'avoue que je 'lai pas fait parce que je connais pas trop RiscOS, OS/2 et autres systèmes gérés par Python...). Ca m'a pris plus de temps taper le message que le code :) (c'est la faute à templeet...)[^] # Re: A si tu compares a C/C++, forcement...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par manatlan (site web personnel) . Évalué à 2.
mais ce qui m'embete le plus, c justement le "typé statiquement"
[^] # Re: A si tu compares a C/C++, forcement...
Posté par Moonz . Évalué à 1.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: C# ou Java.
Posté par Rodolphe E. . Évalué à 2.
[^] # Re: C# ou Java.
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: C# ou Java.
Posté par Volnai . Évalué à 1.
Nan nan, il reste Objective-C aussi : un lagage objet avec une très bonne API, un très bon IDE, proche du C syntaxiquement, et plein de bonne choses reprises ailleurs (C# reprends les delegates je crois, avec une decennie -au moins- de retard).
[^] # Re: C# ou Java.
Posté par TImaniac (site web personnel) . Évalué à 1.
En même temps les delegates c'est les pointeurs de fonction ala C, c'est pas une innovation qui tue :)
Et puis Objective-C utilise un environnement d'exécution, et visiblement ca ne répond pas aux critères.
# haskell, io ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Comme certains l'ont stipulé, le langage Eiffel est très intéressant et, avec le compilateur smarteiffel 2.0 (même en version béta), on obtient du code natif avec des performances semblables à ceux du C++. La cerise sur le gateau d'Eiffel est évidemment son garbadge collector et sa conception soignée.
Sinon, pour proposer des choses originales, il y a aussi Haskell. C'est un langage fonctionnel pure avec un compilateur natif. Je me suis un jour amusé avec en écrivant une petite appli OpenGL et j'ai été bluffé par ses performances et sa concision. Et il existe de quoquette librairies pour celui-ci. Par contre, il est vrai, il demande un effort pour appréhender son côté fonctionnel.
Sinon, si tu aimes explorer des horizons nouveaux, il y a le langage objet à prototype Io (http://www.iolanguage.com). C'est un langage à VM (à ne pas confondre avec interpréteur). Il est sous licence BSD.
Voilà. (Désolé pour les fautes d'orthographe).
# Ruby ?
Posté par spell (site web personnel) . Évalué à 3.
Encore un petit effort : Ruby : j'aimerais avoir des avis sur Ruby; On en entends parler avec Ruby on Rail pour les applis web, mais pour faire des "vraies" applis ?
Ah oui c'est vrai que c'est interprété donc HS, mais finalement, je me demande si les languages compilés ne vont pas céder le pas aux languages interprétés...
[^] # Re: Ruby ?
Posté par Amand Tihon (site web personnel) . Évalué à 4.
Je ne pense pas.
Autant j'aime beaucoup python (à défaut de connaître Ruby) et trouve PyQt très agréable, autant je suis heureux que KDE ne soit pas interprété :)
[^] # Re: Ruby ?
Posté par fredix . Évalué à 4.
Certe je verrais mal un Gimp en python mais la plupart des applications desktop pourraient être sans problème codé avec un langage script ... Il n'y en a finalement que peu qui ont besoin de la forte réactivité d'un langage compilé bas niveau.
[^] # Re: Ruby ?
Posté par Amand Tihon (site web personnel) . Évalué à 2.
Je crois que si tout KDE (Qt compris ?) était codé en python, personne ne l'utiliserait :)
Des nouveaux modules python, codés au départ en python, sont ensuite recodés en C pour une question de performances.
[^] # Re: Ruby ?
Posté par fredix . Évalué à 3.
http://ruby-gnome2.sourceforge.jp/
Ah oui c'est vrai que c'est interprété donc HS, mais finalement, je me demande si les languages compilés ne vont pas céder le pas aux languages interprétés...
C'est certain dans le domaine des IHM graphiques sous forme interprété ou en bytecode.
Mais ça m'étonnerait pour ce qui est des bibliothèques bas niveau, comme GTK+ ou QT.
[^] # Re: Ruby ?
Posté par Erwan . Évalué à 4.
- Du C ou du C++ pour ecrire les bibliotheques qui ont des traitements couteux
- Du Ruby ou du Python pour "coller" les bibliotheques entre elles et creer des applications
Pour Firefox c'est pareil: du C++ pour les couches basses (Gecko, composants XPCOM), et Firefox est programme en Javascript.
En tout cas, c'est l'approche que j'utilise.
# pkoi pas une appli web ?
Posté par wilk . Évalué à 1.
Si c'est l'installation d'un serveur qui t'embête tu peux très bien créer un exécutable indépendant qui fasse serveur et bdd tout en utilisant le navigateur comme interface graphique.
Par exemple tu peux remplacer avantageusement apache+php+mysql par python+sqlite+py2exe.
[^] # Re: pkoi pas une appli web ?
Posté par Rodolphe E. . Évalué à 1.
Pour le moment je trouve que python est un bon choix !
[^] # Re: pkoi pas une appli web ?
Posté par TImaniac (site web personnel) . Évalué à 3.
Tes choix sont vraiment incompréhensibles :
- tu précises ne pas vouloir d'interprété.
- je te propose Java
- tu veux pas non plus de VM
Conclusion : tu te penches sur Python qui utilise à la fois une VM et qui est interprété (????)
[^] # Re: pkoi pas une appli web ?
Posté par golum . Évalué à 2.
Avec python on freeze et hop (même si l'exe prend 3 Go en RAM).
Ca doit être possible avec Java aussi je pense.
[^] # Re: pkoi pas une appli web ?
Posté par manatlan (site web personnel) . Évalué à 2.
les 10 lignes suivantes suffisent amplement pour réaliser celà :
http://www.bigbold.com/snippets/posts/show/654
au passage, l'accès SQLlite versions ultra simple :
http://www.bigbold.com/snippets/posts/show/653
[^] # Re: pkoi pas une appli web ?
Posté par golum . Évalué à 2.
Fais gaffe quand même ;-)
[^] # Re: pkoi pas une appli web ?
Posté par manatlan (site web personnel) . Évalué à 2.
c'est même moi, avec mes contributions, qui ai fait passé le mot clé "python" au-dessus de ruby ... il y a qques mois ...
après, c karakot qui a grandement surenchéri ;-)
et une première appli, en PYTHON (et pygtk), devrait bientôt voir le jour pour utiliser ces snippets ;-)
# ObjectiveC++
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je ne sais pas si l'ObectiveC++ est déjà intégré dans la branche principale de gcc. Si oui, c'est à mon avis un choix intéressant. L'ObjectiveC est à la base de Java qui est lui même à la base de C#. Son modèle object est très souple pour les IHM.
Avec l'ObectiveC++, le modèle MVC peux prendre toute son ampleur. Le modèle en C++ pour la vitesse et la vue en ObjectiveC pour sa souplesse et la cohérence de ses classes graphiques.
Sinon, peu présent sur linuxfr et que je n'ai jamais utilisé mais /a priori/ robuste, il y a aussi Pike qui est un langage de script avec un syntaxe "a la C".
# Personne ne parle de QT
Posté par olympien . Évalué à 2.
[^] # Re: Personne ne parle de QT
Posté par TImaniac (site web personnel) . Évalué à 2.
# Et Ada dans tout ca on en fait quoi?
Posté par totof2000 . Évalué à 3.
En plus linux magazine publie actuellement des articles sur Ada (A quand un hors serie reprenant tous les articles Ada?).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.