Les Cast Codeurs Podcast – Episode 56 – Interview Ceylon avec Stephane Epardaud et Emmanuel Bernard
Emmanuel Bernard
Thibaud Vibes
> http://goo.gl/oucXh
On entend subrepticement parler d'un backend .NET (même si ça
n'apparaît pas dans la roadmap). Dommage j'aurais bien voulu un peu de
développement là-dessus parce que je ne suis pas sur de comprendre.
Qu'est-ce que cela veut dire concrètement?
On pourra compiler son source ceylon en choisissant sa plateforme
cible: la JVM ou la VM .NET?
C'est assez inédit, ça non? Y a d'autres langages pour lesquels c'est
possible? Y a t-il une chance que le langage s'impose sur .NET sans le
concours de Microsoft?
(bon là j'ai une foule de questions, je vais m'arrêter là, on va déjà
voir ça)
Thibaud
Julien Ponge
--Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Patrice Trognon
Rémi Forax
> Scala supportait aussi la compilation vers .Net. Il faudrait regarder
> supporter de mani�re uniforme certaines classes de base entre Java et
> .Net.
>
> Dans la s�rie de langages cit�s dans les notes de l'�pisode : Fantom
>
>
> �+
Clojure a aussi 3 backends (Java, .Net et Javascript),
mais le backend .Net est � la traine.
Le probl�me est que si on regarde sous la capot la JVM et le CLR sont
assez diff�rents
et ne s'optimisent pas du tout de la m�me fa�on donc cela demande double
de boulot
pour les developpeurs du langage alors que cela n'agrandi pas tant que
cela la base
des utilisateurs, les religieux du genre je ne ferais que du Java et
jamais de C# ou vice-versa,
il n'y en a pas tellement.
R�mi
>
> On lundi 2 avril 2012 at 23:59, Thibaud Vibes wrote:
>
>> On 1 avr, 11:05, Emmanuel Bernard <emman...@lescastcodeurs.com> wrote:
>>> http://goo.gl/oucXh
>>
>> On entend subrepticement parler d'un backend .NET (m�me si �a
>> n'appara�t pas dans la roadmap). Dommage j'aurais bien voulu un peu de
>> d�veloppement l�-dessus parce que je ne suis pas sur de comprendre.
>> Qu'est-ce que cela veut dire concr�tement?
>> On pourra compiler son source ceylon en choisissant sa plateforme
>> cible: la JVM ou la VM .NET?
>>
>> C'est assez in�dit, �a non? Y a d'autres langages pour lesquels c'est
>> possible? Y a t-il une chance que le langage s'impose sur .NET sans le
>> concours de Microsoft?
>> (bon l� j'ai une foule de questions, je vais m'arr�ter l�, on va d�j�
>> voir �a)
>>
>> Thibaud
>>
>> --
>> Vous recevez ce message, car vous �tes abonn� au groupe Google
>> Groupes lescastcodeurs.
>> Pour envoyer un message � ce groupe, adressez un e-mail
>> � lescast...@googlegroups.com.
>> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse
>> lescastcodeur...@googlegroups.com.
>> Pour plus d'options, consultez la page de ce groupe :
>> http://groups.google.com/group/lescastcodeurs?hl=fr
>
> --
> Vous recevez ce message, car vous �tes abonn� au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message � ce groupe, adressez un e-mail
> � lescast...@googlegroups.com.
> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse
Sam Bessalah
On 04/03/2012 10:09 AM, Julien Ponge wrote:
Scala supportait aussi la compilation vers .Net. Il faudrait regarder où en est ce sous-projet, je crois qu'ils avaient des problèmes pour supporter de manière uniforme certaines classes de base entre Java et .Net.
Dans la série de langages cités dans les notes de l'épisode : Fantom compile vers Java, .Net et JavaScript.
Il y a aussi J# si ça existe encore ... :-)
À+
--
Julien Ponge
http://julien.ponge.info/
Clojure a aussi 3 backends (Java, .Net et Javascript),
mais le backend .Net est à la traine.
Le problème est que si on regarde sous la capot la JVM et le CLR sont assez différents
et ne s'optimisent pas du tout de la même façon donc cela demande double de boulot
pour les developpeurs du langage alors que cela n'agrandi pas tant que cela la base
des utilisateurs, les religieux du genre je ne ferais que du Java et jamais de C# ou vice-versa,
il n'y en a pas tellement.
Rémi
On lundi 2 avril 2012 at 23:59, Thibaud Vibes wrote:
On 1 avr, 11:05, Emmanuel Bernard <emman...@lescastcodeurs.com> wrote:
http://goo.gl/oucXh
On entend subrepticement parler d'un backend .NET (même si ça
n'apparaît pas dans la roadmap). Dommage j'aurais bien voulu un peu de
développement là-dessus parce que je ne suis pas sur de comprendre.
Qu'est-ce que cela veut dire concrètement?
On pourra compiler son source ceylon en choisissant sa plateforme
cible: la JVM ou la VM .NET?
C'est assez inédit, ça non? Y a d'autres langages pour lesquels c'est
possible? Y a t-il une chance que le langage s'impose sur .NET sans le
concours de Microsoft?
(bon là j'ai une foule de questions, je vais m'arrêter là, on va déjà
voir ça)
Thibaud
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Rémi Forax
> Idemn pour Fantom. Qui tourne sur les deux plateformes.
> deux plateformes. Et sur la rapidit� d'�volution. On a une plateforme
> compilateur ad�quat pose toujours des probl�mes.
> Mais il n'emp�che que c'est pas mal comme id�e.
Je veux pas rentr� dans une guerre de religion mais en terme de
plateforme (pas de langage)
le CLR a que tr�s peux evoluer depuis sa version 2.0.
R�mi
>
> On Tue, Apr 3, 2012 at 10:39 AM, R�mi Forax <fo...@univ-mlv.fr
> <mailto:fo...@univ-mlv.fr>> wrote:
>
> On 04/03/2012 10:09 AM, Julien Ponge wrote:
>
> Scala supportait aussi la compilation vers .Net. Il faudrait
> regarder o� en est ce sous-projet, je crois qu'ils avaient des
> probl�mes pour supporter de mani�re uniforme certaines classes
> de base entre Java et .Net.
>
> Dans la s�rie de langages cit�s dans les notes de l'�pisode :
> Fantom compile vers Java, .Net et JavaScript.
>
> Il y a aussi J# si �a existe encore ... :-)
>
> �+
>
> --
> Julien Ponge
> http://julien.ponge.info/
>
>
> Clojure a aussi 3 backends (Java, .Net et Javascript),
> mais le backend .Net est � la traine.
>
> Le probl�me est que si on regarde sous la capot la JVM et le CLR
> sont assez diff�rents
> et ne s'optimisent pas du tout de la m�me fa�on donc cela demande
> double de boulot
> pour les developpeurs du langage alors que cela n'agrandi pas tant
> que cela la base
> des utilisateurs, les religieux du genre je ne ferais que du Java
> et jamais de C# ou vice-versa,
> il n'y en a pas tellement.
>
> R�mi
>
>
>
> On lundi 2 avril 2012 at 23:59, Thibaud Vibes wrote:
>
> On 1 avr, 11:05, Emmanuel Bernard
> <emman...@lescastcodeurs.com
> <mailto:emman...@lescastcodeurs.com>> wrote:
>
> http://goo.gl/oucXh
>
>
> On entend subrepticement parler d'un backend .NET (m�me si �a
> n'appara�t pas dans la roadmap). Dommage j'aurais bien
> voulu un peu de
> d�veloppement l�-dessus parce que je ne suis pas sur de
> comprendre.
> Qu'est-ce que cela veut dire concr�tement?
> On pourra compiler son source ceylon en choisissant sa
> plateforme
> cible: la JVM ou la VM .NET?
>
> C'est assez in�dit, �a non? Y a d'autres langages pour
> lesquels c'est
> possible? Y a t-il une chance que le langage s'impose sur
> .NET sans le
> concours de Microsoft?
> (bon l� j'ai une foule de questions, je vais m'arr�ter l�,
> on va d�j�
> voir �a)
>
> Thibaud
>
> --
> Vous recevez ce message, car vous �tes abonn� au groupe
> Google Groupes lescastcodeurs.
> Pour envoyer un message � ce groupe, adressez un e-mail �
> lescast...@googlegroups.com
> <mailto:lescast...@googlegroups.com>.
> Pour vous d�sabonner de ce groupe, envoyez un e-mail �
> l'adresse lescastcodeur...@googlegroups.com
> <mailto:lescastcodeurs%2Bunsu...@googlegroups.com>.
> Pour plus d'options, consultez la page de ce groupe :
> http://groups.google.com/group/lescastcodeurs?hl=fr
>
>
> --
> Vous recevez ce message, car vous �tes abonn� au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message � ce groupe, adressez un e-mail �
> lescast...@googlegroups.com
> <mailto:lescast...@googlegroups.com>.
> Pour vous d�sabonner de ce groupe, envoyez un e-mail �
> l'adresse lescastcodeur...@googlegroups.com
> <mailto:lescastcodeurs%2Bunsu...@googlegroups.com>.
> Pour plus d'options, consultez la page de ce groupe :
> http://groups.google.com/group/lescastcodeurs?hl=fr
>
>
> --
> Vous recevez ce message, car vous �tes abonn� au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message � ce groupe, adressez un e-mail �
> lescast...@googlegroups.com
> <mailto:lescast...@googlegroups.com>.
> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse
> lescastcodeur...@googlegroups.com
> <mailto:lescastcodeurs%2Bunsu...@googlegroups.com>.
> Pour plus d'options, consultez la page de ce groupe :
> http://groups.google.com/group/lescastcodeurs?hl=fr
>
>
> --
> Vous recevez ce message, car vous �tes abonn� au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message � ce groupe, adressez un e-mail
> � lescast...@googlegroups.com.
> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse
> lescastcodeur...@googlegroups.com.
Emmanuel Lécharny
> J'ai commencé l'écoute hier au resto, intéressant comme approche.
Ca mérite d'être écouté deux ou trois fois, c'est effectivement riche...
>
> Est ce que vous voyez Ceylon comme le possible nouveau langage business
> dans les années à venir, un point sur lequel java n'a que partiellement réussi
> a mon sens, les codeurs cobols d'hier ont le plus grand mal à coder des SI
> en java aujourd'hui, c'est souvent dans la douleur.
<parenthèse>
Euhh, je connais pas beaucoup d'applications business qui sont écrites
*aujourd'hui* autrement qu'en Java. Les codeurs Cobol d'hier doivent
aujourd'hui être plus proche de la retraite que de l'école... Et il
n'est pas facile de se débarrasser de milliards de lignes de cobol qui
tournent (et plutôt bien !) en entreprise, ce qui n'en fait pas le
langage de choix pour les nouvelles applications !
En tout état de cause, je ne vois pas en quoi Ceylon pourrait être plus
que Java un langage business, en tout cas plus que Java ?
</parenthèse>
Concernant le langage lui-même, je pense que l'approche est extrèmement
intéressante, par rapport à Scala notament. Reste à voir si Ceylon est
appelé à prendre une place importante ou pas, ou s'il va seulement
servir d'aiguillon à Java pour qu'il intègre (enfin) les features qui
lui manquent depuis le début.
Il semble d'ailleurs que Oracle a annoncé que la version 10 de Java
(2017) serait complètement objet ! Et oui, plus de types primitifs...
Après, sur Ceylon lui-même, je n'ai pas d'avis tranché (oui, c'est
possible !). J'aime bien l'idée des Mixins (traits en Scala) qui sont
quand même une addition très utile, les fonctions passées en paramêtre
(mais est-ce réellement important si on dispose des lambdas?). Les
Génériques réifiés c'est carrément mieux que ce que l'on a en java
(putain d'erasure de merde ! D'ailleurs, quand on se dit que
l'implémentation des Génériques en java est dû à Odersky, on comprend
pourquoi Scala est une sorte de centrale atomique...) J'aime moins ce
qu'ils ont récupéré de C# (les property), je trouve cela inutile et
perturbant pour le mainteneur.
Voilà, sinon je crois que Thibault a gagné un T-Shirt Ceylon.
Je reviens plus tard quand j'aurais réécouté l'épisode plus en détail et
regardé le langage plus en profondeur.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Patrice Trognon
Le 3 avr. 2012 à 14:46, Emmanuel Lécharny a écrit :
> Le 4/3/12 10:15 AM, Patrice Trognon a écrit :
>> J'ai commencé l'écoute hier au resto, intéressant comme approche.
>
> Ca mérite d'être écouté deux ou trois fois, c'est effectivement riche...
>>
>> Est ce que vous voyez Ceylon comme le possible nouveau langage business
>> dans les années à venir, un point sur lequel java n'a que partiellement réussi
>> a mon sens, les codeurs cobols d'hier ont le plus grand mal à coder des SI
>> en java aujourd'hui, c'est souvent dans la douleur.
> <parenthèse>
> Euhh, je connais pas beaucoup d'applications business qui sont écrites *aujourd'hui* autrement qu'en Java. Les codeurs Cobol d'hier doivent aujourd'hui être plus proche de la retraite que de l'école... Et il n'est pas facile de se débarrasser de milliards de lignes de cobol qui tournent (et plutôt bien !) en entreprise, ce qui n'en fait pas le langage de choix pour les nouvelles applications !
>
> En tout état de cause, je ne vois pas en quoi Ceylon pourrait être plus que Java un langage business, en tout cas plus que Java ?
> </parenthèse>
<réponse a <parenthèse>>
1/ il reste encore de nombreux codeurs cobols, jeune, voir très jeune, qui gagnent carrément beaucoup mieux leur vie
que des codeurs séniors java, j'en connais et ils ont des salaires à en faire rougir plus d'un. donc détrompe toi.
2/ Pour avoir formé nombre de ces développeurs à java dans une vie précédente ils avaient des problèmes par rapport
à l'objet et surtout aux nombreux concepts autour du langage. je ne reviens pas sur les frameworks tout à été dit ou presque.
Emmanuel dans sa présentation a dit qu'ils ont volontairement fermé dans les specs afin d'éviter les patterns visant à encadrer
le langage java, patterns qui étaient bien plus nombreuses en c++, donc sur cet aspect Ceylon me semble intéressant si il
est capable de se rendre du coup plus accessible au commun des mortels.
En ce sens peut il, sera t'il, plus langage business que java, c'est à dire laissera t'il moins de codeurs de 'base' sur le bord
de la route ?
Du reste il peut tout à fait être les deux, c'est à dire permettre des syntaxes puissantes et très évoluées pour les développeurs
plus core, comme vous messieurs, cela au travers d'une option de compilation, et plus restrictif pour les développeurs plus
business (au sens tertiaire par exemple).
Je m'interroge en fait ?
J'avais déjà fait cette remarque par rapport aux clojures car je trouvais qu'il est dangereux d'ouvrir certaines portes a
tous les développeurs, alors que ces portes sont indispensables pour ceux qui bossent sur des aspects plus avancés.
</réponse a <parenthèse>>
>
> Concernant le langage lui-même, je pense que l'approche est extrèmement intéressante, par rapport à Scala notament. Reste à voir si Ceylon est appelé à prendre une place importante ou pas, ou s'il va seulement servir d'aiguillon à Java pour qu'il intègre (enfin) les features qui lui manquent depuis le début.
> Il semble d'ailleurs que Oracle a annoncé que la version 10 de Java (2017) serait complètement objet ! Et oui, plus de types primitifs...
>
> Après, sur Ceylon lui-même, je n'ai pas d'avis tranché (oui, c'est possible !). J'aime bien l'idée des Mixins (traits en Scala) qui sont quand même une addition très utile, les fonctions passées en paramêtre (mais est-ce réellement important si on dispose des lambdas?). Les Génériques réifiés c'est carrément mieux que ce que l'on a en java (putain d'erasure de merde ! D'ailleurs, quand on se dit que l'implémentation des Génériques en java est dû à Odersky, on comprend pourquoi Scala est une sorte de centrale atomique...) J'aime moins ce qu'ils ont récupéré de C# (les property), je trouve cela inutile et perturbant pour le mainteneur.
>
hum, autant je peux comprendre les propertys en obj-c puisqu'elles permettent de gérer la mémoire, autant
dans un langage avec un GC si c'est juste la génération des getter/setter je ne vois pas non plus l'utilité.
dans 90% des cas attribut public et basta, parce que un attribut private avec un getter et un setter c'est quoi d'autre ?
Pat
> Voilà, sinon je crois que Thibault a gagné un T-Shirt Ceylon.
>
> Je reviens plus tard quand j'aurais réécouté l'épisode plus en détail et regardé le langage plus en profondeur.
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Emmanuel Lécharny
> Le 3 avr. 2012 à 14:46, Emmanuel Lécharny a écrit :
>
>> Le 4/3/12 10:15 AM, Patrice Trognon a écrit :
>>> J'ai commencé l'écoute hier au resto, intéressant comme approche.
>> Ca mérite d'être écouté deux ou trois fois, c'est effectivement riche...
>>> Est ce que vous voyez Ceylon comme le possible nouveau langage business
>>> dans les années à venir, un point sur lequel java n'a que partiellement réussi
>>> a mon sens, les codeurs cobols d'hier ont le plus grand mal à coder des SI
>>> en java aujourd'hui, c'est souvent dans la douleur.
>> <parenthèse>
>> Euhh, je connais pas beaucoup d'applications business qui sont écrites *aujourd'hui* autrement qu'en Java. Les codeurs Cobol d'hier doivent aujourd'hui être plus proche de la retraite que de l'école... Et il n'est pas facile de se débarrasser de milliards de lignes de cobol qui tournent (et plutôt bien !) en entreprise, ce qui n'en fait pas le langage de choix pour les nouvelles applications !
>>
>> En tout état de cause, je ne vois pas en quoi Ceylon pourrait être plus que Java un langage business, en tout cas plus que Java ?
>> </parenthèse>
> <réponse a<parenthèse>>
> 1/ il reste encore de nombreux codeurs cobols, jeune, voir très jeune, qui gagnent carrément beaucoup mieux leur vie
> que des codeurs séniors java, j'en connais et ils ont des salaires à en faire rougir plus d'un. donc détrompe toi.
qui se faisait du 1500€ la journée, et qui bossait 50 jours par an. Ils
étaient 5 comme lui en Europe, et le PDP 11 est embedded dans des
photocomposeuses, qui fonctionnent encore aujourd'hui... C'était un
marché d'ultra niche, que n'est pas encore le Cobol, mais ça va le
devenir au fur et à mesure que les 'vieux' prennent leur retraite. Il y
a de l'avenir à faire du Cobol ! :)
>
> 2/ Pour avoir formé nombre de ces développeurs à java dans une vie précédente ils avaient des problèmes par rapport
> à l'objet et surtout aux nombreux concepts autour du langage.
personnes...
> je ne reviens pas sur les frameworks tout à été dit ou presque.
> Emmanuel dans sa présentation a dit qu'ils ont volontairement fermé dans les specs afin d'éviter les patterns visant à encadrer
> le langage java, patterns qui étaient bien plus nombreuses en c++, donc sur cet aspect Ceylon me semble intéressant si il
> est capable de se rendre du coup plus accessible au commun des mortels.
+1
Quand je regarde du code Ceylon, je n'ai pas les mêmes spasmes
gastriques ni les relachements musculaires postérieures que j'ai avec
Scala...
>
> En ce sens peut il, sera t'il, plus langage business que java, c'est à dire laissera t'il moins de codeurs de 'base' sur le bord
> de la route ?
Ah, tu veux dire, plus 'accessible au commun des développeurs' ?
Franchement, je ne pense pas, mais ça reste à voir en pratique. Je n'ai
pas une vision autre que très succinte de Ceylon, mais ça ressemble
quand même foutrement à Java.
> J'avais déjà fait cette remarque par rapport aux clojures car je trouvais qu'il est dangereux d'ouvrir certaines portes a
> tous les développeurs, alors que ces portes sont indispensables pour ceux qui bossent sur des aspects plus avancés.
> </réponse a<parenthèse>>
>
>> Concernant le langage lui-même, je pense que l'approche est extrèmement intéressante, par rapport à Scala notament. Reste à voir si Ceylon est appelé à prendre une place importante ou pas, ou s'il va seulement servir d'aiguillon à Java pour qu'il intègre (enfin) les features qui lui manquent depuis le début.
>> Il semble d'ailleurs que Oracle a annoncé que la version 10 de Java (2017) serait complètement objet ! Et oui, plus de types primitifs...
>>
>> Après, sur Ceylon lui-même, je n'ai pas d'avis tranché (oui, c'est possible !). J'aime bien l'idée des Mixins (traits en Scala) qui sont quand même une addition très utile, les fonctions passées en paramêtre (mais est-ce réellement important si on dispose des lambdas?). Les Génériques réifiés c'est carrément mieux que ce que l'on a en java (putain d'erasure de merde ! D'ailleurs, quand on se dit que l'implémentation des Génériques en java est dû à Odersky, on comprend pourquoi Scala est une sorte de centrale atomique...) J'aime moins ce qu'ils ont récupéré de C# (les property), je trouve cela inutile et perturbant pour le mainteneur.
>>
> hum, autant je peux comprendre les propertys en obj-c puisqu'elles permettent de gérer la mémoire, autant
> dans un langage avec un GC si c'est juste la génération des getter/setter je ne vois pas non plus l'utilité.
> dans 90% des cas attribut public et basta, parce que un attribut private avec un getter et un setter c'est quoi d'autre ?
Le get/set est juste un moyen d'encaspuler les data. Perso, je mets
*toujours* mes fields en private, rarement en protected (encore plus
rarement en package protected), et *jamais* en public. Question de
principe. Après, mon IDE me génère les getters/setters pour moi, c'est
pour cela que ce truc de se débarrasser des get/set me semble
franchement inutile. Et potentiellement source d'erreur, IMHO.
Patrice Trognon
ouaih forcement, scala quoi !
on a vaguement saisi ce que tu penses de scala (hihi)
>>
>> En ce sens peut il, sera t'il, plus langage business que java, c'est à dire laissera t'il moins de codeurs de 'base' sur le bord
>> de la route ?
> Ah, tu veux dire, plus 'accessible au commun des développeurs' ? Franchement, je ne pense pas, mais ça reste à voir en pratique. Je n'ai pas une vision autre que très succinte de Ceylon, mais ça ressemble quand même foutrement à Java.
>
Oui enfin, java ressemblait foutrement a du c++ tout en étant plus simple, donc si ceylon devient plus simple que java
cela va peut être devenir accessible.
Imaginons dans un rêve totalement fou un langage qui intègrerait la gestion de la persistance simplement et proprement,
qui est tout de même un point de passage pour toute application, au lieu de la laisser partir a tous vents comme on l'a
vécu en java. et cela sans des déclarations à coucher dehors parce que va expliquer les relations possibles de Hibernate
à un néophyte, au bout de 10 mins il te prend à juste raison pour un doux malade.
Voila, à mes yeux un langage orienté business c'est un langage qui va répondre de manière standard à toutes ces problématiques
et donc couper court aux approches olé olé codées par des poilus pour des poilus. Bref comme le faisait un cobol à sa
grande époque, nos parents développaient des applies de gestions sans s'être jamais préoccupés de persistance !
>> J'avais déjà fait cette remarque par rapport aux clojures car je trouvais qu'il est dangereux d'ouvrir certaines portes a
>> tous les développeurs, alors que ces portes sont indispensables pour ceux qui bossent sur des aspects plus avancés.
>> </réponse a<parenthèse>>
>>
>>> Concernant le langage lui-même, je pense que l'approche est extrèmement intéressante, par rapport à Scala notament. Reste à voir si Ceylon est appelé à prendre une place importante ou pas, ou s'il va seulement servir d'aiguillon à Java pour qu'il intègre (enfin) les features qui lui manquent depuis le début.
>>> Il semble d'ailleurs que Oracle a annoncé que la version 10 de Java (2017) serait complètement objet ! Et oui, plus de types primitifs...
>>>
>>> Après, sur Ceylon lui-même, je n'ai pas d'avis tranché (oui, c'est possible !). J'aime bien l'idée des Mixins (traits en Scala) qui sont quand même une addition très utile, les fonctions passées en paramêtre (mais est-ce réellement important si on dispose des lambdas?). Les Génériques réifiés c'est carrément mieux que ce que l'on a en java (putain d'erasure de merde ! D'ailleurs, quand on se dit que l'implémentation des Génériques en java est dû à Odersky, on comprend pourquoi Scala est une sorte de centrale atomique...) J'aime moins ce qu'ils ont récupéré de C# (les property), je trouve cela inutile et perturbant pour le mainteneur.
>>>
>> hum, autant je peux comprendre les propertys en obj-c puisqu'elles permettent de gérer la mémoire, autant
>> dans un langage avec un GC si c'est juste la génération des getter/setter je ne vois pas non plus l'utilité.
>> dans 90% des cas attribut public et basta, parce que un attribut private avec un getter et un setter c'est quoi d'autre ?
> Le get/set est juste un moyen d'encaspuler les data. Perso, je mets *toujours* mes fields en private, rarement en protected (encore plus rarement en package protected), et *jamais* en public. Question de principe. Après, mon IDE me génère les getters/setters pour moi, c'est pour cela que ce truc de se débarrasser des get/set me semble franchement inutile. Et potentiellement source d'erreur, IMHO.
>
mouaih bon ok, c'est une bonne pratique on est d'accord, mais finalement elle apporte quoi quand tu as un attribut private
et un getter qui le retourne et un setter qui l'affecte ! à rien.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Emmanuel Lécharny
>
> Imaginons dans un rêve totalement fou un langage qui intègrerait la gestion de la persistance simplement et proprement,
> qui est tout de même un point de passage pour toute application, au lieu de la laisser partir a tous vents comme on l'a
> vécu en java. et cela sans des déclarations à coucher dehors parce que va expliquer les relations possibles de Hibernate
> à un néophyte, au bout de 10 mins il te prend à juste raison pour un doux malade.
Je ne pense pas qu'il soit possible de définir la persistance au sein
d'un langage. Après tout, quoi de commun entre une base SQL Oracle et du
MySQL ? En quoi un langage devrait supporter toutes les subtilités de
chaque idiome, sans compter sur les nouvelles bases NoSQL ?
Après, rien ne t'obliges à utiliser Hibernate. JDBC, c'est pas si mal...
<petit pas de côté>
Perso, je n'ai jamais bien compris l'intérêt d'Hibernate et autre
système d'ORM : au final, l'accès aux données, c'est qqchose qu'on code
une fois au début du projet, et on y touche rarement par la suite. Je
préfère y consacrer un peu plus de temps mais être sûr que ça soit fait
à peu près correctement, au plus bas niveau, plutôt que de me retrouver
avec une pile d'annotations contradictoires dans lesquelles la gestion
des transactions est faite en dépit du bon sens... Sans compter la
question des perfs...
</petit pas de côté>
>
> Voila, à mes yeux un langage orienté business c'est un langage qui va répondre de manière standard à toutes ces problématiques
> et donc couper court aux approches olé olé codées par des poilus pour des poilus. Bref comme le faisait un cobol à sa
> grande époque, nos parents développaient des applies de gestions sans s'être jamais préoccupés de persistance !
D'un autre côté, en Cobol, ton environnement était quand même vachement
moins riche : CICS, IMS, IBM, point barre. Ca limite les possibilités...
Mais je ne suis pas sûr que ce fût aussi simple que tu le penses...
Thibaud Vibes
Le 4/3/12 10:15 AM, Patrice Trognon a �crit :Je suis d'accord.
J'ai commenc� l'�coute hier au resto, int�ressant comme approche.
Ca m�rite d'�tre �cout� deux ou trois fois, c'est effectivement riche...
J'ai enfin compris ce que c'�tait la covariance et la contravariance (merci � S. Epardaud d'�lever ainsi mon intellect).
Et l'�pisode donne envie de lire la doc qui n'est pas rebutante finalement car ce n'est pas un gros pav� bourr� de th�orie sur la POO. A la vue de cette doc il ne semble vraiment pas d�connant de dire qu'on peut rentrer facilement et rapidemment dans le langage.
[...]Ca n'a pas �t� evoqu� il me semble dans le podcast. Y a des types primitifs en Ceylon? Je dirais non vu que la doc "Tour of Ceylon" ne le mentionne pas et aucun exemple que j'ai lu n'en comporte...
Concernant le langage lui-m�me, je pense que l'approche est extr�mement int�ressante, par rapport � Scala notament. Reste � voir si Ceylon est appel� � prendre une place importante ou pas, ou s'il va seulement servir d'aiguillon � Java pour qu'il int�gre (enfin) les features qui lui manquent depuis le d�but.
Il semble d'ailleurs que Oracle a annonc� que la version 10 de Java (2017) serait compl�tement objet ! Et oui, plus de types primitifs...
Les union / intersection de types c'est quelque chose d�int�ressant. A voir si �a perturbe pas le "d�veloppeur" de base...
Apr�s, sur Ceylon lui-m�me, je n'ai pas d'avis tranch� (oui, c'est possible !). J'aime bien l'id�e des Mixins (traits en Scala) qui sont quand m�me une addition tr�s utile, les fonctions pass�es en param�tre (mais est-ce r�ellement important si on dispose des lambdas?). Les G�n�riques r�ifi�s c'est carr�ment mieux que ce que l'on a en java (putain d'erasure de merde ! D'ailleurs, quand on se dit que l'impl�mentation des G�n�riques en java est d� � Odersky, on comprend pourquoi Scala est une sorte de centrale atomique...) J'aime moins ce qu'ils ont r�cup�r� de C# (les property), je trouve cela inutile et perturbant pour le mainteneur.
A premi�re vue, les unions �a para�t surtout utiles (corrigez moi si je me trompe) parce qu'on en peut pas d�clarer plusieurs m�thodes de m�me nom avec des param�tres diff�rents.
En Java on peut avoir :
public void ranger(Torchon linge){ ... }
public void ranger(Serviette linge){ ... }
En Ceylon, on peut pas, donc on d�fini
shared void ranger(Torchon|Serviette linge){ ... }
Les alias de type: pas bien compris l'int�r�t. L'exemple de la doc me semble m�me contre-productif :
interface People = Set<Person>;
People perd pas mal par rapport en s�mantique �
Set<People> (on ne sait plus que c'est un ensemble de type
Person qui ne peut avoir de doublons).
Sinon je trouve qu'y a quand m�me un truc crado: la concat�nation de cha�ne de caract�res.
Exemples (issue de la doc)
print("Hello,
you ran me at " process.milliseconds); //compile error!
But we can easily fix it:print("Hello, you ran me at "
process.milliseconds "");
les ptits guillemets � la fin pour faire compiler �a me fait penser � des syntaxes comme ""+2 (en java quand on veut transformer un int en String)
Merci de le rappeler Me. Lecharny.
Voil�, sinon je crois que Thibault a gagn� un T-Shirt Ceylon.
Au fait pourquoi un �l�phant (il est d�j� pas mal utilis�: php, postgresql...)? pourquoi Ceylon?
Voila, si j'ai dit trop de conne... vous pouvez me sucrer mon tee-shirt :-)
Je reviens plus tard quand j'aurais r��cout� l'�pisode plus en d�tail et regard� le langage plus en profondeur.
Thibaud
Emmanuel Lécharny
>>
>> Concernant le langage lui-même, je pense que l'approche est
>> extrèmement intéressante, par rapport à Scala notament. Reste à voir
>> si Ceylon est appelé à prendre une place importante ou pas, ou s'il
>> features qui lui manquent depuis le début.
>> Il semble d'ailleurs que Oracle a annoncé que la version 10 de Java
>> (2017) serait complètement objet ! Et oui, plus de types primitifs...
> [...]
> Ca n'a pas été evoqué il me semble dans le podcast. Y a des types
> le mentionne pas et aucun exemple que j'ai lu n'en comporte...
classes representing integers, floating point numbers, arbitrary
precision integers and arbitrary precision decimals"
>
>>
>> Après, sur Ceylon lui-même, je n'ai pas d'avis tranché (oui, c'est
>> possible !). J'aime bien l'idée des Mixins (traits en Scala) qui sont
>> quand même une addition très utile, les fonctions passées en
>> paramêtre (mais est-ce réellement important si on dispose des
>> lambdas?). Les Génériques réifiés c'est carrément mieux que ce que
>> l'on a en java (putain d'erasure de merde ! D'ailleurs, quand on se
>> dit que l'implémentation des Génériques en java est dû à Odersky, on
>> comprend pourquoi Scala est une sorte de centrale atomique...) J'aime
>> moins ce qu'ils ont récupéré de C# (les property), je trouve cela
>> inutile et perturbant pour le mainteneur.
> Les union / intersection de types c'est quelque chose d’intéressant. A
> voir si ça perturbe pas le "développeur" de base...
> A première vue, les unions ça paraît surtout utiles (corrigez moi si
> je me trompe) parce qu'on en peut pas déclarer plusieurs méthodes de
> même nom avec des paramètres différents.
> En Java on peut avoir :
> public void ranger(Torchon linge){ ... }
> public void ranger(Serviette linge){ ... }
>
> En Ceylon, on peut pas, donc on défini
> shared void ranger(Torchon|Serviette linge){ ... }
Perso (mais je n'ai pas regardé en détail), il m'aurait semblé sympa de
disposer plutôt d'une construction style enum, ou plutôt union, comme en
C. Style :
public union Linge
{
Torchon | Serviette
}
ce qui donne :
shared void ranger(Linge linge){ ... }
Juste pour éviter des listes très longues dans le cas des unions multiples.
Peut-être peuvent-ils rajouter cela au langage ?
>
>
>
> Les alias de type: pas bien compris l'intérêt. L'exemple de la doc me
> semble même contre-productif :
> |interface| |People| |= ||Set||<||Person||>;
> |People perd pas mal par rapport en sémantique à Set<People> (on ne
> sait plus que c'est un ensemble de type Person qui ne peut avoir de
> doublons)|.
>
> |
> Sinon je trouve qu'y a quand même un truc crado: la concaténation de
> chaîne de caractères.
> Exemples (issue de la doc)
> |print(||"Hello, you ran me at "||||process.milliseconds); ||//compile
> error!
>
> |But we can easily fix it:
> |print("Hello, you ran me at " process.milliseconds "");
> |
> les ptits guillemets à la fin pour faire compiler ça me fait penser à
> des syntaxes comme ""+2 (en java quand on veut transformer un int en
> String)
Puke, puke, puke ;)
Cédric Beust ♔
putain d'erasure de merde !
Emmanuel Lécharny
> On Tue, Apr 3, 2012 at 5:46 AM, Emmanuel Lécharny<elec...@gmail.com>wrote:
>
>> putain d'erasure de merde !
>
> Euh... non, l'erasure en Java est en fait bien supérieure aux génériques
> réifiés pour pas mal de raisons, j'explique pourquoi
Je ne partage pas ton point de vue.
Si on considère ton premier exemple, rien n'interdirait un compilateur
d'un langage supportat des générique réifiées de générer une erreur de
compilation. Tant que le type n'est pas 'généré', il est simple de
détecter que f(K) et f(V) ont potentiellement la même signature. C'est
ici un problème de compilation, pas un problème du type erasure vs
réification
Le second exemple est problématique. Le fait qu'un système à base
d'erasure le rejette, et pas un système à base de réification est
également un problème de compilation. A ce stade, le type de t est connu
(Object) et il n'est pas possible de considérer qu'il s'agit d'une
instance d'un type paramétrique. Certes, le développeur a écrit un code
faible, mais cela ne doit pas tromper un compilateur.
Pour l'instanciation, itou. Le compilateur peut détecter que l'one ssaye
de créer un objet dont on ne connait pas le type, et générer une erreur.
Ou un warning (et différer la construction de l'objet jusqu'à ce que
l'on connaisse son type, donc au chargement de la classe).
Dans tous les cas de figure, ces exemples ne démontre pas en quoi
l'erasure est supérieure à la réification.
Par contre, dès que l'on va manipuler des tableaux de type génériques,
on va se trouver confronter à des problèmes assez pénibles liés à l'erasure.
ce qui est claire, c'est que ce fut un choix d'implémentation dicté par
le désir de ne pas modifier le langage sous-jacent, plus que par un
soucis d'obtenir la meilleure implémentation possible des générique,
trade of respectable cela dit.
Qu'on puisse vivre avec, oui. Que ce soit parfait, et qu'il n'existe pas
une meilleure solution basée sur la réification, j'en doute très fortement.
Thibaud Vibes
> Perso (mais je n'ai pas regard� en d�tail), il m'aurait sembl� sympa
> de disposer plut�t d'une construction style enum, ou plut�t union,
> public union Linge
> {
> Torchon | Serviette
> }
>
> ce qui donne :
>
> shared void ranger(Linge linge){ ... }
>
> multiples.
>
> Peut-�tre peuvent-ils rajouter cela au langage ?
Ou comme �a:
interface Linge = Torchon | Serviette;
(syntaxe des alias)
A moins que �a ne soit d�j� valide (pas le temps de tester aujourd'hui
X-) )
Emmanuel Bernard
Ca n'a pas été evoqué il me semble dans le podcast. Y a des types primitifs en Ceylon? Je dirais non vu que la doc "Tour of Ceylon" ne le mentionne pas et aucun exemple que j'ai lu n'en comporte...
Concernant le langage lui-même, je pense que l'approche est extrèmement intéressante, par rapport à Scala notament. Reste à voir si Ceylon est appelé à prendre une place importante ou pas, ou s'il va seulement servir d'aiguillon à Java pour qu'il intègre (enfin) les features qui lui manquent depuis le début.
Il semble d'ailleurs que Oracle a annoncé que la version 10 de Java (2017) serait complètement objet ! Et oui, plus de types primitifs...
Les alias de type: pas bien compris l'intérêt. L'exemple de la doc me semble même contre-productif :
interfacePeople=Set<Person>;
People perd pas mal par rapport en sémantique à Set<People> (on ne sait plus que c'est un ensemble de type Person qui ne peut avoir de doublons).
Sinon je trouve qu'y a quand même un truc crado: la concaténation de chaîne de caractères.
Exemples (issue de la doc)
print("Hello, you ran me at "process.milliseconds);//compile error!But we can easily fix it:
print("Hello, you ran me at " process.milliseconds "");
les ptits guillemets à la fin pour faire compiler ça me fait penser à des syntaxes comme ""+2 (en java quand on veut transformer un int en String)
Thibaud Vibes
On Tue, Apr 3, 2012 at 5:36 PM, Thibaud Vibes <thibau...@wanadoo.fr> wrote:
Ca n'a pas �t� evoqu� il me semble dans le podcast. Y a des types primitifs en Ceylon? Je dirais non vu que la doc "Tour of Ceylon" ne le mentionne pas et aucun exemple que j'ai lu n'en comporte...
Concernant le langage lui-m�me, je pense que l'approche est extr�mement int�ressante, par rapport � Scala notament. Reste � voir si Ceylon est appel� � prendre une place importante ou pas, ou s'il va seulement servir d'aiguillon � Java pour qu'il int�gre (enfin) les features qui lui manquent depuis le d�but.
Il semble d'ailleurs que Oracle a annonc� que la version 10 de Java (2017) serait compl�tement objet ! Et oui, plus de types primitifs...
Non. Bref c'est un objet.
�
Les alias de type: pas bien compris l'int�r�t. L'exemple de la doc me semble m�me contre-productif :
interfacePeople=Set<Person>;
tu es taquin...People perd pas mal par rapport en s�mantique � Set<People> (on ne sait plus que c'est un ensemble de type Person qui ne peut avoir de doublons).
T'as d�j� vu des doublons dans un groupe de personnes physiques toi? faut arr�ter de lire de la fantaisie ;)
de ccq tu veux dire ("classe compl�tement qualifi�e" puisqu'on est sur un podcast en fran�ais n'est-ce pas :-p)Les alias sont surtout utiles pour differencier deux types import�s qui auraient le meme nom non qualifi�. Dans le code Ceylon, tu n'utilises jamais de fqcn.
Ce point m'avait �chapp�. Je comprend un peu mieux l'int�r�t
Joseph Pachod
> C'est aussi une
> des raisons pour lesquelles l'effort de back end .Net en Scala est au point
> mort.
bizarre, j'avais lu un post d'Odersky félicitant le gars derrière pour
son boulot et une simple recherche google m'a donné ça
http://www.scala-lang.org/node/10299
ça a l'air de tourner
Cédric Beust ♔
Rémi Forax
pour citer l'article:
"The key limitation for the moment is that Scala programs cannot use
libraries in .Net that
are compiled using CLR generics, such as the .Net collections."
Donc si tu n'utilises pas de libs qui utilisent les collections de C#,
ça tourne.
Et Cedric à raison, les generics du CLR sont souvent cités comme une cause
majeure de problème d'intégration avec les langages dynamiques
(l'autre problème est le manque de de-optimisations mais c'est une autre
histoire)
J'ai entendu des propos similaires par Rich Hickey (Clojure), Charles
Nutter (JRuby) et Brian Franck (Fantom).
Rémi
Miguel Moquillon
Je vais y mettre mon grain de sels : une fois de plus, j'ai le sentiment
de lourdeur dans le langage (j'ai bien dis sentiment).
Je m'explique avec deux exemples :
- d�j� pour r�soudre les probl�mes de covariance, de contravariance et
de typage r�cursif, Ceylon impl�mente un jeu de syntaxe explicite pour
exprimer ceci (les mots-cl� in et out et le tout assaisonn� d'union de
type) alors que l'expression du typage de second ordre F-Bound permet de
r�pondre de fa�on uniforme � ceci. (Sinon, dans un autre ordre de
registre, le langage Eiffel, d�s les ann�es 1984, a apport� une solution
int�ressante aux probl�mes de covariance et de contravariance.)
- ensuite, r�soudre les probl�mes de choix que l'on retrouve souvent
sous forme d'initialisation ou non d'objet, d'objet vide, etc. Ceylon
apporte l'union de type alors que les monads permettent aussi de
r�pondre � ceci mais en plus en y apportant un moyen �l�gant
d'encapsuler la logique de traitement sur des objets qui peuvent poser
des probl�mes (nullit�, absence d'�l�ments, effets de bords impromptus,
etc.)
N�anmoins, il offre des caract�ristiques qui me font souvent d�faut dans
Java. Je garde donc un �il dessus ;-)
Miguel
Le 01/04/2012 11:05, Emmanuel Bernard a �crit :
> http://goo.gl/oucXh
>
> --
> Vous recevez ce message, car vous �tes abonn� au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message � ce groupe, adressez un e-mail
> � lescast...@googlegroups.com.
> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse
Stephane Maldini
Je vais y mettre mon grain de sels : une fois de plus, j'ai le sentiment de lourdeur dans le langage (j'ai bien dis sentiment).
Je m'explique avec deux exemples :
- déjà pour résoudre les problèmes de covariance, de contravariance et de typage récursif, Ceylon implémente un jeu de syntaxe explicite pour exprimer ceci (les mots-clé in et out et le tout assaisonné d'union de type) alors que l'expression du typage de second ordre F-Bound permet de répondre de façon uniforme à ceci. (Sinon, dans un autre ordre de registre, le langage Eiffel, dès les années 1984, a apporté une solution intéressante aux problèmes de covariance et de contravariance.)
- ensuite, résoudre les problèmes de choix que l'on retrouve souvent sous forme d'initialisation ou non d'objet, d'objet vide, etc. Ceylon apporte l'union de type alors que les monads permettent aussi de répondre à ceci mais en plus en y apportant un moyen élégant d'encapsuler la logique de traitement sur des objets qui peuvent poser des problèmes (nullité, absence d'éléments, effets de bords impromptus, etc.)
Néanmoins, il offre des caractéristiques qui me font souvent défaut dans Java. Je garde donc un œil dessus ;-)
Miguel
Le 01/04/2012 11:05, Emmanuel Bernard a écrit :
http://goo.gl/oucXh
--
Vous recevez ce message, car vous êtes abonné au groupe Google
Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail
à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
lescastcodeurs+unsubscribe@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe :
http://groups.google.com/group/lescastcodeurs?hl=fr
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Rémi Forax
> Int�ressant �a mais y'a des languages comme haXe (http://www.haxe.org)
> sur le cr�neau aussi!
sauf que les cr�ateurs de haXe ont pris plein de d�cisions ridicules.
L'exemple le plus navrant est que le type d'une variable d�pend de sa
premi�re
initialization, donc
a = getAnObject()
a = getAString()
compile mais
a = getAString()
a = getAnObject()
ne compile pas.
Et si vous voulez rire regarder la s�mantique du mot cl� inline.
R�mi
>
> 2012/4/4 Miguel Moquillon <miguel.m...@gmail.com
> <mailto:miguel.m...@gmail.com>>
>
> Discussion int�ressante.
> Je vais y mettre mon grain de sels : une fois de plus, j'ai le
> sentiment de lourdeur dans le langage (j'ai bien dis sentiment).
> Je m'explique avec deux exemples :
>
> - d�j� pour r�soudre les probl�mes de covariance, de
> contravariance et de typage r�cursif, Ceylon impl�mente un jeu de
> syntaxe explicite pour exprimer ceci (les mots-cl� in et out et le
> tout assaisonn� d'union de type) alors que l'expression du typage
> de second ordre F-Bound permet de r�pondre de fa�on uniforme �
> ceci. (Sinon, dans un autre ordre de registre, le langage Eiffel,
> d�s les ann�es 1984, a apport� une solution int�ressante aux
> probl�mes de covariance et de contravariance.)
>
> - ensuite, r�soudre les probl�mes de choix que l'on retrouve
> souvent sous forme d'initialisation ou non d'objet, d'objet vide,
> etc. Ceylon apporte l'union de type alors que les monads
> permettent aussi de r�pondre � ceci mais en plus en y apportant un
> moyen �l�gant d'encapsuler la logique de traitement sur des objets
> qui peuvent poser des probl�mes (nullit�, absence d'�l�ments,
> effets de bords impromptus, etc.)
>
> N�anmoins, il offre des caract�ristiques qui me font souvent
> d�faut dans Java. Je garde donc un �il dessus ;-)
>
> Miguel
>
> Le 01/04/2012 11:05, Emmanuel Bernard a �crit :
>
> http://goo.gl/oucXh
>
> --
> Vous recevez ce message, car vous �tes abonn� au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message � ce groupe, adressez un e-mail
> � lescast...@googlegroups.com
> <mailto:lescast...@googlegroups.com>.
> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse
> lescastcodeur...@googlegroups.com
> <mailto:lescastcodeurs%2Bunsu...@googlegroups.com>.
> Pour plus d'options, consultez la page de ce groupe :
> http://groups.google.com/group/lescastcodeurs?hl=fr
>
>
> --
> Vous recevez ce message, car vous �tes abonn� au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message � ce groupe, adressez un e-mail �
> lescast...@googlegroups.com
> <mailto:lescast...@googlegroups.com>.
> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse
> lescastcodeur...@googlegroups.com
> <mailto:lescastcodeurs%2Bunsu...@googlegroups.com>.
> Pour plus d'options, consultez la page de ce groupe :
> http://groups.google.com/group/lescastcodeurs?hl=fr
>
>
>
>
> --
> *St�phane MALDINI*
> --
>
>
> --
> Vous recevez ce message, car vous �tes abonn� au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message � ce groupe, adressez un e-mail
> � lescast...@googlegroups.com.
> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse
> lescastcodeur...@googlegroups.com.
Matthew Farwell
L'homme qui s'occupe de Scala .NET s'appelle Miguel Garcia, et son
repo github se trouve ici: https://github.com/magarciaEPFL. Je ne sais
pas l'état de Scala & .NET, mais il me semble qu'il y a de l'activité
là-dedans. Scala lui-même et dans https://github.com/scala/scala.
Cordialement,
Matthew Farwell.
Stéphane Épardaud
Les monades par contre je ne suis pas du tout d´accord. Les monades sont des concepts créés avant tout pour pallier au problèmes des langages fonctionnels purs (sans effet de bords), donc déjà on en a juste pas besoin, mais surtout le concept même de monade est tellement dur à expliquer que ça reste flou pour la grande majorité des gens. Moi j´aime pas le flou, j´aime les solutions simples pour les problèmes complexes, et les langages faciles à expliquer.
Joseph Pachod
Je suis loin d'être expert ès languages, juste curieux du sujet. Et
j'avais lu un article sur les monades bien intéressants, surtout si
appliqué aux entrées/sorties. Je vais tenter de transcrire ce que j'en
ai compris et pourquoi je pense que c'est intéressant pour bien plus
de monde que seuls les praticiens du fonctionnel.
En gros, l'idée des monades appliquées aux entrées/sorties est, si
j'ai bien compris, la suivante: au lieu de faire les IO une à une au
fur et à mesure, la "Monad IO" permet de les empiler au sens
programmatique du terme et de décider quand on veut les déclencher. Ca
reprend l'idée d'une transaction DB, avec commit ou rollback décidé
par l'utilisateur, appliquée aux fichiers.
En termes de gains pour le développeur normal, ça saute aux yeux: si
j'écris un bout de code qui participe à l'écriture dans un flux, je ne
contribue qu'à la monade et charge au coordinateur de tout cela de
décider - ou non - de rendre la chose effective. Si on a besoin de
savoir l'état courant du flux, on inspecte la monade plutôt que de
devoir regarder dans les fichiers impactés. Bien sûr, cela aide aussi
pour les tests impliquant des IO: plus besoin d'aller jusqu'à
matérialiser les fichiers, on inspecte la monade et puis basta.
Bref, AMHA, la monad IO c'est top. Vivement un language qui le supporte
++
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google
> Groupes lescastcodeurs.
> Cette discussion peut être lue sur le Web à l'adresse
> https://groups.google.com/d/msg/lescastcodeurs/-/G3IwSg581AYJ.
>
> Pour envoyer un message à ce groupe, adressez un e-mail
> à lescast...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
Miguel Moquillon
> Salut,
Bonjour,
> Pour le typage F-Bound, je ne suis pas vraiment ce que tu veux dire.
> N��tant pas un expert, il me semble que rien que les m�thodes � type
> param�tr�s en Java 5 permettent de le faire, et de la m�me mani�re en
> Ceylon.
Pas tout � fait par ce qu'en Java tu te limites � un typage secondaire
universelle ou contraint m�me pas r�ifi� !
Avec le typage secondaire F-Bound, le d�veloppeur se concentre sur les
classes de types (qui sont des familles de types polymorphiques
contraintes par l'interface de la classe) et sur l'appartenance de ces
types � ces classes ; il ne se concentre plus sur le type des objets et
les relations entre ces types : le principe de Liskov n'est plus la
r�f�rence pour r�aliser le polymorphisme.
>
> Les monades par contre je ne suis pas du tout d�accord. Les monades sont
> des concepts cr��s avant tout pour pallier au probl�mes des langages
> fonctionnels purs (sans effet de bords), donc d�j� on en a juste pas
> besoin, mais surtout le concept m�me de monade est tellement dur �
> expliquer que �a reste flou pour la grande majorit� des gens. Moi j�aime
> pas le flou, j�aime les solutions simples pour les probl�mes complexes,
> et les langages faciles � expliquer.
Non, les monades sont au-del� de �a. Ce n'est pas parce que les monades
sont utilis�s dans Haskell, qui est un langage fonctionnel pur, pour
repr�senter les effets de bords qu'ils n'ont d'utilit� que dans ce
contexte l�.
Au contraire, Haskell les utilise aussi dans d'autres contextes comme,
par exemple, celui qui est pr�sent� dans l'interview avec les options.
Leur utilit� va bien au del� et sont tr�s utiles particuli�rement dans
les cas limites (division par 0, IO avec cas d'erreurs exceptionnels, etc.)
M�me Caml qui est un langage fonctionnel non pur (donc avec effets de
bords) permet d'�crire des monades (bien que le langage ne les
supportent pas comme concept). M�me des d�veloppeurs Ruby en codent.
C'est finalement utilis� comme un pattern au m�me titre que celui
Visiteur ou Command.
Une monade n'est en fait qu'une structure de donn�es repr�sentant la
notion de traitement: elle encapsule l'objet sur laquelle porte un
traitement et permet d'obtenir une autre monade avec l'objet r�sultant
de ce traitement. Les monades permettent de cha�ner des actions de fa�on
s�quentielle et d'en g�rer le flot selon les r�sultats de chacune des
actions ; la programmation concurrente, la gestion des exceptions, celle
des entr�es-sorties, etc. peuvent se faire de fa�on �l�gante sous forme
de monades.
Miguel
Emmanuel Bernard
Le 05/04/2012 10:26, Stéphane Épardaud a écrit :
Salut,Bonjour,
Pour le typage F-Bound, je ne suis pas vraiment ce que tu veux dire.
Pas tout à fait par ce qu'en Java tu te limites à un typage secondaire universelle ou contraint même pas réifié !N´étant pas un expert, il me semble que rien que les méthodes à type
paramétrés en Java 5 permettent de le faire, et de la mème manière en
Ceylon.
Avec le typage secondaire F-Bound, le développeur se concentre sur les classes de types (qui sont des familles de types polymorphiques contraintes par l'interface de la classe) et sur l'appartenance de ces types à ces classes ; il ne se concentre plus sur le type des objets et les relations entre ces types : le principe de Liskov n'est plus la référence pour réaliser le polymorphisme.
Les monades par contre je ne suis pas du tout d´accord. Les monades sont
des concepts créés avant tout pour pallier au problèmes des langages
fonctionnels purs (sans effet de bords), donc déjà on en a juste pas
besoin, mais surtout le concept même de monade est tellement dur à
expliquer que ça reste flou pour la grande majorité des gens. Moi j´aime
Non, les monades sont au-delà de ça. Ce n'est pas parce que les monades sont utilisés dans Haskell, qui est un langage fonctionnel pur, pour représenter les effets de bords qu'ils n'ont d'utilité que dans ce contexte là.pas le flou, j´aime les solutions simples pour les problèmes complexes,
et les langages faciles à expliquer.
Au contraire, Haskell les utilise aussi dans d'autres contextes comme, par exemple, celui qui est présenté dans l'interview avec les options. Leur utilité va bien au delà et sont très utiles particulièrement dans les cas limites (division par 0, IO avec cas d'erreurs exceptionnels, etc.)
Même Caml qui est un langage fonctionnel non pur (donc avec effets de bords) permet d'écrire des monades (bien que le langage ne les supportent pas comme concept). Même des développeurs Ruby en codent.
C'est finalement utilisé comme un pattern au même titre que celui Visiteur ou Command.
Une monade n'est en fait qu'une structure de données représentant la notion de traitement: elle encapsule l'objet sur laquelle porte un traitement et permet d'obtenir une autre monade avec l'objet résultant de ce traitement. Les monades permettent de chaîner des actions de façon séquentielle et d'en gérer le flot selon les résultats de chacune des actions ; la programmation concurrente, la gestion des exceptions, celle des entrées-sorties, etc. peuvent se faire de façon élégante sous forme de monades.
Miguel
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Emmanuel Lécharny
> Faut faire attention parce que quand tu enchaines deux monades, ça fait une
> binade.
/me crawls back under a rock...
Guillaume Laforge
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Guillaume Laforge
Groovy Project Manager
SpringSource, a division of VMware
Stéphane Épardaud
Le jeudi 5 avril 2012 12:32:01 UTC+2, Emmanuel Bernard a écrit :
Faut faire attention parce que quand tu enchaines deux monades, ça fait une binade.Guillaume
Stéphane Épardaud
mmoqui
wrote:
>
> - ton message est illisible sous google groups, je ne comprends pas
> pourquoi mais vois toi-même :(
(thunderbird). J'ai du mal le configurer.
> - je n´ai pas compris le F-bounded polymorphism visiblement, mais ton
> explication ne m´a pas aidé
Je vais essayer d'expliquer avec un exemple simple. Tu définis par
exemple une classe de types Number. En général, cette classe est
définie comme l'ensemble des type T tel que T <: Number[T <:
Number[T]], autrement dit l'ensemble de tous les types T qui satisfont
l'interface de Number et pour lequel il existe un point fixe, c'est-à-
dire un type qui satisfait exactement (pas plus) l'interface de la
classe.
Tu spécifies ensuite (tissage statique ou dynamique) que Real et
Integer sont des types de Number. Pour chaque type, il existe une
classe pour lequel le type est un point fixe. Il existe donc pour Real
une classe de types pour lequel il est point fixe. Ce qui fait que, au
lieu de spécifier que Integer est un sous type de Real, tu déclares
que Integer est en fait aussi un type de cette classe des types ! Et
cette classe n'est finalement qu'une sous-classe de Number. Le tour
est joué : tu peux utiliser des entiers là où est attendu un real et
les méthodes définies dans les classes sont, pour chacun des types,
typées correctement.
> - les monades c´est un pattern et on peut le faire dans tous les langages
> il me semble donc malgré le fait que je ne vois pas bien à quoi ça sert, si
> j´ai bien compris Ceylon les supporte ;)
ou moins facilement. Par exemple, en Java, j'ai peur à ce que l'on
arrive vite à quelque chose de limité et difficilement lisible.
Lorsque ces derniers sont incorporés dans le langage, c'est un outil
mis à disposition de tout le monde et qui, en plus, a été pensé avec
le langage.
En fait, ici, Ceylon propose de répondre à des problèmes en jouant sur
différents concepts. Ce qui ajoute, à mon avis, un certain sentiment
de lourdeur. Or, parmi ces problèmes, les monades permettent d'y
répondre. Les réifier dans Ceylon permettrait de proposer un seul
concept uniforme et puissant.
Cédric Beust ♔
Cédric Beust ♔
Rémi Forax
oui et non, comme il y a aussi les implicits, on est très proche de la
surcharge d'opérateur du C++
même si certain operateurs ne peuvent pas être codé en Scala.
>
> --
> Cédric
Rémi
Julien Ponge
Au fait, un autre commentaire rapide sur le podcast: contrairement à ce que beaucoup de personnes semblent penser, Scala ne supporte pas la surcharge d'opérateur.Ce que Scala supporte, c'est 1) de pouvoir utiliser des caractères exotiques dans les noms de méthodes et 2) une certaine liberté (assez inégale) de pouvoir utiliser des invocations "infix" et/ou de pouvoir omettre le point (a.f = a f).
Julien Ponge
http://julien.ponge.info/
Alexandre Bertails
> On 04/05/2012 05:52 PM, Cédric Beust ♔ wrote:
>>
>> Au fait, un autre commentaire rapide sur le podcast: contrairement à ce
>> que beaucoup de personnes semblent penser, Scala ne supporte pas la
>> surcharge d'opérateur.
>>
>> Ce que Scala supporte, c'est 1) de pouvoir utiliser des caractères
>> exotiques dans les noms de méthodes et 2) une certaine liberté (assez
>> inégale) de pouvoir utiliser des invocations "infix" et/ou de pouvoir
>> omettre le point (a.f = a f).
>
>
> oui et non, comme il y a aussi les implicits, on est très proche de la
> surcharge d'opérateur du C++
"surcharger" une méthode en utilisant un implicit ne fonctionne pas,
puisque justement la méthode en question existe déjà, et du coup il
n'y a même pas besoin d'aller chercher un implicit.
Dans le cas général, le typechecker rejettera toute ambiguité. Il n'y
a jamais de surprise avec les implicits, qui sont déterminés
statiquement, contrairement à la surcharge, qui elle est dynamique, et
donc potentiellement dangereuse si on ne fait pas attention, bien plus
que d'avoir des "caractères exotiques dans les noms de méthodes".
C'est une feature dans Ceylon (un peu extrême, mais bon). D'ailleurs,
je pense que la doc Ceylon devrait être un peu plus positive à ce
sujet. On peut lire "It's time for some bad news: Ceylon doesn't
support method or constructor overloading" à [1].
Alexandre.
[1] http://ceylon-lang.org/documentation/1.0/tour/classes/#living_without_overloading
> même si certain operateurs ne peuvent pas être codé en Scala.
>
>>
>> --
>> Cédric
>
>
> Rémi
>
>
Alexandre Bertails
> Ce que tu décris n'as pas grand-chose à voir avec les monades, c'est juste
> comment unsafePerformIO marche en Haskell. Ce mécanisme utilise une monade
> en dessous (IO) mais c'est le seul rapport. Et franchement, c'est une
> approche assez limitée qui te contraint à utiliser une autre méthode si tu
> as besoin de déclencher l'évaluation plus tôt, ce qui arrive tout le temps
> (pour les curieux, il faut passer aux Iteratees).
>
> Vous connaissez probablement déjà au moins une monade sans le savoir: le
> design pattern du "Null Object". Je peine un peu à expliquer ça en français,
> mais en gros, s'il y a une chose à retenir en faveur des monades, c'est
> qu'elles permettent de composer des opérations qui ne sont pas faites pour
> être composées à l'origine.
Au contraire ! Un type monadique est justement une abstraction qui dit
comment elle se compose avec une abstraction du même type :-)
Pour ceux qui seront à DevoxxFr, je crois qu'il y aura une
présentation qui introduira (entre autres) les monades. Sûrement le
mercredi.
Alexandre.
Alexandre Bertails
> Au fait, un autre commentaire rapide sur le podcast: contrairement à ce que
> beaucoup de personnes semblent penser, Scala ne supporte pas la surcharge
> d'opérateur.
Si si, puisque un "opérateur" n'est rien d'autre qu'une méthode :
[[
scala> class Foo() { def +(foo: Foo): Foo = new Foo() }
defined class Foo
scala> class Bar() extends Foo { override def +(foo: Foo) = new Bar() }
defined class Bar
]]
Alexandre.
>
> Ce que Scala supporte, c'est 1) de pouvoir utiliser des caractères exotiques
> dans les noms de méthodes et 2) une certaine liberté (assez inégale) de
> pouvoir utiliser des invocations "infix" et/ou de pouvoir omettre le point
> (a.f = a f).
>
> --
> Cédric
>
Cédric Beust ♔
Dans le cas général, le typechecker rejettera toute ambiguité. Il n'y
a jamais de surprise avec les implicits, qui sont déterminés
statiquement, contrairement à la surcharge, qui elle est dynamique,
Cédric Beust ♔
Au contraire ! Un type monadique est justement une abstraction qui dit
comment elle se compose avec une abstraction du même type :-)
Rémi Forax
Kea, Cecil, Dylan, Groovy et quasiment tous les langages dynamiques qui
tournent
sur une VM Java lorsqu'ils appelent du Java (transition monde non-typé
vers monde typé)
répond le mec qui à fait sa thèse sur les multi-méthodes :)
>
> --
> Cédric
Rémi
Alexandre Bertails
> 2012/4/5 Cédric Beust ♔ <ced...@beust.com>:
>> Au fait, un autre commentaire rapide sur le podcast: contrairement à ce que
>> beaucoup de personnes semblent penser, Scala ne supporte pas la surcharge
>> d'opérateur.
>
> Si si, puisque un "opérateur" n'est rien d'autre qu'une méthode :
>
> [[
> scala> class Foo() { def +(foo: Foo): Foo = new Foo() }
> defined class Foo
>
> scala> class Bar() extends Foo { override def +(foo: Foo) = new Bar() }
> defined class Bar
> ]]
Bien entendu, l'exemple était complètement à côté de la plaque (je me
perds avec les traductions : surcharge != overriding) même si le
commentaire reste vrai. Comme en Java (remplacer + n'importe quoi
d'autre), on peut écrire
[[
scala> object Foo { def +(i: Int) = i; def +(s: String) = s }
defined module Foo
scala> Foo + 42
res0: Int = 42
scala> Foo + "42"
res1: String = 42
]]
Et Rémi a raison avec les implicits (mais ça reste statique), même si
y en a pas besoin au départ :-) À noter qu'à cause de l'erasure, il y
a certaines limites (comme en Java) mais on peut utiliser Manifest
[[
scala> object Foo { def +(l: List[Int]) = l; def +(l: List[String]) = l }
<console>:7: error: double definition:
method +:(l: List[String])List[String] and
method +:(l: List[Int])List[Int] at line 7
have same type after erasure: (l: List)List
object Foo { def +(l: List[Int]) = l; def +(l: List[String]) = l }
scala> object Foo { def +(l: List[Int]) = l; def +[M: Manifest](l:
List[String]) = l }
defined module Foo
scala> Foo + List("42")
res0: List[String] = List(42)
scala> Foo + List(42)
res1: List[Int] = List(42)
]]
Alexandre.
Thibaud Vibes
> Salut,
>
> L'homme qui s'occupe de Scala .NET s'appelle Miguel Garcia, et son
> repo github se trouve ici: https://github.com/magarciaEPFL. Je ne sais
> là-dedans. Scala lui-même et dans https://github.com/scala/scala.
>
> Cordialement,
>
> Matthew Farwell.
je me suis permis de renommer...
2 questions :
- est-ce qu'on connait les motivations à porter Scala sur la plateforme
.NET? Vu la connaissance que semble avoir ces gens sur les langages, ils
devaient avoir conscience de la difficulté (tout ce qu'y a été dit sur
les generics notamment) Donc pourquoi? (et pareil pour les autres
langages qui s'y essayent)
-> Est-ce un POC ou un peu plus que cela? N'y a t-il rien de séduisant
disposer d'un langage "universel" (même si on ne peut pas intégrer le
meilleure des 2 mondes pour cause d'incompatibilité) ?
-> Est-ce porté par les créateurs initiaux ou bien une initiative de la
communauté. Miguel Garcia à l'air un peu tout seul a commiter sur ce
projet. Ca fait un peu Don Quichotte.
- Y a t-il autant de flamewar à l'encontre de Scala de la part de la
communauté .NET ? (ça c'est la question optionnelle :-) elle vaut pas
beaucoup de points)
J'ai travaillé l'année dernière avec une boite "tout microsoft" qui nous
sous-traitaient un peu de R&D (nous on est full Java / Linux). Comme on
maîtrise mal on a quand même codé en Java et livré les sources dans
l'optique qu'il les reprennent et les réécrivent en C#. Si on avait eu
un langage compatible avec les 2 JVM ça nous aurait peut-être aidé.
Thibaud
Thibaud Vibes
> - ton message est illisible sous google groups, je ne comprends pas
<HS>
J'ai le m�me pb, j'utilise plut�t mon client mail pour suivre le groupe,
mais tous mes messages ont des caract�res corrompus � l'affichage dans
Google Groupes. C'est pas cool.
</HS>
Thibaud
Guillaume Laforge
Le 05/04/2012 13:29, Stéphane Épardaud a écrit :<HS>
- ton message est illisible sous google groups, je ne comprends pas pourquoi mais vois toi-même :(
J'ai le même pb, j'utilise plutôt mon client mail pour suivre le groupe, mais tous mes messages ont des caractères corrompus à l'affichage dans Google Groupes. C'est pas cool.
</HS>
Thibaud
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Emmanuel Lécharny
C# et Java sont assez proche. Ca reste quand même pénible de faire le
portage de l'un vers l'autre...
La question est plutôt de savoir pourquoi se limiter à une JVM qui ne
tourne que sur un seul OS quand on dispose d'une autre JVM qui tourne
partout?
Ceux qui décident de faire du M$ on certaiment avantage à tout faire
dans un environnement M$, mais du coup, pourquoi faire du Scala sur une
JVM .Net ?
Je pense qu'on risque d'être confronté au même problème que Mono, à
savoir un 'truc' qui n'est implémenté que partiellement.
Rémi Forax
> Le 4/5/12 10:16 AM, Thibaud Vibes a �crit :
>> Le 04/04/2012 20:26, Matthew Farwell a �crit :
>>> Salut,
>>>
>>> L'homme qui s'occupe de Scala .NET s'appelle Miguel Garcia, et son
>>> repo github se trouve ici: https://github.com/magarciaEPFL. Je ne sais
>>> l�-dedans. Scala lui-m�me et dans https://github.com/scala/scala.
>>>
>>> Cordialement,
>>>
>>> Matthew Farwell.
>> Ce sujet m'intrigue. Comme il n'a plus grand chose avec le post
>> initial je me suis permis de renommer...
>>
>> 2 questions :
>> qu'y a �t� dit sur les generics notamment) Donc pourquoi? (et pareil
>> -> Est-ce un POC ou un peu plus que cela? N'y a t-il rien de
>> int�grer le meilleure des 2 mondes pour cause d'incompatibilit�) ?
>> -> Est-ce port� par les cr�ateurs initiaux ou bien une initiative de
>> la communaut�. Miguel Garcia � l'air un peu tout seul a commiter sur
>>
>> communaut� .NET ? (�a c'est la question optionnelle :-) elle vaut pas
>> beaucoup de points)
>>
>>
>> J'ai travaill� l'ann�e derni�re avec une boite "tout microsoft" qui
>> sources dans l'optique qu'il les reprennent et les r��crivent en C#.
>> Si on avait eu un langage compatible avec les 2 JVM �a nous aurait
>> peut-�tre aid�.
>
> C# et Java sont assez proche. Ca reste quand m�me p�nible de faire le
C# et Java sont assez proche mais .Net et Java la plateforme sont pas si
proche que cela
surtout vis � vis d'un langage comme Scala.
Un exemple tout con, un lambda en Scala va �tre vu comme un delegate en
C# et
une interface en Java.
Tu peux utiliser aussi des interfaces en .Net mais comme le runtime ne
de-virtualize pas,
au niveau perf t'es mort.
Donc la translation est pas du tout la m�me.
Et tu auras le m�me probl�me pour les varargs, les appels par structural
typing etc,
et le pire est que dans le langage les trucs se combinent et le fait que
Scala ait de la feature � revendre
n'arrange pas les choses.
Donc oui tu peux avoir un langage qui target plusieurs backends, mais
chaque backend est un vrai gros boulot,
s�rement pas quelque chose que l'on peut nommer 'portage'.
>
> La question est plut�t de savoir pourquoi se limiter � une JVM qui ne
> tourne que sur un seul OS quand on dispose d'une autre JVM qui tourne
> partout?
>
> Ceux qui d�cident de faire du M$ on certaiment avantage � tout faire
> dans un environnement M$, mais du coup, pourquoi faire du Scala sur
> une JVM .Net ?
>
> Je pense qu'on risque d'�tre confront� au m�me probl�me que Mono, �
> savoir un 'truc' qui n'est impl�ment� que partiellement.
>
>
R�mi
Thibaud Vibes
Thibaud
Le 06/04/2012 09:51, Guillaume Laforge a �crit�:
Et puis je sais pas pourquoi, mais c'est chiant, parce que tes messages, je suis oblig� de les mod�rer un par un dans l'interface de Google Groups.Tes trois-quatre derniers messages, c'�tait comme �a.
2012/4/5 Thibaud Vibes <thibau...@wanadoo.fr>
Le 05/04/2012 13:29, St�phane �pardaud a �crit :<HS>
- ton message est illisible sous google groups, je ne comprends pas pourquoi mais vois toi-m�me :(
J'ai le m�me pb, j'utilise plut�t mon client mail pour suivre le groupe, mais tous mes messages ont des caract�res corrompus � l'affichage dans Google Groupes. C'est pas cool.
</HS>
Thibaud
Guillaume Laforge
Depuis ma maj thunderbird j'ai un bouton "Répondre à la liste" mais je l'utilise pas, peut-être c'est ça
Thibaud
Le 06/04/2012 09:51, Guillaume Laforge a écrit :Et puis je sais pas pourquoi, mais c'est chiant, parce que tes messages, je suis obligé de les modérer un par un dans l'interface de Google Groups.Tes trois-quatre derniers messages, c'était comme ça.
2012/4/5 Thibaud Vibes <thibau...@wanadoo.fr>
Le 05/04/2012 13:29, Stéphane Épardaud a écrit :<HS>
- ton message est illisible sous google groups, je ne comprends pas pourquoi mais vois toi-même :(
J'ai le même pb, j'utilise plutôt mon client mail pour suivre le groupe, mais tous mes messages ont des caractères corrompus à l'affichage dans Google Groupes. C'est pas cool.
</HS>
Thibaud
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Thibaud Vibes
Appelez-moi boulet.
Boulet
Le 06/04/2012 10:39, Guillaume Laforge a �crit�:
Aucune id�e.Mais tes deux derniers messages sont pass�s direct sans intervention.Le myst�re reste entier.
2012/4/6 Thibaud Vibes <thibau...@wanadoo.fr>
Depuis ma maj thunderbird j'ai un bouton "R�pondre � la liste" mais je l'utilise pas, peut-�tre c'est �a
Thibaud
Le 06/04/2012 09:51, Guillaume Laforge a �crit�:
Et puis je sais pas pourquoi, mais c'est chiant, parce que tes messages, je suis oblig� de les mod�rer un par un dans l'interface de Google Groups.
Tes trois-quatre derniers messages, c'�tait comme �a.
2012/4/5 Thibaud Vibes <thibau...@wanadoo.fr>
Le 05/04/2012 13:29, St�phane �pardaud a �crit :<HS>
- ton message est illisible sous google groups, je ne comprends pas pourquoi mais vois toi-m�me :(
J'ai le m�me pb, j'utilise plut�t mon client mail pour suivre le groupe, mais tous mes messages ont des caract�res corrompus � l'affichage dans Google Groupes. C'est pas cool.
</HS>
Thibaud
Cédric Beust ♔
- Il y a déjà C# et F# sur .net.
- Un langage qui n'est pas supporté nativement par Visual Studio n'a quasiment aucune chance de s'imposer.
- Il n'y a quasiment aucun avantage à tourner Scala sur IL par rapport à la JVM.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
Pour plus d'options, consultez la page de ce groupe :
http://groups.google.com/group/lescastcodeurs?hl=fr
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Sam Bessalh
Sent from IPhone
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Rémi Forax
> Je ne pense pas que faire tourner Scala sur ka CLE soit un projet de
> typesafe. Mais plutot de Microsoft lui même, puisqu'il le finance, en
> partenariat avec l'EPFL.
> D'ailleurs je ne vois pas où est le problème , il y a bien Fantom qui
> cible les deux plateformes.
Non, le support de .Net pour Fantom est un proto [#1]
> Ou encore des implementations de langages comme IronPythob ou IronRuby
> qui existent.
Elles existent mais Microsoft à couper le financement et je sais que
dans le cas
de IronRuby, ils ne sont pas capable de faire tourner rail.
> Cela dit je doute que le doute soit d'en faire des implem de
> reference. Et dans le cas de typesafe, les dernières versions de scala
> ou de akka sont tellement liées à la jvm que toute potentielle
> implementation sur .net mettra des années à etre au meme niveau.
En y réfléchissant, je suis pas sur qu'il existe un langage qui target
la JVM et le CLR
et pour lequel les deux backends sont production ready.
>
> Sent from IPhone
[1] https://en.wikipedia.org/wiki/Fantom_%28programming_language%29
>
>
> On Apr 6, 2012, at 17:40, Cédric Beust ♔ <ced...@beust.com
> <mailto:ced...@beust.com>> wrote:
>
>> Je n'ai jamais compris la motivation:
>>
>> * Il y a déjà C# et F# sur .net.
>> * Un langage qui n'est pas supporté nativement par Visual Studio
>> n'a quasiment aucune chance de s'imposer.
>> * Il n'y a quasiment aucun avantage à tourner Scala sur IL par
>> <mailto:ced...@beust.com>> a écrit :
>>
>> On Tue, Apr 3, 2012 at 1:53 PM, Joseph
>> Pachod<joseph...@gmail.com
>> <mailto:joseph...@gmail.com>>
>> wrote:
>>
>> On Tue, Apr 3, 2012 at 5:53 PM, Cédric Beust
>> ♔<ced...@beust.com <mailto:ced...@beust.com>> wrote:
>>
>> C'est aussi une
>> des raisons pour lesquelles l'effort de back end
>> .Net en Scala est au
>> point
>> mort.
>>
>> bizarre, j'avais lu un post d'Odersky félicitant le
>> gars derrière pour
>> son boulot et une simple recherche google m'a donné ça
>> http://www.scala-lang.org/node/10299
>>
>> ça a l'air de tourner
>>
>>
>> Cet article date d'il y a un an, et il dit:
>>
>> "The key limitation for the moment is that Scala programs
>> cannot use
>> libraries in .Net that are compiled using CLR generics,
>> such as the .Net
>> collections. However, for this particular example that's
>> a minor limitation
>> as the much better Scala collections library would be the
>> natural developer
>> choice anyway. Just to be clear: it's only CLR generics
>> that are not
>> implemented in the Scala.Net <http://Scala.Net> compiler,
>> all the Scala features (including
>> Scala generics) are available to the programmer. The .Net
>> generics will be
>> supported in the fall."
>>
>> Ce qu'il ne dit pas c'est que la raison de cette
>> limitation est parce que
>> les génériques de C# sont réifiés (une des raisons pour
>> lesquelles je disais
>> que la réification des génériques a plus d'inconvénients
>> que d'avantages).
>>
>> J'ai essayé de trouver un repository ou les sources pour
>> avoir une idée de
>> l'activité mais je suis revenu bredouille, peut-être
>> as-tu eu plus de chance
>> que moi ? Tu as un lien ?
>>
>> Quoi qu'il en soit, à mon avis, ce projet n'ira nulle part.
>>
>> --
>> Cédric
>>
>> --
>> Vous recevez ce message, car vous êtes abonné au groupe
>> Google
>> Groupes lescastcodeurs.
>> Pour envoyer un message à ce groupe, adressez un e-mail
>> à lescast...@googlegroups.com
>> <mailto:lescast...@googlegroups.com>.
>> Pour vous désabonner de ce groupe, envoyez un e-mail à
>> l'adresse
>> lescastcodeur...@googlegroups.com
>> <mailto:lescastcodeurs%2Bunsu...@googlegroups.com>.
>> Pour plus d'options, consultez la page de ce groupe :
>> http://groups.google.com/group/lescastcodeurs?hl=fr
>>
>>
>> --
>> Vous recevez ce message, car vous êtes abonné au groupe Google
>> Groupes lescastcodeurs.
>> Pour envoyer un message à ce groupe, adressez un e-mail à
>> lescast...@googlegroups.com
>> <mailto:lescast...@googlegroups.com>.
>> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
>> lescastcodeur...@googlegroups.com
>> <mailto:lescastcodeurs%2Bunsu...@googlegroups.com>.
>> Pour plus d'options, consultez la page de ce groupe :
>> http://groups.google.com/group/lescastcodeurs?hl=fr
>>
>>
>> --
>> Vous recevez ce message, car vous êtes abonné au groupe Google
>> Groupes lescastcodeurs.
>> Pour envoyer un message à ce groupe, adressez un e-mail à
>> lescast...@googlegroups.com <mailto:lescast...@googlegroups.com>.
>> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
>> lescastcodeur...@googlegroups.com
>> <mailto:lescastcodeur...@googlegroups.com>.
Joseph Pachod
approcher de plus près ces concepts? Ca m'intéresse beaucoup mais je
peine à trouver des resources...
Merci !
++
joseph
On Fri, Apr 6, 2012 at 10:43 AM, Thibaud Vibes <thibau...@wanadoo.fr> wrote:
> J'ai utilisé le bouton "Répondre à la liste" plutôt que "Répondre" :-) (il
> doit mettre les entêtes qui vont bien)
>
> Appelez-moi boulet.
>
> Boulet
>
>
> Le 06/04/2012 10:39, Guillaume Laforge a écrit :
>
> Aucune idée.
> Mais tes deux derniers messages sont passés direct sans intervention.
> Le mystère reste entier.
>
> 2012/4/6 Thibaud Vibes <thibau...@wanadoo.fr>
>>
>> Depuis ma maj thunderbird j'ai un bouton "Répondre à la liste" mais je
>> l'utilise pas, peut-être c'est ça
>>
>> Thibaud
>>
>> Le 06/04/2012 09:51, Guillaume Laforge a écrit :
>>
>> Et puis je sais pas pourquoi, mais c'est chiant, parce que tes messages,
>> je suis obligé de les modérer un par un dans l'interface de Google Groups.
>> Tes trois-quatre derniers messages, c'était comme ça.
>>
>> 2012/4/5 Thibaud Vibes <thibau...@wanadoo.fr>
>>>
>>> Le 05/04/2012 13:29, Stéphane Épardaud a écrit :
>>>
>>>> - ton message est illisible sous google groups, je ne comprends pas
>>>> pourquoi mais vois toi-même :(
>>>
>>> <HS>
>>> J'ai le même pb, j'utilise plutôt mon client mail pour suivre le groupe,
>>> mais tous mes messages ont des caractères corrompus à l'affichage dans
>>> Google Groupes. C'est pas cool.
>>> </HS>
>>>
>>> Thibaud
>
>
Joseph Pachod
http://www.infoq.com/articles/ScalaNETInterview :
InfoQ: A few years ago there already had been a Scala version for .NET
which disappeared. So why do you consider it important to provide
Scala on .NET?
Martin Odersky: Scala .Net has a complex history, that’s rarely
discussed outside the hacker community. Individuals like Nikolay
Mihaylov and Lukas Rytz made great progress creating a cross-compiler,
and Miguel Garcia, part of the Scala group at EPFL, has worked
diligently to get the cross-compiler to actually bootstrap itself to
the .Net environment - in order to have a executable Scala.net that
compiles its own sources - which he refers to as “a classic chicken
and egg problem of colossal proportions.“
Also, there are many reasons why it’s valuable to have Scala on .Net,
both for developers and companies in general. Developers have to learn
just one language to suit both environments, and companies can move
scarce resources, good developers, easily between platforms to save
money and increase flexibility.
Given the concise and highly productive nature of Scala, by using
Scala on .Net, developers are able to quickly deploy applications
across the two major industry platforms: JVM and .Net. .Net provides
an integration platform for several languages and this implementation
of Scala inter-operates nicely. You can use existing .Net libraries or
applications without re-writing everything in Scala. Ultimately it
means that many tools and applications created for the .Net and JVM
environments can be ported from one to the other. This works to
everyone’s advantage.
Concernant la mise en oeuvre du portage, Miguel Garcia s'est basé sur
IKVM, http://www.ikvm.net/ . On peut d'ailleurs lire sur leur home
page:
IKVM.NET is an implementation of Java for Mono and the Microsoft .NET
Framework. It includes the following components:
A Java Virtual Machine implemented in .NET
A .NET implementation of the Java class libraries
Tools that enable Java and .NET interoperability
Bien que ce soit toujours un gros boulot, il n'est tout de même pas
parti de zéro, loin de là à priori
++
Cédric Beust ♔
Net provides an integration platform for several languages and this implementationof Scala inter-operates nicely.
Alexandre Bertails
> Cédric, Alexandre: pouvez vous me conseiller les bons livres pour
> approcher de plus près ces concepts? Ca m'intéresse beaucoup mais je
> peine à trouver des resources...
À venir (et sûrement génial connaissant les auteurs) :
http://manning.com/bjarnason/
Sinon très facile d'accès : http://learnyouahaskell.com/
Alexandre.
Cédric Beust ♔
2012/4/6 Joseph Pachod <joseph...@gmail.com>:
> Cédric, Alexandre: pouvez vous me conseiller les bons livres pourÀ venir (et sûrement génial connaissant les auteurs) :
> approcher de plus près ces concepts? Ca m'intéresse beaucoup mais je
> peine à trouver des resources...
http://manning.com/bjarnason/
Sinon très facile d'accès : http://learnyouahaskell.com/
Joseph Pachod
Acheté :) Vivement qu'il avance!
> Quant au livre, j'attends de voir. Il sera bon si Paul et Runar arrivent à
> faire en sorte que Tony se limite aux faits et s'abstient de donner ses
> opinions, qui lui ont déjà valu plusieurs éjections de mailing-lists. Il n'y
> a pas de doute que ce sont tous les trois des experts, mais il y une
> différence notable entre être un expert et être capable d'expliquer son
> expertise à des débutants.
pédagogue. Je ne connais pas ses acolytes par contre. Ceci dit, avoir
le livre en MEAP est aussi l'occasion d'aller se plaindre si ça tourne
mal, même si pour l'instant les 2 chapitres proposés me semblent bien
>>
>> Sinon très facile d'accès : http://learnyouahaskell.com/
>
>
> Oui, LearnYouAHaskell est une bonne ressource qui décrit bien les bases
> (functors, applicative functors et monades, entre autres). C'est une longue
> lecture parce que l'auteur prend son temps, mais c'est aussi la raison pour
> laquelle c'est un bon point de départ pour débutants.
>
> LYAH est aussi une bonne ressource à revisiter plusieurs fois si tu
> n'arrives pas à le lire en entier la première fois: comme tous les idées
> théoriques, certains concepts ont besoin d'être lus plusieurs fois avant de
> commencer à prendre sens.
livre... Mais s'il est aussi bien que vous le dites, et il a l'air,
j'achèterai.
Merci pour ces ressources :)
++