Re: Bouquin Java

Bonsoir Yves,

C'est très bien de discuter un peu bouquins.

Le 04/04/2021 à 20:10, Yves Martin a écrit :
> Bonjour Aimé
>
> Merci pour ton point de vue
>
>
> On Sun, 2021-04-04 at 01:03 +0200, Aimé Vareille wrote:
>> Bref, les bouquins fondamentaux portent sur les concepts (e.g.
>> théorie
>> des objets, physique de la lumière ...) et il est préférable de les
>> choisir immatériels (formats epub, pdf ...) ; entre autres le papier
>> n'est pas adapté au partage d'annotations personnelles, usage qui du
>> coup ne se développe pas suffisamment ...
>
> La plupart des auteurs acceptent les retours de leurs lecteurs afin
> d'améliorer leur contenu dans une édition suivante.
Je me suis frité avec pas mal d'auteurs qui acceptaient plutôt mal les
remises en question même quand on leur propose des solutions.
> J'avoue que je suis curieux de l'intérêt du partage des annotations
> personnelles, surtout en comparaison de la logorrhée ininterrompue que
> l'on peut observer sur les "réseaux" quels qu'ils soient. Sans
> curateur, ces partages me sembleraient plus suivre le principe du
> "fire-and-forget" sans réel intérêt.
C'est comme les pages perso beaucoup n'y voient pas de réel intérêt mais
laisser en annotation ses coordonnées de lecteur, quelques explications
sur ce qui nous a semblé intéressant, les liens qu'on a trouvé avec
d'autres lectures, les questions qu'on s'est posé ... ça va plus loin
que du "read and forget".
>> Effectivement, Java est une technologie de programmation orientée
>> objet
>> toujours en évolution et qui peine à réaliser son « /Write once, run
>> anywhere/ » plus proche du « Write once, debug everywhere » parce
>> qu'il
>> est difficile de développer sans connexion internet.
>>
>> Au demeurant, actuellement, ces connexions internet sont aussi
>> quasi-indispensables pour toutes les activités de hacking.
>
> J'en ai marre de cette ritournelle qui détourne le slogan marketing de
> Sun qu'il faut replacer dans le contexte de l'époque, entre 1995 et
> 2005.
>
> Merci de me trouver le moindre language qui n'aurait pas le symptôme du
> "write once, debug everywhere". Et personne ne peut espérer écrire un
> code sans le tester sur les différentes cibles souhaitées - le problème
> provenant la plupart du temps de non-respect des bonnes pratiques, de
> la non-lecture des docs API, de l'intégration de code natif non/peu
> portable...
Mais réaliser du « /Write once, run anywhere/ » en s'appuyant sur un
concept de machine virtuelle ça reste un bon principe de la même façon
que les architectures fractales pour s'efforcer de réduire la complexité
croissante des systèmes.
> Surtout à notre époque du développement mobile qui a encore plus
> exacerbé le problème, chaque fournisseur ayant la volonté de
> créer/conserver son propre pré-carré plutôt que d'aller vers du "vrai
> libre":
> - Google a fait sa propre version de Java sur Android
> - Apple a créé son language Swift à partir de LLVM mais ne cible que
> iOS et n'est disponible qu'avec XCode sur macOS (achat de matériel
> Apple requis...)
> - Google a créé Dart et Flutter
> - les frameworks JavaScript pullulent... je vous laisse vous noyer dans
> votre moteur de recherche pour les sélectionner si vous devez en
> choisir un (en général au hasard...)
>
> Et plutôt comme contre-exemples, voici des tentatives plus "open
> source"
> - JetBrains a créé Kotlin, même si c'est pour vendre des licenses
> IntelliJ IDEA
La vie c'est la diversité on butte inévitablement sur des effets "tour
de Babel" en matière de langages.
>
> Enfin je ne comprends pas ton ajout d'une contrainte supplémentaire de
> "travail hors-connexion" qui me semble anachronique. Tout language
> moderne nécessite l'usage d'un grand nombre de bibliothèques pour
> atteindre des objectifs "haut niveau", et "si vraiment", on peut
> préparer son poste avec tous les outils, les dépendances, les
> documentations de référence... Git aidant pour l'historique, mais quid
> du ticketing et de la documentation ? OK il existe Fossil...
> Bref, difficile pour moi de travailler plus d'une journée "hors-
> connexion"
>
> Personnellement, l'efficacité du développeur tient surtout à la
> capacité d'exploiter des résultats de recherche dans les documentations
> et sur stackexchange, les forums...
C'est tout à fait exact, c'est justement cette tendance à la perte
d'autonomie qu'il serait intéressant de chiffrer et juguler ; le bouquin
est un vestige de cette quête d'autonomie.
> Cordialement,

Des développements il faut pouvoir abstraire des concepts ; les bouquins
sont surtout utiles pour éclairer les concepts.

Au demeurant, comme j'avais essayé d'expliquer par ma digression sur les
bouquins présentant les développements de la physique, il n'y a plus de
hautes technologies sans puissance de calcul et on rêve d'ordinateurs
quantiques ...

Amicalement