#101 Le 26/03/2010, à 16:06
- no_spleen
Re : Petit guide pour aider au choix d'un langage
Le fichier de maillage est trops gros à poster !
Hors ligne
#102 Le 26/03/2010, à 17:09
- tshirtman
Re : Petit guide pour aider au choix d'un langage
un code permettant de générer un fichier de ce type alors? 
je vais regarder ton code voir si je voit quelque chose de choquant pour les perfs, et éventuellement passer par CProfile pour voir les bottleneck…
Malheureusement, cela n'a pas l'air ce changer quoi que soit chez moi.
bizarre 
3) Je vais installer python 3 pour voir !
python3 est plus lent que python2.6, pypy est plus intéressant de ce coté là par contre.
http://speed.pypy.org/
Dernière modification par tshirtman (Le 26/03/2010, à 17:11)
Hors ligne
#103 Le 26/03/2010, à 18:40
- Le Farfadet Spatial
Re : Petit guide pour aider au choix d'un langage
Salut à tous !
Bon, les résultats ne m'étonnent pas, c'est effectivement ce sur quoi j'étais resté. Ce n'est pas surprenant : Python n'a pas du tout été créé dans un objectif de calculs intensifs. Cela dit, tous les langages qui ont vraiment fonctionné étaient des langages qui avaient un objectif en vue et qui se sont attachés à l'atteindre plutôt qu'à vouloir être le langage parfait pour tout.
Je n'oublie pas le code C++, ça va venir vite.
À bientôt.
Le Farfadet Spatial
Hors ligne
#104 Le 26/03/2010, à 19:00
- tshirtman
Re : Petit guide pour aider au choix d'un langage
Le but auquel le python s'attache est la clareté, et le dynamisme, l'universialisme de son offre découle plus de sa popularité que d'un but réel de sa conception.
Hors ligne
#105 Le 26/03/2010, à 22:35
- Le Farfadet Spatial
Re : Petit guide pour aider au choix d'un langage
Salut à tous !
Le but auquel le python s'attache est la clareté, et le dynamisme, l'universialisme de son offre découle plus de sa popularité que d'un but réel de sa conception.
À mon sens, le but de Python, c'est de créer efficacement et proprement des automates et de gérer efficacement les entrées-sorties, ainsi que tout ce qui est traitement de fichiers et ce qui s'y rattache (de manière très générale). Par extension, son domaine porte aussi sur les interfaces graphiques. Tout cela fait qu'il se combine très bien avec des langages tels que C++ pour réaliser des applications ambitieuses. Dans sa conception, le parti a été pris de lui faire supporter un grand nombre de paradigmes -- impératif, fonctionnel, objet, modulaire et d'autres. Par réaction à Perl, qui est parfois ésotérique, l'accent a été mis sur la clarté et pour cela il y a eu une forte inspiration de Haskell.
De part sa conception, il s'agit d'un langage interprété (même s'il existe des compilateurs just in time), ce qui le rend impropre à l'informatique haute performance, mais il faut d'abord se souvenir que la majorité des applications ne sont pas des applications à hautes performances, d'une part. D'autre part le fait que le langage soit interprété donne une grande souplesse, notamment cela permet à Python d'autoriser la méta-programmation dynamique, c'est-à-dire l'écriture de programmes qui changent au court de leur exécution, par opposition à la méta-programmation de C++, qui est statique (le programme ne change que pendant la phase de compilation).
Par contre, je ne conseillerais pas Python pour l'embarqué, à mon sens ADA est plus approprié. De toute façon, je ne donnerais pas le qualificatif d'universel à Python, mais des langages à vocation universelle, il y en a eu beaucoup et à chaque fois il s'agissait d'usines à gaz inutilisables en pratique. C'est donc plutôt une bonne chose que Python ne soit pas universel.
À bientôt.
Le Farfadet Spatial,
qui devrait réaliser le
code C++ ce week-end.
Dernière modification par Le Farfadet Spatial (Le 26/03/2010, à 22:36)
Hors ligne
#106 Le 27/03/2010, à 01:35
- tshirtman
Re : Petit guide pour aider au choix d'un langage
par opposition à la méta-programmation de C++, qui est statique (le programme ne change que pendant la phase de compilation).
d'ou la quasi non usabilité des templates…
mais oui, pour le haute performance, le dynamisme est un frein sérieux, le just in time permet de rattraper une partie de la perte, mais il est évident que par construction, ça ne peut pas être aussi performant…
Hors ligne
#107 Le 27/03/2010, à 08:07
- Le Farfadet Spatial
Re : Petit guide pour aider au choix d'un langage
Salut à tous !
par opposition à la méta-programmation de C++, qui est statique (le programme ne change que pendant la phase de compilation).
d'ou la quasi non usabilité des templates…
Les modèles sont parfaitement utilisables. D'abord, tu n'es pas obligé de faire de la méta-programmation pour utiliser les modèles. Ensuite, Boost, par exemple, montre bien que la méta-programmation est parfaitement exploitable, certes au prix d'une lisibilité un peu délicate. Tu as parfaitement le droit de détester C++, mais ton affirmation est objectivement fausse.
À bientôt.
Le Farfadet Spatial
Hors ligne
#108 Le 27/03/2010, à 10:05
- no_spleen
Re : Petit guide pour aider au choix d'un langage
Pour obtenir le maillage, il faut installer le logiciel gmsh (il est dans les dépots). Voici un fichier a nommer lit.geo et ensuite en ligne de commande
gmsh lit.geo -3ce qui va générer le maillage lit.msh
Point(1) = {0, 0, 0, 0.1};
Point(2) = {0.009299999999999999, 0, 0, 0.1};
Point(3) = {0.0373, 0, 0, 0.1};
Point(4) = {0.056, 0, 0, 0.01};
Line(5) = {1,2};
Line(6) = {2,3};
Line(7) = {3,4};
Extrude {{0, 0, 1}, {0, 0, 0}, Pi/4} {
Line{5, 6, 7};
}
Extrude {{0, 0, 1}, {0, 0, 0}, Pi/4} {
Line{8, 11, 15};
}
Extrude {{0, 0, 1}, {0, 0, 0}, Pi/4} {
Line{19, 22, 26};
}
Extrude {{0, 0, 1}, {0, 0, 0}, Pi/4} {
Line{37, 33, 30};
}
Extrude {{0, 0, 1}, {0, 0, 0}, Pi/4} {
Line{41, 45, 49};
}
Extrude {{0, 0, 1}, {0, 0, 0}, Pi/4} {
Line{52, 56, 60};
}
Extrude {{0, 0, 1}, {0, 0, 0}, Pi/4} {
Line{71, 67, 63};
}
Extrude {{0, 0, 1}, {0, 0, 0}, Pi/4} {
Line{74};
}
Extrude {{0, 0, 1}, {0, 0, 0}, Pi/4} {
Line{77};
}
Extrude {{0, 0, 1}, {0, 0, 0}, Pi/4} {
Line{81};
}
Physical Surface(96) = {40};
Physical Surface(97) = {29};
Physical Surface(98) = {18};
Physical Surface(99) = {95};
Physical Surface(100) = {84};
Physical Surface(101) = {66};
Physical Surface(102) = {55};
Physical Surface(103) = {44};
Physical Surface(104) = {48};
Physical Surface(105) = {36};
Physical Surface(106) = {25};
Physical Surface(107) = {14};
Physical Surface(108) = {91};
Physical Surface(109) = {80};
Physical Surface(110) = {70};
Physical Surface(111) = {59};
Physical Surface(112) = {51, 32, 21, 10, 87, 76, 73, 62};
Extrude {0, 0, 0.4} {
Surface{55, 44, 40, 29, 18, 95, 84, 66, 59, 48, 36, 25, 14, 91, 80, 70, 62, 51, 32, 21, 10, 87, 76, 73};
}
Physical Surface(601) = {125,213, 279, 257, 235, 213, 191, 169, 147};
Physical Surface(602) = {134, 156, 178, 200, 288, 266, 244, 222, 310, 332, 354, 376, 398, 420, 442, 481, 498, 515, 532, 549, 566, 583, 600, 464};
Physical Volume(603) = {7, 6, 14, 15, 8, 1, 2, 3, 4, 5, 13, 12, 11, 10, 9, 16, 17, 24, 23, 22, 21, 20, 19, 18};Hors ligne
#109 Le 01/04/2010, à 23:29
- tshirtman
Re : Petit guide pour aider au choix d'un langage
je vient de me dire qu'il faudrait peut être que je fasse un retour là dessus. J'ai généré le fichier mesh, mais si je ne m'abuse il manque le fichier linear_system.py pour tester…
Hors ligne
#110 Le 02/04/2010, à 00:18
- Le Farfadet Spatial
Re : Petit guide pour aider au choix d'un langage
Salut à tous !
Flûte : je me suis laissé avoir par le « je le ferais plus tard ». Bon, il faut que je m'occupe de la version C++.
À bientôt.
Le Farfadet Spatial
Hors ligne
#111 Le 02/04/2010, à 06:44
- no_spleen
Re : Petit guide pour aider au choix d'un langage
Bonjour, je le poste dans la journée !
Hors ligne
#112 Le 02/04/2010, à 08:28
- no_spleen
Re : Petit guide pour aider au choix d'un langage
Voici le fichier linear_system. C'est une classe gérant les systèmes linéaires, basée sur le module pysparse.
Comme tu as cité Cprofile, je me suis renseigné et j'ai un peu testé. Pour expliquer les résultats il faut que j'explique un peu ce qui se passe dans le code.
Les degrés de liberté (les inconnues) sont définis dans la classe dofkey. Ce sont en fait un couple entre un noeud (de la classe node) et un string désignant le nom de l'inconnue. La classe dof_manager gère ces degrés de libertés, en créant deux dictionnaires. Un dictionnaire self._fixed qui est la liste des degrés de libertés fixés (par exemple, on sait que sur une paroi la vitesse est nulle), et le dictionnaire self._numbering qui est la liste des ddl que l'on va réellement calculer.
Quand on va faire une opération, le dof_manager va vérifier si l'on parle d'un ddl fixé ou non, et réaliser l'action adéquate, ce qui se traduit par exemple par ce bout de code
def numberVertex(self,node,name):
dof = dofkey(node,name)
try:
a = self._fixed[dof]
except KeyError:
self._numbering[dof]=(len(self._numbering))qui est la fonction ajoutant un ddl à la liste des ddl à calculer. Avant de l'ajouter, on vérifie si ce n'est pas un ddl fixé, car dans ce cas on ne le rajoute pas.
Et voila ou je voulais en venir. En faisant un cProfile, j'ai remarqué que la plus grosse partie du temps perdu l'est dans les comparaisons entre degrés de libertés (fonction __eq__ de la classe dofkey), c'est à dire à mon avis à chaque fois qu'il faut chercher un ddl dans les dictionnaires (puisque à mon avis, quand in cherche un élément dans un dictionnaire, il fait une boucle sur les clés et appelle la fonction __eq__ non ?)
from pysparse import spmatrix,superlu,itsolvers
from numpy import *
import psyco
psyco.full()
class linear_system :
"""
Linear system class based on pysparse
"""
def __init__(self,n):
self._a = spmatrix.ll_mat(n,n)
self._xold = array(zeros(n))
self._xnew = array(zeros(n))
self._b = array(zeros(n))
def addToMatrix(self,r,c,val):
self._a[r,c] += val
def getFromMatrix(self,r,c):
val = self._a[r,c]
return val
def fixInMatrix(self,r,c,val):
self._a[r,c] = val
def zeroMatrix(self):
self._a[:,:] = 0.0
def addToSolution(self,r,val):
self._xnew[r] += val
def getFromNewSolution(self,r):
val = self._xnew[r]
return val
def getFromOldSolution(self,r):
val = self._xold[r]
return val
def fixInSolution(self,r,val):
self._xnew[r] = val
def zeroSolution(self):
seld._xnew[:] = 0.0
def addToRHS(self,r,val):
self._b[r] += val
def getFromRHS(self,r):
val = self._b[r]
return val
def fixInRHS(self,r,val):
self._b[r] = val
def zeroRHS(self):
self._b[:] = 0.0
def solve(self):
#LU = superlu.factorize(self._a.to_csr())
#LU.solve(self._b,self._xnew)
itsolvers.pcg(self._a.to_sss(),self._b,self._xnew,1e-12,2000)
def getOldSolution(self):
return self._xold
def getNewSolution(self):
return self._xnew
def swichSolution(self):
self._xold = self._xnewHors ligne
#113 Le 06/04/2010, à 01:21
- Le Farfadet Spatial
Re : Petit guide pour aider au choix d'un langage
Salut à tous !
J'ai en ce moment de gros problèmes matériels. En conséquence, je n'ai pas pu avancer sur le code et je risque de ne pas pouvoir le faire avant quelques temps.
À bientôt.
Le Farfadet Spatial
Hors ligne
#114 Le 19/04/2010, à 16:24
- Foromus
Re : Petit guide pour aider au choix d'un langage
Bonjour,
J'ai lu avec intérêt et attention tous les commentaires depuis la création de cette discussion.
Je me considère comme "débutant", même si j'ai pas mal programmé en VB et que, tout récemment, je viens de découvrir Gambas (qui n'est pas la même chose, même si il y a des éléments communs ou ressemblants). En effet, j'ai quitté Win il y a deux ans ou presque, et je suis maintenant sous Ubuntu.
En tant que néophyte, je suis réellement décontenancé par ce que j'ai lu.
Bon, le mieux, dites-vous, c'est d'oublier Basic, et ce qui y ressemble : Fort bien. Il est probable que pour des programmes d'importance, et éventuellement professionnels, le basic ne tienne peut-être pas le haut du pavé.
A un moment, j'avais abordé Python, vu l'éloge qui en était fait. Compte-tenu de l'éloge encore une fois mentionné ici, je me suis dit que je devrais regarder sérieusement la chose, car, malheureusement, j'ai absolument tout oublié du peu que j'avais appris sur le sujet. J'ai téléchargé le pdf recommandé (A Byte of Python - version française du 12-01-2010), et je l'ai lu. Soucieux de trouver un éditeur à la hauteur, j'ai installé ce que j'ai trouvé dans la bibliothèque Ubuntu, à savoir "EricPython".
Bien, j'ai lu le bouquin, j'ai essayé (timidement) de faire quelque chose dans mon éditeur, rien ne s'est passé...
Enfin, et d'après ce que j'ai cru comprendre, ça marche essentiellement en console. Bien entendu, il est possible de mettre du graphisme, mais cela fait l'objet d'un autre bouquin il me semble.
A ma grande honte, je dois avouer que le fait de mettre un bouton sur une page, et de remplir la procédure y afférente me plaisait bien aussi. Et surtout, je trouvais ça pratique. Là, si je veux écrire "Hello Word" au milieu de la page en cliquant sur un bouton, je ne vois pas, pour l'heure, comment je pourrais faire.
La console, c'est bien. Par exemple, quand je veux lire un fichier codé, je vais dans la console, je tape ccrypt-d et j'ajoute le chemin du fichier concerné, je rentre le mot de passe, et je peux ouvrir le fichier. Une fois consulté, je refais l'opération, et mon fichier est à nouveau codé. Sous Win, je faisais un clic droit sur mon fichier, le menu contextuel me proposais "déchiffrer", un clil, le mot de passe, et je pouvais ouvrir mon fichier. Le simple fait de le refermer le codait. Je suis désolé, mais je trouvais ça plus pratique, beaucoup plus rapide et moins fastidieux.
J'en déduis donc, à la lecture de toutes ces informations, que le sujet est proposé à des gens qui se destinent vraiment à la programmation, et qui ont des choses conséquentes à faire. Dans ce cas de figure, on pourrait supposer qu'ils ont déjà un minimum de connaissances en informatique, et par conséquent, ils sont probablement en mesure de faire un choix qui leur convient.
Voilà, c'était l'avis d'un "candide" !
Je reste très content d'avoir lu tout ça, j'ai acquis une bonne culture générale sur le sujet.
Je souhaite une bonne réussite à tous les aspirants programmeurs !
#115 Le 19/04/2010, à 16:53
- Le Farfadet Spatial
Re : Petit guide pour aider au choix d'un langage
Salut à tous !
Voilà, c'était l'avis d'un "candide" !
Un tel avis est important, vu que c'est la première cible. Donc, merci d'avoir posté ton avis.
Cela dit, les manipulations graphiques que tu as données m'apparaissent bien fastidieuses, je trouve que ça prend trop de temps.
En général (on peut trouver des cas particuliers), le programmeur qui a de la bouteille sous un système Unix, mais également quelqu'un d'habitué à donner des cours de programmation est très réticent à commencer par la partie graphique, parce que cela détourne de l'essentiel et pousse à se focaliser sur des détails.
Toutefois, lorsque l'on veut créer une interface graphique, il est en effet préférable d'avoir recours à un outil de construction d'interface graphique, par exemple Glade pour Gtk+. Cela dit, mon avis est que la construction d'interface graphique ne devrait pas être la première chose à présenter à un débutant en programmation, quel que soit ce qu'il entend réaliser par la suite.
Cela dit, à te lire, j'ai l'impression que ce n'est pas tant le choix du langage qui te pose problème, que la façon dont son enseignement est dispensé.
Bon, puisque je t'ai sous la main : dans ton cas, que veux-tu faire en programmation ?
À bientôt.
Le Farfadet Spatial
Hors ligne
#116 Le 19/04/2010, à 17:54
- tshirtman
Re : Petit guide pour aider au choix d'un langage
il existe de nombreuses bibliothèques de widgets disponibles en python (les widgets c'est les fenetres, les boutons, les cadres, les onglets, tout ce qui fait une interface gaphique moderne), on cite en général GTK, QT, WXwidgets, et en python, TK (qui viellit, mais est facile à aborder), cependant, il est en effet plus pratique d'utiliser un logiciel pour créer son interface (glade est très bien) et lui relier les fonctions. Enfin si tu veux quelque chose de bien intégré pour créer des applications python/gnome sans te prendre la tête, quickly (présent dans les dépots) pourrait te plaire. Tu sera lancé assez facilement normalement. (glade est intégré à l'ensemble).
Mais bon après faire des applications modernes ça demande quand même un minimum d'apprentissage sur ce qui se fait. Enfin VB et Gambas sont certes des environnements simples pour créer des petites applications (jetables, souvent), mais ne sont pas, en effet efficace pour faire des projets plus solides.
Hors ligne
#117 Le 20/04/2010, à 11:20
- Foromus
Re : Petit guide pour aider au choix d'un langage
Bonjour,
Merci d'avoir pris mon avis en considération, même s'il ne présente pas grand intérêt.
""""dans ton cas, que veux-tu faire en programmation ?""""
Rien de spécial ! Désolé de vous décevoir...
Programmer me plaît bien : ça entretient un peu l'esprit, ça fait fonctionner le cerveau.
Mais encore faut-il avoir un but...
Sans raconter ma vie, je dirais que j'ai commencé avec le ZX81 : 1K° de mémoire (oui, un seul petit kilo !), mais avec une extension de 16k°, quel pied, et une télé comme écran et un petit magnéto à K7 pour le stockage de masse...
Ensuite, je suis passé sous un Apple : 48K° de mémoire, mais avec une carte de 16 K° supplémentaires, j'ai pu commencer à utiliser mon premier tableur, et un traitement de texte ! Tout ça pour dire que le ZX fonctionnait avec son basic propre, et l'Apple aussi avec quelque chose qui devait s'appeler EditBasic ou quelque chose du genre. Vous conviendrez donc que si je voulais écrire Bonjour le Monde au milieu de l'écran, il fallait que je me débrouille tout seul. J'ai tout appris tout seul, par des livres et par le vécu, je n'ai jamais eu de profs, c'est peut-être une raison qui fait que je suis assez peu réceptifs aux conseils des autres, et c'est probablement pour ça aussi que je me fais régulièrement rabrouer dans les forums, à tel point que j'ai abandonné le site de Gambas tellement je me suis fait laminer. J'ai à peu près vécu la même chose ici quand je suis passé sous Ubuntu, ma façon de comprendre et d'apprendre ne convenant pas à ceux qui "ont le savoir". Bref, j'ai été assez rudement traité, mais j'ai fini par arriver à me servir un peu d'Ubuntu (mais il est évident que je ne dois l'utiliser qu'à 5 ou 10 %..).
Cette parenthèse étant fermée, je ne reste pas sectaire puisque l'auteur de cette discussion cherche à savoir, ce qui est tout à fait à son honneur.
J'ai fait des choses en Visual Basic, et si ce n'est pas le langage le plus performant, je suis quand même arrivé à faire un logiciel avec des milliers de lignes de code et j'ai utilisé la plupart des fonctions proposées. Au passage, j'ai sincèrement admiré la simplicité de Python pour le peu que j'en ai vu.
Pour donner un exemple précis, en VB, j'ai aussi fait un programme d'apprentissage du clavier français. A chacun son truc, moi, quand je vois des gens frapper le clavier en regardant où ils posent leurs deux index, francehment, ça m'énerve ! Moi quand je tape, je regarde ce qui s'inscrit sur l'écran, à la rigueur, je regarde ce que je veux recopier, je trouve ça plus rationnel que de regarder mes index ou mes huit autres doigts...
Donc, dans un premier temps, j'aurais aimé retranscrire dans un langage autre que VB ce programme, de manière à ce qu'il tourne sous Linux. Opération totalement gratuite, vous l'aurez compris, puisque l'usage personnel de ce logiciel n'est plus vraiment nécessaire, encore que, comme dans toute discipline, il faut toujours s'entraîner. Mon programme comporte 20 leçons, il analyse les erreurs, les comptabilise, donne un coefficient de réussite (100 - vitesse de frappe / erreurs) (je ne me souviens plus exactement de la formule que j'avais établie à l'époque) , on peut enregistrer ses scores, l'enregistrement n'est proposé que quand le score obtenu est meilleur que ce qui est déjà enregistré. Naturellement, tous les utilisateurs peuvent avoir leur propre dossier, ça tombe sous le sens. On peut tout paramétrer au niveau de la présentation, on peut activer ou non des infobulles sur les touches du clavier représenté, et le texte de l'exercie est affiché dans une fenêtre qui change de couleur juste après la frappe, le modèle à travailler étant dans une fenêtre juste au-dessus. Alors, je veux bien que le graphisme ne soit pas du premier intérêt, mais je ne vois pas comment je pourrai réécrire ce programme en Python, tout au moins, avec le peu que j'en ai vu jusqu'alors.
Je voudrais aussi répondre au fait que la programmation doit commencer avec les bases et ne pas s'embarrasser du graphisme qui écarterait des bases et détourerait l'attention, cela pouvant conduire à une éventuelle dissémination de l'esprit. Fort bien, dont acte. Cela dit, quand j'ai étudié le VB avec un livre - j'ai eu la chance de tomber sur un bon, ce qui reste exceptionnel, j'ai appris certes le graphisme, j'ai aussi appris ce qu'était une procédure, une fonction, une variable - fut-elle locale ou globale, j'a aussi appris toutes les commandes, les instructions, boucles, tableaux, débranchements, fichiers et je n'ai pas un seul instant senti que le graphisme gênant d'une manière ou d'une autre. Maintenant, on peut aussi considérer que toutes les bases auxquelles vous faites allusions, je les ai déjà un peu tutoyées dans mon utilisation précédente de mon Apple, je me souviens qu'à l'époque, je m'étais construit un logiciel professionnel - j'étais artisan à l'époque, et qui gérait mes factures (clients et fournisseurs), la gestion de mes pièces détachées, imprimait mes factures et faisait même mes lettres de rappel ! Et tout ça, sans graphisme, naturellement !
Ceci m'amène à réitérer mon avis à propos des aspirants programmeurs, et je crois sincèrement que ceux qui envisagent de se mettre à la programmation ont déjà une expérience réelle et suffisante de l'informatique pour pouvoir déjà avoir une idée de leurs choix possibles. Mais je me répète encore, une discussion comme celle-ci est très utile car elle donne une bonne vue d'ensemble sur les différents langages, j'avoue pour ma part que des choses comme Perl ou C++, pour moi, c'est de l'hébreu, et si j'avais un programme important à faire, je crois que je trouverais matière à creuser.
Bien, mais comme j'approche des mes 70 ans, je n'ai plus vraiment de grandes réalisations à faire !
Mais je vais continuer à lire ce fil avec intérêt !
#118 Le 20/04/2010, à 14:08
- Le Farfadet Spatial
Re : Petit guide pour aider au choix d'un langage
Salut à tous !
Bon, Foromus, tu reconnaîtras aisément, je pense, que tu restes un cas assez atypique.
Oui, les premiers micro-ordinateurs, depuis l'Altair, ont été livrés avec Basic. Cela dit, avec le recul, il faut reconnaitre que ce langage pousse à utiliser des pratiques de programmation rendant les programmes difficiles à déboguer et à maintenir, en plus de problèmes de performances. Raison pour laquelle nombreux sont ceux, dont je fais partie, qui, s'ils reconnaissent l'intérêt qu'a eu Basic, le déconseille maintenant au vu de l'offre disponible.
Concernant le choix d'un langage, oui, je pense que quelqu'un qui se lance aura tendance à avoir une certaine expérience de l'informatique. Toutefois, le présent fil de discussion est né de la démultiplication sur le forum des messages demandant quel langage choisir et d'une demande des intervenants du forum.
Au sujet des interfaces graphiques, le problème c'est que, très (trop) souvent, on voit des débutants se lancer dans la réalisation d'une interface avant, d'une part, de vraiment avoir déterminé ce qu'ils voulaient coder, d'autre part avant même de savoir programmer. Le résultat est la création d'une interface qui ne fonctionne pas, ne sert à rien et un découragement du dit débutant. Commencer par des petits programmes en mode console est plus simple, plus rapide, permet de voir facilement le résultat et évite de s'atteler tout de go à des problèmes qui demandent de la minutie.
Cela dit, dans ton cas, je pense en effet que tu aurais intérêt à te pencher sur Python, ainsi que Gtk+ et Glade. Tout cela te permettrait de réaliser une nouvelle version de ton programme à la fois maintenable et efficace, ceci assez facilement (même si la logique est différente de celle de Basic). En revanche, cela nécessitera de remettre en question ce que tu penses savoir de la programmation.
À bientôt.
Le Farfadet Spatial
Hors ligne
#119 Le 20/04/2010, à 16:08
- tshirtman
Re : Petit guide pour aider au choix d'un langage
@Foromus: je cerne un peu mieux ton expérience, tu as programmé au quotidien, en autodidacte, depuis très longtemps, avec des outils qui ne sont pas les meilleurs, mais sont assez facile a appréhender pour s'y mettre en autodidacte (je suis passé par là aussi), alors certes, se passer du basic quand on a connus que ça est assez difficile, car en effet il rends très simple à faire les choses simples, mais compliqué les choses complexes. Beaucoup de langages font le choix inverse, considérant que ce n'est pas grave de complexifier l'apprentissage de la base, si c'est pour fournir des outils bien plus puissant, et donc permettre de réaliser plus simplement des choses très complexes.
Python est (à mon sens) l'un des rares langages à permettre plusieurs niveaux de complexités, tout en gardant une simplicité de réalisation assez simple. Ce n'est pas le langage parfait (qui n'existe pas) mais il est bon. Si l'anglais n'est pas un problème pour toi (je suppose vu que tu programme depuis longtemps) je te conseil de regarder du coté de quickly pour te lancer, ils expliquent comment commencer facilement un projet en gtk/glade/python, après un temps d'adaptation tu devrais t'en sortir je pense 
.
Hors ligne
#120 Le 29/04/2010, à 16:44
- Foromus
Re : Petit guide pour aider au choix d'un langage
Bonjour,
Voilà, je ne voudrais pas abuser de mon temps d'antenne, mais vu que la conversation se tarit un petit peu, j'en profite pour rajouter un petit grain de sel...
D'abord, accordez-moi cette justice que je ne suis pas borné au basic. Aurais-je laissé penser cela ?
Partir de l'apprentissage complexe pour arriver à faire facilement des choses complexes me semble une excellente démarche. Prenons par exemple, l'apprentissage de la musique : une école préconise de faire faire 4 ans de solfège à l'apprenant, avant de lui laisser toucher un instrument. Une autre école préconise de d'abord donner un instrument, et parallèlement, l'apprenant devra acquérir les notions indispensables. Comme on peut s'en douter la première méthode produit un nombre considérable de déchets, apprendre le solfège peut parfois manquer d'intérêt, d'autant que cela concerne des règles rigides, pures et dures et incontournables. C'est peut-être pour ça que je fais le lien avec la programmation. Concernant la seconde méthode, les déchets sont carrément ahurissants, il n'y a pratiquement aucune réussite, et pire, l'apprenant peut éprouver un dégoût profond qui le fera renoncer à jamais, ce qui n'est pas le cas de la première méthode : le jour où l'apprenant aura compris la nécessité du solfège avant l'instrument. Remarquez, on s'en serait douté : serait-ce raisonnable de confier un livre de philo à un illettré en lui proposant d'apprendre à lire en même temps qu'il apprendrait la logique formelle ?
Pour revenir à Python, dont on me vante ici les grands mérites - ce dont je ne doute pas, je m'y mettrai peut-être un jour... Je viens de relire quelques passages du livre recommandé et déjà mentionné. Première déclaration : Python est simple... Ah bon ?.... Voyons voir....
Prenons une variable : pas besoin de la déclarer, la déclaration se fait au moment de l'emploi (si j'ai bien compris, ce qui n'est pas sûr....). Ensuite, pour une numérique, il y a 3 types : entier, flottant, imaginaire. Fort bien, je ne me souviens pas que la troisième catégorie fut présente dans les basics, mais je ne l'ai pas forcément vue. C'est vrai que ça change entre la byte, le integer, le float, le long, le super long et je ne sais plus quoi...Donc, Python serait plus simple. Pas forcément pour moi....
Quand je programme, il m'arrive encore de déclarer des numériques en Byte. Il y a probablement là un vieux réflexe d'une époque où l'on avait à cœur d'utiliser au mieux la ressource, le gaspillage n'était pas de mise, pas à la mode. Il en est tout autrement maintenant, la mémoire ne coûte plus rien, le µ pédale à 3 ou 4 GHz, que demande le peuple ? Et tout le reste est à l'avenant : on prend 5 douches par jour, on met à la poubelle, etc, je ne veux pas déborder, sachant que chaos qui nous attend fera tomber de haut une génération déboussolée par l'excès...
Pour revenir aux déclarations : il est clair que lorsqu'on commence à avoir un programme d'importance - même au stade de projet, il est totalement absurde de foncer dans le code avant d'avoir établi au moins les grandes lignes : avant de coder, il faut au minimum avoir rédigé sa trame ! (Et c'est peut-être là la mise en garde mentionnée plus haut). Il faut aussi, et c'est un minimum, prévoir ses variables. Le mieux est encore de les écrire, ne serait-ce pour pouvoir retrouver à quoi elles correspondent plus tard, de même que pour les définir, ce qui peut éviter pas mal d'erreurs d'incompatibilité. Les écrire d'abord (sur un papier ou sur un fichier texte - la première solution étant de loin la meilleure) est certainement la chose à faire bien avant le codage. Que l'on fasse du code pour "essayer" tel ou tel commande ou contrôle me parait logique, foncer tête baissée me le semble beaucoup moins...
Bon, je reviens à Python.
Qui utilise les nombres imaginaires dans son quotidien, même si il est programmeur ? Je conçois que peut-être, un scientifique ou quelqu'un qui veut faire des polices vectorielles ou du dessin du même type soit adhérent, pour le reste du commun des programmeurs, ce n'est pas l'outil qu'il doit obligatoirement tenir sous une patte de sa souris. Par ce que, là aussi, il faut se demander ce qu'on va faire avec la programmation que l'on souhaite apprendre. J'ai comme l'impression que l'on fait rarement un apprentissage comme ça, gratuitement, en général, c'est pour donner suite à un souhait ou un besoin, fut-il d'ailleurs simplement ludique !
Je voulais aussi parler d'une autre chose vue dans Python, et qui se réclame de la simplicité : la boucle IF.
Au premier abord, j'ai été séduit : c'est vrai, tout simple, même pas de End pour terminer, pas de Then mais deux-points, à première vue, c'est simple. Et le Else ? Une gentillesse...
En fait, je vois les choses autrement. D'abord, le Else. Je ne l'utilise pratiquement jamais ! Que signifie Else ? Tout le reste et n'importe quoi ! Imaginons un impondérable qui se glisse dans votre construction, et il se peut fort bien qu'il soit exécuté par un Else ! En général, je mets une boucle avec la condition, et une seconde boucle avec la non-condition. En fait, ça me prend une ligne de plus, mais c'est clair, net, précis, sans équivoque, il n'y a que ce qui est écrit qui peut arriver, et pas autre chose.
Toujours en rapport avec la boucle IF pythonesque, j'ai noté avec un bond sur mon fauteuil que l'identation était très importante. Et l'auteur de souligner à propos du code : ça va générer une erreur car il y a un espace au début... Chacun ses habitudes, moi, je suis très pointilleux sur l'identation, c'est la condition sine qua non pour s'y retrouver dans son code, surtout si on doit le relire six mois ou un an après. Quand je programme une boucle IF, j'écris ma première ligne, la condition donc, et immédiatement après, je tape mon End par retour chariot, ce qui fait qu'il est obligatoirement à la même identation. J'ajoute des espaces entre les deux lignes, et si j'ai des IF imbriqués, je fais exactement la même chose, sauf bien sur dans le cas de la décision unique où le End n'est pas nécessaire. Il m'est même arrivé avec des procédures un peu alambiquées il est vrai, de numéroter les IF et END en commentaires pour être certain de m'y retrouver.
Tout ça pour dire que ce n'est pas forcement, suivant ma logique, que parce qu'il y a moins de lignes que c'est plus simple. Il en va de même pour certaines formules mathématiques que l'on peut toujours enchaîner, certes, mais dont on n'arrive plus à savoir exactement la préséances des opérateurs. Pour peu que l'on veuille une assurance sécurité, il faudra ajouter un nombre significatif de parenthèses qui compliqueront d'autant le code, alors que parfois, l'ajout d'une au deux variables locales simplifie considérablement la lisibilité.
Cela dit, mon propos n'est pas d'essayer de démontrer quoi que ce soit, encore moins de faire le procès de Python. C'est un langage que je vais peut-être essayer d'approcher, cela dit, ou plutôt redit, il faut qu'un intérêt apparaisse, il faut un projet qui motive cet apprentissage, on ne fait rien sans motivation !
D'après ce que j'ai lu de Python, la simplicité promise ne me semble pas du tout au rendez-vous, j'ai vraiment le sentiment que c'est quelque chose de compliqué, pas forcément inaccessible, mais assurément compliqué, et en lisant le livre sus-mentionné, il y a plein de trucs auxquels je n'ai rien compris, et si je voulais réécrire mon programme d'apprentissage de clavier par exemple, je ne vois même pas par quel bout je pourrais commencer !
Tout cela m'amène à une considération déjà effleurée plus haut. Je crois l'avoir dit, je suis resté vraiment surpris de trouver cette discussions sur ce site. Quand j'ai décidé de migrer sous Linux, j'ai tâté un peu hasard, et je ne me souviens pas du tout des raisons de mon choix ! Ce que j'ai retenu, c'est que Ubuntu est une distribution facile et sûre, deux raisons de retenir mon attention, il est quand même certain que vu mon âge, les grosses difficultés me posent plus de problèmes qu'il y a trente ou quarante ans ! Bref, ce n'est pas si facile de migrer, même sous une distribution simple. Je le répète, ici, sur ce site, je me suis fait virer et pratiquement insulter. Je veux bien que quand on débarque, on pose des questions stupides, idiotes, je sais bien que parfois, on oublie de consulter une aide disponible en ligne, tout simplement parce qu'on est coincé, ou que l'on ne se rappelle plus où se trouve cette aide potentielle. Je sais également que beaucoup de gens donnent de leur temps précieux et de leur patience pour aider les débutants, et qu'ils sont peu nombreux face à la demande, aussi, ils sont parfois excédés par des questions répétitives. A cela je fais remarquer que si ils ont raison dans l'immédiat, ils n'ont pas forcément raison dans le temps. Certes, au début, on patauge, on pose plein de questions, et au fur et à mesure que l'on découvre, on apprend, non seulement à utiliser le produit, mais aussi à trouver seul des éventuelles solutions. En rabrouant les gens, comme je l'ai vu faire pas mal de fois, la discussion se terminait par : "Et merde, j'en ai marre, je retourne sous Windows"... Etait-ce bien le but de la manœuvre ?... Mais le pire, c'est que j'ai retrouvé un comportement quasi similaire sur le site de Gambas ! Alors, je veux bien admettre que je suis un peu bouché à l'émeri et que j'ai un caractère de vache, il n'en reste pas moins vrai que si j'ai un peu avancé, il a fallu montrer une réelle persévérance. Je me souviens d'un proche qui m'a dit un jour : "Si tu vas sous Linux, tu vas avoir les trois quarts de tes programmes qui ne vont plus marcher. Et puis, sous Linux, il faut déjà être un peu informaticien". Je veux bien que cette conversation date de un ou deux ans, néanmoins, tous mes programmes fonctionnent sous Linux, et même mieux pour certains, et je ne suis toujours pas informaticien !
Pourquoi tout ce baratin me direz-vous ? Et bien justement, c'est en rapport avec ce que j'ai dit plus haut, et qui concerne mon étonnement d'avoir trouvé cette discussion sur ce site. Si Ubuntu est simple et facile - ce serait aux dires de certains la distribution la plus facile, pourquoi des aspirants à la programmation chercheraient ici les bases ou les conseils sur le choix d'un langage, surtout lorsqu'il est dit dans le fil que l'apprentissage le plus sérieux sera d'évidence le plus rigoureux ? Je remarque quand même qu'il n'y a pas foule dans les commentaires, non ? Bien entendu, il y a probablement beaucoup de gens qui lisent sans intervenir, je voudrais quand même remarquer que, lorsqu'on est intéressé, on se manifeste en général !
Bien en conclusion, je crains d'avoir été un peu long, je vais me relire quand même...
Pour l'instant, me mettre à Python est une hypothèse, il me reste à trouver les moyens de m'y mettre, c'est à dire, de trouver de la documentation, une aide sérieuse et sur laquelle je puisse compter, et surtout, une perspective très claire du chemin à parcourir : sans carte, sans GPS et sans idée du but à atteindre, il est hors de question d'entreprendre le chemin... Tant que je n'aurai pas une idée claire du chemin où je dois poser mon premier pas phytonneux, je crains de rester béatement dans le confort de mon fauteuil...
Merci à tous pour vos interventions !
Je souhaite sincèrement que cette discussion éveille des vocations !
#121 Le 29/04/2010, à 22:59
- Le Farfadet Spatial
Re : Petit guide pour aider au choix d'un langage
Salut à tous !
Foromus, sans vouloir polémiquer, tu devrais aérer et structurer un peu plus tes interventions, ce serait plus facile à lire.
Quelques remarques : tout d'abord, il n'y a pas que Python. Ensuite, tu parles beaucoup de tes habitudes, encore une fois il est certain qu'en changeant de langage, il faut changer d'habitude. Cela dit, oui, il est préférable d'avoir une motivation particulière lorsque l'on veut se lancer dans la programmation, d'ailleurs cela me semblait être indiqué dans le message de départ.
Concernant le type des variables, il faut tout de même garder en tête plusieurs choses. Tout d'abord, jusqu'aux années quatre-vingt-dix, à peu près, sur les ordinateurs de bureau, on gérait la pénurie. Aujourd'hui, on gère l'abondance : la pénurie ne se gère pas du tout comme l'abondance. De plus, faire des économies de bouts de chandelles n'est pas la marque d'un fin gestionnaire. Il ne faut pas oublier que le bogue de l'an 2000, c'était d'abord une affaire de variables trop justes pour pouvoir supporter le changement de millénaire : il ne faut pas oublier qu'un programme va évoluer. Par exemple, coder un entier sur un seul octet signifie qu'il sera compris entre -128 et 127, ce qui est très juste. D'autant qu'un système 8 bits gérera mieux les variables 8 bits, un système 16 bits les variables 16 bits et ainsi de suite -- notamment en ce qui concerne les caches, dans lesquels on peut facilement perdre de la place à vouloir à tout prix créer des variables extrêmement justes, c'est le problème d'alignement des variables. En clair, une bonne gestion de la mémoire, ce n'est pas réduire à tout prix la taille des variables, au risque de rendre le programme incapable d'évoluer (voir incapable de traiter les cas que l'on veut traiter), au mépris des performances, parfois en entrainant une perte de mémoire. Une bonne gestion de la mémoire, c'est de prendre du recul et de faire attention à ses structures de données, c'est-à-dire analyser son problème en amont.
Sinon, depuis que je suis inscrit à ce forum, j'ai vu de l'ordre d'une fois par mois apparaître un message demandant quel langage choisir pour débuter la programmation. Si ce fil de discussion a été créé, c'est à la demande des utilisateurs et aussi parce que ceux qui répondaient en avait assez de répéter sans arrêt la même chose. D'ailleurs, il a atteint pour l'heure cinq pages, ce qui le place au-dessus de la moyenne des fils de discussion. Après, si tu le trouves inutile, le mieux, c'est encore que tu ne le consultes pas.
À bientôt.
Le Farfadet Spatial
Dernière modification par Le Farfadet Spatial (Le 30/04/2010, à 07:05)
Hors ligne
#122 Le 12/05/2010, à 13:28
- ffw137
Re : Petit guide pour aider au choix d'un langage
Bonjour à tous, je trouve ce sujet très intéressant et notamment ce que Foromus et le Farfadet Spatial échange. J'adore programmer à titre personnel depuis une trentaine d'année et je suis très très loin d'être un expert, je suis passé également par le TRS-80, ZX-80 et toute la série avec l'upgrade chaque année.
Maintenant au niveau des langages, je pense que l'on est tous un peu sectaire et on a tendance à défendre celui que l'on utilise le plus. J'ai programmé en ZXBasic, QBasic, Turbo Basic et VB et j'ai aimé fortement ces langages sauf quand il fallait avoir de la vitesse et l'accès rapide au hardware, donc je me suis marié avec mon second meilleur ami: l'assembleur qui lui n'est pas sympa et à rarement de beau IDE graphique pour créer sa fenêtre avec le bouton qui affiche bonjour mais quand on sait le faire, le programme ne pèse rien et va à la vitesse d'une bombe.
Ensuite j'ai découvert Turbo Pascal, Turbo C et Turbo Prolog très complémentaires, j'ai programmé assez bien mais mon cœur à virer vers Blaise et c'est naturellement que j'ai opté pour Delphi (Lazarus est très bon sous linux).
Maintenant j'en ai un peu marre de passer des heures à convertir une bibliothèque du C/C++ (qui représente une énorme parie des codes sources ) vers le pascal, je me suis replonger dans le C/C++.
Donc je pense qu'il faut savoir gouter à tout, maintenant je suis pour l'apprentissage pas à pas en mode console pour apprendre les bases et les dissocier de l'interface graphique mais celle-ci doit rapidement être vue pour apprendre les bases d'un bon dialogue utilisateur/programme.
Combien de programmeurs talentueux font des interfaces de m... car ils n'ont aucune idée de l'ergonomie "normale", pas la leur car ils vont trouver ultra important une fonction sur laquelle ils auront passer des heures et occulter une autre qui sera pourtant fortement demandée mais peu maniable et provoquera l'abandon de leur programme.
Pour l'éditeur on prend ce qu'on aime et pas nécessairement avec Emacs/Vim sans pluggin dirait certains selon qui le fait de taper du code avec une aide quelconque est une hérésie et empêche d'apprendre toutes les arcanes d'un langage, je leur rétorquerai, que j'ai passé mon temps à programmer des ordinateurs 24 bits (oui 24 bits!) en porte NAND (plusieurs milliers en composant non discret) en entrant des séquences octales avec pression d'un bouton dans chaque adresse pendant des heures donc ils peuvent aller se recoucher, de plus la complétion automatique m'a souvent fait découvrir des choses que je ne connaissais pas avant et m'a enfin fait lire la documentation un peu plus complètement.
Maintenant, je suis un programmeur "bord.elle...hic", je n'utilise pas UML, j'ai ouvert un livre, j'ai commencé à lire et je n'y ai vu aucun exemple pratique appliqué à des cas réels, juste du code exemple sans aucun contexte et qui ne permet pas de réellement l'utiliser mais je persévèrerai et j'y arriverai un jour.
Par contre, j'adore toujours l'assembleur et ma passion est la rétro-ingénierie des firmwares de décodeurs satellites par pour le piratage mais pour savoir comment cela fonctionne et là, malheureusement, j'ai pu voir les dégâts engendrés par la programmation objet mal utilisée, des tonnes de tables de saut indirects pointant sur des autres tables qui pointaient sur du code qui appelaient également des méthodes indirectes via des pointeurs de pointeurs tout cela rend vraiment triste quand on voit de précieuses ressources mémoires (en général 2 Mo de flash et 8 Mo de RAM à partager avec la vidéo, l'audio et le système) ainsi dilapidées.
La programmation objet est géniale pour développer, maintenir mais on doit ensuite replonger dans le code assembleur pour l'optimiser et bien utiliser les options des compilateurs sinon on a un programme lent! J'ai vu du code tourner deux fois moins vite sans problème à cause de cela mais tout est une question d'équilibre.
Donc pour moi, il faut connaître un peu de tous les langages, donc en tester un grand nombre, développer des interfaces graphiques convenables également et une ligne de commande utilisable aussi mais surtout optimiser ses programmes.
Je suis venu à Ubuntu dans cet esprit et quand j'aurai du temps libre réaliser un programme permettant le désassemblage des firmwares satellites un peu comme IDA PRO, j'en ai fait une partie avant sous delphi/win (la partie transformant l'assembleur MIPS en code C) mais maintenant je suis entrain de voir Ajunta et GTK+ et j'espère aider cette communauté et partager mes expériences.
Désolé pour la longueur.
Dernière modification par ffw137 (Le 12/05/2010, à 14:47)
Acer 5610-Epson DX3850-Samsung ML-1640-Lucid
Samsung NC-10-Lucid-Ecran 17"
"Un philosophe c'est quelqu'un qui est prêt à faire mourir les autres pour ses idées avant d'en changer quand vient son tour" (perso enfin je pense)
Hors ligne
#123 Le 12/05/2010, à 17:34
- Le Farfadet Spatial
Re : Petit guide pour aider au choix d'un langage
Salut à tous !
Tout d'abord, merci pour ton intervention Ffw137.
Quelques remarques :
l'assembleur qui lui n'est pas sympa et à rarement de beau IDE graphique pour créer sa fenêtre avec le bouton qui affiche bonjour mais quand on sait le faire, le programme ne pèse rien et va à la vitesse d'une bombe.
Ce n'est plus tout à fait vrai : depuis les années 80, les choses ont bien changé. Désormais, les processeurs sont superscalaires et multi-cœurs, ce qui implique des architectures intrinsèquement parallèles et une forte utilisation du principe de pipeline. En conséquence, les optimisations adaptées à de telles architectures sont difficilement réalisables par un être humain. De plus, un code en assembleur est par essence non-portable.
De nos jours, une utilisation raisonnée de l'assembleur est d'y avoir recours pour l'accès fin au matériel et pour certaines applications embarquées.
Combien de programmeurs talentueux font des interfaces de m... car ils n'ont aucune idée de l'ergonomie "normale", pas la leur car ils vont trouver ultra important une fonction sur laquelle ils auront passer des heures et occulter une autre qui sera pourtant fortement demandée mais peu maniable et provoquera l'abandon de leur programme.
Il est généralement préférable de détacher l'interface graphique du programme, car il s'agit de deux choses différentes. Le code est l'affaire du programmeur, l'interface de l'ergonomiste. Les bibliothèques tels que Qt ou Gtk+ permettent de faciliter une telle distinction.
Pour l'éditeur on prend ce qu'on aime et pas nécessairement avec Emacs/Vim sans pluggin dirait certains selon qui le fait de taper du code avec une aide quelconque est une hérésie et empêche d'apprendre toutes les arcanes d'un langage, je leur rétorquerai, que j'ai passé mon temps à programmer des ordinateurs 24 bits (oui 24 bits!) en porte NAND (plusieurs milliers en composant non discret) en entrant des séquences octales avec pression d'un bouton dans chaque adresse pendant des heures donc ils peuvent aller se recoucher, de plus la complétion automatique m'a souvent fait découvrir des choses que je ne connaissais pas avant et m'a enfin fait lire la documentation un peu plus complètement.
En réalité, tant Emacs que Vim fournissent de nombreuses aides aux programmeurs, notamment ils possèdent tous les deux la complétion automatique. Ce sont loin d'être de simples éditeurs de textes, ce sont des environnements de travail très complets. Pour ma part, après avoir testé en profondeur de nombreux environnements de développements intégrés, je suis revenu à Emacs, non pas parce que c'est une hérésie d'avoir de l'aide au développement, mais justement parce que les outils offerts par Emacs me permettent d'être plus productif avec Emacs qu'avec aucun des environnements de développements intégrés aujourd'hui disponibles.
j'ai pu voir les dégâts engendrés par la programmation objet mal utilisée, des tonnes de tables de saut indirects pointant sur des autres tables qui pointaient sur du code qui appelaient également des méthodes indirectes via des pointeurs de pointeurs tout cela rend vraiment triste quand on voit de précieuses ressources mémoires (en général 2 Mo de flash et 8 Mo de RAM à partager avec la vidéo, l'audio et le système) ainsi dilapidées.
Il ne faut pas oublier l'importance du compilateur dans ce processus et aussi des options de compilations, de quand remontent tes expériences et avec quels compilateurs ? Cela dit, oui, il est bon de programmer en réfléchissant aux conséquences que cela à sur l'utilisation des ressources.
on doit ensuite replonger dans le code assembleur pour l'optimiser et bien utiliser les options des compilateurs sinon on a un programme lent!
C'est très vite dit. Les optimisations, il faut savoir où et comment les faire : la mise au point d'algorithmes et de structures de données performantes permet aisément de gagner un facteur 1000 -- de plus, c'est portable et maintenable --, l'utilisation intelligente du compilateur un facteur 100. Les petites optimisations de sioux permettent au mieux de faire gagner un facteur 10, peuvent rendre le code incorrect et sont difficiles à maintenir. Il peut arriver d'en avoir besoin, mais c'est loin d'être un passage obligé, c'est même plutôt quelque chose de dangereux.
À bientôt.
Le Farfadet Spatial
Dernière modification par Le Farfadet Spatial (Le 12/05/2010, à 17:35)
Hors ligne
#124 Le 12/05/2010, à 18:21
- ffw137
Re : Petit guide pour aider au choix d'un langage
Merci pour cette réponse!
Pour Emacs, comme je l'ai précisé cela est sans les pluggins mais bien un Emacs tout nu mais je l'apprend aussi en parallèle avec anjuta ainsi que vim, maintenant pour un premier venu qui a programmé sous windows, il est un fait qu'il faut qu'il s'habitue à l'ergonomie de Emacs ou Vim. Existe-t-il un bon site qui répertorie les pluggins de Emacs et leurs fonctions.
Maintenant pour mes expériences de programmation, tu as surement vu que j'aime les systèmes embarqués des décodeurs qui sont en général des mono core avec beaucoup de hardware spécialisés autour comme les SC2000 / SC2005, maintenant pour l'optimisation, il est un fait que je me concentre sur une seule plateforme et ce n'est pas maintenable avec plusieurs.
Pour les dernières compilations: j'ai eu affaire au couple diab/psos, gcc/système proprio de ALi donc des systèmes destinés à de l'embarqué donc je ne peux juger avec les avancées actuelles.
Maintenant, je suis d'accord pour une bonne organisation des données et une bonne analyse en amont mais parfois je vois de l'utilisation de l'objet pour tout et n'importe quoi, la moindre variable devient un objet avec une tonne de méthodes sous le couvert de la facilité de maintenance et la réutilisation mais bon cela est juste mon impression.
Maintenant, quand je vois la tonne de fichier généré par anjuta, c'est vrai que ça fait peur également!
Allez je vais me mettre plus à Emacs alors! Pour les interfaces, j'utilise quand même glade en couple avec Emacs ou bien je dois utiliser autre chose?
PS: Existe-t-il un pluggin emacs pour afficher l'arborescence des fichiers d'un projet si oui je suis satisfait.
Merci pour ce post!
Acer 5610-Epson DX3850-Samsung ML-1640-Lucid
Samsung NC-10-Lucid-Ecran 17"
"Un philosophe c'est quelqu'un qui est prêt à faire mourir les autres pour ses idées avant d'en changer quand vient son tour" (perso enfin je pense)
Hors ligne
#125 Le 13/05/2010, à 16:11
- Le Farfadet Spatial
Re : Petit guide pour aider au choix d'un langage
Salut à tous !
Existe-t-il un bon site qui répertorie les pluggins de Emacs et leurs fonctions.
Un excellent livre pour découvrir Emacs :
Introduction à GNU Emacs
Debra CAMERON, Bill ROSENBLATT et Eric S. Raymond
O'Reilly
Dans la documentation, il y a une section dédiée à Emacs avec des liens intéressants :
http://doc.ubuntu-fr.org/emacs
Tout cela devrait te donner de bons points de départs.
PS: Existe-t-il un pluggin emacs pour afficher l'arborescence des fichiers d'un projet si oui je suis satisfait.
Oui, il est possible de naviguer dans l'arborescence d'un projet par l'intermédiaire de Emacs. Tu devrais trouver ce qu'il te faut avec les éléments que je t'ai donnés.
pour un premier venu qui a programmé sous windows, il est un fait qu'il faut qu'il s'habitue à l'ergonomie de Emacs ou Vim.
Oui, c'est certain : il faut changer ses habitudes, ce qui demande toujours du temps.
À bientôt.
Le Farfadet Spatial
Hors ligne