Critical temperature

Le Wed, 03 Jan 2007 17:33:04 +0100, remy a écrit :

le déploiement pour les service web aussi ?
l'integration des jars aussi ?
le débogage aussi ?
etc...

écoute, franchement je ne connais pas tous les détails, d'abord je
n'utilise pas Java parce que je trouve ça assez abominable comme langage,
ensuite ne j'utilise pas non plus emacs ou vim (enfin pas comme éditeur
principal en tout cas) mais je connais des tas de gens qui codent
exclusivement avec ces outils, y compris en Java, sans avoir de problème.

Les fonctionnalités zim boum avec interface yakakliquer genre j'appuie
sur le bouton et paf! l'application est déployée c'est très bien en
théorie, en pratique quand ça ne marche pas c'est impossible à
déméler. Moi je continue à déployer avec scp, rsync et ftp en ligne de
commande et ça roule impeccable, le tout éventuellement piloté par un
script shell ou perl.
Sans compter que j'ai regardé Eclipse une fois ou deux, et il ne fait
aucun doute pour moi que comprendre comment fonctionne les interfaces
graphiques magiques pour faire ce genre de trucs me prendrait 10 fois plus
de temps passé à cliquer partout façon neuneu, que d'écrire
directement un script shell de 10 lignes. C'est l'approche réfléchie
contre l'approche "exploration". L'exploration c'est très bien pour les
enfants et les chimpanzés, mais ce n'est pas un mode de fonctionnement
professionnel.


--
"Dope will get you through times of no money better
than money will get you through times of no dope."
Freewheelin' Franklin.

Le Wed, 03 Jan 2007 18:12:01 +0100, remy a écrit :

au fait tu as passe combien de temps a configurer la bete ?
et a lire la doc qd elle est a jour

Moins de temps que pour installer le monstre Eclipse, toujours :)

--
Pluralitas non est ponenda sine necessitate.
Guillaume d'Ockham.

Le Wed, 03 Jan 2007 17:53:18 +0000, Michel Talon a écrit :

Emmanuel Florac <eflorac@imaginet.fr> wrote:

Certes. Mais ça peut être utilisé efficacement avec d'autres outils
qu'Eclipse.

Oui, mais:
- eclipse a une très bonne présentation visuelle sur l'écran, là où
emacs, même aprés avoir passé du temps à choisir les fontes, produit
un aspect illisible, sans parler des Ctl-Meta-Shift ***et autres
acrobaties digitales.

Je n'utilise personnellement pas beaucoup Emacs, mais je trouve que la
présentation est bonne, surtout si c'est XEmacs d'ailleurs.

Ensuite eclipse a une aide contextuelle
formidable, complètement automatique, présentations des définitions (*)
dans un cartouche, etc.

Oui mais dans quel éditeur moderne n'ya t'il pas ça, franchement? Même
vim en ligne de commande sait le faire (OK, pas dans un cartouche :)

Puis eclipse a un débogueur de java de premier
ordre, qui marche super bien, permet de rentrer dans les définitions des
fonctions de librairie, etc.

C'est surtout bien quand on fait du java, pour ma part je ne suis pas
vraiment concerné :) Bon, je promets de m'intéresser à Groovy qui a
l'air élégant et bien foutu (la syntaxe de Java me sort positivement par
tous les trous, et encore je suis poli).

C'est un ordre dse grandeur mieux que ce
qui existe traditionnellement dans le monde Unix. Evidemment c'est
inspiré par le Visual C++ de Microsoft qui est paraît-il l'un des
meilleurs logiciels de Microsoft.

Sans doute.

- de plus, pour les gens qui programment en Java, pourquoi ne pas
utiliser un environnement où le Java est très bien intégré, tel que
eclipse ou netbeans, et qui se présente de la même manière sous tous les
OS, ce qui est intéressant pour un langage multiplateforme. On n'a
qu'un système à apprendre on l'applique partout. En fait eclipse est
tellement bon que les gens utilisent même pour faire du C/C++ ou du
python avec des plugins appropriés. Certes ça occupe 300Megs, et alors?
qu'est-ce qu'on en a à faire quand la moindre machine a 1 gig sinon
plusieurs. Sur une machine moderne, il démarre en quelques secondes,
tout comme OpenOffice.

Heu, non, il démarre en deux plombes et demi sur mon PC. Pour ma part
j'ai l'habitude de naviguer et d'ouvrir des éditeurs soit depuis un term,
soit en double-cliquant sur un fichier, et attendre 40 secondes le
lancement ça me saoûlerait vite...

Je te rappelle que dans le passé on a adressé
exactement les mêmes critiques à emacs, alors que sur ta machine emacs
démarre maintenant de façon instantanée.

Certes.

- en fait, ta position vient de l'idée fausse que Java est lent.

Non, pas du tout. Je sais très bien que Java n'est plus (en général)
lent. C'est l'approche "grosse usine à gaz qui fait tout" qui est selon
moi étranger à la philosophie Unix et qui ne me plait pas. On peut dire
évidemment qu'Emacs est comme ça aussi, bien sûr, mais après tout
Emacs ne vient pas du monde Unix.
Je reste un grand amateur de ligne de commande et de wc tr grep sort uniq
find sed vi...

L'avantage de Java est de disposer d'immenses bibliothèques pour
attaquer toutes sortes de problèmes, de manière multiplateforme. Aussi
d'avoir, comme python, une syntaxe extrêmement simple et claire.

Je ne dirais qu'une chose à propos de la syntaxe de java :
Beeeeeeuuuuuuuuuuuarrrrrrk.
C'st simple, depuis Java 1.0 j'ai essayé de m'y mettre à chaque release,
j'ai jamais pu, j'ai jamais rien compris à rien. Ignoble, imbitable,
verbeux, atroce. Je déteste profondément la syntaxe de Java.
Par ailleurs je n'aime pas des masses python non plus, l'indentation
signifiante m'emmerde au plus au point. Ruby, c'est chouette.
Malheureusement c'est encore un peu "léger". Lua c'est pas mal, mais
encore plus léger. groovy a l'air bien, c'est vrai :)

de construction à la mode de C++, ce qui nécessite d'être un vrai Pic de
la Mirandole pour en assimiler tous les aspects.

Argh, c'est sûr que C++ c'est méga craignos... Objective C, j'aime assez
au premier abord, mais je ne m'y suis jamais mis... Dommage que ça n'ai
pas vraiment pris, parce que le framework OpenStep comme le langage objC
ont l'air vraiment très bien.
À tout prendre j'aime encore mieux le C "pseudo orienté objet" façon
Linux (le noyau) que C++ :)


--
L'église est une secte qui a réussi.
Ernest Renan.

Emmanuel Florac wrote:

je ne
vois pas pourquoi on devrait utiliser justement celui qui n'est pas
installé en standard, qui est énorme et qui dépend de Java.

C'est con que java devienne libre. C'est une pourriture qui devrait
rester propriétaire. Faire sans c'est faire mieux qu'avec et on s'en
serait bien passé.

--
Izatis

une syntaxe extrêmement simple et claire. En fait
il a énormément influencé les langages modernes comme python et ruby
dans cette direction. Il a montré que en pratique on pouvait résoudre
les problèmes efficacement sans disposer d'une myriade de possibilités
de construction à la mode de C++, ce qui nécessite d'être un vrai Pic de
la Mirandole pour en assimiler tous les aspects.

cela commence a ne plus etre vraiment vrai

j'ai redecouvert un truc pour rendre le code illisible les Closures
sont maintenant possibles en java :-(

c'est selon moi a cause de point net il se tire la bourre
mais pas dans le bon sens

(*) On trouve ça dans Vim 7.0 uniquement.

le déploiement pour les service web aussi ?
l'integration des jars aussi ?
le débogage aussi ?
etc...

écoute, franchement je ne connais pas tous les détails, d'abord je
n'utilise pas Java parce que je trouve ça assez abominable comme langage,
ensuite ne j'utilise pas non plus emacs ou vim (enfin pas comme éditeur
principal en tout cas) mais je connais des tas de gens qui codent
exclusivement avec ces outils, y compris en Java, sans avoir de problème.

Les fonctionnalités zim boum avec interface yakakliquer genre j'appuie
sur le bouton et paf! l'application est déployée c'est très bien en
théorie, en pratique quand ça ne marche pas c'est impossible à
déméler. Moi je continue à déployer avec scp, rsync et ftp en ligne de
commande et ça roule impeccable, le tout éventuellement piloté par un
script shell ou perl.
Sans compter que j'ai regardé Eclipse une fois ou deux, et il ne fait
aucun doute pour moi que comprendre comment fonctionne les interfaces
graphiques magiques pour faire ce genre de trucs me prendrait 10 fois plus
de temps passé à cliquer partout façon neuneu, que d'écrire
directement un script shell de 10 lignes. C'est l'approche réfléchie
contre l'approche "exploration". L'exploration c'est très bien pour les
enfants et les chimpanzés, mais ce n'est pas un mode de fonctionnement
professionnel.


l'approche reflechie j'aime bien cette approche

je l'aime tellement que je considere que la machine est au
service et donc se doit de me simplifier la vie

un exemple ant a la main s'est pas rigolo c'est meme chiant a ecrire
et le xml des conteneurs dans tomcat n'est vraiment pas evident a ecrire
alrs a la main...

Emmanuel Florac <eflorac@imaginet.fr> wrote:

L'exploration c'est très bien pour les
enfants et les chimpanzés, mais ce n'est pas un mode de fonctionnement
professionnel.

Oui, outre les enfants et les chimpanzés, c'est aussi le mode de
fonctionnement des chercheurs ... peut être une espèce intermédiaire
entre les enfants et les singes? comme dirait qui tu sais ...

--

Michel TALON

Emmanuel Florac <eflorac@imaginet.fr> wrote:

plusieurs. Sur une machine moderne, il démarre en quelques secondes,
tout comme OpenOffice.

Heu, non, il démarre en deux plombes et demi sur mon PC. Pour ma part
j'ai l'habitude de naviguer et d'ouvrir des éditeurs soit depuis un term,
soit en double-cliquant sur un fichier, et attendre 40 secondes le
lancement ça me saoûlerait vite...

Sur mon portable fraîchement booté, là tout de suite, montre en main:
- openoffice 12 s.
- eclipse 18 s.
- netbeans 20 s.
- eric3 8 s.
Au deuxième lancement:
- openoffice 3 s.
- eclipse 10 s.
- netbeans 10 s.
- eric3 3 s.
Et ceci avec un disque de portable qui est bien moins rapide qu'un
disque de desktop, par contre le processeur est puissant.

--

Michel TALON

remy <remy@fctpas.fr> wrote:

une syntaxe extrêmement simple et claire. En fait
il a énormément influencé les langages modernes comme python et ruby
dans cette direction. Il a montré que en pratique on pouvait résoudre
les problèmes efficacement sans disposer d'une myriade de possibilités
de construction à la mode de C++, ce qui nécessite d'être un vrai Pic de
la Mirandole pour en assimiler tous les aspects.

cela commence a ne plus etre vraiment vrai

j'ai redecouvert un truc pour rendre le code illisible les Closures
sont maintenant possibles en java :-(

c'est selon moi a cause de point net il se tire la bourre
mais pas dans le bon sens

Je ne savais pas ça et du coup j'ai googlé un peu, et suis tombé sur
ceci:


This definitely seems like a better proposal. Many feel (validly, I
think) that the increasing complexity of the language (generics for
instance) is a real risk to the readability and maintainability of code
written and Java, and the future popularity of the language. BGGA seems
to add too much complexity for too little gain; CICE definitely seems to
have a simpler conceptual model. I hope all you smart folks figure out
the perfect point on the curve to do closures right in Java.

Effectivement, je pense que les templates sont une monstruosité en C++,
et les avoir introduit (même sous une forme atténuée) en Java pour
copier le C# une erreur grossière. La qualité numéro un, pour ne pas
dire la seule de Java, c'est la simplicité. Tout ce qui ruine la
simplicité est une catastrophe.

Les closures c'est encore pire. Voici un texte à ce sujet qui est bien
digne de Heidegger ou Husserl :-(

http://gafter.blogspot.com/2006/08/closures-for-java.html

Function types provide a natural way to express some kinds of
abstraction that are currently quite awkward to express in Java. For
programming in the small, closures allow one to abstract an algorithm
over a piece of code; that is, they allow one to more easily extract the
common parts of two almost-identical pieces of code. For programming in
the large, closures support APIs that express an algorithm abstracted
over some computational aspect of the algorithm. We propose to add
function types and closures to Java. We anticipate that the additional
expressiveness of the language will simplify the use of existing APIs
and enable new kinds of APIs that are currently too awkward to express
using the best current idiom: interfaces and anonymous classes.

Et pour Emmanuel qui trouve que la syntaxe de ruby est géniale, voici
un exemple des choses dont les afficionados se réjouissent:
IO.foreach("foo.txt") do |line|
if (line =~ /total: (d+)/)
puts $1;
end
end
Toute cette syntaxe perlesque et merdeuse pour faire ce que python fait
de façon claire, aussi brève et pas plus verbeuse!
http://fishbowl.pastiche.org/2003/05/16/closures_and_java_a_tutorial

(*) On trouve ça dans Vim 7.0 uniquement.

--

Michel TALON

Michel Talon, dans le message <eniknj$1jfv$3@asmodee.lpthe.jussieu.fr>,
a écrit :

Effectivement, je pense que les templates sont une monstruosité en C++,
et les avoir introduit (même sous une forme atténuée) en Java pour
copier le C# une erreur grossière.

Je ne pense pas que les génériques de java puissent se comparer aux
templates du c++. C'est au contraire quelque chose de très naturel. Avant,
si tu voulais faire une liste chaînée de String et une autre d'Integer, il
fallait faire attention à ne pas ajouter un Integer à la première et un
String à la seconde, et utiliser un cast quand on lit les objets. Avec les
génériques, on n'a plus deux LinkedList tout court, on a une LinkedList de
String et une LinkedList d'Integer.

Le compilateur va vérifier, à la compilation, qu'on ajoute des éléments du
bon type, et à la lecture, les éléments auront directement le bon type.
C'était déjà le cas pour les tableaux, ça devient vrai pour le reste.

C'est un pas dans le bon sens. Le pas suivant, c'est qu'il n'y ait plus
besoin d'écrire explicitement les génériques, et de laisser le compilateur
déterminer le type des objets, et vérifier qu'il est utilisé de manière
cohérente partout dans le programme.