Kotlin est maintenant passé de Bêta à Release Candidate, la version 1.0 du langage

Kotlin est maintenant passé de Bêta à Release Candidate, la version 1.0 du langage
est disponible et apporte plusieurs améliorations

Le langage de programmation Kotlin est désormais passé de Bêta à Release Candidate. L’annonce a été faite dans un billet de blog publié sur le site de Jetbrains dans lequel l’équipe derrière le langage ainsi que la communauté qui la suit se réjouissent de cette nouvelle. La version 1.0 du langage de programmation a fait l’objet d’une recompilation complète, assure l’auteur du billet, Andrey Breslav, qui est l’un des concepteurs du langage chez Jetbrains. Il ajoute que cela a été fait dans le but de s’assurer qu’aucun code compilé avec les anciennes versions du langage ne subsiste.

Cette nouvelle version de Kotlin vient avec des changements considérables. Tout d’abord, l’équipe derrière le langage a tenu à faire un nettoyage. Ainsi les anciens éléments dépréciés du langage qui étaient marqués jusque là comme avertissements sont maintenant considérés comme des erreurs et les éléments dépréciés qui étaient générés dans le Bytecode ont tout simplement été enlevés. La plupart des changements apportés au langage en tant que tel constituent des changements mineurs et concernent le plus souvent des résolutions de bogues.

La nouvelle version du langage vient aussi avec le support d’une nouvelle annotation @delegate. Cette annotation permet par exemple pour marquer un objet délégué avec l’annotation @Transient, de faire tout simplement comme dans le bout de code qui suit :

Pièce jointe 200174

L’auteur du billet de blog fait également noter qu’ils ont résolu dans cette version un nombre important de bogues relatifs aux projections de types. Le compilateur pourrait maintenant détecter certains bogues qui lui échappaient jusqu’ici dans le code source. Par exemple, le bout de code qui suit était accepté par erreur par le compilateur, mais ne l’est plus dans la nouvelle version.

Pièce jointe 200175

Le compilateur arrive maintenant à détecter une erreur dans ce code et renvoie le message d’erreur suivant.

Pièce jointe 200176

Andrey Breslav fait état également de certaines améliorations en ce qui concerne l’interopérabilité avec le langage Java, notamment celles apportées aux propriétés de synthèse dérivées du couple get/set de Java. La version 1.0 de Kotlin permet maintenant l’utilisation de setters Java qui retournent des valeurs. Par ailleurs, il a été ajouté à cette nouvelle version du langage, le support des annotations @Nullable et @NotNull ceci à travers plusieurs bibliothèques populaires telles que javax.annotations ou encore Android SDK.

La bibliothèque standard a également connu certains changements avec son code source qui a été redistribué entre plusieurs packages sans pour autant modifier le code source lui-même. Certaines fonctions ont été transformées en des fonctions de type inline et plusieurs de ces fonctions ne peuvent plus être invoquées à partir d’un code Java. D’après les concepteurs du langage, cela va aider à réduire considérablement la taille de la bibliothèque en exécution. Les fonctions Map.getOrElse() et Map.getOrPut() considèrent désormais les clés associées à une valeur comme manquantes et les fonctions mutableListOf, mutableSetOf, mutableMapOf ont été ajoutées pour la création de collections mutables. La fonction toArrayList a été dépréciée et remplacée par la fonction toMutableList. Les fonctions associate et associateBy quant à elles permettent la création de maps, elles remplacent respectivement les fonctions toMap et toMapBy. Les fonctions de comparaisons ont été déplacées dans le package kotlin.comparisons qui n’est pas importé par défaut.

Des améliorations ont également été apportées à l’EDI (Environnement de Développement Intégré) de Kotlin. Il s’agit notamment de la complétion de code qui suggère des noms de variable ou de fonctions basés sur les identifiants non reconnus dans le fichier courant. Les expressions when sont également autocomplétées et l’annotation @Suppress marche maintenant avec les inspections de l’EDI. Avec cette nouvelle version, si l’environnement d’exécution de Kotlin n’est pas configuré, l’IDE affiche une notification « Kotlin not configured » lors de l’ouverture d’un fichier d’extension .kt. Ces améliorations concernant l’EDI peuvent ne pas être prises en compte par les mises à jour automatiques d’IntelliJ IDEA, les utilisateurs de cet environnement de développement devront par conséquent télécharger et installer le plug-in proprement.

Source : blog Jetbrains

Et vous ?

:fleche: Que pensez-vous de cette nouvelle version de Kotlin ?

Voir aussi

:fleche: la rubrique Autres langages pour la JVM

Kotlin 1.0 est disponible en version finale
le langage de programmation pour JVM et Android mise sur la compatibilité avec plusieurs outils existants

Depuis plus de 5 ans, Jetbrains et les contributeurs de la plateforme GitHub se sont lancés dans la mise en œuvre de Kotlin, le langage de programmation open source statiquement typé. Selon ses concepteurs, Kotlin se veut clair, sûr et suffisamment outillé pour répondre aux besoins des utilisateurs.

Pièce jointe 200910

Un des points saillants mis en avant par l’équipe de développement, outre ceux cités, est son caractère interopérable avec le langage de programmation Java et sa compatibilité avec les architectures déjà existantes. Selon les dires d’Andrey Breslav, le concepteur en chef de ce langage, « n’importe quelle bibliothèque Java peut être utilisée dans Kotlin et vice versa ».

Aussi, ajoute-t-il, les développeurs embrassant ce langage n’auront pas besoin de tout « réapprendre, réinventer, refaire à partir de zéro », car les outils tels qu’Ant, Gradle et Maven peuvent être utilisés pour la compilation, IntelliJ IDEA ou Eclipse peuvent être utilisés comme environnement de développement et un outil en ligne permet de coder et effectuer des tests directement dans le navigateur. C’est ce qui incite Andrey et son équipe à décrire Kotlin comme un langage « pragmatique ».

Au début de ce mois, l’équipe de Jetbrains avait annoncé la disponibilité de la version Release Candidate (RC) de Kotlin 1.0. Avec cette version RC, les développeurs devaient recompiler leur code pour s’assurer qu’il fonctionne avec la nouvelle mouture.

Par ailleurs, la release candidate marquant une étape importante vers la sortie de première version stable, il était évident que la version finale de ce langage ne tarderait pas à voir le jour. Et depuis quelques heures, c’est désormais le cas. L’équipe de Jetbrains vient d’annoncer la disponibilité de la version finale de Kotlin 1.0.

À partir de cette phase, affirme Andrey Breslav, « nous nous engageons à assurer à long terme la compatibilité descendante du langage et de sa bibliothèque standard (Kotlin-stdlib) ». Pour parvenir à cela, Andrey explique dans la feuille de route « qu’un nouveau compilateur fonctionnera avec des binaires plus anciens (mais les compilateurs plus anciens ne pourront pas comprendre la composition des binaires plus récents, comme javac 1.6 n’est pas capable de lire les classes compilées par javac 1.8) ».

De même, plusieurs travaux tels que l’amélioration des performances de la chaine d’outils de Kotlin sont prévus, ainsi qu’un support de JavaScript et un support générant du bytecode Java 8 avec des expressions lambda optimisées.

Mais pour l’heure, l’on note dans cette version finale quelques changements au niveau de la bibliothèque et du compilateur. On peut citer par exemple le fait que :

• l’annotation kotlin.Metadata doit être utilisée au lieu de KotlinClass ;
• les anciennes annotations des métadonnées ont été supprimées du package kotlin.jvm.internal ;
• l’usage de HALF_EVEN comme mode d’arrondi par défaut est préconisé pour l’opérateur de division BigDecimal ;
• la taille de la mémoire tampon pour les opérations IO est maintenant de 8 k comme celle par défaut dans la classe Java BufferedReader ;
• les éléments de la bibliothèque dépréciés dans la version RC ont été abandonnés ;
• le problème d’incompatibilité avec RoboVM a été résolu ;
• une mauvaise inférence du type du résultat obtenu avec la structure conditionnelle if/else a été réglée ;
• un problème de visibilité interne des projets Gradle dans IntelliJ IDEA 16 a été corrigé ;
• le compilateur déclenche l’exception UninferredParameterTypeConstructor dans un bloc de code où tous les types sont conditionnés par la condition When. Ce problème a été également réglé.

Pour ceux qui souhaitent utiliser Kotlin, nous rappelons qu’il est possible de s’en servir pour développer des applications côté serveur, des applications mobiles Android et des applications de bureau.

Kotlin sur GitHub

Source : Blog Jetbrains

Et vous ?

:fleche: Que pensez-vous de cette version finale ? Les arguments présentés sont-ils suffisants pour vous faire migrer vers ce langage ?

:fleche: Utilisez-vous déjà Kotlin ? Comment le trouvez-vous vis-à-vis des autres langages ?

Voir aussi

:fleche: Forum Autres langages pour la JVM

Je m'y suis essayé il y a quelques temps, notamment pour le développement Android.
Je codais notamment dans Android Studio grâce au plugin Gradle.

La syntaxe et les fonctionnalités du langages me sont apparues agréables. J'ai eu l'impression en quelque sortes de me simplifier le développement de la même manière qu'avec le langage Groovy : la courbe d'apprentissage m'est apparue très courte d'ailleurs.

Seul bémol (c'était bien avant la sortie du 1.0, que je n'ai pas encore testé), lors d'un déploiement en mode débogage sur un vrai périphérique, l'application que je développais ne pouvais pas démarrer, alors que sur les émulateurs (x86) elle fonctionnait correctement.

Je test Kotlin pour du développement Android depuis peu et j'aime beaucoup. La syntaxe est particulièrement agréable, toutes les bibliothèques que j'utilise sur mes projets Android fonctionnent avec Kotlin et le langage est bien intégré à Android Studio.

Je pense que Kotlin a toutes les chances de se faire une place dans le développement Android, il reste à espérer que Jetbrains continue à supporter le langage et que Google s'y intéresse.

Le principal avantage de kotlin est sans doute sa capacité à éviter le NullPointerException via la phase de compilation et une syntaxe spécifique (Son seul concurrent est ceylon, un langage récent aussi).
C'est plus puissant que le "Option" de scala; les langages existants (Java, C# ...) ne peuvent adopter ce principe sans briser leur compatibilité ascendante; c'est sans doute une évolution aussi importante que l'avait été le garbage collector de Java à sa sortie.
Si ce langage n'a pas le succès qu'il mérite; au minimum, ce principe du NullSafety devra faire partie des langages d'avenir ;)

Ayant étudié de prêt Ceylon, je suis curieux de regarder ce langage de plus prêt. Le problème c'est que ce n'est pas le seul sur la pile sans compter les frameworks, les bases de données, les sérialisations, les middlewares, etc. difficile de tout regarder dans le détail.

En parlant de Ceylon, il va plus loin dans la sûreté en l'appliquant également dans la conversion (cast), ainsi il n'y a pas de ClassCastException non plus. Est-ce que Kotlin fait de même ?

Autre point, y a-t-il un projet porteur pour ce langage comme Play!/Akka pour Scala, Gradle/Grails pour Groovy ? Je pense que c'est ce qui fait cruellement défaut à Ceylon pour réellement décollé. Même si un gros travail a été fait pour proposer une API Vert.x pour Ceylon.

Un des premiers points positifs de Kotlin, qui était un blocker pour moi avec Ceylon, c'est l'absence de compromis sur les types standards de java.
Je comprends que pour certaines personnes, les tableaux sans boxing ainsi que les nombres de moins de 64 bits (byte, short, float, int) ne soient pas nécessaires. Malheureusement c'est pas valable dans mon cas, avoir des listes de 1000000 int primitifs ou 1000000 longs boxés, ça revient pas au même. J'ai l'impression que c'est un compromis imposé au backend JVM pour le bénéfice de l'interop javascript, en réalité je suis pas sûr des vraies raisons.

Les points les plus intéressants à mon sens dans Ceylon et qui me manquent en java, soit

• les properties (un remplacement de getter/setter sans méthodes détournées comme Lombok)
• la distinction entre référence nullable ou non
• Les variables immuable (final) ou non
• l'inférence de type

Je les retrouve aussi dans Kotlin. En revanche, un point sympa dans ceylon qui n'est pas dans Kotlin, ce sont les intersections et les unions de type.

J'ai utilisé kotlin dans un projet non stratégique ces derniers jours (conversion de données) et je voulais tester en même temps l'interaction avec du java standard. J'ai utilisé l'une des choses les plus moches de java, soit du JAXB dont j'ai recouvert mes classes kotlin d'annotations. Je m'attendais à ce que ça foire à cause de la réflection et de différences subtiles sur la nature des types, Je n'ai eu aucun effort spécifique à faire pour sérializer mes objets en XML dans un sens et l'autre, j'ai juste du mettre des valeurs par défaut aux arguments de mon constructeur principal pour être compatible javaBean. Ajouté une librairie java pour parser du HTML, aucun souci là non plus, je me sers directe de la lib sans ciment.

J'ai adoré me servir des extensions de la lib standard pour la classe File (ForeachLine, Writer)
https://kotlinlang.org/api/latest/jv...java.io.-file/

Je me sers peu des lambdas dans java8 sur les collections et les map, en quelques minutes de Kotlin j'en suis devenu accroc. Etant utilisateur d'Intellij ultimate, j'avais droit à un support IDE de pointe, la syntaxe sort naturellement, y'a ce petit "it" pour faire référence à l'objet concerné qu'on peut renommer si le souhaite en cas de nesting, tout cela coule tout seul, concis et lisible. Normalement je suis pas emballé par les déclarations "nomVariable : Type" mais ça pose en fait rarement problème tant j'use et abuse de l'inférence de type.

Bref, après ce premier contact, sentiment très positif. J'ai l'impression de faire du python avec le typage poussé (càd avec l'IDE qui comprend ce que vous retourne vos constructions et l'autocomplétion en conséquence) tout en pouvant profiter pleinement de l'écosystème de java. Pour moi c'était l'un des possibles juste milieu pour la JVM, un java amélioré avec 80% de ce que Scala offre de vraiment utile mais sans l'effort d'apprentissage.

Je ne saurais pas pondre une comparaison ceylon et kotlin, mais je trouve qu'ils vont tous les deux dans le bon sens et surtout les deux se relisent très très bien. Je n'aurai aucun souci à les utiliser pour un développement en équipe avec des développeurs de niveau inégal (alors que Scala je serais prudent à ce que je risque de devoir lire). C'est cependant dommage qu'effectivement, autant pour l'un que pour l'autre, il manque le super framework qui donne envie, comme play! pour Scala.

Citation:

---

Envoyé par _skip

Un des premiers points positifs de Kotlin, qui était un blocker pour moi avec Ceylon, c'est l'absence de compromis sur les types standards de java.
Je comprends que pour certaines personnes, les tableaux sans boxing ainsi que les nombres de moins de 64 bits (byte, short, float, int) ne soient pas nécessaires. Malheureusement c'est pas valable dans mon cas, avoir des listes de 1000000 int primitifs ou 1000000 longs boxés, ça revient pas au même.

---

Je ne veux pas faire de la promo pour Ceylon dans une discussion sur Kotlin, ça serait mal venu. Par contre je voulais juste répondre à ça pour dire que en Ceylon si vous compilez pour la JVM, vous pouvez utiliser les tableaux de la JVM (`int[]` -> `java.lang.IntArray` en Ceylon par exemple) qui ne feront donc pas de boxing.

Kotlin 1.2 est disponible : cette nouvelle version permet de partager le code entre la JVM et JavaScript
et améliore de 25 % les temps de compilation

L'équipe JetBrains vient de publier une nouvelle version majeure de son langage de programmation Kotlin : la version 1.2. Rappelons-le, Kotlin est un langage de programmation orienté objet et fonctionnel, avec un typage statique qui permet de compiler pour la Machine virtuelle Java (JVM) et JavaScript. Il est également un langage de choix pour le développement Android. Sa première version officielle, Kotlin 1.0, a été publiée en février 2016 et la version 1.1 en mars dernier.

Kotlin 1.2 est donc la deuxième version majeure pour cette année, et est présenté par l'équipe JetBrains comme une grande avancée vers son objectif de permettre l’utilisation de Kotlin dans tous les composants d’une application moderne. « Avec Kotlin 1.1, nous avons fourni le support officiel de JavaScript comme cible de déploiement, permettant ainsi de compiler Kotlin en JS pour une exécution dans le navigateur », expliquent les développeurs du langage. « Avec Kotlin 1.2, nous ajoutons la possibilité de partager le code entre la JVM et JavaScript. Vous pouvez désormais écrire une seule fois la logique métier de votre application et la réutiliser dans toutes les couches de votre application — le backend, un navigateur frontend et une application mobile Android. » L'équipe JetBrains dit également travailler sur des bibliothèques favorisant la réutilisation du code, comme une bibliothèque cross-platform de sérialisation.

La principale nouveauté dans Kotlin concerne donc les projets multiplateformes, mais il y a aussi des gains de performance pour la compilation, ainsi que d’autres améliorations du langage et de la bibliothèque standard.

Projets multiplateformes

Un projet multiplateforme vous permet de construire plusieurs couches de votre application — backend, frontend et App Android — depuis la même base de code. Ce type de projet contient à la fois des modules communs, qui contiennent du code indépendant de la plateforme, et des modules plateforme, qui contiennent le code spécifique à une plateforme (JVM ou JS) et qui peuvent utiliser des bibliothèques de cette plateforme. Kotlin 1.2 vous permet donc d'appeler du code plateforme depuis un module commun.

http://www.developpez.com/public/ima...2-multipla.png

Comme cela a été également mentionné précédemment, JetBrains travaille sur une série de bibliothèques communes pour vous permettre de déplacer plus de code vers des modules communs. Il s’agit notamment de :

• kotlin.test, qui est inclus par défaut dans Kotlin 1.2 et vous permet d’écrire vos tests une seule fois et de les exécuter à la fois dans la JVM et en JS ;
• kotlinx.html, qui supporte un rendu isomorphique — le même code produit du HTML en backend et en frontend ;
• kotlinx.serialization, qui permet de sérialiser facilement vos objets Kotlin entre les différentes couches de votre application, en utilisant JSON ou ProtoBuf comme format de sérialisation.

Il est important de préciser que les projets multiplateformes sont actuellement disponibles en tant que fonctionnalité expérimentale. Cela veut dire que la fonctionnalité peut être utilisée, mais il est possible que sa conception soit modifiée dans la prochaine version de Kotlin. Dans ce cas, JetBrains assure qu’il fournira aux développeurs des outils de migration.

Performances de compilation

Kotlin 1.2 vient avec des optimisations pour les performances du compilateur. JetBrains dit avoir amélioré les temps de compilation de 25 % par rapport à Kotlin 1.1, et prévoit d’autres améliorations significatives qui seront introduites dans les mises à jour Kotlin 1.2.x.

Autres améliorations du langage et de la bibliothèque standard

JetBrains a également réalisé des améliorations ciblées du langage et de la bibliothèque standard. Il s'agit entre autres de :

• une syntaxe plus concise pour transmettre plusieurs paramètres à une annotation (array literals) ;
• le support de lateinit sur les propriétés top-level et les variables locales, ainsi que la vérification de l’initialisation effective d’une variable lateinit ;
• des smart casts plus évolués et une amélioration de l’inférence de type dans certains cas ;
• la compatibilité de la bibliothèque standard avec les restrictions de séparation de package introduites par Java 9 ;
• un nouveau package kotlin.math dans la bibliothèque standard ;
• de nouvelles fonctions dans la bibliothèque standard pour travailler avec les séquences et les collections, comprenant notamment une série de fonctions pour séparer une collection ou une séquence en plusieurs groupes de taille définie.

Kotlin : une adoption croissante dans la communauté des développeurs et éditeurs

Comme nous l’avons déjà mentionné, Kotlin est maintenant un langage officiel pour le développement Android, avec un support inclus dans Android Studio 3.0. Comme conséquence, JetBrains note que Kotlin est déjà utilisé dans plus de 17 % des projets sous Android Studio 3.0, y compris dans des applications des startups les plus actives et des entreprises du Fortune 500.

Du côté serveur, il faut également noter que Spring Framework 5.0 a été publié avec de nombreuses fonctionnalités de support de Kotlin, et le framework événementiel pour la JVM Vert.x supporte Kotlin depuis la publication de la version 3.4.0. Par ailleurs, Gradle est désormais fourni avec le support d’un DSL Kotlin, et le projet Gradle Kotlin DSL s’approche rapidement de la publication de sa version 1.0.

JetBrains explique que depuis la sortie de Kotlin 1.1 en mars de cette année, l’adoption du langage a connu une croissance très importante dans le monde. L'intérêt croissant pour Kotlin s'est confirmé récemment à la première conférence internationale KotlinConf qui a réuni environ 1200 participants à San Francisco les 2 et 3 novembre.

Kotlin 1.2 étant disponible, vous pouvez l'essayer en ligne à l'adresse try.kotlinlang.org ou directement dans vos IDE :

• sous Maven, Gradle et npm : utilisez 1.2.0 comme numéro de version pour le compilateur et la bibliothèque standard ;
• sous IntelliJ IDEA : utilisez la version 2017.3 qui contient Kotlin 1.2. Pour les versions précédentes, installez ou mettez à jour le plugin Kotlin plugin à la version 1.2 ;
• sous Android Studio : installez ou mettez à jour le plugin depuis Plugin Manager ;
• sous Eclipse : installez le plugin en utilisant Marketplace.

Il faut noter que le compilateur en ligne de commande peut être téléchargé depuis la page GitHub sur les notes de version. En ce qui concerne la compatibilité, avec Kotlin 1.2, le langage et la bibliothèque standard assurent la compatibilité ascendante. Cela veut dire que ce qui compilait et s’exécutait dans les versions 1.0 et 1.1 devrait continuer à fonctionner avec la version 1.2. Pour aider les équipes de grande taille à effectuer la mise à jour de leur code progressivement, l'équipe JetBrains fournit aussi des options de compilateur qui désactivent les nouvelles fonctionnalités.

Sources : Blog JetBrains, Nouveautés dans Kotlin 1.2

Et vous ?

:fleche: Utilisez-vous Kotlin ? Si oui, avec quel IDE ?
:fleche: Que pensez-vous des nouveautés de Kotlin 1.2 ?
:fleche: Qu’attendez-vous encore du langage ?

Voir aussi :

:fleche: Android Studio 3.0 est disponible avec le support de Kotlin, plus de fonctionnalités Java 8 et bien plus
:fleche: Développement Android : Kotlin gagnerait du terrain au détriment de Java, et Realm prédit qu'il sera le plus utilisé fin 2018
:fleche: Classement Tiobe : Kotlin, le langage pour JVM entre dans le top 50, et pourrait connaître la même ascension rapide que Swift, selon certains

Je connais pas Kotline mais j'ai pas envie connaitre. Java marche et marchera toujours bien, pourquoi changer ?

Kotlin, sans e, merci.

Qu'un langage puisse tourner sur 2 VM différentes, Java et ES (arrêtons de parler de JS svp...), wow! On a aujourd'hui 3 "terminaux" cibles, le web, Android et iOS, et on aimerait effectivement n'avoir qu'un code...: ES pour les SPA utilisant WebView mais plus lent que du natif, PWA (Ionic 3...) bientôt si Apple enfin ne fait pas d'abus de quasi monopole, WebAssembly (WASM) idem si Apple veut bien, ES avec React Native ou NativeScript ou mieux, C# avec MS Xamarin, hybrides quasi natifs, ou ce nouveau Kotlin pour Web et Android. (Quid de Dart sur framework Flutter pour Android et iOS?). Ca commence à faire beaucoup de solution et de types d'hybridations, un tableau serait utile pour éclaircir le présent et futur proches...
Et le futur d'Android, c'est FuschiaOS avec les langages C, C++, Rust, Go, Python et Swift supportés, mais pas ES ni Java, soit justement... pas Kotlin, pourtant désormais supporté officiellement par Google pour son Android actuel!!! Allez comprendre...

On sera in fine drivé par le chaînon faible, comme JS/ES a fini sur les serveurs (Node) à défaut des langages sérieux serveurs sur le navigateur: Apple iOS et son "Swift et rien que Swift" (et un peu de ES mais juste pour vous faire plaisir et surtout pas d'ombre à ma vache à lait Ap'Store et sa com° de 30% + 99€/an...). C'est d'ailleurs bien pour ça que Google a annoncé le support de Swift pour Fuschia... mais pas de Kotlin. Et puisque Swift est désormais open-source, pourquoi pas l'enrichir (le forker?) pour qu'il sache faire du web (sur WebAssembly) et sur Android? On peut rêver...

En 2000, on s'était pris à rêver à ne plus coder en windows et peut-être mac mais tout en web, maintenant on doit coder en web, android, ios, et peut-être en windows et en macos... un rêve s'est perdu en route...

Citation:

---

Envoyé par nhugodot

Kotlin, sans e, merci. (...)
En 2000, on s'était pris à rêver à ne plus coder en windows et peut-être mac mais tout en web, maintenant on doit coder en web, android, ios, et peut-être en windows et en macos... un rêve s'est perdu en route...

---

Merci beaucoup pour toutes ces informations, très utiles. Cela confirme que rester dans des langages bétons comme C / C++ est plutôt pérenne...

De mon côté, je reste sur Unity / C# pour Linux, Windows, Android, iOS et même PS4, pour des applis professionnelles avec un bon UI. Oui je sais c'est lourd, une appli Unity plein de RAM juste pour afficher 4 combobox et 6 checkboxes + 2 boutons, mais en termes de cross-compilation + fonctionnement 100% identique sur tous les supports, c'est simple : il n'y a rien de mieux, tout court. En plus C# est vraiment un langage excellent.
Côté Web, même chose pour la rentabilité : rien n'arrive à la cheville de Django / Python.

Mais je supporte Kotlin à ma façon : je paie une souscription PyCharm à Jetbrains depuis trois ans déjà ;) !

Citation:

---

Envoyé par SurferIX

Merci beaucoup pour toutes ces informations, très utiles. Cela confirme que rester dans des langages bétons comme C / C++ est plutôt pérenne...
En plus C# est vraiment un langage excellent.
Côté Web, même chose pour la rentabilité : rien n'arrive à la cheville de Django / Python.

---

De rien!

C#, oui, si on aime l'héritage C, la syntaxe, etc. (j'aime pas... rien à faire...:D), mais chapeau à MS. Et ils font le même coup avec TypeScript: reprendre un langage vieux (voire pourri) et en faire un truc nettoyé, propre, puissant, agréable, ... (ils avaient déjà fait ça avec DOS... devenu Windows 95, puis NT, ils savent faire...:D)
Je préfère la lignée Lisp et Smalltalk: resp. Elixir (voire Clojure) et Pharo.

Python/Django, vraiment le plus productif?
J'ai essayé l'an dernier...
Et puis devant faire des apps mobiles, rien à faire, on doit se taper swift/java, ou ES (React Native, ou NativeScript, ou Ionic 3 que je vais tester... Au moins c'est sur Angular donc TypeScript... dommage, Google utilise ce dernier en Dart que j'aurais préféré, ils disent avoir eu +20% de productivité, alors pourquoi passer à TypeScript? Parce qu'encore une fois les dev corporate venant de C, C++, Java, C# veulent un truc qui les dépayse pas, normal... Donc va pour TS... Google ne s'embarrasse pas de cet héritage, lui qui avait démarré en Python ainsi que Youtube d'ailleurs, ils ont remplacé C++ par Go et JS par Dart...). Bref, on s'est tapé React Native, pas pour les enfants... (le bazar React vs la cathédrale Angular).
A priori, le plus productif est Pharo, pas Python, Seaside, pas Django, et en plus y'a un smalltalk client JS: Amber, plus avancé que le Python transpilé en JS, Transcript par exemple (y'en a 3 au moins...):
https://medium.com/smalltalk-talk/a-...9ab#.pfbyjfuq5
https://medium.com/@richardeng/i-gue...t-2e166eff88bf
Elm et Clojure ont aussi un expérience de dev "wow"...

Mais je suis tout ouïe pour découvrir enfin du vrai dev productif! (fatigué de réinventer des roues... ), web et apps (webapps mobiles ou natives stp)? Grand merci!
ps: je cherche un CTO pour ma start-up, projet excitant, un bon, si intéressé... https://fr.linkedin.com/in/nicolashugodot/fr !

Citation:

---

Envoyé par nhugodot

A priori, le plus productif est Pharo, pas Python, Seaside, pas Django, et en plus y'a un smalltalk client JS: Amber, plus avancé que le Python transpilé en JS, Transcript par exemple (y'en a 3 au moins...):
https://medium.com/smalltalk-talk/a-...9ab#.pfbyjfuq5
https://medium.com/@richardeng/i-gue...t-2e166eff88bf
Elm et Clojure ont aussi un expérience de dev "wow"...

---

Quand je parle de productivité, voici, après une dizaine de sites Web 100% custom vendus, en Php puis en Django, dont deux ont une bonne fréquentation, ce que j'ai retiré de mon expérience : on passe le plus de temps à déboguer côté serveur et client que tout le reste.
En gros :
Temps (création + développement) < (maintenance + évolutions + déboguage).

En Django, on peut mettre des points d'arrêt partout, le déboguage est d'une facilité et d'une rapidité déconcertante. Mieux : ce qui n'est toujours pas le cas en Symfony, tu peux mettre des points d'arrêt dans le templating (! oui !) et voir uniquement les variables du template ! En termes de déboguage ce sont des heures / journées entières de gagnées. J'en suis à un ratio de 1/5 globalement : ce que je faisais en 5 jours en (Php création du site + correction de bogues + évolutions) je le fais en un jour en Django (Php création du site + correction de bogues + évolutions). C'est ça que j'appelle "la meilleure productivité".

Hier soir, j'ai débogué + corrigé en quelque lignes + quelques minutes, quelque chose dont je sais par expérience, qui m'aurait pris des heures en Php.

Je ne parle pas de performances ou autres, je parle de faire rapidement des sites + corrections, afin que le client soit content. Si en smalltalk on peut faire des points d'arrêt n'importe où, et qu'il y a une gestion de templating + gestion des modèle aussi simple qu'en Django, je suis très intéressé. Si ce n'est pas le cas alors on ne peut pas arriver au même niveau de rapidité de développement. A l'inverse s'il a tout ça je m'y pencherai volontiers ASAP.

Citation:

---

Envoyé par SurferIX

Quand je parle de productivité, voici, après une dizaine de sites Web 100% custom vendus, en Php puis en Django, dont deux ont une bonne fréquentation, ce que j'ai retiré de mon expérience : on passe le plus de temps à déboguer côté serveur et client que tout le reste.
En gros :
Temps (création + développement) < (maintenance + évolutions + déboguage).

En Django, on peut mettre des points d'arrêt partout, le déboguage est d'une facilité et d'une rapidité déconcertante. Mieux : ce qui n'est toujours pas le cas en Symfony, tu peux mettre des points d'arrêt dans le templating (! oui !) et voir uniquement les variables du template ! En termes de déboguage ce sont des heures / journées entières de gagnées. J'en suis à un ratio de 1/5 globalement : ce que je faisais en 5 jours en (Php création du site + correction de bogues + évolutions) je le fais en un jour en Django (Php création du site + correction de bogues + évolutions). C'est ça que j'appelle "la meilleure productivité".

Hier soir, j'ai débogué + corrigé en quelque lignes + quelques minutes, quelque chose dont je sais par expérience, qui m'aurait pris des heures en Php.

Je ne parle pas de performances ou autres, je parle de faire rapidement des sites + corrections, afin que le client soit content. Si en smalltalk on peut faire des points d'arrêt n'importe où, et qu'il y a une gestion de templating + gestion des modèle aussi simple qu'en Django, je suis très intéressé. Si ce n'est pas le cas alors on ne peut pas arriver au même niveau de rapidité de développement. A l'inverse s'il a tout ça je m'y pencherai volontiers ASAP.

---

on a bien compris que Monsieur SurferIX est un extrémiste Django python. qu'il a des œillères qui l’empêche de voir autre chose...

On a bien compris la tactique qui consiste à faire du PHP bashing à la moindre occasion.. avec des arguments qui tourne : un coup ça se porte sur la performance, un autre coup sur le deboguage, un autre coup sur le langage, un autre coup sur l'installation..... même si c'est faux, même si c'est du à son incompétence.

Monsieur surferIX manie subtilement et sournoisement les mots pour faire en sorte d'avoir toujours raison.


sur indeed :
1443 offres d'emploi ou est cité Symfony
203 offres d'emploi ou est cité Django

sur monster.fr :
77 offres d'emploi Symfony
9 offres d'emploi Django

Je te remercie pour ce commentaire très constructif (et surtout très à la pointe :ptdr:), et je te laisse dans ton cercle Php, tant mieux, reste-y !
T'es super bien en France on dirait, car ici on est un ratio extrêmement opposé, mais c'est vrai que la Silicon Valley n'est remplie que de crétins ! Au fait tu viens quand avec moi en amphi ? Je t'attends toujours pour ta présentation et tes réponses Symfony :D
Au moins je serai comme tous les développeurs Django en France : mieux payé que ceux en Php (donc que toi (67K€ contre 51K€)) 8-).
(Ecris aussi à geekpress pour l'insulter, c'est encore un de ceux que tu dois considérer comme extrémiste :mouarf:)

Oh j'oubliais ! Stackoverflow aussi n'est rempli que d'extrémistes, regarde ici il y a 3 mois, contacte les et insulte les s'il te plaît, car regarde où ils voient Python et où ils voient Php fin 2018 :

Pièce jointe 334451

Pour le reste, relis ce que tu écris, car les fautes d'orthographes sont comme Php : on n'a que des warnings, ça brûle les yeux, mais on continue quand même :zoubi:

Il n'empêche que j'attends une réponse de @nhugodot car, (lui), il paraît ouvert, et a amené des choses vraiment constructives... des propositions très intéressantes.

Salut,

https://w3techs.com/technologies/ove...g_language/all

A+

Moralité : on peut faire dire aux chiffres n'importe quoi, c'est pas demain la veille que Python va remplacer PHP, j'espère que tu peux au moins reconnaître ça sans trop avoir l'impression de t'écarteler...

Citation:

---

Envoyé par nhugodot

Au moins c'est sur Angular donc TypeScript... dommage, Google utilise ce dernier en Dart que j'aurais préféré, ils disent avoir eu +20% de productivité, alors pourquoi passer à TypeScript? Parce qu'encore une fois les dev corporate venant de C, C++, Java, C# veulent un truc qui les dépayse pas, normal... Donc va pour TS... Google ne s'embarrasse pas de cet héritage, lui qui avait démarré en Python ainsi que Youtube d'ailleurs, ils ont remplacé C++ par Go et JS par Dart...). Bref, on s'est tapé React Native, pas pour les enfants... (le bazar React vs la cathédrale Angular).

---

Ce n'est pas qu'une question d'habitude ou de dépaysement. Le succès (si on peut dire) de typescript vient aussi de son interopérabilité avec javascript qui est complète. Si tu choisis de coder en TS tu ne te prives aucunement de l'écosystème javascript. Tu ne fais que rendre ton code plus typé, et plus facile à maintenir. Dans un monde où on se sert beaucoup de libs existantes, ça compte énormément de pas passer par des couches interops foireuses et de finir le derrière entre deux chaises.

C'est aussi ce qui, je pense pourrait faire fonctionner kotlin. C'est un meilleur java avec une très bonne interop.

Citation:

---

Envoyé par _skip

Ce n'est pas qu'une question d'habitude ou de dépaysement. Le succès (si on peut dire) de typescript vient aussi de son interopérabilité avec javascript qui est complète. Si tu choisis de coder en TS tu ne te prives aucunement de l'écosystème javascript. Tu ne fais que rendre ton code plus typé, et plus facile à maintenir. Dans un monde où on se sert beaucoup de libs existantes, ça compte énormément de pas passer par des couches interops foireuses et de finir le derrière entre deux chaises.

C'est aussi ce qui, je pense pourrait faire fonctionner kotlin. C'est un meilleur java avec une très bonne interop.

---

Merci Skip, commentaire autrement plus intéressant que l'humanoïde dissocié et son PHP...:D

Oui, TS est génial car garde toute la compatibilité avec l'existant: codes JS, codeurs JS et C++/Java/C#... ;), .. Google a été très pragmatique sur ce coup là, en faisant une évolution et pas une révolution. Et on peut utiliser TS avec Angular (donc Ionic et NativeScript) mais AUSSI avec React et VueJS etc.

Kotlin tournant sur VM JS et Java, je me demande quelle killer stratégie on peut bien y trouver pour faire quelque chose de génial que Java ou JS ne saurait pas faire... : tourner sur backend java et sur front end (JS, forcément... tant que WebAssembly n'est pas partout), profiter des deux écosystèmes et richesses de librairies?

Citation:

---

Envoyé par Spartacusply

Salut,
https://w3techs.com/technologies/ove...g_language/all
A+
Moralité : on peut faire dire aux chiffres n'importe quoi, c'est pas demain la veille que Python va remplacer PHP, j'espère que tu peux au moins reconnaître ça sans trop avoir l'impression de t'écarteler...

---

Je reconnaîtrai volontiers que c'est pas demain la veille que Python va remplacer PHP en France... uniquement si tu reconnais que Python remplace déjà Php dans presque tous les autres pays depuis ~2 ans. Mais comme je sais que tu ne le reconnaîtras jamais, je t'avoue : je reconnais déjà ces deux faits et je pense sincèrement que c'est pas demain la veille que Python va remplacer PHP en France uniquement (sachant que j'ai déjà remplacé deux de mes projets Php par la même chose en Python pour des raisons de maintenabilité = des raisons de coût, mais pour ça, il faut avoir une entreprise et pas être en CDI pour comprendre que c'est pas que de l'idéologie, mais des chiffres concrets).

J'ai tellement l'impression de parler à une mentalité de Mac Addict que je sais que quoi que je dise, tu n'y croiras jamais.
Mais aussi l'impression que tu ne sais vraiment pas que de mon côté j'ai toujours été à fond Php. J'ai même écrit un très gros framework sur lequel j'ai fait mon mémoire d'ingénieur, et sur lequel plusieurs entreprises on travaillé pendant plusieurs années, largement fait avant Symfony, puis ré-écrit au fil des ans complètement 3 fois.

Pièce jointe 334511

J'imagine que pour JavaScript, je suis sûr que tu sais ce que j'ai fait sur TM en scripting...

Bref. C'est tellement hors sujet et dans des attaques aussi personnelles qu'inutiles que je ne répondrai plus à tes provocations stérilse, envoie moi un PM si tu veux être invité en amphi pour justifier du bien fondé de Symfony 3 et de sa stack trace pour déboguer...