os et concept de langage

debug this fifo a écrit :

remy wrote:

pour éviter les problèmes de débordement de zones m émoire, c'est
l'utilité première d'un garbage collector (la sécurità ©)

il y a des gens vraiment crédules dans le coin...

essaye d'en programmer un ,ou fait une recherche avec google


--
http://remyaumeunier.chez-alice.fr/

remy wrote:

l'obj facilite la lecture et la compréhension du code

1er avril tres productif, je constate...

On 2010-04-01, remy wrote:

[ un poisson d'avril, je l'espère ]

OK, c'est drôle. Mais quel est le rapport avec Linux ?

--
Unix is simple. It just takes a genius to understand its simplicity
--Dennis M. Ritchie

debug this fifo a écrit :

remy wrote:

l'obj facilite la lecture et la compréhension du code

1er avril tres productif, je constate...

je ne suis pas d'accord et je maintiens

l'obj facilite la lecture et la compréhension du code

non mais

remy
--
http://remyaumeunier.chez-alice.fr/

remy wrote:

pour éviter les problèmes de débordement de zones mémoire, c'est
l'utilité première d'un garbage collector (la sécurité)

il y a des gens vraiment crédules dans le coin...

essaye d'en programmer un ,ou fait une recherche avec google

quel rapport entre un ramasse-miette et un debordement de zone memoire ?

Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le 01-04-2010, ? propos de
os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

bonjour

'jour,

si je suppose que le c++ est encore en train de trainer dans les bars
à la recherche de son domaine d'application ,à mon avis il
est trop tard et il finira alcolo tout comme le caml ou ocaml
un truc qui a le mérite d'exister et c'est déjà pas mal
que java depuis le rachat de sun a un avenir incertain

Bof. Déjà, il faudrait voir en quoi java est essentiel à
l'informatique

comment ça c'est pas le premier, ok mais il apporte une vraie
portabilité du code "compilé"

Pas plus qu'un compilo C qui suit une norme précise et même moins.
Tant que tu restes sous Windows, Linux i386/amd64, Solaris et MacOS,
peut-être. Dès que tu attaques la vraie portabilité (PDA, NetBSD PPC
et j'en passe), c'est largement moins portable qu'un truc écrit en C parce
que les JVM n'ont pas été portées ou ne sont plus d'origine
Sun^WOracle. Essaye déjà de porter un soft Java spécifié JVM 1.5 sur
une J9/PPC et on en reparle. Java n'est _pas_ normalisé et rien que
ça, ça limite la portabilité sur tout ce qui n'est pas couvert par
les JVM Sun^WOracle.

c'est un faux problème, le langage n'est pas normalisé au sens strict du
terme mais la machine virtuelle, elle, pour prétendre exécuter du java
se doit de passer une batterie de tests qui garantissent son bon
fonctionnement et donc "la norme"

Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n'est
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple). Lorsque tu prends la norme C ou Fortran
quelque chose, tu _sais_ à quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnement
de tes logiciels sur la JVM cible. Et au passage, lorsque tu as une
merde quelconque, tu ne sais plus si le bug est dans ton code, dans
l'OS ou dans ce qui est entre les deux, la JVM.

et pour ta comparaison, ben cela ne le fait pas
ben oui le seul problème c'est que l'on ne compile pas les programmes
mais que l'on installe des exécutables, ne me dit pas que tu ne t'es
jamais retrouvé avec un binaire qui tourne sous une distribution et pas
sur une autre à cause d'une sordide histoire de linker

Jamais, pour la simple raison que lorsque je suis contraint à
diffuser des binaires, j'écris un makefile aux petits oignons avec
une édition des liens statique et juste les symboles nécessaires.
L'exécutable est un peu plus gros et parfaitement portable puisqu'il
n'est dynamiquement lié qu'à la libc et deux ou trois trucs
dépendants du système. Lorsque je diffuse des sources, autoconf fait
le boulot à ma place et rajoute ce qu'il faut.

et je vois mal Oracle faire des conneries avec Java.

OpenJDK fonctionne pas mal et pourrait bien devenir la version de
référence de ce truc non normalisé.

ok pour la normalisation, mais pas d'accord pour "le fonctionne pas mal"
essayes jmf

Je ne fais du Java que contraint et forcé. Pour ce que j'en fait,
OpenJDK suffit largement.

L'immense majorité des développeurs

ont déserté Sun depuis le rachat par Oracle.

la programmation obj a tout de même un domaine de prédilection
les interfaces graphiques ou programmations évènementielles

Pourquoi ? J'ai codé des trucs parfaitement aboutis avec un simple
compilo C et X11/Xt/Xm. Pas besoin de C++ pour cela. Et Motif est un
truc _très_ agréable à coder en C. Maintenant, on peut ne pas aimer
le design de Motif, personnellement, j'aime assez parce que ce
design se fait par un fichier externe au soft compilé, ce qui est
très bien.

je ne connait pas motif, mais une interface graphique qui n'est pas obj
si elle ne l'est pas j'en veux pas

Tu peux faire _sans_ objet au sens programmation objet. Et pour
avoir fait du Qt (objet) et du Motif (non objet), la programmation
de Motif est bien plus efficace et facile.

pour un petit truc, probablement, mais dès que tu passes au gros machin
ou tu clik à tout va l'usine à gaz devient ingérable avec aucune
méthodologie

Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le truc
le plus clair que je connaisse après SMG$. C'est limpide, même à la
relecture. Tu crées tes objets graphiques en les attachant les uns
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.

l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'octroie
pour avoir à l'arrivée quelque chose d' imbitable et non maintenable

Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, juste
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du graphe
associé. Avec du temps, tu vas y arriver. Mais si tu avais un
fichier d'en-tête avec la définition du type 'graphe' et les deux ou
trois routines associées à la gestion de ce graphe, ce serait
beaucoup plus simple (sans compter que ce serait plus efficace,
parce que le graphe de boost est un graphe bien plus général que
celui nécessaire à un A* et sa création prend un temps dingue pour
rien).

et pourtant il y a un autre domaine où il pourrait être super utile
au hasard les os

Un OS en C++, p'taing, ce qu'il ne faut pas entendre. Il y a
tellement de couches d'abstractions dans du C++ que c'est
contre-productif, mais c'est à toi de voir. Il y a régulièrement des
batailles pour mettre du C++ dans les noyaux Unix et ça termine
toujours de la même manière.

je serais assez partisan d'un peu d'obj dans les drivers
cela éviterait le changement d'interface à chaque nouvelle
bibliothèque

Foutaises. Ça simplifie les interfaces au dépens du reste (et de
l'efficacité). On n'utilise pas la programmation objet pour obvier à
un problème de design (et de macros) mal fichu. C'est vraiment le
pire argument qui puisse être.

absolument pas, en quoi le fait d'avoir une approche obj grefferait les
performances

Tu as des problèmes de compréhension.

la programmation obj dans le cas par exemple du c++ est aussi performant
que le c, la preuve n'est plus à faire

Je te demande d'utiliser un calcul de trajet issu de pgrouting
(Boost, C++) et le même algorithme codé à la main. Tu vas juste
avoir des surprises. D'un côté, tu mets à plat une T5120 avec 16 Go
de mémoire et je ne sais plus combien de voies et de l'autre, tu
fais tourner la même chose avec 300 Mo de mémoire et un vieux
Pentium III. La preuve est faite. En revanche, pour la majorité des
traitements où l'on n'en est pas à compter les cycles, la différence
n'est pas vraiment perceptible parce que moins importante.

la différence entre le c et le c++ réside dans la méthodologie
l'un est permissif l'autre t'envoie chier sans aucun remord
mais après compilation c'est du kif kif au pouillem près

Et non, mais c'est toi qui vois. Ce n'est pas parce que tu ne sais
pas programmer en C qu'il est permissif. En C, c'est à toi de
t'enquérir des erreurs. Si tu ne le fais pas, c'est ton problème,
pas celui du langage.

par exemple un langage obj multi thread
comment faire en 3 coups de cuillère à pot un os minimaliste

Et carrément sous-optimal. Tu ne peux avoir en même temps
l'efficacité du C et l'abstraction du C++. Si tu veux un bon exemple :
regarde pgrouting et utilise cette bibliothèque avec une
cartographie à l'échelle de l'ensemble des rues d'un pays.
Maintenant, prends un compilo C et code ton propre A* pour obtenir
le même résultat. Tu verras une sacré différence de vitesse (20 fois
plus rapide pour la version C) et une occupation mémoire différente
(10 fois moindre pour la version C). Les types qui ont codé Boost ne sont
pas des imbéciles. Seulement les couches du C++ qui s'empilent sont
toutes génériques et jamais parfaitement adaptées à _ton_ problème
qui est la recherche du meilleur chemin avec un A*.
Le résultat est que tu perds des cycles à droite et à gauche et
qu'au final le résultat est _mauvais_.

4 fifo (4 niveaux de priorité)
1 thread maitre qui parcourt les fifos et lance les thread
qui sont dans le fifo

Personnellement, je ne gèrerais pas vraiment ça avec des fifo mais
avec un seul anneau et des règles de saut, mais c'est à toi de voir.

ce qui revient au même, mais je cherchais surtout à être
compréhensible, mais on est d'accord sur le fond

Pas vraiment, mais si tu le dis.

et ton saut ou règle de saut dans ton anneau il correspond à quoi ?

Aux sauts d'une tâche à une autre. Quelle question ?! Tu implantes
un buffer circulant sous la forme d'un anneau chaîner, ce qui éviter
la gestion de fifo pour le coup parfaitement inefficaces.

un thread qui remplit le fifo

et un petit dernier qui alloue les zones mémoire
et pour faire plaisir à jdk on ne l'appellera pas garbage collector
(je plaisante )

Un noyau de système n'a rien à faire de la gestion de la mémoire
dynamique au sens où tu l'entends. Dans un système Unix, c'est la
libc (ou l'une de ses composantes) qui s'amuse à ça. Le noyau gère
sa propre mémoire et n'a pas besoin d'un garbage collector. Pourquoi ?

pour éviter les problèmes de débordement de zones mémoire, c'est
l'utilité première d'un garbage collector (la sécurité)

Bon, je vais enfoncer un clou. Sais-tu pourquoi un OS comme VMS est
largement plus sécurisé qu'un truc comme Unix ? Tout simplement
parce que les chaînes de caractères sont traitées par des
descripteurs, ce qui évite de fait les débordements de tampon. La
connerie intrinsèque des systèmes Unix, c'est la chaîne de
caractères terminée par un caractère nul. C'est de là que vient
l'immense majorité des failles. Pour résoudre ce problème, il ne
faut pas un garbage collector, mais un truc capable de traiter une
chaîne de caractère (ou un buffer) _avec_ sa longueur et capable de
te foutre un coup de pied au cul à chaque tentative de débordement.

c'est peut être une des causes mais à une rustine, je préfère une
approche globale qui me garantit le bon fonctionnement du processus
plutot qu' une rustine sur une rustine puis une autre rustine en
attendant la prochaine approche qui nécessitera encore une énième
rustine

Tu es vraiment irrécupérable. Je viens de te dire comment éviter les
'buffer overflows' et tu me parles de rustine... Le fait d'avoir une
chaîne terminée par un 0 ou des fonctions de bas niveau capables de
déborder est la cause de l'immense majorité des failles. Il faut
donc changer de paradigme. Dans un code userland, on pourra toujours
contourner le problème, mais dans un noyau d'OS, il restera toujours
des bugs dues à cette gestion historique et foireuse.

puisque dans un thread, on a tout ce qu'il nous faut pour suspendre
arrêter ou lancer un processus, avec en plus des mécanismes de
protection mémoire liés au concept obj, donc pourquoi s'en passer

Il y a juste un truc que tu oublies. Un OS, c'est un programme lié
statiquement avec rien qui dépasse. Tu n'as a priori rien pour gérer
ça si tu ne le fais pas à la mimine.

pas bien compris

Tu ne peux pas faire des appels à la libc depuis un noyau Unix parce
que la libc s'appuie sur le noyau. C'est le coup de la poule ou de
l'oeuf. Ça va mieux ?

c'est exactement là que je place l'hypothétique gain
l'idée consiste à imposer certaines contraintes par la définition du
langage ou de la librairie de manière à éviter tous les contrôles
dynamiques qui existent dans un os

un exemple histoire d'être plus clair un driver

public MyDriver :: Driver
{

}
ben cette simple notation me donne accès aux espaces d'adressages qui
correspondent au hard et m'imposent un canal de communication pour les
applis qui ont besoin du hard ( l'imprimante par exemple)
pas besoin de savoir si je suis dans le noyau aux caraïbes ou à péta
ouchnouke je protège de manière structurelle mon hard et je ne fais pas
de test inutile

Bon, il vaut mieux lire ça qu'être aveugle... Réfléchis à ce que tu
viens d'écrire et tu verras à quel point c'est absurde.

en gros l'idée consiste à gagner du temps processeur
en définissant en statique "définition du langage" tous les contrôles
qui sont actuellement faits en dynamique contrôle sur les signaux
protection mémoire etc

Exprime-toi correctement. C'est incompréhensible.

en plus si les threads sont bien pensés l'on peut faire du scalaire ou
du vrai parallélisme

Que le scalaire ou le vectoriel dépend plus de l'architecture que de
l'OS lui-même, mais on n'est plus à ça près...

pas d'accord ,bien sur que l'architecture rentre en ligne de compte
c'est évident, actuellement le parallélisme est très mal géré, il se
résume à une augmentation de la charge mais pas à une augmentation de la
puissance de traitement

Je crois surtout que tu confonds allègrement scalaire, vectoriel et
parallèle. Parallèle ou non, c'est un concept qui vient de l'OS (on
dira même multitâche ou multithread). Scalaire ou vectoriel, ça vient
de l'architecture matérielle. Parallèle, ce n'est pas le contraire de
scalaire.

je ne veux pas dire mais c'est ce que je dis
en gros je me répète

si les threads sont bien pensés l'on pourra utiliser tous les coeurs
d'une machine avec un seul thread maintenant on est d'accord ce n'est
pas du scalaire dans sa définition exacte du terme si cela peut te faire
plaisir

Cen'est pas ce que tu écrivais puisque tu opposais parallèle et
scalaire.

quand pensez vous ?

Que tes produits sont vachement efficaces.

je suppose inefficace :-)

Non, ton dealer t'en a filé de la bonne.

pas vraiment, mais je pense que ce qui ne passe pas avec l'obj
c'est que l'obj impose une réflexion avant de coder contrairement au c
où l'on peut très souvent s'arranger disons que le degré de liberté est
moindre et encore j'ai un doute, j'ai déjà codé à l'arraché comme un
goret
tiens exemple mon algo de compression franchement je plains
l'inconscient qui veut lire le code :-)

Tiens, il y avait longtemps.

Parce que l'inconscient, il essayera de comprendre
l'incompréhensible. Je t'aide, lorsque tu code dans un langage
impératif, tu commences _toujours_ par faire une analyse, que tu la
nommes fonctionnelle ou non. Il n'y a aucune raison que
l'utilisation d'un langage impératif génère un code ignoble (pas
plus que l'utilisation d'un langage objet génère un code propre).
J'ai des tas d'exemples de codes écrits en C de plusieurs dizaines
de milliers de lignes quasiment sans commentaire et qui sont
_limpides_ alors que j'ai des trucs beaucoup plus courts en C++
et imbitables.

Maintenant, l'utilisation d'un truc comme Java fait du code
généralement compréhensible par le seul concepteur dès que le
programme dépasse une taille critique parce qu'on ne sait plus
réellement à l'échelle du programme (je ne parle pas de la fonction)
comment tout ce beau monde interagit.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

debug this fifo a écrit :

remy wrote:

pour éviter les problèmes de débordement de zones mémoire, c'est
l'utilité première d'un garbage collector (la sécurité)

il y a des gens vraiment crédules dans le coin...

essaye d'en programmer un ,ou fait une recherche avec google

Euh... Juste une chose... Le garbage collector, c'est une fois le
dépassement de buffer effectué puisqu'il ne s'occupe que de la
libération de la mémoire...

Hors sujet !

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

On 2010-04-01, Vivien MOREAU wrote:

On 2010-04-01, remy wrote:

[ un poisson d'avril, je l'espère ]

OK, c'est drôle. Mais quel est le rapport avec Linux ?

Ben, la reecriture du noyau Linux en java, non ? Avec le
GC ca va rendre Linux tellement secure que meme OpenBSD aura
l'air aussi vulnerable qu'un vulguaire Windows en
comparaison.

--
Bruno Ducrot

-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.

On 2010-04-01, Bruno Ducrot wrote:

Ben, la reecriture du noyau Linux en java, non ? Avec le
GC ca va rendre Linux tellement secure que meme OpenBSD aura
l'air aussi vulnerable qu'un vulguaire Windows en
comparaison.

Il en aurait bien besoin le manchot, pour l'instant il a la tête à
l'envers.

--
Unix is simple. It just takes a genius to understand its simplicity
--Dennis M. Ritchie

JKB a écrit :

Non, c'est parfaitement faux. Que tu le crois prouve simplement que
les types du marketing ont bien fait leur boulot. Le problème n'e st
pas sur les 99% de Java que tu utilises, mais sur les 1% restant. Et
je t'assures qu'il y a des trucs assez rigolos sur les gestions de
threads (par exemple).

jamais rencontré de problème avec les threads en java
trouves moi un exemple ou quelques lignes de java


Lorsque tu prends la norme C ou Fortran

quelque chose, tu _sais_ à quoi t'attendre. Pour Java, c'est
beaucoup plus flou et ça t'oblige de valider le bon fonctionnemen t
de tes logiciels sur la JVM cible.

connerie ou argument d'autorité
j'ai jamais eu d'incompatibilité entre une jmv sun et ibm
peut être quelques temps d'exécution différents

Et au passage, lorsque tu as une
merde quelconque, tu ne sais plus si le bug est dans ton code, dans
l'OS ou dans ce qui est entre les deux, la JVM.

et pour ta comparaison, ben cela ne le fait pas
ben oui le seul problème c'est que l'on ne compile pas les progra mmes
mais que l'on installe des exécutables, ne me dit pas que tu ne t 'es
jamais retrouvé avec un binaire qui tourne sous une distribution et pas
sur une autre à cause d'une sordide histoire de linker

Jamais, pour la simple raison que lorsque je suis contraint à
diffuser des binaires, j'écris un makefile aux petits oignons ave c
une édition des liens statique et juste les symboles nécessa ires.
L'exécutable est un peu plus gros et parfaitement portable puisqu 'il
n'est dynamiquement lié qu'à la libc et deux ou trois trucs
dépendants du système. Lorsque je diffuse des sources, autoc onf fait
le boulot à ma place et rajoute ce qu'il faut.

cela ne change rien au fait que l'on installe un binaire et pas un code
source

Non. Mais tu peux le croire si ça te chante. L'ABI Motif est le t ruc
le plus clair que je connaisse après SMG$. C'est limpide, mê me à la
relecture. Tu crées tes objets graphiques en les attachant les un s
aux autres et tu rajoutes les callbacks. Plus simple, plus propre,
c'est impossible à faire.

l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s' octroie
pour avoir à l'arrivée quelque chose d' imbitable et non m aintenable

Non. La programmation objet, c'est l'illusion de la simplicité.
Regarde juste Boost, histoire de rigoler. Je te mets au défi, jus te
avec Boost (les sources, hein, pas la doc), de comprendre comment
l'algorithme A* est implanté et quelle est la structure du graphe
associé.

tiens je te parie " rien " je suis fauché, qu'il n'y a pas
de structures associées au graphe mais des obj que tu peux associer à la
structure d'un graphe, la structure est dans l'agencement des obj en
gros. Cela permet d'avoir le même traitement quelque soit la structu re


Avec du temps, tu vas y arriver. Mais si tu avais un

fichier d'en-tête avec la définition du type 'graphe' et les deux ou
trois routines associées à la gestion de ce graphe, ce serai t
beaucoup plus simple (sans compter que ce serait plus efficace,
parce que le graphe de boost est un graphe bien plus général que
celui nécessaire à un A* et sa création prend un temps dingue pour
rien).

je ne connais pas ton A* ni d'un point de vue mathématique ni d'un
point de vue algorithmique

Et non, mais c'est toi qui vois. Ce n'est pas parce que tu ne sais
pas programmer en C qu'il est permissif. En C, c'est à toi de
t'enquérir des erreurs. Si tu ne le fais pas, c'est ton problè me,
pas celui du langage.

bien sur que si

c'est le problème du langage parce que comme tu le dis, tout le mond e ne
sait pas programmer en c ou que tout le monde a sa propre vision du
traitement de l'erreur ou exception, ou croit qu'il le fait dans les
règles

et ton saut ou règle de saut dans ton anneau il correspond à quoi ?

Aux sauts d'une tâche à une autre. Quelle question ?! Tu imp lantes
un buffer circulant sous la forme d'un anneau chaîner, ce qui à ©viter
la gestion de fifo pour le coup parfaitement inefficaces.

et comment tu fais pour faire le distingo entre les différentes
priorités,
franchement si c'était juste pour dire que tu connaissais les buffeu rs
circulaires c'était pas la peine

Tu es vraiment irrécupérable. Je viens de te dire comment à ©viter les
'buffer overflows' et tu me parles de rustine... Le fait d'avoir une
chaîne terminée par un 0 ou des fonctions de bas niveau capa bles de
déborder est la cause de l'immense majorité des failles. Il faut
donc changer de paradigme.

c'est pas ce que tu proposes "un changement de paradigne" tu
proposes un changement de structures, en gros introduire la taille dans
la chaine ou buffeur

c'est exactement là que je place l'hypothétique gain
l'idée consiste à imposer certaines contraintes par la dé finition du
langage ou de la librairie de manière à éviter tous les contrôles
dynamiques qui existent dans un os

un exemple histoire d'être plus clair un driver

public MyDriver :: Driver
{

}
ben cette simple notation me donne accès aux espaces d'adressages qui
correspondent au hard et m'imposent un canal de communication pour les
applis qui ont besoin du hard ( l'imprimante par exemple)
pas besoin de savoir si je suis dans le noyau aux caraïbes ou à   péta
ouchnouke je protège de manière structurelle mon hard et je ne fais pas
de test inutile

Bon, il vaut mieux lire ça qu'être aveugle... Réflé chis à ce que tu
viens d'écrire et tu verras à quel point c'est absurde.

huùmmmmmmmmmmmmmmmm

toujours pas trouvé, tu peux m'éclairer

si les threads sont bien pensés l'on pourra utiliser tous les coe urs
d'une machine avec un seul thread maintenant on est d'accord ce n'est
pas du scalaire dans sa définition exacte du terme si cela peut t e faire
plaisir

Cen'est pas ce que tu écrivais puisque tu opposais parallèle et
scalaire.

copier /coller

en plus si les threads sont bien pensés on peut faire du scalaire ou
du vrai parallélisme

quand pensez vous ?

Que tes produits sont vachement efficaces.

je suppose inefficace :-)

Non, ton dealer t'en a filé de la bonne.

pas vraiment, mais je pense que ce qui ne passe pas avec l'obj
c'est que l'obj impose une réflexion avant de coder contrairement au c
où l'on peut très souvent s'arranger disons que le degré de liberté est
moindre et encore j'ai un doute, j'ai déjà codé à l'arraché comme un
goret
tiens exemple mon algo de compression franchement je plains
l'inconscient qui veut lire le code :-)

Tiens, il y avait longtemps.

Parce que l'inconscient, il essayera de comprendre
l'incompréhensible. Je t'aide, lorsque tu code dans un langage
impératif, tu commences _toujours_ par faire une analyse, que tu la
nommes fonctionnelle ou non. Il n'y a aucune raison que
l'utilisation d'un langage impératif génère un code ign oble (pas
plus que l'utilisation d'un langage objet génère un code pro pre).

laisse un bout de code entre plusieurs mains et reviens voir le
résultat

J'ai des tas d'exemples de codes écrits en C de plusieurs dizaine s
de milliers de lignes quasiment sans commentaire et qui sont
_limpides_ alors que j'ai des trucs beaucoup plus courts en C++
et imbitables.

Maintenant, l'utilisation d'un truc comme Java fait du code
généralement compréhensible par le seul concepteur dà ¨s que le
programme dépasse une taille critique parce qu'on ne sait plus
réellement à l'échelle du programme (je ne parle pas de la fonction)
comment tout ce beau monde interagit.

l'obj est indissociable des design patent donc parfaitement
compréhensible et cela quel que soit la taille du dit programme.

<connerie>
et oui madame quel que soit la taille, cela laisse rêveur hein
</>

JKB

--
http://remyaumeunier.chez-alice.fr/