Faut-il simplifier la programmation et revoir ses fondements ? Un journaliste s'essaye au développement

Bonjour à tous,

Ce que je pense du blog*?
Si on veut être méchant, ça ressemble à une crise nerveuse de quelqu'un agacé par quelque chose qui le dépasse*: ça c'est fait.
Mais soyons plus constructif*:
En premier lieu du haut de très nombreuses années d'utilisation de nombreux langages de programmation et de script, je peux dire que ce n'est pas dans le langage que réside complexité informatique.
En effet, et particulièrement avec les systèmes assistés comme par exemple Eclipse, Netbean, Visual Studio ou Xcode pour l'Objective C d'Apple, la syntaxe s'apprend assez rapidement et il est même difficile de faire une erreur de syntaxe non signalée et non auto-corrigée.
Pour gérer les événements, de nombreux "Wizards" sont disponibles.
Ce qui est compliqué, c'est précisément traduire notre «*pensée humaine*» en code rigoureux et non ambigu.
Souvent, et même chez les professionnels de l'informatique, il s'avère déjà difficile de traduire sa pensée en langage naturel qui ne comporte pas d'ambigüité*: Pourtant, c'est la première étape cruciale du développement informatique.
Je conseillerait une démarche à M. Tompkins*:

Suivre le tutoriel de Xcode en essayant de comprendre ce qui est proposé (programmer c'est penser, pas cliquer!)
Lire le maximum de doc d'Apple sur le sujet*: elle est très bien faite (En anglais, mais ce langage n'est pas trop compliqué pour lui non?)
Faire quelques exemple très très simples.
Quand il aura assimilé le fonctionnement technique (c'est comme la voiture, pourtant accessible à tout le monde, il faut des heures de conduite accompagnée avant de se lancer seul sur la route), bien mettre sur papier la description précise de ce que doit faire son programme en partant du plus général au plus détaillé (évidemment l'idéal serait de connaître UML, mais je crains que ça lui fasse peur) et ensuite, seulement à ce moment là, commencer à programmer son application.

La programmation n'est ni trop complexe ni trop simple*: comme le dit lui même M. Tompkins, il y a plus de 40 ans d'évolution des langages. Quand on n'a pas connu les langages de première, 2ième voire 3ieme génération, on peut ne pas comprendre certaines subtilité de la syntaxe et de la sémantique des langages d'aujourd'hui.
Ce qui est compliqué, c'est ce que l'on veut faire faire à l'informatique maintenant*:
La gestion multimédia, les accès distant et partagés, les communications hétérogènes,le multilinguisme, la répartition de charge, le multi-tâche, une gestion accrue de la sécurité, le traitement de quantités de données de plus en plus important et j'en passe (beaucoup) et des meilleures.
Le mythe du «*je pense, donc je programme*» existe mais il ne sera pas résolu de sitôt.

Allez, un dernier clin d’œil*:
Quand j'ai appris à faire du vélo, je n'arrêtais pas de tomber dans un tas de cendres froides. J'ai tourné toute la journée autour jusqu'à ne plus tomber. Ensuite, j'ai pu partir tranquillement en suivant les allées*: eh, oui rien n'est facile quand on veut faire par soi même*!

Citation:

---

Envoyé par TropMDR

Ensuite, j'aimerais bien savoir pourquoi les langages fonctionnelles n'auraient "rien de conceptuellement commun avec ce que pense le commun des mortels".

---

Juste pour le fun, des exemples qui m'int été donné lors d'un débat ici-même :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

-- infinite lists of triangle, pentagonal, hexagonal numbers tries = scanl1 (+) [1..] pents = scanl1 (+) [1,4..] hexas = scanl1 (+) [1,5..] -- intersection (of sorted lists, infinite or not) [] /\ _ = [] _ /\ [] = [] xxs@(x:xs) /\ yys@(y:ys) = case compare x y of LT -> xs /\ yys EQ -> x : (xs /\ ys) GT -> xxs /\ ys -- should be (tries /\ pents /\ hexas) but all hexas are tries main = print $ (pents /\ hexas) !! 2

---

T'appeles ça compréhensible pour le commun des mortels ????



Mais on peut aussi y mettre d'autres exemples donnés aussi dans des débats ici :

Code:

---

1 2 3 4 5 6 7

class image = object val mutable l : surf list = [] method add s = l <- s :: l method surface = List.fold_left (fun acc s -> acc +. s#surface) 0. l end;;

---

Code:

---

1 2 3

val rect : < shrinkx : float -> unit; shrinky : float -> unit; surface : float > = <obj>

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

let rect = object val mutable sdx = 1. val mutable sdy = 2. method shrinkx sx = sdx <- sdx *. sx method shrinky sy = sdy <- sdy *. sy method surface = sdx *. sdy end;;

---

Pas plus.. :aie:

Citation:

---

Envoyé par souviron34

[] /\ _ = []
_ /\ [] = []

---

Citation:

---

Envoyé par souviron34

xs /\ yys
x : (xs /\ ys)
xxs /\ ys

---

Au début, j'ai lu vite j'ai cru que c'était de l'Art ASCII :aie:

Très modestement, ce qu'il faudrait, c'est modéliser le fonctionnement humain dans tout ce qu'il a de variable et de surprenant et mettre tout cela dans une bibliothèque. Bref, créer un cerveau mais sans volonté ni désir: ces deux derniers attributs resteraient la prérogative du développeur improvisé. Cool !
Notre journaliste rêve de devenir dieu :)

Je developpe en C++ et franchement ? Heureusement que c'est "dur" (c'a l'est? :) ) sinon tout lemonde pourait faire mon job. Oh et puis cet article me fait penser a une chose ou pluto me rappelle qq chose, depuis que je travaille (13 ans) j'ai tres souvent eu la nette impression venant des industriel, directeur de projet ou autre personne n'ayant absolument aucune notion de programation (ily en a en ches les dir de proj aussi...) qu'en fait mon job c'est FACILE. "Oh mais y a qu'a.... Faut qu'on.....". Bref a tous ces gens la et a monsieur le journaliste, c'est tres simple, c'est un boulot a part entierre, y en a qui font 4 a 5 annees d'etude pour ca et il ne sont meme pas bon dans ce qu'ils font. Qu l'on arrete de denigrer le travail de certain et que l'on rende a cesar ce qui appartien a cesar.

A bon entendeur, salut :D

Citation:

---

Envoyé par tendu1

"Oh mais y a qu'a.... Faut qu'on....."

---

C'est pour cela qu'on appelle ce type de gens les Yakafokon. ils pullulent dans pas mal de boîtes.

On a aussi les "Deumontan" qui commencent toutes leurs phrases par "De mon temps, ... suivi d'une grosse connerie" (ex: De mon temps, en 85, les webservices on les faisait juste en URL simple (comprenez HTTP-GET))

Enfin on a les "Jlavédi" qui ne foutent absolument rien, qui disent que rien ne fonctionnera jamais et qui apparaissent comme des diables sortant de leurs boîte pour vous enfoncer en cas d'erreur en disant "Je vous l'avais dit" et qui s'évaporent de nouveau dans l'ombre en attendant l'heure de votre prochaine bévue.

J'oublais les "Pffeu", qui à défaut d'être méchants sont carréments pénibles. Ils vivent souvent dans les bureaux proches du développeurs et passent leurs journées à dire continuellement "Pff, ... c'est de la m**** ... boulot de m**** ... pff" jusqu'à ce que vos nerfs lâchent et que vous lui hurlier dans les oreilles "T'as qu'a démissionner, C*****" ou "Fais moi plaisir, machin, vas jouer dans une bétonneuse !!"

Quand j'ai fait mes études, il y avait le basic, le cobol et le fortran, tous trois facile à apprendre en quelques heures et cours et un peu d'expérimentation.
Puis sont arrivés les premiers microprocesseurs et l'assembleur. Egalement simple à appréhender, très puissant, mais qui impose de bien connaître le hardware de la machine utilisée.
Puis sont arrivés le C et le Pascal. Le Pascal, assez limité, ne cause aucune gêne pour son apprentissage car toutes les règles et syntaxes sont connues et simples. Par contre, le C, même si on l'utilise basiquement, a une syntaxe plus complexe. Il a de plus des possibilités plus ou moins cachées qui n'apparaissent pas dans les docs et ne sont pas enseignées. Ce sont ces possibilités qui sont largement utilisées par les développeurs experts et qui rendent ce langage incompréhensible.
Puis sont arrivés les langages dits "objets", Borland C++ et tous les autres. Si leur principe est théoriquement très simple, il faut bien se rendre à l'évidence que les syntaxes utilisées complexifient énormément leur apprentissage.

Et il n'y a pas que la syntaxe qui rebute. Le paramétrage de Microsoft Visual C++ est toujours une source d'angoisse, même pour un développeur expérimenté. Au bout de X années, il a compris qu'il y avait certains paramètres à ne pas toucher, que d'autres étaient souvent sources d'erreurs, etc ..., sans en comprendre les raisons.

La question n'est pas seulement la syntaxe du langage, mais aussi par exemple :
- comment et où vais je trouver les fichiers exécutables nécessaires pour diffuser mon application ?
- comment trouver une bibliothèque pour ouvrir des images ?
- comment faire une IHM ?

Il y a quelques décennies, le logiciel était souple et était largement utilisé pour compenser les défauts du matériel.
Aujourd'hui, les responsables de projet cherchent à modifier le matériel pour compenser les bugs et les manquements du logiciel.

Citation:

---

Envoyé par jope004

Quand j'ai fait mes études, il y avait le basic, le cobol et le fortran, tous trois facile à apprendre en quelques heures et cours et un peu d'expérimentation.
Puis sont arrivés les premiers microprocesseurs et l'assembleur. Egalement simple à appréhender, très puissant, mais qui impose de bien connaître le hardware de la machine utilisée.
Puis sont arrivés le C et le Pascal. Le Pascal, assez limité, ne cause aucune gêne pour son apprentissage car toutes les règles et syntaxes sont connues et simples. Par contre, le C, même si on l'utilise basiquement, a une syntaxe plus complexe. Il a de plus des possibilités plus ou moins cachées qui n'apparaissent pas dans les docs et ne sont pas enseignées. Ce sont ces possibilités qui sont largement utilisées par les développeurs experts et qui rendent ce langage incompréhensible.
Puis sont arrivés les langages dits "objets", Borland C++ et tous les autres. Si leur principe est théoriquement très simple, il faut bien se rendre à l'évidence que les syntaxes utilisées complexifient énormément leur apprentissage.

Et il n'y a pas que la syntaxe qui rebute. Le paramétrage de Microsoft Visual C++ est toujours une source d'angoisse, même pour un développeur expérimenté. Au bout de X années, il a compris qu'il y avait certains paramètres à ne pas toucher, que d'autres étaient souvent sources d'erreurs, etc ..., sans en comprendre les raisons.

La question n'est pas seulement la syntaxe du langage, mais aussi par exemple :
- comment et où vais je trouver les fichiers exécutables nécessaires pour diffuser mon application ?
- comment trouver une bibliothèque pour ouvrir des images ?
- comment faire une IHM ?

Il y a quelques décennies, le logiciel était souple et était largement utilisé pour compenser les défauts du matériel.
Aujourd'hui, les responsables de projet cherchent à modifier le matériel pour compenser les bugs et les manquements du logiciel.

---

Objection votre honneur ! (J'ai toujours rêvé de dire cela en vrai :mrgreen:)

J'ai codé en Fortran 77 pendant 3 ans et ok, la syntaxe est simple.
Cependant essaye de coder un Wow ou même un simple doom-like en basic ou fortran.

Le problème de mon point de vue n'est pas que le langage est trop complexe pour l'utilisateur néophyte mais que ce dernier n'est pas assez humble.

Dans la programmation comme dans bien des domaines on commence par apprendre avant de faire tel le bébé qui fait du 4 pattes avant de courir.

Mais ce point a déjà été soulevé précédemment

Clairement (comme disait A Breton), si il y a un problème dans le développement ou l'informatique en général, c'est de toujours rechercher le "salut" dans un nouveau modèle, syntaxe, etc, alors que le "problème" (ça n'en est pas un) et le fait de ne pas reconnaitre que ce qui est nécessaire est une source d'étiquettes communes dont les vannes sont largement ouvertes, ou autrement dit le partage d'un énorme paquet d'épingles. Ce qui pourrait être caractérisé comme une version paroxystique du "cordonnier toujours le plus mal chaussé", en quelque sorte ..

Déjà évoqué là :
http://www.developpez.net/forums/d10...-personnelles/

Et proposition à ce sujet présentée ici :
http://iiscn.wordpress.com/about/

Citation:

---

Envoyé par souviron34

Juste pour le fun, des exemples qui m'int été donné lors d'un débat ici-même

---

La première fois qu'on t'a collé un code impératif sous les yeux, ça t'a semblé évident ? Moi non plus. Oui, la prog fonctionnelle nécessite un réapprentissage. Mais, crois-moi, ça vaut le coup, elle enseigne d'autres façons de penser qui sont utiles pour résoudre certains problèmes.

@zeyr2mejetrem
Demontan on ne programmait qu'en Basic et c'était très bien ! Jlavédit qu'on allait tout compliquer pour rien avec ces nouveaux trucs à la mode. Faukon revienne au Basic ! Yaka se plaindre suffisamment et ils finiront tous pas céder et enterrer tous ces nouveaux langages idiots. Pffffeuh !
:zoubi:

Citation:

---

Envoyé par jope004

La question n'est pas seulement la syntaxe du langage, mais aussi par exemple :
- comment et où vais je trouver les fichiers exécutables nécessaires pour diffuser mon application ?
- comment trouver une bibliothèque pour ouvrir des images ?
- comment faire une IHM ?

Il y a quelques décennies, le logiciel était souple et était largement utilisé pour compenser les défauts du matériel.
Aujourd'hui, les responsables de projet cherchent à modifier le matériel pour compenser les bugs et les manquements du logiciel.

---

Bien vu !

En fait, il n'y a pas de différence fondamentale entre logiciel et matériel, des artefacts ou creations humaines dans les deux cas, et d'autre part un circuit intégré se définit avec un éditeur logiciel à travers un format ou langage approprié avant d'être imprimé, et une fonction logicielle peut aussi être transférée sous forme de circuit intégré, si il y a une différence, c'est dans le fait de croire que le soft serait soft, alors qu'il n'y a rien de moins soft ou plus "cristallin" que du soft !
Il serait temps de s'en rendre compte ..

Citation:

---

Envoyé par YvesT75

En fait, il n'y a pas de différence fondamentale entre logiciel et matériel, des artefacts ou creations humaines dans les deux cas, et d'autre part un circuit intégré se définit avec un éditeur logiciel à travers un format ou langage approprié avant d'être imprimé, et une fonction logicielle peut aussi être transférée sous forme de circuit intégré, si il y a une différence, c'est dans le fait de croire que le soft serait soft, alors qu'il n'y a rien de moins soft ou plus "cristallin" que du soft !
Il serait temps de s'en rendre compte ..

---

J'ai cru comprendre que le paradigme fonctionnel est plus adapté à la programmation parallèle.

Citation:

---

Envoyé par chaplin

J'ai cru comprendre que le paradigme fonctionnel est plus adapté à la programmation parallèle.

---

Oui possible, mais il s'agit aussi de dire que dans les deux cas ce sont des publications, des livres en quelque sorte (même si dans le cas du soft, souvent une seule instance active dans tout ce qui est plus ou moins de l'informatique de gestion ou systèmes autour des telecoms par exemple).

Un informaticien est par excellence quelqu'un d’opiniâtre. Cela signifie qu'il ne peut se résoudre à ne pas solutionner un problème posé.
Par cet état de fait, je pense que la difficulté n'est pas dans le langage mais dans l'individu lui même. Un projet informatique, pour certains novices, peut devenir très vite insurmontable.
Pourquoi ? Tout simplement parce qu'il doit avoir de la patience et que, comme tout autre langage, il lui manque ce que l'on appelle : l'expérience. C'est en butant, en passant des heures sur une situation qu'il va enfin trouver la solution. Parfois, il découvre que l'idée d'origine qu'il avait envisagée n'était pas la meilleure solution. C'est la deuxième qualité que l'on reproche souvent à un informaticien : son perfectionnisme. Plus tard arrive une troisième qualité, après un acquis conséquent et des heures à plancher : l'optimisation. Il peut, par exemple, réécrire un programme car il vient de découvrir une philosophie ou une méthodologie plus appropriée.
En fin de compte l'informaticien forge ses compétences tout au long de ses réalisations, car il apprend à solutionner des projets pour les concrétiser et coller au plus prêt au cahier des charges. Il doit constamment se remettre en question vis à vis du demandeur, des besoins et de l'évolution technologique. la complexité réside surtout dans le fait qu'il est en continuel apprentissage, car il veut toujours solutionner une situation demandée... C'est cela qui fait la complexité.

Citation:

---

Envoyé par Luc Hermitte

Parce que le commun des mortels quand il donne des recettes de cuisine ou des directions pour aller quelque part il le fait en impératif ?

---

Encore une fois, je ne pense pas qu'un des paradigmes soit incomparablement mieux que l'autre. C'est d'ailleurs pour ça que je préfère personnellement ocaml à haskell, parce qu'il me permet (naturellement) de faire de l'impératif (avec boucles, tableaux et références) quand je le veux, même si le style habituel du langage est plus le fonctionnel. En gros il tente de contrarier le moins possible les habitudes !

Pour ce qui est des recettes de cuisine, oui, c'est principalement impératif. Mais il y a quand même des traits "haut niveau" qui s'approche de la vision fonctionnelle. Par exemple, si on dit "émincer les oignons". L'action émincer a été définie de façon très impérative (prendre un couteau, couper en fine tranche, etc). Néanmoins pour la phrase "émincer les oignons", on approche plus d'une vision fonctionnelle "map emincer oignons" (ou iter). On ne dit pas comment on passe d'un oignon à l'autre, juste qu'il faut le faire sur tous les oignons. Dans les langages impératifs typique (je ne parle pas des ajouts plus ou moins récents de constructeurs foreach par exemple), il aurait fallu dire "tant qu'il ne reste pas d'oignon dans l'assiette, en prendre un, l'émincer, et recommencer". Disons qu'aux feuilles (pour décrire certaines opérations précise), on est en impératif. Mais aux nœuds, pour décrire l'association de ces opérations élémentaires, on a une approche plus fonctionnelle de "appliquer l'opération élémentaire à tous les...".

Après, l'approche fonctionnelle et l'approche impérative sont tous les deux des paradigmes de calcul créés par l'être humain. La frontière entre les deux est évidement floue, d'autant plus lorsque l'on tente de catégorise des algorithme non informatique. Ce qui peut donner une impression de mauvaise foi, dans un sens comme dans l'autre :)

L'informatique ne résout pas des problèmes, elle écrit des solutions

Citation:

---

Envoyé par souviron34

Juste pour le fun, des exemples qui m'int été donné lors d'un débat ici-même :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

-- infinite lists of triangle, pentagonal, hexagonal numbers tries = scanl1 (+) [1..] pents = scanl1 (+) [1,4..] hexas = scanl1 (+) [1,5..] -- intersection (of sorted lists, infinite or not) [] /\ _ = [] _ /\ [] = [] xxs@(x:xs) /\ yys@(y:ys) = case compare x y of LT -> xs /\ yys EQ -> x : (xs /\ ys) GT -> xxs /\ ys -- should be (tries /\ pents /\ hexas) but all hexas are tries main = print $ (pents /\ hexas) !! 2

---

T'appeles ça compréhensible pour le commun des mortels ????

---

Si "commun des mortels" == "personnes qui ont fait du C toute leur vie et n'ont jamais pris la peine de regarder autre chose" ou alors "commun des mortels" == "personnes qui pensent que tout doit être clair et limpide au premier coup d'oeil sinon c'est pas bon" (genre notre journaliste), clairement pas. Après si on parle de personne qui font un minimum d'effort pour se rendre compte qu'il y a parfois un petit cout d'entrée, ça devrait le faire.

Première chose, dans les langages fonctionnels à la caml/haskell, l'application de fonction se fait par simple juxtaposition. Par exemple "f x" est l'application de f à x. Ensuite quand on a plusieurs arguments, ça donne "f x y".

Autre feature de haskell, la définition de liste de façon concise. Par exemple [1,2..] est la liste de tous les entier à partir de 1 (elle peut en fait s'écrire [1..]). [1,3..] sera la liste de tous les entiers impairs. [1,3..100] sera celle de tous les entiers impair entre 1 et 100. Tu vas me dire que pour quelqu'un ayant fait plus qu'un semestre d'université de maths ça dépasse l'entendement ?

Donc

Code:

---

tries = scanl1 (+) [1..]

---

défini la valeur de tries comme étant l'application de la fonction scanl1 à la fonction + et à la liste des entiers plus grand que 1. Bien sûr, si on ne connait pas scanl1, on ne peut pas comprendre. Mais si on lit du C et qu'on rencontre la fonction a2i, il est peut probable qu'on s'en sorte aussi... Un petit saut par la doc de haskell nous apprends qu'on obtient en fait la liste [1, 1+2, 1+2+3, etc].

Ensuite, la syntaxe pour les liste est:

• [] : liste vide
• x : xs : liste qui a x pour tête et xs pour queue

Donc regardons

Code:

---

1 2 3 4 5 6 7 8

-- intersection (of sorted lists, infinite or not) [] /\ _ = [] _ /\ [] = [] xxs@(x:xs) /\ yys@(y:ys) = case compare x y of LT -> xs /\ yys EQ -> x : (xs /\ ys) GT -> xxs /\ ys

---

Là le commentaire nous dit qu'on défini l'intersection de deux listes. Comment est ce qu'on définirait ça ? Alors, l'intersection d'une liste vide et de n'importe quoi, c'est la liste vide

Code:

---

[] /\ _ = []

---

L'intersection de n'importe quoi et de la liste vide, c'est encore la liste vide

Code:

---

_ /\ [] = []

---

L'intersection des listes x : xs et y:ys, liste que nous appellerons xxs et yys pour simplifier dépend de x et y.
Si x est strictement plus petit que y, alors x n'est pas non plus dans ys (les listes sont triées), donc il n'est pas dans l'intersection. On le jette, et on prend l'intersection de xs avec yys (on ne jette surtout pas y !)
Si x et y sont égaux, alors on garde la valeur commune, et on fait l'intersection du reste
Si y est strictement plus petit que x, alors on le jette, et on calcule l'intersection de xxs avec ys.

Code:

---

1 2 3 4 5

xxs@(x:xs) /\ yys@(y:ys) = case compare x y of LT -> xs /\ yys EQ -> x : (xs /\ ys) GT -> xxs /\ ys

---

Voilà, on a fait une définition par cas de l'intersection, avec dans un des cas, trois sous cas suivant l'ordre de x et y.

C'est vraiment si imbitable que ça, surtout pour quelqu'un qui dit avoir fait des études scientifiques très poussées ? C'est amusant, moi ça me semble très très très proche des définitions que l'ont voit en math.

Citation:

---

Envoyé par souviron34

Mais on peut aussi y mettre d'autres exemples donnés aussi dans des débats ici :

---

Et bien continuons alors

Citation:

---

Envoyé par souviron34

Code:

---

1 2 3 4 5 6 7

class image = object val mutable l : surf list = [] method add s = l <- s :: l method surface = List.fold_left (fun acc s -> acc +. s#surface) 0. l end;;

---

---

Donc on dit que la classe image construit un objet. Cet objet contient une valeur mutable l qui est une liste de surface initialement vide. Il a aussi une méthode add qui attend en argument un s et l'ajoute à l (si la syntaxe l <- s :: l semble choquante, il ne faut surtout pas aller lire de pseudo code).
Il y a ensuite une méthode "surface" qui calcule la surface totale de l'image et sommant toutes les surfaces de ses composants. Effectivement, l'usage de fold_left peut troubler. Néanmoins, juste en lisant la doc, on comprends ce qu'ils se passe.

Vraiment si peu compréhensible ?

Citation:

---

Envoyé par souviron34

Code:

---

1 2 3

val rect : < shrinkx : float -> unit; shrinky : float -> unit; surface : float > = <obj>

---

---

Maintenant tu attaques donc la syntaxe des types. Effectivement, venant du monde C, tu es habitué à plus simple, genre "struct tag (*[5])(float)" ou "int f(int (*)(char *), double(*)[])".
Mais une fois que l'on sait que <meth1:typ1; meth2:typ2...> c'est le type des objets qui ont une méthode meth1 de type typ1 et meth2 de type typ2 (notation finalement pas totalement absurde), bah on voit que rect est un objet ayant les méthodes shrinkx, qui prend un float et fait une action, shrinky, de même type, et surface, qui retourne juste un float. Le = <obj> à la fin, c'est juste le top level qui dit qu'il n'a pas de printer générique pour les objets, et affiche donc juste "<obj>". Toujours aussi illisible ?

Et pour finir:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

let rect = object val mutable sdx = 1. val mutable sdy = 2. method shrinkx sx = sdx <- sdx *. sx method shrinky sy = sdy <- sdy *. sy method surface = sdx *. sdy end;;

---

Effectivement, OCaml permet de définir des objets localement, sans passer par la définition d'une classe intermédiaire, ce qui peut paraitre choquant quand on vient d'autres langages objets typés. Donc rect est directement un objet qui contient deux valeurs mutables sdy et sdy et trois méthodes (dont les types ont été donné au dessus).

Citation:

---

Envoyé par souviron34

Pas plus.. :aie:

---

Au final, tout ce qui fait que tu trouves que ce n'est pas compréhensible, c'est que tu ne t'es jamais penché sur la syntaxe de ces langages et encore moins sur leur philosophie, et tu en déduis que puisque ce n'est pas la même que celle dont tu as l'habitude, c'est une absurdité. Au final, tu n'es pas plus ouvert que le journaliste dont tout le monde se moque depuis 11 pages de troll. Tu n'acceptes pas qu'un domaine nouveau puisse avoir un coût d'entré non nul, et tu penses que "vu ton niveau", tout devrait t'être immédiatement accessible. C'est un peu dommage je trouve pour un esprit scientifique.

Il faudrait lui programmer un IDE totalement wysig à ce garçon, ça ferait son bonheur. Perso j'ai pas de temps à investir dans une application tournant sur une plateforme propriétaire unique.

Il n'y a pas que dans la programmation que l'effort est indispensable pour obtenir des résultats. En sport c'est la même.

Citation:

---

Envoyé par TropMDR

Pour ce qui est des recettes de cuisine, oui, c'est principalement impératif. Mais il y a quand même des traits "haut niveau" qui s'approche de la vision fonctionnelle. Par exemple, si on dit "émincer les oignons". L'action émincer a été définie de façon très impérative (prendre un couteau, couper en fine tranche, etc). Néanmoins pour la phrase "émincer les oignons", on approche plus d'une vision fonctionnelle "map emincer oignons" (ou iter). On ne dit pas comment on passe d'un oignon à l'autre, juste qu'il faut le faire sur tous les oignons. Dans les langages impératifs typique (je ne parle pas des ajouts plus ou moins récents de constructeurs foreach par exemple), il aurait fallu dire "tant qu'il ne reste pas d'oignon dans l'assiette, en prendre un, l'émincer, et recommencer".

---

Ada et bourne shell ne sont ni récents ni fonctionnels.
"Pour tout x vérifiant P(x) faire" est une veille propriété chez plus d'un langage impératif.

Au fait, je n'ai pas dit que c'était mieux. Juste que c'est plus intuitif (/naturel) pour le commun des mortels car c'est déjà ainsi qu'il donne des instructions à ses congénères (une machine n'étant pas un congénère)