/* Topic des codeurs couche-tard [5] */

tshirtman · Le 28/06/2011, à 16:06

ArkSeth a écrit :

tshirtman a écrit :
En quel honneur? il n'y a aucun problème avec le typage dynamique
Bah si on voit l'aspect mathématique des choses, quand on définit une fonction, il faut commencer par donner son domaine de définition.
Puis je voyais ça sur la logique du Java, où tu peux définir deux fonctions qui aient le même nom, mais des paramètres différents.
Du genre, multiplier deux entiers et multiplier deux matrices, ce n'est pas tout à fait la même chose, même si on dit multiplier dans les deux cas.
Et la fameuse relation d'équivalence en question sera différente selon le type des objets auxquels on l'applique.

Si je ne m'abuse, tu confong typage dynamique et typage faible (sans doute à force de faire du php )

J'avoue que mon expérience en matière de surcharge d'opérateurs est assez limitée, mais j'ai du mal à voir comment on peut redéfinir proprement le fonctionnement selon le type, si on n'a le type qu'au moment de l'exécution.

Je ne sais plus comment ça s'appele, mais le fait de différencier à l'éxecution la fonction ou méthode appelé en fonction des types des parametres et même du type de retour attendu, ça existe, et certains langages le font

tshirtman a écrit :
Je ne suis pas d'accord, dans un tel langage, c'est le symbole, par ce que c'est sa place, et pas d'équivalence -> there should be only one way to do it!
Ouais, ça se tient aussi, en effet, mais dans ce cas, il faut donner un statut différent à une fonction et à un opérateur, avec deux manières différentes de les définir (parce que je pars du principe qu'un tel langage serait extensible, et donc donnerait la possibilité de définir aussi de nouveaux opérateurs).

Je ne suis pas sur qu'un tel langage soit facile a étendre, surtout si on part sur les sèmes, il faudrait beaucoup de temps pour les définir. Et ça pose le problème de la sémantique des variables aussi. (à supposer qu'on puisse se passer des commentaires).

Ma vision des choses avait l'avantage, outre d'offrir quand même une possibilité de coder aux malheureux ne disposant pas d'une vraie dispo clavier (genre les utilisateurs de Windows, par exemple) de n'offrir qu'une seule manière de gérer les deux.

Ils ne pourraient pas éditer le code existant simplements de toutes façons, et avec une telle rétrocompatibilité, on avancera jamais /

tshirtman a écrit :
ouais, enfin, abs(f1 - f2) < gap, ça le fait aussi
En effet, mais j'avais envie de faire un code avec des symboles unicodes ^^
(Et j'voulais en profiter aussi pour noter le fait que dans un tel langage, [] et {} devraient correspondre respectivement aux intervalles et aux ensembles).
tshirtman a écrit :
pas faut, mais ça flirt un peu avec le lambda calcul, niveau lisibilité ^^
[inculte]Le quoi ?[/inculte]

http://en.wikipedia.org/wiki/Lambda_calculus
(je me méfie, tu serait capable d'aimer ça...)

The Uploader · Le 28/06/2011, à 16:15

tshirtman a écrit :

Je ne sais plus comment ça s'appele, mais le fait de différencier à l'éxecution la fonction ou méthode appelé en fonction des types des parametres et même du type de retour attendu, ça existe, et certains langages le font

Si je ne m'abuse, c'est le polymorphisme des langages OO (surcharge/redéfinition).

Dernière modification par The Uploader (Le 28/06/2011, à 16:16)

tshirtman · Le 28/06/2011, à 16:32

non, ça existe aussi dans des langages non objets.

Elzen · Le 28/06/2011, à 16:59

tshirtman a écrit :

Si je ne m'abuse, tu confong typage dynamique et typage faible (sans doute à force de faire du php )

En fait, n'ayant jamais eu (de ce que je me souviens, en tout cas) d'explication sur le sens précis de ces différents termes, j'ai jeté un rapide coup d'œil à ceci et j'ai tenté d'en déduire, tout aussi rapidement (je ne connais que deux des langages présentés) à quoi correspondait la nécessité de préciser le type d'une variable au moment de la déclarer.

tshirtman a écrit :

Je ne sais plus comment ça s'appele, mais le fait de différencier à l'éxecution la fonction ou méthode appelé en fonction des types des parametres et même du type de retour attendu, ça existe, et certains langages le font

Ouais, je sais qu'il y a ça au moins dans le PL/SQL d'Oracle. Après, je sais pas du tout comment c'est géré en interne.

tshirtman a écrit :

Je ne suis pas sur qu'un tel langage soit facile a étendre, surtout si on part sur les sèmes, il faudrait beaucoup de temps pour les définir. Et ça pose le problème de la sémantique des variables aussi. (à supposer qu'on puisse se passer des commentaires).

Bah j'partais du principe que simplement, tu définis une fonction comme tu le ferais dans n'importe quel autre langage, sauf qu'en plus tu y ajoutes une forme d'« expression » (« nomVariable1 symbole nomVariable2 » dans la plupart des cas), et il y a juste à vérifier que le symbole est bien du format attendu (caractère unicode non-alphanumérique, pour éviter de confondre ça avec un nombre ou un nom de variable, en très très gros) et que ça ne fait pas doublon avec une autre opération déjà définie.
Au départ, j'pensais juste à associer un opérateur à un nom de fonction, mais ça perd la possibilité de faire des trucs un peu plus complexes, du genre le ≈ ± dont j'parlais plus tôt.

Mais si t'as une autre idée, je t'écoute

tshirtman a écrit :

http://en.wikipedia.org/wiki/Lambda_calculus
(je me méfie, tu serait capable d'aimer ça...)

Tant que j'ai qu'une explication en anglais, il y a peu de chances… *tente de comprendre ça*

Dernière modification par ArkSeth (Le 28/06/2011, à 17:11)

grim7reaper · Le 28/06/2011, à 17:15

tshirtman a écrit :

@grim: je me demande ce qu'il pense du switch lisp -> python du MIT en 2008

Chai pas, tu lui demanderas

ArkSeth a écrit :

grim7reaper a écrit :
Haskell :]
Ouais, j'regarderai ça, un jour… mais bon, c'est du fonctionnel pur, non ? L'objet, c'est pas mal non plus

Oui c'est du fonctionnel pur (mais il existe des implémentations objet comme Haskell++, O'Haskell ou Mondrian).
Oui l'OO c'est pas mal, mais c'est comme tout : c'est loin d'être parfait, ça a ses limites et ça ne répond pas à tous le besoins (contrairement à ce que certains semblent croire). Au passage, je signale que la tirade précédente s'applique aussi bien à la prog impérative, fonctionnelle, orienté aspect ou encore la prog' logique.
Donc c'est dommage de camper dessus.

tshirtman a écrit :

ArkSeth a écrit :
Sur le principe, je pense qu'on pourrait reprendre la syntaxe Python (ça fera plaisir à certains ^^), mais avec un typage statique.
En quel honneur? il n'y a aucun problème avec le typage dynamique

Ho que si, y'en a autant qu'avec un typage statique intelligent (donc pas comme celui du C ou du C++ bien sûr).
Ils sont différents c'est sûr, mais ils existent.
Et puis d'abord, ça existe pas les langages typés dynamiquement (oui je sais, c'est un repost)

tshirtman a écrit :

pas faut, mais ça flirt un peu avec le lambda calcul, niveau lisibilité ^^

Mais c'est très bien le lambda‑calcul !
Bon après au niveau visibilité, le lambda‑calcul lui‑même je ne sais pas car j'ai jamais bossé avec directement…

tshirtman a écrit :

non, ça existe aussi dans des langages non objets.

Ah ça tombe bien, le polymorphisme n'est pas reservé aux langage OO.
Haskell, pour parler de ce que je connais, a du polymorphisme bien qu'il soit fonctionnel pur.

Dernière modification par grim7reaper (Le 28/06/2011, à 17:17)

The Uploader · Le 28/06/2011, à 17:42

grim' a écrit :

(contrairement à ce que certains semblent croire)

Tu parles de moi ? T'inquiète pas, j'en suis conscient. (surtout que l'aspect vient à la "rescousse" de certaines limitations de l'objet, si j'ai bien compris ce que m'a raconté mon prof une fois)

grim' a écrit :

Ah ça tombe bien, le polymorphisme n'est pas reservé aux langage OO.

Ah désolé, je n'ai aucune expérience de l'orienté aspect et très peu de fonctionnel (le GimpFu......... ça compte ? ) ou logique (en fait à part la prog' impérative ou objet ou déclarative, rien). Donc c'est peut-être nul, mais quand je lis polymorphisme, ça m'évoque "classe", "surcharge", ...

Mais bon, par exemple pour l'aspect, je crois que je vais devoir l'utiliser tôt ou tard : je bute parfois (du moins j'en ai l'impression) sur les limites de l'OO..
Et puis c'est pas comme si j'avais pas de projets en C.
(tiens d'ailleurs faudrait que je me remette au hack d'Audacious, mais c'est assez lourd...
En fait après avoir fait du Ruby toute la semaine/journée j'ai pas le temps/courage - Puis faudrait que je fasse mon rapport de stage en avance.. >_<)

grim' a écrit :

Ho que si, y'en a autant qu'avec un typage statique intelligent (donc pas comme celui du C ou du C++ bien sûr).
Ils sont différents c'est sûr, mais ils existent.

C'est loin d'être aussi grave que les problèmes du typage faible. Mais +1 pour le typage statique.

Dernière modification par The Uploader (Le 28/06/2011, à 17:45)

Elzen · Le 28/06/2011, à 17:42

grim7reaper a écrit :

Oui c'est du fonctionnel pur (mais il existe des implémentations objet comme Haskell++, O'Haskell ou Mondrian).
Oui l'OO c'est pas mal, mais c'est comme tout : c'est loin d'être parfait, ça a ses limites et ça ne répond pas à tous le besoins (contrairement à ce que certains semblent croire). Au passage, je signale que la tirade précédente s'applique aussi bien à la prog impérative, fonctionnelle, orienté aspect ou encore la prog' logique.
Donc c'est dommage de camper dessus.

Ouais, bien d'accord, ç'pour ça que le mieux, ce sont les langages qui peuvent tout faire

Troll à part, j'pense que j'ai tendance à penser naturellement en impératif, mais avec quelques objets en cas de besoin.

Après, le fonctionnel, à part le très vague souvenir d'avoir beaucoup aimé le Lisp à l'époque lointaine et reculée (et dont j'ai presque tout oublié) où j'en ai fait un peu, je ne connais clairement pas assez. J'essayerai de m'y mettre, un jour.

En fait, j'crois que toute mon éducation est à refaire ^^ J'veux bien une rapide explication des différentes sortes de programmation (y compris impératif, d'ailleurs, parce que c'est pareil, j'suis même pas sûr que l'interprétation que j'en ai en ayant rencontré le mot comme ça sur le tas est la bonne), si jamais quelqu'un a ça sous la main.

Dernière modification par ArkSeth (Le 28/06/2011, à 17:44)

The Uploader · Le 28/06/2011, à 17:45

Je plussoie ton dernier paragraphe, mais pour l'aspect!

grim7reaper · Le 28/06/2011, à 17:57

The Uploader a écrit :

grim' a écrit :
(contrairement à ce que certains semblent croire)
Tu parles de moi ?

Non pas du tout, je ne parlais de personne sur ce topic en fait.
Je repensais juste à certains code que j'avais vu passer, genre le code était forcément bon car OO (sans parler que c'était de l'OO vraiment mal foutu généralement, mais passons…).
Un peu comme les mecs qui te foutent des Design Pattern partout sans réfléchir, comme si la simple utilisation d'un DP rendait le code propre et fonctionnel :]

The Uploader a écrit :

(surtout que l'aspect vient à la "rescousse" de certaines limitations de l'objet, si j'ai bien compris ce que m'a raconté mon prof une fois)

Possible, pour être honnête la POA je connais juste de nom. Jamais eu de cours dessus (mais y'en a certains dans une des filières de mon école qui en font) et j'en ai jamais fait.
Mais ouais, il me semble que la POA à pour but de « patcher » certains problèmes de l'OO.

The Uploader a écrit :

grim' a écrit :
Ah ça tombe bien, le polymorphisme n'est pas reservé aux langage OO.
Ah désolé, je n'ai aucune expérience de l'orienté aspect et très peu de fonctionnel (le GimpFu......... ça compte ? ) ou logique (en fait à part la prog' impérative ou objet ou déclarative, rien). Donc c'est peut-être nul, mais quand je lis polymorphisme, ça m'évoque "classe", "surcharge", ...

Bah j'ai jamais fait de prog logique non plus hein, je connais juste ^^.
Et puis c'est pas « nul » de penser à classe et surcharge car c'est pas faux. Faut juste savoir que le polymorphisme ça se limite pas à l'OO (bon après y a aussi plusieurs types de polymorphismes…)

The Uploader a écrit :

En fait après avoir fait du Ruby toute la semaine/journée j'ai pas le temps/courage - Puis faudrait que je fasse mon rapport de stage en avance.. >_<)

Moi faudrait que je commence le mien >_<"

tshirtman · Le 28/06/2011, à 18:07

bah, wikipedia a une section sur les paradigmes de dev...

(et oui, un langage qui les fait tous, est parfaitement lisible, fortement typé, bourré de libs surpuissantes, ça existe )

Dernière modification par tshirtman (Le 28/06/2011, à 18:08)

Pylades · Le 28/06/2011, à 18:11

ArkSeth a écrit :

Mais en fait, dans le calcul courant, on utilise aussi parfois le = comme symbole d'équivalence (pour les fractions simplifiables, par exemple, 2⁄2 a la même valeur que 1, mais ne représente pas la même chose). Donc bon, c'est à fixer, quoi ^^

Je proteste. 2/2 et 1, c’est le même nombre ; on a juste deux représentations différentes. Donc t’as une relation d’égalité, stou.

ArkSeth a écrit :

Mais pour un langage orienté sémantique, ça me paraît indispensable d'utiliser l'indentation comme en Python, d'où le fait que j'ai pensé à Python (ce qui ne répond pas du tout à la question posée, j'en conviens).

À mon sens, c’est un des défauts de la syntaxe de Python. Le deux autres étant de ne pas avoir de marque d’instruction mais plutôt d’utiliser le LF comme séparateur ; et d’avoir des mots-clef verbeux plutôt que d’utiliser des symboles, à tel point qu’il n’y a pas de ternaire mais qu’on fait une soupe avec if et else.
Donc non, ça ne me plaît pas.

tshirtman a écrit :

Πυλάδης a écrit :
Mon clone a marqué exactement cinq points. Je le jure. Tu peux demander à n@ny.
accordé, c'est juste l'info que je voulais

Merci ! \o/

tshirtman a écrit :

ArkSeth a écrit :
Sur le principe, je pense qu'on pourrait reprendre la syntaxe Python (ça fera plaisir à certains ^^), mais avec un typage statique.
En quel honneur? il n'y a aucun problème avec le typage dynamique

Hum, je ne sais pas si on peut vraiment parler de typage dynamique, en Python… en fin de compte, on ne manipule que des noms. Alors après, ouais, ces noms peuvent pointer sur n’importe quel type d’instance… D’ailleurs quand tu bosses sur des types immutables, tu peux même faire comme si tu ne manipulais pas le nom mais l’objet lui-même. Mais je sais vraiment pas si on peut parler de typage dynamique. C’est assez unique, Python, de ce point de vue…

ArkSeth a écrit :

[…] j'ai jeté un rapide coup d'œil à ceci […]

Ce bout de page, c’est la merde. D’abord parce que ça laisse entendre qu’il n’existe que des langages compilés, et ensuite parce que ça affirme que le C a un typage faible. Le typage faible, c’est le mal absolu ; alors que le C, c’est le bien (presque) absolu. Donc c’est forcément des conneries.

grim7reaper · Le 28/06/2011, à 18:25

tshirtman a écrit :

bah, wikipedia a une section sur les paradigmes de dev...
(et oui, un langage qui les fait tous, est parfaitement lisible, fortement typé, bourré de libs surpuissantes, ça existe )

Oui et non, pour parler fonctionnel, bah python c'est pas le pied.
Ok y'a map, filter et les fonctions lambdas mais ça pas mal de langages l'ont maintenant (C++ va l'avoir il me semble, Java l'a, etc).
Mais où est la transparence référentielle ?
Les structures de données persistantes ?
Ça ce sont des points important (parmi d'autres) pour vraiment profiter du paradigme fonctionnel.
Alors oui, on peut dire que Python peut utiliser un style relativement fonctionnel, mais certainement pas qu'il supporte le paradigme fonctionnel.

Sinon, pour la prog logique, il a quoi Python ?

Πυλάδης a écrit :

Hum, je ne sais pas si on peut vraiment parler de typage dynamique, en Python… en fin de compte, on ne manipule que des noms. Alors après, ouais, ces noms peuvent pointer sur n’importe quel type d’instance… D’ailleurs quand tu bosses sur des types immutables, tu peux même faire comme si tu ne manipulais pas le nom mais l’objet lui-même. Mais je sais vraiment pas si on peut parler de typage dynamique. C’est assez unique, Python, de ce point de vue…

Non c'est pas unique, c'est le principe du typage dynamique (du moins une des ses implémentation).

Πυλάδης a écrit :

ArkSeth a écrit :
[…] j'ai jeté un rapide coup d'œil à ceci […]
Ce bout de page, c’est la merde. D’abord parce que ça laisse entendre qu’il n’existe que des langages compilés, et ensuite parce que ça affirme que le C a un typage faible. Le typage faible, c’est le mal absolu ; alors que le C, c’est le bien (presque) absolu. Donc c’est forcément des conneries.

Bah le C à un typage faible hein.
Après c'est comme tout, c'est relatif : C est fortement typé par rapport à PHP, mais il est faiblement typé par rapport à la majorité des langages (Haskell, Java, Ada, voire C++, etc).
Donc oui, le C est faiblement typé.

Dernière modification par grim7reaper (Le 28/06/2011, à 18:33)

The Uploader · Le 28/06/2011, à 18:29

Tout est fortement typé par rapport à PHP..

Pylades · Le 28/06/2011, à 18:36

grim7reaper a écrit :

@Pylade : bah le C à un typage faible hein.
Après c'est comme tout, c'est relatif : C est fortement typé par rapport à PHP, mais il est faiblement typé par rapport à la majorité des langages (Haskell, Java, Ada, voire C++, etc).
Donc oui, le C est faiblement typé.

Ben, à partir du moment où une chaîne ne se transforme pas entier comme par magie, pour moi c’est du typage fort. J’ai du mal à voir comme on pourrait typer plus fortement. Peut-être à la façon de Python, avoir un type élémentaire pour les chaînes, et ne pas avoir des chaînes qui ne sont en fait que des tableaux d’entiers terminés par nul ? C’est ça, le typage fort ?

Elzen · Le 28/06/2011, à 18:49

Bon, alors, après un tour rapide sur ces différents articles de Wikipédia (j'aime pas Wikipédia quand c'est la seule référence que j'ai sous ma main ) :

Prog impérative
Prog fonctionnelle
Prog orientée objet
Prog logique
Prog aspectuelle

bah ça confirme grosso-modo ce que je pensais sur l'« impératif », c'est déjà ça. Encore que de l'impératif non-procédural, ça doit être lourd, je pense ^^

Curieux, Wikipédia n'a pas l'air de faire la différence, dont j'me souviens vaguement avoir entendu parler en cours, entre « objet » tout court et « orienté objet »… je suppose rétrospectivement que mes profs de l'époque cherchaient par là à nous faire différencier la programmation orientée objet de la programmation impérative utilisant des objets… peut-être.

Au niveau de la programmation fonctionnelle, je retrouve un peu ce dont je me souvenais, et ça a toujours l'air intéressant, mais j'ai quand même quelques réserves (du genre, le fait qu'il n'y ait pas d'affectations et tout : pour faire des applis en ligne de commande, où on attend une entrée de l'utilisateur pour réagir, ça a l'air super bien, mais j'vois pas comment on peut se servir de ça pour faire des trucs graphiques avec plein de paramètres du genre Emacs ou Sawfish.
Donc j'demande une meilleure explication.

Idem pour la prog logique, ça a l'air bien sympa, mais seulement à utiliser dans certains cas bien spécifiques, et pas adapté à de la programmation en général pour faire des applis comme celles qu'on croise le plus souvent, j'trouve…

Pour la prog aspectuelle, j'ai toujours pas compris…

Πυλάδης a écrit :

Je proteste. 2/2 et 1, c’est le même nombre ; on a juste deux représentations différentes. Donc t’as une relation d’égalité, stou.

Ou pas.
C'est la même classe d'équivalence, à savoir les trucs qui ont la valeur 1, mais ça n'est pas le même nombre. Dixit ma prof de maths à l'IUFM (qui avait donné une vraie explication, mais dont j'me souviens pas, j'aurais du prendre plus de notes).

Πυλάδης a écrit :

Ce bout de page, c’est la merde. D’abord parce que ça laisse entendre qu’il n’existe que des langages compilés, et ensuite parce que ça affirme que le C a un typage faible. Le typage faible, c’est le mal absolu ; alors que le C, c’est le bien (presque) absolu. Donc c’est forcément des conneries.

Bah fais-en un mieux et va corriger.

…mais poste ici avant, qu'on relise, parce que ta vision non plus n'a pas l'air de faire l'unanimité.

grim7reaper a écrit :

Sinon, pour la prog logique, il a quoi Python ?

D'après le lien sus-cité, PyPy.

Πυλάδης a écrit :

Ben, à partir du moment où une chaîne ne se transforme pas entier comme par magie, pour moi c’est du typage fort. J’ai du mal à voir comme on pourrait typer plus fortement. Peut-être à la façon de Python, avoir un type élémentaire pour les chaînes, et ne pas avoir des chaînes qui ne sont en fait que des tableaux d’entiers terminés par nul ? C’est ça, le typage fort ?

D'après le passage de Wikipédia qui ne te plait pas, j'en viens à supposer qu'en typage fort, un truc déclaré d'un type particulier ne peut pas être utilisé comme d'un autre type, même quand les types sont aussi proche que short et int (d'après l'exemple) ou int et char (d'après mon extrapolation personnelle et le fait que je considère que 2/2 et 1 soient deux entités différentes, bien que de même classe d'équivalence (c'est la même logique, je pense)).

Dernière modification par ArkSeth (Le 28/06/2011, à 18:50)

The Uploader · Le 28/06/2011, à 18:49

Quand tu vois des codes C avec des casts de partout, mais surtout des pointeurs de type void (pointeurs sans type, donc) partout, tu te dis que le typage fort statique du C est parfaitement accessoire pour certains..

(les casts existent aussi en Java (et en C#, etc..) mais qu'entre classes ayant une relation d'héritage)

Dernière modification par The Uploader (Le 28/06/2011, à 19:25)

Elzen · Le 28/06/2011, à 18:52

Si j'ai bien compris ce que tu voulais dire, pour Java, en gros, ouais.

Mais cette histoire de void* et de int/char me rappelle vaguement le dernier troll sur PHP…

Dernière modification par ArkSeth (Le 28/06/2011, à 18:52)

tshirtman · Le 28/06/2011, à 19:07

Πυλάδης a écrit :

À mon sens, c’est un des défauts de la syntaxe de Python. Le deux autres étant de ne pas avoir de marque d’instruction mais plutôt d’utiliser le LF comme séparateur ; et d’avoir des mots-clef verbeux plutôt que d’utiliser des symboles, à tel point qu’il n’y a pas de ternaire mais qu’on fait une soupe avec if et else.
Donc non, ça ne me plaît pas.

C'est une implémentation de l'opérateur ternaire, que ce soit "?" et ":" ou "if" et "else", c'est la même chose…

Hum, je ne sais pas si on peut vraiment parler de typage dynamique, en Python… en fin de compte, on ne manipule que des noms. Alors après, ouais, ces noms peuvent pointer sur n’importe quel type d’instance… D’ailleurs quand tu bosses sur des types immutables, tu peux même faire comme si tu ne manipulais pas le nom mais l’objet lui-même. Mais je sais vraiment pas si on peut parler de typage dynamique. C’est assez unique, Python, de ce point de vue…

Hum, tu ne nomme pas forcément les choses que tu manipule, genre "a = range(3); a[2] = a" mais je comprends un peu ton point de vue.

grim7reaper a écrit :

tshirtman a écrit :
bah, wikipedia a une section sur les paradigmes de dev...
(et oui, un langage qui les fait tous, est parfaitement lisible, fortement typé, bourré de libs surpuissantes, ça existe )
Oui et non, pour parler fonctionnel, bah python c'est pas le pied.
Ok y'a map, filter et les fonctions lambdas mais ça pas mal de langages l'ont maintenant (C++ va l'avoir il me semble, Java l'a, etc).
Mais où est la transparence référentielle ?

Je ne suis pas sur de savoir ce que c'est, je regarderais…

Les structures de données persistantes ?

les tupples et les dicts ça compte?

Ça ce sont des points important (parmi d'autres) pour vraiment profiter du paradigme fonctionnel.
Alors oui, on peut dire que Python peut utiliser un style relativement fonctionnel, mais certainement pas qu'il supporte le paradigme fonctionnel.

Il me semblait qu'avec les itertools, la plupart des besoins étaient couverts…

Sinon, pour la prog logique, il a quoi Python ?

True et False?
non, sinon j'y connais pas grand chose, mais on a pas mal de réponses par là http://www.google.com/search?q=logical+ … +in+python

Non c'est pas unique, c'est le principe du typage dynamique (du moins une des ses implémentation).

ok

Donc oui, le C est faiblement typé.

Bah à partir du moment ou tu fais toutes les choses avec des pointeurs, tu peux faire des programmes faiblements typés

grim7reaper · Le 28/06/2011, à 19:11

Πυλάδης a écrit :

grim7reaper a écrit :
@Pylade : bah le C à un typage faible hein.
Après c'est comme tout, c'est relatif : C est fortement typé par rapport à PHP, mais il est faiblement typé par rapport à la majorité des langages (Haskell, Java, Ada, voire C++, etc).
Donc oui, le C est faiblement typé.
Ben, à partir du moment où une chaîne ne se transforme pas entier comme par magie, pour moi c’est du typage fort.

Bah pourtant, c'en est pas (enfin c'est une base de typage fort, mais sans plus ^^).

Πυλάδης a écrit :

J’ai du mal à voir comme on pourrait typer plus fortement. Peut-être à la façon de Python, avoir un type élémentaire pour les chaînes, et ne pas avoir des chaînes qui ne sont en fait que des tableaux d’entiers terminés par nul ? C’est ça, le typage fort ?

Oui, c'est du typage fort.
Mais on peut typer plus fortement en interdisant les cast, même implicite. Bon là c'est du typage vraiment fort, mais c'est le seul exemple qui me vient à l'esprit.
C'est le cas en Haskell, si une fonction prend un flottant tu ne pourras pas lui passer un entier directement ou caster à la sauvage.

Une fois encore, c'est un domaine assez flou, et pour moi ces notions ont un sens réel seulement dans un cadre relatif. Dans l'absolu c'est bien plus difficile de trancher clairement. Même si on est tous d'accord pour dire que PHP est faiblement typé et Haskell est fortement typée, pour d'autres langages ça reste discutable (mais à mon sens, pas pour le C).

Au passage, une chaîne de caractère c'est pas forcément une suite d'entiers fini pas nul, certains langage (comme Pascal il me semble) ont une autre convention (genre la taille est codé dans le type).

Mais bon le C typée fortement, faut pas déconner non plus.
Un code comme ça compile

int main(void)
{
    int i = 777;
    char c = i;
    double d = 3.14;
    i = d;

    return 0;
}

Oui, les compilos vont émettre des warnings (et encore, gcc sans option ne dis rien), mais un langage est défini par sa norme pas par l'implémentation que les compilos en font. Et ce genre de code, la norme l'autorise.
Donc oui, tu ne peux pas non plus faire n'importe quoi (genre affecter un double à un int*), mais ça n'en fait pas un langage fortement typée pour autant.

ArkSeth a écrit :

Au niveau de la programmation fonctionnelle, je retrouve un peu ce dont je me souvenais, et ça a toujours l'air intéressant, mais j'ai quand même quelques réserves (du genre, le fait qu'il n'y ait pas d'affectations et tout : pour faire des applis en ligne de commande, où on attend une entrée de l'utilisateur pour réagir, ça a l'air super bien, mais j'vois pas comment on peut se servir de ça pour faire des trucs graphiques avec plein de paramètres du genre Emacs ou Sawfish.
Donc j'demande une meilleure explication.

Et pourtant, on peut (vu qu'Emacs existe et bien d'autres existent)
Je voudrais bien détailler, mais je manque un peu de temps là.
À l'occasion, rappelle‑le moi (ptetr plutôt les week‑end ^^) et j'essayerais d'être plus verbeux à ce sujet.

tshirtman a écrit :

grim7reaper a écrit :
[…]
Mais où est la transparence référentielle ?
Je ne suis pas sur de savoir ce que c'est, je regarderais…

C'est dommage, parce que c'est une des clef de voûte de la programmation fonctionnelle.
C'est d'ailleurs un des trucs qui facilite énormément la parallélisation des codes fonctionnels.

Franchement, sans ça je pense pas qu'on puisse dire (sérieusement) que l'on supporte le paradigme fonctionnel.

tshirtman a écrit :

Les structures de données persistantes ?
les tupples et les dicts ça compte?

Je ne suis pas certains qu'ils soient persisants, ils sont peut‑être immutables mais persistant j'ai un doute (je connais pas assez Python pour le dire, il faudrait vérifier).
Car si la persistance implique l'immutabilité, l'inverse n'est pas forcément vrai.

En tout cas s'ils sont vraiment persistant c'est un début, mais c'est clairement insuffisant (car limité à ses seuls types).

tshirtman a écrit :

Ça ce sont des points important (parmi d'autres) pour vraiment profiter du paradigme fonctionnel.
Alors oui, on peut dire que Python peut utiliser un style relativement fonctionnel, mais certainement pas qu'il supporte le paradigme fonctionnel.
Il me semblait qu'avec les itertools, la plupart des besoins étaient couverts…

Faudrait que je vois ce que font les itertools, mais s'il n'y a pas de transparence référencielle (indispensable !!) ni de structures persistantes il reste des besoins très importants à couvrir avant d'affirmer supporter ce paradigme.

Dernière modification par grim7reaper (Le 28/06/2011, à 19:25)

The Uploader · Le 28/06/2011, à 19:22

Effectivement ce n'est pas du typage fort mais statique et faible (pour le C). >_<

M'enfin faible et dynamique c'est le mal : c'est PHP.

Dernière modification par The Uploader (Le 28/06/2011, à 19:23)

tshirtman · Le 28/06/2011, à 19:35

faible, c'est le mal surtout

@grim: ben les gens qui aiment coder fonctionnels disent que ça se fait bien en python, même s'il manque des trucs, et guido n'a jamais vraiment cherché à faire un langage fonctionnel (pas dans le sens "qui marche" ^^').
un bon résumé ici je pense: http://stackoverflow.com/questions/1017 … rogramming

grim7reaper · Le 28/06/2011, à 19:42

Jdis pas le contraire, c'est juste que dire que Python supporte le fonctionnel ça m'a fait tiquer.
Qu'il propose pas mal d'outil pour c'est vrai, et ça permet de coder avec un style fonctionnel assez simplement (et de manière pas trop moche pour ce que j'en ai vu), mais pour moi ça reste différent de « supporter le paradigme fonctionnel ».

(sinon là j'ai survolé très (très !) rapidement le lien et ça semble confirmer ce que je disait, j'essayerais de le relire plus attentivement plus tard).

Dr Le Rouge · Le 28/06/2011, à 19:48

ArkSeth a écrit :

Πυλάδης a écrit :
Je proteste. 2/2 et 1, c’est le même nombre ; on a juste deux représentations différentes. Donc t’as une relation d’égalité, stou.
Ou pas.
C'est la même classe d'équivalence, à savoir les trucs qui ont la valeur 1, mais ça n'est pas le même nombre. Dixit ma prof de maths à l'IUFM (qui avait donné une vraie explication, mais dont j'me souviens pas, j'aurais du prendre plus de notes).

Tout dépend de ce qu'on entend par égalité... Dans Q (ensemble des rationnels), 2/2 est dans la même classe d'équivalence que 1 (la relation étant un truc du style "p/q R p'/q' <=> (il existe (m,n) dans Z tel que p'*m = p*n, q'*m = q*n et PGCD(p',q') = 1"). Mais si on définit Q comme l'ensemble des couples (n,m) avec n et m dans Z, 2/2 n'est pas égal à 1 (2!=1).

C'est pourquoi on ne le fait pas : Q est un corps si on considère non pas les couples d'entier mais leur classes d'équivalence pour le R défini ci-dessus. Comme (2/2 R 1/1), on dit que 2/2=1.

En fait, l'égalité en maths, c'est souvent un abus de langage (genre des fonctions "égales" au sens de Lebesgue dont la valeur diffère en une infinité de points)...

tshirtman · Le 28/06/2011, à 19:50

@ArkSeth: PyPy est une implémentation de python en Rpython qui supporte le JIT compiling, et aussi un compilateur Rpython → C. (qui compile donc le premier en un CPython bien plus efficace pour beaucoup de choses).

Pylades · Le 28/06/2011, à 19:54

ArkSeth a écrit :

Πυλάδης a écrit :
Je proteste. 2/2 et 1, c’est le même nombre ; on a juste deux représentations différentes. Donc t’as une relation d’égalité, stou.
Ou pas.
C'est la même classe d'équivalence, à savoir les trucs qui ont la valeur 1, mais ça n'est pas le même nombre. Dixit ma prof de maths à l'IUFM (qui avait donné une vraie explication, mais dont j'me souviens pas, j'aurais du prendre plus de notes).

Ouais ben faudrait une belle explication, là, c’est un peu gros ton truc… On appelle Le Rouge ?

Édit : OK, Le Rouge est passé. ^^
Donc ouais, en pratique en programmation, on voit juste ℤ et ℝ comme un ensemble nombres, point. Jouons pas au plus con.

Édit : en plus en programmation on ne bosse même pas sur ℤ et ℝ !
(Même si Python permet de bosser sur ℤ entier.)

ArkSeth a écrit :

D'après le passage de Wikipédia qui ne te plait pas, j'en viens à supposer qu'en typage fort, un truc déclaré d'un type particulier ne peut pas être utilisé comme d'un autre type, même quand les types sont aussi proche que short et int (d'après l'exemple) ou int et char (d'après mon extrapolation personnelle et le fait que je considère que 2/2 et 1 soient deux entités différentes, bien que de même classe d'équivalence (c'est la même logique, je pense)).

short et int, c’est le même type de données, c’est juste la taille qui change (et encore, pas sur toutes les plate-formes). Donc oui, ça peut avoir des comportement différent ; mais à l’intérieur tu n’as pas deux choses différentes, t’as un entier. Pis avec toutes les conversions implicites qui se déroulent lorsque l’on applique un opérateur à deux entiers, ces différences sont toutes relatives.
T’additionneras jamais un entier et un champ de bits, en C…

tshirtman a écrit :

C'est une implémentation de l'opérateur ternaire, que ce soit "?" et ":" ou "if" et "else", c'est la même chose…

Ouais mais c’est trop verbeux, justement…

tshirtman a écrit :

Hum, tu ne nomme pas forcément les choses que tu manipule, genre "a = range(3); a[2] = a" mais je comprends un peu ton point de vue.

Ben là tu utilises un nom, a.
Pour accéder à a[2] t’es bien obligé de passer par a.

Et puis cette construction est tout simplement ignoble (d’ailleurs Python 3 refuse, et t’obtiens un truc vraiment étrange avec Python 2, qui justement montre bien que tout n’est que nom).

Mais c’est avec range(3)[2] que tu ne passes pas par un nom (à part range, qui en est un aussi).

grim7reaper a écrit :

Mais bon le C typée fortement, faut pas déconner non plus.
Un code comme ça compile
int main(void)
{
    int i = 777;
    char c = i;
    double d = 3.14;
    i = d;

    return 0;
}
Oui, les compilos vont émettre des warnings (et encore, gcc sans option ne dis rien), mais un langage est défini par sa norme pas par l'implémentation que les compilos en font. Et ce genre de code, la norme l'autorise.
Donc oui, tu ne peux pas non plus faire n'importe quoi (genre affecter un double à un int*), mais ça n'en fait pas un langage fortement typée pour autant.

Ouais, j’avais oublié que ce genre d’horreur peut compiler. Le C est laxiste.
Tiens, c’est encore un défaut du C, pour moi. Je pense qu’on ne devrait jamais pouvoir compiler la sixième ligne…

Dernière modification par Πυλάδης (Le 28/06/2011, à 20:03)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#576 Le 28/06/2011, à 16:06

Re : /* Topic des codeurs couche-tard [5] */

#577 Le 28/06/2011, à 16:15

Re : /* Topic des codeurs couche-tard [5] */

#578 Le 28/06/2011, à 16:32

Re : /* Topic des codeurs couche-tard [5] */

#579 Le 28/06/2011, à 16:59

Re : /* Topic des codeurs couche-tard [5] */

#580 Le 28/06/2011, à 17:15

Re : /* Topic des codeurs couche-tard [5] */

#581 Le 28/06/2011, à 17:42

Re : /* Topic des codeurs couche-tard [5] */

#582 Le 28/06/2011, à 17:42

Re : /* Topic des codeurs couche-tard [5] */

#583 Le 28/06/2011, à 17:45

Re : /* Topic des codeurs couche-tard [5] */

#584 Le 28/06/2011, à 17:57

Re : /* Topic des codeurs couche-tard [5] */

#585 Le 28/06/2011, à 18:07

Re : /* Topic des codeurs couche-tard [5] */

#586 Le 28/06/2011, à 18:11

Re : /* Topic des codeurs couche-tard [5] */

#587 Le 28/06/2011, à 18:25

Re : /* Topic des codeurs couche-tard [5] */

#588 Le 28/06/2011, à 18:29

Re : /* Topic des codeurs couche-tard [5] */

#589 Le 28/06/2011, à 18:36

Re : /* Topic des codeurs couche-tard [5] */

#590 Le 28/06/2011, à 18:49

Re : /* Topic des codeurs couche-tard [5] */

#591 Le 28/06/2011, à 18:49

Re : /* Topic des codeurs couche-tard [5] */

#592 Le 28/06/2011, à 18:52

Re : /* Topic des codeurs couche-tard [5] */

#593 Le 28/06/2011, à 19:07

Re : /* Topic des codeurs couche-tard [5] */

#594 Le 28/06/2011, à 19:11

Re : /* Topic des codeurs couche-tard [5] */

#595 Le 28/06/2011, à 19:22

Re : /* Topic des codeurs couche-tard [5] */

#596 Le 28/06/2011, à 19:35

Re : /* Topic des codeurs couche-tard [5] */

#597 Le 28/06/2011, à 19:42

Re : /* Topic des codeurs couche-tard [5] */

#598 Le 28/06/2011, à 19:48

Re : /* Topic des codeurs couche-tard [5] */

#599 Le 28/06/2011, à 19:50

Re : /* Topic des codeurs couche-tard [5] */

#600 Le 28/06/2011, à 19:54

Re : /* Topic des codeurs couche-tard [5] */

Pied de page des forums