Discussion :

[LLB]

Vraiment sympa la syntaxe F# j'aimerai bien un petit mix entre C# et F#

Je ne vois pas bien ce que tu voudrais. D'un côté, tu peux coder en F# comme tu le ferais en C#. Les différences
de syntaxe ne sont pas énormes (un peu comme C# comparé à VB.NET) et c'est
facile de porter du C# en F#.

D'un autre côté, tu as beaucoup de fonctionnalités disponibles en plus
(certaines viennent de Caml, d'autres d'ailleurs, et certaines sont assez
innovantes).

Par contre qu'est ce que tu veux dire par "plus de choses" ?

La comparaison reste délicate car ça concerne dans fonctionnalités qui ne sont pas dans C#, mais dans l'ensemble le style de programmation que F# t'incite à adopter offre beaucoup plus de sûreté. Certaines constructions (comme le pattern matching) vérifient que ton code gère bien tous les cas ; si tu oublies un cas ou si un cas est traité en double, le compilateur te prévient et te donne un exemple de problème. La valeur null est quasiment enlevée (sauf pour l'interopérabilité) du langage, au profit d'un type option. De cette façon, on ne peut pas oublier de traiter le cas où il n'y a pas de valeur.

Le système de typage est aussi beaucoup plus fin et tu peux même indiquer l'unité de mesure de tes valeurs numériques. Le compilateur t'interdit alors d'additionner des mètres et des secondes, mais tu peux les diviser (et le compilateur déduit tout seul l'unité du résultat). Le compilateur est aussi plus strict et empêche bon nombre de conversions implicites (on ne peut pas mélanger des int et des float par exemple).

(Comme la conversation dévie, elle peut être continuée dans le forum F#)

[anthyme]

Je ne vois pas bien ce que tu voudrais. D'un côté, tu peux coder en F# comme tu le ferais en C#. Les différences
de syntaxe ne sont pas énormes (un peu comme C# comparé à VB.NET) et c'est
facile de porter du C# en F#.

Le problème c'est que même si F#a des cotés très intéressant, je ne suis pas fan de tout ce qui est fait en F# conne cette syntaxe un peu violente d'affectation (par exemple une définition de classe est affecté dans le nom de la classe) et il n'est pas possible de créer une classe F# au milieu d'un projet C#

D'un autre côté, tu as beaucoup de fonctionnalités disponibles en plus
(certaines viennent de Caml, d'autres d'ailleurs, et certaines sont assez
innovantes).

La comparaison reste délicate car ça concerne dans fonctionnalités qui ne sont pas dans C#, mais dans l'ensemble le style de programmation que F# t'incite à adopter offre beaucoup plus de sûreté. Certaines constructions (comme le pattern matching) vérifient que ton code gère bien tous les cas ; si tu oublies un cas ou si un cas est traité en double, le compilateur te prévient et te donne un exemple de problème. La valeur null est quasiment enlevée (sauf pour l'interopérabilité) du langage, au profit d'un type option. De cette façon, on ne peut pas oublier de traiter le cas où il n'y a pas de valeur.

Le système de typage est aussi beaucoup plus fin et tu peux même indiquer l'unité de mesure de tes valeurs numériques. Le compilateur t'interdit alors d'additionner des mètres et des secondes, mais tu peux les diviser (et le compilateur déduit tout seul l'unité du résultat). Le compilateur est aussi plus strict et empêche bon nombre de conversions implicites (on ne peut pas mélanger des int et des float par exemple).

(Comme la conversation dévie, elle peut être continuée dans le forum F#)

Je pense que je vais me documenter avant de débattre

J'ai mis F# in action dans ma "book list"

[LLB]

Le problème c'est que même si F#a des cotés très intéressant, je ne suis pas fan de tout ce qui est fait en F# conne cette syntaxe un peu violente d'affectation (par exemple une définition de classe est affecté dans le nom de la classe)

Je ne comprends pas bien. L'affectation se fait avec l'opérateur "<-" mais il est finalement assez peu utilisé. "=" sert pour les déclarations et les tests d'égalité (comme en maths).

et il n'est pas possible de créer une classe F# au milieu d'un projet C#

Si.

[ijk-ref]

De deux, tu n'aimes pas ma proposition d'affecter 3 variables à la volée séparé par des virgule et dans le post d'après tu apprécie la notation F# qui est exactement la même, il y a comme une incohérence dans ton propos... Cette syntaxe déjà implémenté depuis un moment dans F# ça montre bien qu'elle du sens autant dans la lisibilité que dans la fonctionnalité.

En fait j'appréciais surtout de savoir qu'un langage comme F# possède en natif l'affectation de plusieurs variables. Ensuite je ne permettrai pas de critiquer son écriture car je ne souviens plus trop de la philosophie derrière.

Concernant C# je vois les choses un peu différemment... . Les "parenthèses" me semblent plus naturelles sans changer la nature profonde des méthodes et il serait invraisemblable pour moi qu'on arrête de typer les variables.

Surement parce que j'aime bien compartimenter... soit y voir une sorte d'extension du langage existant.

Toi tu vas trop loin pour moi... je ne vois plus la liaison avec le reste du langage... surement que je manque d'imagination

(...) tu n'as pas non plus la science absolu alors merci d'être ouvert et de respecter les propositions des autres plutôt que partir dans des réflexions sarcastiques sans grand intérêt qui ne font pas avancer grand chose.

J'ai bien les réflexions "sarcastiques" ainsi tu as donné plus de conviction dans tes idées. Et puis sans ça LLB n'aurait jamais participé à l'enrichissement du débat

[anthyme]

Je ne comprends pas bien. L'affectation se fait avec l'opérateur "<-" mais il est finalement assez peu utilisé. "=" sert pour les déclarations et les tests d'égalité (comme en maths).

C'est ça que j'aime pas des masses :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
type MySimpleRecord =
  { a: int;
    b: int;}

C'est considérer une classe comme une variable nommé où j'affecte ma définition dedans, malgré que j'ai touché a pas mal de langage dynamique ça me choc encore pour le moment

Si.

NOOOOONNNN !!!??? Je croyais que c'était pas possible ... Bon je m'y met de suite !

[LLB]

C'est considérer une classe comme une variable nommé où j'affecte ma définition dedans, malgré que j'ai touché a pas mal de langage dynamique ça me choc encore pour le moment

Ce n'est pas une affectation, c'est une définition. C'est le problème, tu as utilisé trop de langages dynamiques, tu crois que tout s'affecte ; non, il y a peu d'affectations en F#, de modifications (beaucoup moins que dans les autres langages). Le "=" sert à déclarer, un peu comme un alias si tu veux. Avec le "=", on ne peut rien changer, on ne peut pas incrémenter de valeur, ni rien. Au niveau de la philosophie du langage, F# est très éloigné de Python, Ruby et les autres (ce qui offre de fait beaucoup plus de sûreté).

Je croyais que c'était pas possible

Ca compile vers la même chose au final, un peu comme C# et VB.NET. Je ne connais pas bien cet aspect, mais il me semble qu'il faille passer par une dll intermédiaire.

[anthyme]

Ce qui me gène c'est que la syntaxe est la même c'est perturbant ...

Je vais regarder tout ça en détail bientôt ... car ... Je viens aujourd'hui de rentrer dans la cellule R&D de ma boite et je suis devenu expert .net

[dotnethub]

Bonjour Jérôme,

deux commentaires sur cet intéressant article :
(je n'ai pas lu tous les 66 commentaires précédents alors j'espère ne pas faire doublon...)

- tu as une petite coquille dans ton code §3 : "new System.Tuple.Create" --> supprimer le "new"

- sinon une erreur par rapport à la version "VS 2010 RC" (qui me semble d'ailleurs être plutôt un bug dans la RC d'ailleurs, mais soit...) :
Il existe une différence entre new Tuple<T1, ...., T8> et et Tuple.Create<T1, ..., T8>.

Dans le 2ème cas, ta propriété "Rest" ne vaudra pas T8, mais Tuple<T8>.

Aberrant me semble-t-il mais voilà...

Par conséquent dont ton §4, dans ton 2ème exemple, si tu voulais récupérer la valeur "Jérôme", tu devrais faire :
- tuple4.Rest.Item1.Item1 --> "Jérôme"
- tuple4.Rest.Item1 --> ("Jérome", "Lambert")

Si tu avais instancié ta classe avec des "new" et non l'utilisation de "Create", tu aurais :
- tuple4.Rest.Item1.Item1 --> Erreur de compil car "Rest.Item1" est un string
- tuple4.Rest.Item1 --> "Jérome"


Mais confirme-moi... Je n'ai pas rêvé... Le comportement n'était pas comme ça dans les versions Beta si ?

Bien à toi,
Pierre-Emmanuel Dautreppe
http://www.dotnethub.be