Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
_skip pense à Scala... il a quand même un peu raison, non ? Celà dit... Scala ou autre, dès que le langage laisse des libertés au développeur, on peut arriver à du code lisible ou pas. IMHO, il doit en être de même pour Ceylon !Envoyé par professeur shadoko
ça ça ressemble à un préjugé
Perso, ce qui m'attire dans Scala, c'est qu'il casse les idées reçues sur la programmation impérative... Mais comme _skip avec Ceylon, je ne me vois pas pousser ce langage dans l'industrie !
(note: je trouve que Scala occupe une niche très analogue à celle de Lisp)
mais dans ce cas il le dit directement .... le qualificatif "universitaire" général me navre
(précision: le "professeur" dans mon avatar est une blague, même si j'évolue dans le monde universitaire, même si il m'arrive d'enseigner.... je ne suis pas moi-même un universitaire)
Oui et non.
Ce n'est pas comme si il avait fallu 5 ans entre la version béta et la première release stable.
L'autre façon de voir les choses, c'est de dire que Java était suffisamment complet pour avoir le luxe de prendre son temps pour la version 7.
@Nemek: C'était pas voulu comme une ligne temporelle. Cobol est encore très utilisé, C++ aussi. PHP aussi. D'ailleurs, dire que Cobol c'est un truc de comptable... tu as déjà pratiqué? Parce que pour le (très) peu que j'en ait fait, c'est plutôt casse pied comme usage. Donc pas si trivial.
Intéressant comme initiative même s'il y a peu de chance pour que je m'y mette, sauf sous la torture.
En lisant le résumé, ce qui est intéressant, c'est aussi et surtout la génération de code en JS en plus de Java.
[troll]
Certains diront que c'est un bref effet de mode autour de JS. Pour ma part, c'est peut-être un indice de plus montrant le déclin de Java au profit d'autres langages dont JS.
[/troll]
Ce Ceylon pourrait être en tout cas un langage qui facilitera la migration de la communauté Java vers JS qui sait
PS : Les Java-zélotes, relax hein !
Que tu le veuilles ou non, il s'agit bien de la ligne temporelle de création des langages. Et le fait qu'ils soient encore utilisé ou non ne change rien.
Les forces et les idiomes de chaque langage est plus ou moins contextuel aux usages de l'époque à laquelle il est né.
Aujourd'hui on met beaucoup en avant la productivité (lisibilité, maintenabilité) parce que les coûts des logiciels n'ont jamais été aussi regardé par les "acheteurs" (ou les "payeurs").
Oui, j'ai déjà fait du COBOL pendant plus d'un an et demi sur Windows et z/OS. COBOL n'est pas casse pied, c'est juste horrible.
Et l'horreur est né justement pour que les choses soient très parlante. Il est né à une époque ou on ne formait pas de développeur, de concepteur ou d'AMOA. Le langage se voulait lisible du commun des mortels et notamment des "gestionnaires". Il y avait encore un lien directe entre l'analyste-programmeur et le demandeur.
D'ailleurs un programme COBOL relativement bien écrit est le récit de ce qu'il fait.
Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
Ceylon : Installation - Concepts de base - Typage - Appels et arguments
ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
Une solution vous convient ? N'oubliez pas le tag
Signature par pitipoisson
Là je dois dire que je ne sais pas trop ce que vaut cette idée de faire du JS. Je ne sais pas si c'est comme tu dis un peu du marketing mais je suis persuadé que ça a posé quelques soucis sur les types primitifs disponibles (je rappelle qu'à ce jour y'a un type entier et un type réel, 64 bits chacun, même si des projets existe d'avoir un préfixe short et un type byte).
Par contre avec un framework web bien fichu dans le style de Play!, pouvoir coder côté serveur et côté client avec le même langage, c'est intéressant.
Et moi ce qui me navre, c'est que sur tout le texte que j'ai écrit, ce seul mot t'ait causé une réaction. Ca m'intéresse que très moyennement de débattre sur la légitimité de l'expression puisque j'espérais que d'autres éléments de mon post seraient plus intéressants à discuter. Cependant, puisqu'en général je lis tes interventions avec un certain intérêt, je vais juste t'éclairer sur l'emploi de ce qualificatif et tu verras à quel point ce n'est pas grand-chose.
Je trouve juste que sur la panoplie de nouveaux langages qu'on voit déferler, si peu semblent pensés avec les réalités du terrain en tête. J'utilise le qualificatif "d'universitaire" pour qualifier ceux qui sont, à mon sens, plus intéressés par produire du concept que par répondre à des besoins de l'industrie. Même si ça arrive que ce soit le cas, ça ne veut pas dire qu'ils sont faits par des gens qui évoluent dans une université.
Quant à scala, j'ai déjà assez trollé dessus, je voulais éviter d'en parler mais ceylon et scala sont justement 2 approches totalement à l'opposé.
En te lisant, j'ai tout de suite pensé à Scala ! Car si on exempte Groovy... Clojure, Kotlin, etc n'ont, IMHO, rien apporté de plus que du buzz ! Tu penses que Groovy n'est pas fait pour l'industrie ?
Développer s'est effectivement faire autre chose que du one-liner sous emacs !
Avant, tout un langage se doit
- d'être lisible / partageable
- d'être documenté / supporté
- d'être suffisament générique
- d'être interropérable avec le reste du monde
- d'avoir un environnement de dév
- lisible/partageable: c'est la moindre des choses puisque l'on parle d'un langage !
- documenté / supporté : une autre évidence !
- générique : s'il fallait apprendre un langage par domaine, on ne s'en sortirait pas
- l'interropérabilité logicielle est un des points crutiaux pour la simple et bonne raison qu'un langage n'est pas un tout mais un moyen de... Si à chaque changement de techno et/ou langage il fallait tout mettre à la poubelle... on ne ferait que du Cobol ou du Lisp
- l'environnement de dév est tout aussi important: nous nous devons d'être productif; et à contrario, développer ne doit pas être une punition
Au final, pour la JVM, de tous les langages dit alternatifs que reste-t'il ?
- Groovy qui a une large communauté; et, est soutenu par SpringSource
- itou pour Scala qui a retenu l'attention de l'U.E.
- peut-on y ajouter JRubyIMHO, non...
- pourra-t'on y ajouter Ceylon
Et c'est bien dommageTous ces langages (y compris Scala
) ont de bonnes idées. Et, surtout ils apportent un renouvellement que Java ne peut apporter :
- Les évolutions de Java se sont des JSRs un JCP... bref, une machine très lourde.
- Java s'est aussi des casseroles que l'on tire de version en version
Bref, les Ceylon, Kotlin, etc peuvent se permettre de remettre en cause certains des choix de Java ! Pour l'ecosystème Java, il est difficile de se remettre en question...
Finalement, et c'est paradoxal, j'en viens à me demander si un langage peut-être le fruit de la communauté ? Des technos alternatives issues de la communauté arrivent s'imposer... les langages qui pourraient-être leur socle; eux, ils n'y arrivent pas !!!
P.S. : Ben tiens, je viens de redécouvrir Fantom en relisant cet article
Techniquement c'est possible en Java, via l'API de Scripting...
Mais perso je ne pense pas qu'utiliser du JS coté serveur soit une bonne idée.
Quitte à utiliser le même langage des deux cotés, je préfère de loin utiliser un langage plus typé et plus "sûr", quitte à le "compiler" en JavaScript pour la partie client.
D'ailleurs ce principe semble de plus en plus répandu (GWT, Ceylon et même Dart).
a++
Je pensais pas à du JS serveur, je pensais à un environnement de dév comme celui de play2 ou tu as un répertoire pour tes sources serveurs controlleurs, models et ça, et un répertoire pour tes assets JS/css etc...
Le tout est surveillé par un build system qui se charge entre autre de détecter les changements dans le code JS/coffeescript, de transformer automatiquement tout ça en JS minifié en passant un coup de closure compiler dessus pour que tu n'aies plus qu'à t'en servir dans les vues sans t'encombrer d'étapes supplémentaires.
Je me dis que si on pouvait avoir un framework et un build system du même genre en ceylon, ou tu pourrais coder du ceylon pour la JVM et du ceylon pour JS (en profitant des avantages du typage statique, refactoring, sécurité etc..) qui serait automatiquement converti en ressource, ce serait certainement intéressant. Ca permettrait des choses sympas.
Sinon Philippe, je ne peux pas décortiquer tout ton post mais globalement je suis d'accord avec toi sur les exigences très poussées qu'on aurait pour un langage à la java. Je pense que red hat, entreprise habituée à maintenir de grosses bases de code s'il en est, a pris un parti intéressant en privilégiant la sécurité et la lisibilité quitte à rester sur la retenue côté super-features qui font économiser des retours chariots.
Je ne les imagine pas avoir payé pendant plusieurs années des développeurs de ce niveau-là juste pour se targuer d'avoir inventé un langage, ils comptent certainement s'en servir pour eux-mêmes et le faire vivre sur scène.
Tu parlais de Fantom, c'est une idée intéressante aussi, qui est utilisée en production, mais c'est loin de m'inspirer assez confiance. J'ai pas l'impression qu'il y a un backing assez solide derrière.
Pour groovy, j'ai besoin de me mettre à jour sur la version 2 avec les nouvelles possibilités de compilation statique. Mais je n'ai pas encore eu le temps de suffisamment pousser la réflexion sur ce dernier mais quant à en faire un remplaçant de java, je lui reprochais à l'époque d'être juste plus lent et moins statique.
@_skip : je ne connais pas Play (hormis de nom).
En fait je pensais plus à Node.js qui permet d'utiliser JavaScript coté serveur... ce qui me semble une abbération pour une grosse application !
Perso j'ai passé une application JEE "classique" sous Struts/JQuery vers GWT.
Non seulement on peut partager le même code coté client et serveur, mais le coté client est entièrement codé en Java (ou presque - on doit avoir une vingtaine de ligne de code en JavaScript).
Et franchement c'est que du bonheur.
Le code est certe plus verbeux et il y a quelques défauts (comme la compilation GWT Java -> JavaScript très longue), mais je trouve qu'il y a tellement d'avantage à coté que ca les vaut bien !
a++
Je ne dis pas que ça serait plus simple à implémenter. Je pense que ça serait plus difficile à contourner. Avec une annotation, je pense qu'il sera difficile d'intercepter des contournements comme l'utilisation de l'introspection. Après, on peut aussi décider que si le programmeur utilise l'introspection, c'est que si ça pète, il l'a cherché. Mais ça ne respecte plus vraiment le principe d'encapsulation qui est un des fondements de la POO.
Si la version 7 avait eu toutes les features prévues, j'aurais été d'accord avec toi. Mais en l'occurrence, je pense que la relative désaffection que connait Java (pas encore réellement sur le déclin, mais clairement plus sur une pente ascendante) est une conséquence de cette lenteur, entre autres causes, comme le rachat par Oracle et ses suites (procès avec Google, polémique sur les brevet, gueguerre avec le JCP, mise au rencart de différents projets open-source soutenus par Sun...)
Groovy a choisi les annotations pour la partie fonctionnelle ! Il serait intéressant de savoir pourquoi...
YAL (Yet Another Language!)
Le système de typage de Ceylon est vraiment novateur mais potentiellement très complexe. Le reste est plus classique avec quelques idées intéressantes (modularité, vrais généricité, null, etc.). Cependant, il me semble que ce langage offre trop peu de rupture technologique pour avoir une réelle chance de percer. Hormis le système de typage, il est d'ailleurs probable qu'il soit possible d’implémenter, à terme et sans trop de casse, un bon nombre des fonctionnalités de Ceylon dans Java.
Si tu parles de Java, ca veut dire surement jamais, au mieux trop tard. Voir l'exemple de Jigsaw.
Ceylon aura l'avantage de fonctionner dans des environnements JavaScript (ex : Navigateur, Node.js) et Java (JavaFX, J2EE) et donc aussi bien côté client que côté serveur.
Concernant la complexité du typage, je m'en fais pas trop. On fait rarement des choses compliquées, même si parfois on s'y essaye, on se rend compte que c'est compliqué parce qu'on s'est trompé de raisonnement (KISS). Et dans les autres cas, l'IDE ne fournira toute l'information nécessaire sur ce que le compilateur a inféré. A ce sujet le dernier billet du log est intéressant : http://ceylon-lang.org/blog/2013/11/...-and-variance/.
Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
Ceylon : Installation - Concepts de base - Typage - Appels et arguments
ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
Une solution vous convient ? N'oubliez pas le tag
Signature par pitipoisson
Ce qui veut dire 2 choses :
- Soit le langage est "transformé" en JavaScript.
- Soit il est compilé en bytecode Java
Dans les deux cas c'est déjà possible en Java (via GWT pour le premier cas).
a++
Tout comme Nemek (et Traroth2 il me semble...), je n'attends plus grand chose de java et du JCP. Tout ce que je sais, c'est que dans la version prévue en 2014 il n'y aura toujours pas les features dont j'espérais me servir en 2009, toutes repoussées aux calendes grecques. Et c'est sans compter l'impossibilité de remise en question de l'existant.
Je suis un peu étonné que ce projet ne suscite aucun enthousiasme sur DVP, juste des jeux de mots sur le nom ou des "encore un nouveau langage". C'est clair que c'est nouveau, et jeune, etc... Mais ça débarque avec un IDE de référence basé sur eclipse bien complet (autocomplete, navigation, refactoring), une spécification complète et à jour et un système de module et de gestion de dépendances directement pris en charge au niveau langage (et non au niveau d'un build system ce qui limite déjà le besoin de recourir à ceux-ci).
Y'a peu de nouvelles technos qui se pointent avec autant de choses. Quand je vois les similarités avec java, perso plutôt que me dire "oh c'est nul c'est pas révolutionnaire", je me dis plutôt "le prix du ticket d'entrée pour le javaïste sera faible" et cela pour des gains potentiellement très intéressants.
Ailleurs sur le net, et sur la mailing list du projet, les gens sont assez positifs, ont des idées, proposent des projets... Bref il y a sans doute un potentiel, perso ça me laisse pas indifférent.
_skip comme je te l'ai dit à plusieurs reprises Ceylon est rafraichissant (nouvelles idées, pas la lourdeur d'un JCP, pas de contraintes de rétrocompatibilité), etc... Bref, dans l'esprit très différent de Java...
Mais après, comme tu le soulignes il est encore jeune ! En 10ans, des langages comme Groovy ou Scala n'ont pas pris... D'autres comme, JRuby, Fantom, Clojure, Duby, Ioke, ... ne font que du buzz ! L'avenir nous dira, ce qu'il adviendra de Ceylon, mais au jour d’aujourd’hui investir dans Ceylon ne peut-être, IMHO, qu'un investissement purement personnel.
Tu remarqueras aussi que les forums DVP les langages alternatifs ne sont pas très populaires : sur un an: 25 fils de discussion sur Scala/Groovy... ce qui laisse penser d'un manque d’intérêt pour ces technologies alternatives. Maintenant, que Ceylon passe la 1.0, il serait bon qu'il soit au moins mentionné dans la liste DVP ici !
Tu parlais de la gestion des dépendances dans le compilo : j'ai découvert cette feature récemment pour Ceylon (Groovy a aussi un système similaire) ! Perso : je ne vois pas l’intérêt de cette feature directement dans le compilo... les outils de build actuels ne sont-ils pas suffisant
a+
Philippe
Le problème est toujours le même lorsqu'on compare un "vieux" langage à un langage totalement nouveau.
D'un coté on est forcément restreint par l'existant, alors que de l'autre on peut faire un peu tout ce qu'on veut, et on peut également profiter de l'expérience des autres langages (afin de ne pas reproduire les mêmes erreurs).
Java évolue lentement, mais je pense que son évolution est saine.
Elle n'est pas conduite par la dernière "feature" à la mode ou le besoin d'en faire toujours plus.
Même si ca peut faire rager de ne pas avoir certains fonctionnalités qui deviennent courante dans les nouveaux langages...
Le JCP est peut-être lourd, mais les décisions impacterons sûrement des millions de développeurs.
Oui il y a du potentiel.
Mais il faudra le concrétiser en pratique pour qu'il y ait un vrai enthousiasme.
Pourtant je pense que ce sera une des fonctionnalités majeurs des prochains langages (ou une des nouveautés apportées aux langages existants).Tu parlais de la gestion des dépendances dans le compilo : j'ai découvert cette feature récemment pour Ceylon (Groovy a aussi un système similaire) ! Perso : je ne vois pas l’intérêt de cette feature directement dans le compilo... les outils de build actuels ne sont-ils pas suffisant
a++
Je suis on ne peut plus d'accord avec la dernière phrase. En revanche Scala et Groovy sont utilisés en production depuis des années déjà (surtout groovy, avec gradle, grails etc...).
Groovy a pris le parti du dynamisme ce qui limite ses chances de remplacer java là où on apprécie les avantages du typage statique (ce qui veut pas dire qu'il n'a pas d'autres utilités) et Scala... bon, c'est une autre approche de la programmation qui ajoute ses solutions et ses problèmes.
Ouais ma foi, si c'est vide et non animé c'est clair que ça a de bonne chance de le rester. Mais je trouvais aussi qu'à l'inverse, DVP avait réuni et porté une communauté assez importante autour de delphi malgré un déclin progressif de la techno. Evidemment, voir une communauté vivante autour d'une techno ça encourage.Tu remarqueras aussi que les forums DVP les langages alternatifs ne sont pas très populaires : sur un an: 25 fils de discussion sur Scala/Groovy... ce qui laisse penser d'un manque d’intérêt pour ces technologies alternatives.
Ben tu vois pourquoi jigsaw était important même si on a Maven, Sbt, Gradle, BuildR, Ant? La prise en charge des modules par le langage plutôt que par un système tiers permet entre autres l'isolation des dépendances. Donc si tu utilises un module qui dépend d'une certaine version d'une librairie, et un autre qui en utilise une autre, tu ne te retrouves pas avec un "classpath hell" et des conflits. Sans compter que les libs de base seront également modulaires et donc plus facilement évolutives.Tu parlais de la gestion des dépendances dans le compilo : j'ai découvert cette feature récemment pour Ceylon (Groovy a aussi un système similaire) ! Perso : je ne vois pas l’intérêt de cette feature directement dans le compilo... les outils de build actuels ne sont-ils pas suffisant
Par ailleurs, si comme beaucoup de gens, tu utilisais maven ou un build system quelconque seulement dans le but de gérer tes dépendances, plus la peine, le compilo sait le faire. Et donc ton IDE aussi, sans plug in et sans XML. Après ça veut pas dire qu'avoir un build system n'a aucun sens, y'a un tas de chose qu'on peut vouloir faire avec un build system, lancer des générateurs, packager une application, etc...
Répondre avec citation
Partager