Bon, tu sais ce que j’en pense, et en 3 ans, je n’ai pas changé d’avis. Ca reste un langage de fanatique, qui n’a pas sa place dans une entreprise ‘normale’ pour un projet ‘standard’ qui sera maintenu par une autre équipe (cas le plus fréquent).
Ppur une startup, par contre, c’est un aure débat. Après tout, pourquoi refuser de se faire plaisir
Je ne réagirais pas longuement sur la partie “langage de fanatique”, je manque de contexte: je ne pense pas être un fanatique de quoi que ce soit (je suis peut-être même l’archétype du gars indécis et qui pèse 12 fois une décision pour la valider), et pourtant j’utilise Scala.
Donc, sur la seconde partie: c’est quoi, une entreprise normale dans un projet standard ? Une qui externalise le développement de application de gestion de demande de congès à la SSII du coin ? Oui, dans ce cas, clairement Java (ou PHP, ou Cobol ou Fortran, suivant ton domaine métier) sont de meilleurs choix, et c’est dit dans les slides.
Après, sans aller jusqu’à la caricature précédente, si l’application en question est ton coeur de métier, ca se discute, et ce que je voulais montrer dans ces slides, c’est que des entreprises de plus en plus “mainstream” (pas de la finance, pas le site-web-social-2.0 à la mode, pas la start-up qui va révolutionner la télé), choississent Scala, avec succès. The Guardian semble être un bon exemple: c’est loin d’être une start-up, et ils utilisent Scala pour la publication de leur site. Et ca marche.
Bref, je veux bien entendre que tu n’aimes pas Scala, et clairement, je ne chercherai pas à te convaincre de l’utiliser, ni même de remettre en cause tes idées sur ce langage !
Aucune connotation négative dans le terme fanatique, je te rassure. J’aurais dû employer le terme fana, c’est moins connoté ‘fou de dieu ‘
Une entreprise normale, c’est juste une entreprise qui délègue son développement à une SSII. SSII qui n’a pas les moyens ni le désir de se payer le cador Scala avec l’encadrement qui va bien, et qui n’a surtout pas les moyens d’entretenir une équipe de scalaistes en interne ! Ca recouvre, je pense, 99% des SSII en France.
Après, ça n’empêche pas les expérimentations.
Concernant The Guardian, il faut aussi remettre les choses dans leur contexte : le site Web du Guardian, c’est 100 000 lignes de code au total, principalement du Java. C’est franchement peu. On n’est pas ici dans le cadre d’une entreprise normale, les gars sont tous des internes, ça ressemble en fait fuieusement à du mode startup.
Après, que ça marche, je n’ai aucun doute la dessus. Scala, ce n’est pas furieusement buggé, ni inutilisable. C’est juste dangereux à long terme.
Avec la définition “Une entreprise normale, c’est juste une entreprise qui délègue son développement à une SSII”, je pense qu’on est d’accord. Et que les slides ne disent pas l’inverse, au contraire.
La remarque “100 000 lignes de code au total, principalement du Java. C’est franchement peu.” couplée à la définition précédente d’entreprises normales me fait m’interroger sur leurs choix de développer autant de soft en externe plutôt que de monter une équipe interne / acheter des softs tout fait, mais c’est un autre débat…
Je te rejoins complètement sur le second point, qui mérite un débat. Je suis intimement persuadé que recourir à des SSII pour tous les développements est juste ruineux à long terme.
Mais on aura l’occasion d’en discuter cette semaine, avec plein de bières, bein sûr ! Par contre, compte pas sur moi pour sortir en boîte après, surtout si tu veux allez à la Scala !
Ce langage présente un très gros inconvénient : mis dans les mains d’un développeur moyen on obtient du code illisible.
Ceci est lié directement aux libertés trop grandes offertes par ce langage.
(possibilité d’omettre les parenthèses lors de l’appel d’une fonction, possibilité d’omettre les ; , possibilité de faire des boucles cachées….)
De plus scala est encore trop jeune:
- outils/plugin lents
- peu de développeurs scala expérimentés
- changement majeurs d’une version à l’autre
“Ici, le facteur clé est le système de type de Scala, qui permet de définir simplement des propriétés fortes sur les données (« non, l’ID d’une personne n’est pas une chaîne de caractères, c’est un ID ») ”
Quelles sont les fonctionnalités du langage qui permettent de faire ça? Aurais tu un exemple?
@Loic: essentiellement la facilité de créer des types via les case class, et depuis Scala 2.10 les value class (cf: http://docs.scala-lang.org/overviews/core/value-classes.html ). Là où en Java, chaque class correspond à un fichier, et où il est tout simplement trop lourd de faire une class “PersonId”, en Scala, ca se fait naturellement: on construit le fichier qui contient la définition d’une personne, et c’est entre autre une classe PersonId.
@Marc: les avantages de ses inconvénients… Pour le code illisible, je pense que c’est vrai dans n’importe quel langage (oui, même Java), et que c’est plutôt lié à la jeunesse du langage, et donc au manque de bonnes pratiques et de convention (et d’outils pour les imposer). En reprenant Java, regardait du code fait par un dev moyen, ou pire, par un dev Java moyen à la fin des années 90 (vous savez, un qui avait fait du C avant, mais pas trop bien…)
Par contre, je ne suis pas sûr de voir en quoi omettre les “;” en fait parti, ni ce que sont les boucles cachées. Après, comme pour tout gros projet, les revues de code sont là pour se mettre d’accord sur ce qui est acceptable et ce qui ne l’est pas, et vers quoi tendre.
Salut François
Bon, tu sais ce que j’en pense, et en 3 ans, je n’ai pas changé d’avis. Ca reste un langage de fanatique, qui n’a pas sa place dans une entreprise ‘normale’ pour un projet ‘standard’ qui sera maintenu par une autre équipe (cas le plus fréquent).
Ppur une startup, par contre, c’est un aure débat. Après tout, pourquoi refuser de se faire plaisir
Je ne réagirais pas longuement sur la partie “langage de fanatique”, je manque de contexte: je ne pense pas être un fanatique de quoi que ce soit (je suis peut-être même l’archétype du gars indécis et qui pèse 12 fois une décision pour la valider), et pourtant j’utilise Scala.
Donc, sur la seconde partie: c’est quoi, une entreprise normale dans un projet standard ? Une qui externalise le développement de application de gestion de demande de congès à la SSII du coin ? Oui, dans ce cas, clairement Java (ou PHP, ou Cobol ou Fortran, suivant ton domaine métier) sont de meilleurs choix, et c’est dit dans les slides.
Après, sans aller jusqu’à la caricature précédente, si l’application en question est ton coeur de métier, ca se discute, et ce que je voulais montrer dans ces slides, c’est que des entreprises de plus en plus “mainstream” (pas de la finance, pas le site-web-social-2.0 à la mode, pas la start-up qui va révolutionner la télé), choississent Scala, avec succès. The Guardian semble être un bon exemple: c’est loin d’être une start-up, et ils utilisent Scala pour la publication de leur site. Et ca marche.
Bref, je veux bien entendre que tu n’aimes pas Scala, et clairement, je ne chercherai pas à te convaincre de l’utiliser, ni même de remettre en cause tes idées sur ce langage !
Aucune connotation négative dans le terme fanatique, je te rassure. J’aurais dû employer le terme fana, c’est moins connoté ‘fou de dieu ‘
Une entreprise normale, c’est juste une entreprise qui délègue son développement à une SSII. SSII qui n’a pas les moyens ni le désir de se payer le cador Scala avec l’encadrement qui va bien, et qui n’a surtout pas les moyens d’entretenir une équipe de scalaistes en interne ! Ca recouvre, je pense, 99% des SSII en France.
Après, ça n’empêche pas les expérimentations.
Concernant The Guardian, il faut aussi remettre les choses dans leur contexte : le site Web du Guardian, c’est 100 000 lignes de code au total, principalement du Java. C’est franchement peu. On n’est pas ici dans le cadre d’une entreprise normale, les gars sont tous des internes, ça ressemble en fait fuieusement à du mode startup.
Après, que ça marche, je n’ai aucun doute la dessus. Scala, ce n’est pas furieusement buggé, ni inutilisable. C’est juste dangereux à long terme.
Avec la définition “Une entreprise normale, c’est juste une entreprise qui délègue son développement à une SSII”, je pense qu’on est d’accord. Et que les slides ne disent pas l’inverse, au contraire.
La remarque “100 000 lignes de code au total, principalement du Java. C’est franchement peu.” couplée à la définition précédente d’entreprises normales me fait m’interroger sur leurs choix de développer autant de soft en externe plutôt que de monter une équipe interne / acheter des softs tout fait, mais c’est un autre débat…
Je te rejoins complètement sur le second point, qui mérite un débat. Je suis intimement persuadé que recourir à des SSII pour tous les développements est juste ruineux à long terme.
Mais on aura l’occasion d’en discuter cette semaine, avec plein de bières, bein sûr ! Par contre, compte pas sur moi pour sortir en boîte après, surtout si tu veux allez à la Scala !
On utilise Scala sur un gros projet.
Ce langage présente un très gros inconvénient : mis dans les mains d’un développeur moyen on obtient du code illisible.
Ceci est lié directement aux libertés trop grandes offertes par ce langage.
(possibilité d’omettre les parenthèses lors de l’appel d’une fonction, possibilité d’omettre les ; , possibilité de faire des boucles cachées….)
De plus scala est encore trop jeune:
- outils/plugin lents
- peu de développeurs scala expérimentés
- changement majeurs d’une version à l’autre
Hello,
Retour d’expérience très intéressant!
“Ici, le facteur clé est le système de type de Scala, qui permet de définir simplement des propriétés fortes sur les données (« non, l’ID d’une personne n’est pas une chaîne de caractères, c’est un ID ») ”
Quelles sont les fonctionnalités du langage qui permettent de faire ça? Aurais tu un exemple?
Merci
@Loic: essentiellement la facilité de créer des types via les case class, et depuis Scala 2.10 les value class (cf: http://docs.scala-lang.org/overviews/core/value-classes.html ). Là où en Java, chaque class correspond à un fichier, et où il est tout simplement trop lourd de faire une class “PersonId”, en Scala, ca se fait naturellement: on construit le fichier qui contient la définition d’une personne, et c’est entre autre une classe PersonId.
@Marc: les avantages de ses inconvénients… Pour le code illisible, je pense que c’est vrai dans n’importe quel langage (oui, même Java), et que c’est plutôt lié à la jeunesse du langage, et donc au manque de bonnes pratiques et de convention (et d’outils pour les imposer). En reprenant Java, regardait du code fait par un dev moyen, ou pire, par un dev Java moyen à la fin des années 90 (vous savez, un qui avait fait du C avant, mais pas trop bien…)
Par contre, je ne suis pas sûr de voir en quoi omettre les “;” en fait parti, ni ce que sont les boucles cachées. Après, comme pour tout gros projet, les revues de code sont là pour se mettre d’accord sur ce qui est acceptable et ce qui ne l’est pas, et vers quoi tendre.