Un mot sur l'informatique.

Bonjour,
Je lis ça :

Fin_de_partie a écrit:La plupart des Tous les programmes utilisent des appels à des librairies ou un API d'un environnement informatique (système d'exploitation etc).
Un développeur de programmes utilise sans arrêt le code des autres. Tu files à n'importe quel développeur 100 000 lignes de programme sans documentation, je ne suis pas certain qu'il va comprendre rapidement ce que fait ledit programme.

Ca me gène un peu.
Il y a deux problèmes évoqués
1- la connaissance du problème traité. Il est vrai qu'un informaticien n'est pas censé connaitre tous les problèmes mathématiques. S'il écrit un programme pour traiter un problème quel qu'il soit, soit il est spécialiste de la question, soit il dispose d'une documentation suffisamment détaillée. Dans tous les cas il doit comprendre, au moins momentanément, ce qu'il fait.
2- C'est plutôt ce dont parle FdP. Oui, il y a des quantités de bibliothèques de modules existants. S'il sait ce qu'il fait (cf le point 1) il est normal qu'il utilise les bibliothèques disponibles, elle sont faites pour ça et s'il avait le temps, il serait capable de les écrire, sauf des cas très particuliers comme la gestion du système qui est en relation directe avec le matériel.

Par contre, il y a un problème que j'évoque de temps en temps, c'est le côté utilisateur. De nombreux utilisateurs se servent des outils informatiques, alors qu'ils n'ont pas la moindre idée de ce qu'ils doivent faire, c'est à dire qu'ils seraient incapables de la faire sans informatique si on leur donnait le temps.
L'exemple typique, c'est l'opération "régression" linéaire.
Et ça, c'est très ennuyeux.

Bonjour,
Réf. : https://les-mathematiques.net/vanilla/index.php?p=/discussion/2335126/soucis-python
Un peu dans le même contexte.
J'ai lu soigneusement le sujet. Très nettement dp connait très bien la programmation et Python en particulier, j'ai peur que N.P. soit limité à une bonne connaissance des méthodes à utiliser en Python.
Au passage, j'ai remarqué un certain désaccord concernant la définition de "fonction". C'est un objet Python ou pas ?
Il faudrait déjà savoir de qu'est un objet dans le contexte informatique. On parle souvent de la programmation orientée objet, qu'est-ce que ça veut dire ?
Il me parait étonnant de dire qu'une fonction est un objet, justement parce que c'est le point d'opposition de la POO par rapport à la programmation qu'on peut appeler "classique".
Un objet, quelque soit le langage, contient un ensemble de choses, par exemple, des données, des fonctions, d''autres objets. En C++ on construit un objet (le constructeur), c'est une fonction dont le seul but est d'initialiser un certain nombre de choses, c'est à dire, réserver de la mémoire etc. Un même objet peut avoir plusieurs constructeurs différents, mais l'objet construit est unique et suivant l'unique définition pour un tel objet.
Par contre, une fonction, c'est un outil, contrairement à un objet que l'on construit et que l'on détruit quand on n'en a plus besoin. Que l'on ait besoin ou pas de la fonction, elle existe toujours, soit bien cachée dans la bibliothèque, soit sur la table de travail.
C'est assez marrant, on trouve ce même type de problème dans des discussions purement mathématiques ou la nuance entre fonction et valeur est vraiment difficile à détecter.

Oui, bon j'ai tort, d'ailleurs, j'ai jamais rien compris à l'informatique et en particulier, tous les programmes que j'ai écrits sont nuls.
"One of the most powerful features of Python is that everything is an object, including functions. Functions in Python are first-class objects."
Tout à fait d'accord si la traduction française de "object" est "truc".
En fait, ça correspond tout à fait à l'incompréhension systématique et l'absence généralisée de définition. Au moins on est sûr de ne pas se tromper.
Quand j'étais jeune on comparait ce genre de discussion à la distinction entre "fer" et "métal".
Bon, moi je veux bien qu'une fonction soit un objet, mais comment construit-on un objet, sinon avec une fonction ? Cette affirmation péremptoire du mode d'emploi est peut-être dû au fait que cette construction d'objet est transparente pour l'utilisateur, ou que des choses comme print sont appelées méthodes au lieu de fonction, mais en tout cas donnera bien l'occasion à certains de dire "c'est pas vrai" et en tout cas compliquer à souhait la compréhension.

L'exemple est typique, soit le code :
def bid(m,t):
t=print("machin et truc",m,t)
return t

Si print est réellement un objet, comme t est un objet (par définition) alors la fonction bid renvoie un objet.
Ben non, c'est pas ce qui se passe "print" est une fonction qui exécute une opération, celle d'imprimer, et renvoie éventuellement une valeur, par exemple si l'opération s'est bien passée. Il se trouve que la fonction print, quel que soit la langage, est une des fonctions de base comme "read" puisqu'elle fait appel à un environnement extérieur. Bref, je perds mon temps......

Ce que tu détailles, ce sont des particularités de chaque langage.
Par contre, si on veut faire un peu de programmation et de logique en général il ne faut pas donner le même nom à deux choses différentes, par exemple l'outil et l'objet fabriqué.
Que N.P. reprenne bd sur "une fonction est un objet python" est tout à fait anormal. En python, ils existe des fonctions comme print. Quand on a un objet, on peut lui inclure des fonctions. Quand on crée une fonction avec def, on peut l'appeler truc, mais dire que c'est un objet au sens de POO, c'est incompréhensible pour un débutant.
Une fonction est un "élément de Python", les fonction de base sont dans des bibliothèques.

PS J'insiste, ce n'est pas une question de fonctionnement de logiciel, c'est une question d'abus de langage, on appelle "objet" tout élément de Python, alors qu'en informatique "objet" a un sens bien précis, quelque soit le langage.
A l'age du fer, il n'y avait pas grand inconvénient à appeler "fer" tous les métaux de la classification de Mendéléif, maintenant il vaut mieux éviter.

Je vais essayer d'expliquer rapidement cette notion d'objet.
D'abord, on définit une classe. C'est une définition unique ferme et définitive.
Exemple simple, je définis une classe "SEGMENT". Cette classe comporte la définitions de deux points (x,y) et la définition de Longueur.
Je construis l'objet Seg qui est de la classe SEGMENT.
C'est à dire que si j'écris d=Seg.Longueur, alors j'obtiendrai la distance entre les points qui ont servi à construire l'objet Seg.
Il est clair que pour calculer Longueur, j'aurai quelque-chose comme
Longueur = sqrt((x1-x2)^2 + (y1-y2)^2)
sqrt est une fonction, ce n'est évidemment pas un objet. Par contre, cette fonction pourra être déclaré dans une classe, par exemple math et on aura une fonction math.sqrt().
On peut remonter autant qu'on veut, mais à tout moment, on trouvera une fonction qui fait un calcul et retourne un résultat.

SEGMENT, que j'ai mis en majuscule, c'est pas obligatoire mais assez courant, c'est une définition de classe.
Seg, c'est un objet qui a pour définition la classe segment.
Quand on déclare segment, on construit l'objet de type SEGMENT.
Il est vrai que dans Python, tout ça est automatique, transparent pour le programmeur, donc incompréhensible.
En fait dans python, sauf des gens comme N.P., personne n'entend parler de SEGMENT, c'est caché.
Il faut voir aussi que Python est un langage interprété, donc ces objets sont construits et détruits au fur et à mesure de l'exécution, certains objets sont construits au départ et détruits à la fin de l'exécution.
En fait, tout ça n'est pas vraiment utili à savoir, comme le dit bd, j'en parle fuste à cause de la distinction fondamentale entre fonction, valeur et objet. Si on parle d'objet, on parle de logique de base du système d'exécution.
Dans l'exemple t=print(...) print est une fonction qui envoie des caractères où ça a été prévu. Je ne pense pas que print retourne une valeur, donc à la limite, c'est une faute de code.
Pour mémoire, le Python donne souvent des boutons, de l'exéma, voire des nausées à de nombreux développeurs. La raison est simple : on ne sait pas ce qu'on fait.

Je reviens sur le centre du sujet. La question n'est pas vraiment ce qu'est un objet, ce qu'est une fonctions etc. mais : il y a un membre qui est compétent, qui cherche à comprendre.
Il pose une question vraiment élémentaire. Mon constat est :
1- un étudiant de ce niveau, étant donné les programmes officiels et l'importance de l'informatique, ne devrait pas en être arrivé à poser ce genre de question. Il y a un défaut majeur dans le système de formation.
2- un membre compétent et très pédagogue lui explique la situation. Il se fait contrer par un pilier de ce forum, certainement compétent dans le détail d'un certain logiciel, je suis choqué.

Annexe, je genre de situation est vraiment répétitive, tous les argument possibles sont utilisés pour faire croire que celui qui explique les choses n'y connais rien.
J'ai en mémoire un échanges avec un membre un peut "bricolo" qui l'a envoyé ballader proprement sans aucune réaction de membres "posés" et bien-sûr de la modération.
On en revient pas ailleurs au défaut caractéristique de définitions claires et précises des termes que l'on emploie

PM je n'ai pas eu de réponse à la question "trouver une fonction telle que f(x) - f(1/x) >0 pour x compris entre 0 et 1".

Nicolas P. a écrit:On n’est pas obligé de tuer le processus avec exit(1) quand on lance une exception, tout dépend de ce qu’on veut en faire.

Ca c'est bien une réflexion de prof.
Dans un programme, il arrive que l'on mette ce genre de contrôle. C'est tout simplement pour prévoir l'imprévisible, donc si ça arrive on arrête tout.
Par contre, si c'est un cas rare mais possible pour telle ou telle raison, alors on l'a prévu et on a programmé la suite en conséquence. Ce n'est pas du tout la même démarche intellectuelle.
Pour simplifier, si on est sûr de soi, c'est à dire si on a programmé soigneusement, les instruction try ; catch etc. ne devraient pas être utilisées.
Par contre il est vrai qu'en phase de débogage et de mise au point elles sont intéressantes.