no_spleen
Le fichier de maillage est trops gros à poster !
tshirtman
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…
no_spleen a écritMalheureusement, 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/
Le Farfadet Spatial
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
tshirtman
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.
Le Farfadet Spatial
Salut à tous !
tshirtman a écritLe 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.
tshirtman
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…
Le Farfadet Spatial
Salut à tous !
tshirtman a écritpar 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
no_spleen
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 -3
ce 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};
tshirtman
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…
Le Farfadet Spatial
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
no_spleen
Bonjour, je le poste dans la journée !
no_spleen
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._xnew
Le Farfadet Spatial
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
[supprimé]
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 !
Le Farfadet Spatial
Salut à tous !
Foromus a écritVoilà, 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
tshirtman
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.
[supprimé]
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 !
Le Farfadet Spatial
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
tshirtman
@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 🙂.
[supprimé]
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 !
