L’accueil se déroulera au pied de la Tour Eiffel.
Le lieu précis de cet accueil vous sera transmis par mail le matin de l’événement, vers 8h. Il vous faudra être présent dès midi pour passer la sécurité et prendre les ascenseurs par petits groupes.
65 ans déjà (comptés en année chat, en informatique, on parle plutôt en année chat, c’est plus représentatif de la vitesse des cycles), Java a bien changé aussi, Sun est mort, l’OpenJDK a repris le flambeau, on a maintenant des releases continues …
Avec un brin de nostalgie pour les vieux et comme une époque glorieuse et sépia pour les plus jeunes, je raconterais comment c’était Java au début, comment c’était Java il y a 65 ans, c’est quoi Java maintenant et bien sûr quel sont les futures de Java.
-
OpenJDK : Java will be Open Sourced the 13th November 2006.
OpenJDK 6 project was developped by RedHat, and was at that time ONLY tested on server, NOT on anything else (desktop by example…)
|
📎
|
RedHat resigned the support of OpenJDK 6 in 2017, which was then taken by Azul Systems and Microsoft |
-
Have a look at the VM Eclipse OpenJ9 (October 2017)
Functional Programming promotes immutability and the use of higher order functions.
For those of us who have designed and architected applications using imperative style of programming and the object-oriented paradigm, this largely appears like a strange idea.
We often ask, how is it practical to apply these ideas, realistically to build practical applications.
It turns out it’s highly practical but we have to change how we design and how we model our systems.
Come to this presentation to think about functional style and how to start viewing design to make better use of this way of programming.
1967 → 1990 : 23 ans nécessaires pour l’adoption de la programmation OO !
Et pourquoi si longtemps ? → Il a fallu attendre qu’une nouvelle génération arrive…
gotois to structured programming as assignment is to functional programming!
→ NO EXPLICIT ASSIGNMENT
-
Imperative = tell what to do and also how to do
-
Declarative = tell what and NOT how
functional style = declarative + higher-order functions
-
We often talk about immutability and higher-order function, but these are really means to a greater end:
-
functional composition and lazy evaluation
(expressive and efficiency)
-
Streams are fundamentaly lasy
→ close-over = closure
Rappel du "effectively final" quand on ote un final qui peut être donné implicitement du fait du contexte.
-
Voir également précédemment les 2 règles de pureté d’une fonction :
-
the function does not modify anything
-
the function does not depend on anything that may possibly change
-
→ Java assumes that lambdas and closures are pure
|
❗
|
Immutability is absolutely necessary for lazy evaluation. |
-
Plutôt que créer notre archi avec au centre la BDD (circle of purity) et "tout le code" autour (ring of impurity), ne faudrait-il pas mieux mettre notre code au centre ?
|
❗
|
We should move the mutability to the outer ring, to keep the center pure. |
-
Exception handling and functional programming are mutually exclusive.
The functional mindset :
-
in Java 8 → Streams
-
in Javscript → Promises CompletableFuture
List vs Stream could be seen as: Bucket vs Pipe collection of data vs collection of functions
|
❗
|
Stream does NOT execute each function for each value, instead it executes a collection of function for each value, but only as necessary. |
Venkat est un fantastique speaker, très clair, super anglais, dynamique et plein d’humour.
De plus, c’est bien la 1ere conf que je vois se dérouler sous la forme d’un live coding et présentation sur Notepad++
Fantastique conf à revoir.
→ On peut trouver la même conf sur YouTube, lors des XP Days Ukraine (2018/02)
We’re in the midst of renewed interest in functional programming.
At the same time we see quite a bit of excitement around reactive programming.
Where did reactive programming come from?
How is it related to functional programming, if at all?
In this presentation we will discuss the merits of reactive programming and how functional programming concepts seamlessly transition into the programming model espoused by reactive programming.
-
Learn a new language is not that difficult → learning a new paradigm is a lot more
-
We are moving towards "Collection Pipeline Pattern" (cf l’article de Martin FOWLER)
imamge::20180515_parisjug_from-funct-to-react_01.jpg[]
-
Formerly : CRUD
-
database → process / function → database
-
-
And now Dataflow computation : d → f → d → f → d → f
-
Amazon lambdas and serverless
-
|
❗
|
Reactive programming IS dataflow computation |
-
In life, we should never share 2 thinkgs:
-
toothbrush
-
database
→ Do not expose your database, instead, export your data
-
Reactive applications:
-
Elastic
-
Message Driven
-
Responsive
-
Resilience
→ Reactive proramming is functional programming++
It is built on functional composition and lazy evaluation.
Reactive programming is a very good application of functional programming.
-
Java 8 Streams : "push at your pace" which is not a good thing
→ Whereas with Reactive Streams, there is backpressure.
|
❗
|
Info très intéressante de Venkat dans la gestion des erreurs. Venkat n’aime pas la gestion des erreurs via les Monades, car ces dernières gèrent le "bon" cas ET le "mauvais" (l’erreur). Avec la programmation reactive, on dispose d’un flux normal ET d’un flux d’erreur, chacun gérant son type d’objets, d’où une meilleure cohésion. |
(qtip = cotons-tiges)
Tout aussi bon que le talk précédent
→ On peut également trouver la même conf au Warsaw JUG (2017/11)
Profitons de ce dixième anniversaire pour :
-
faire une rétrospective des apports de Java et du Paris JUG à la communauté durant cette décennie,
-
et esquisser leur futur.
