informatique/autodidacte-apprendre la manipulation de bits

In article <hv4pbg$2as$1@news.cict.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:

C est devenu un standard parce qu'il était la meilleure/moins pire
réponse aux problèmes que se posaient l'industrie à un moment donné.
La compatibilité entre machines, dans le temps et avec la base
installée font qu'il reste incontournable, et imuable dans ses
qualités et ses défauts.

Je me demande entre autre si aujourd'hui, d'autres ne peuvent pas
imposer des standards (communauté Androîd supportée par Google...par
exemple) ? Mais c'est un autre sujet.

Tu as vu la guerre Java/C++/C# ?
Sun est mort, mais C# n'a pas gagné la guerre, loin de là.
Il faut une certaine "puissance de feu" pour faire émerger un
standard, mais ça n'est pas tout.

Une des tres importantes raisons pour lesquelles C est un standard, c'est
que c'est un standard ouvert: pas de problemes de brevets logiciels concernant
des reimplementations du langage. Et sans doute aussi une question d'epoque.
Les compilos C opensource sont "nes avec" le mouvement opensource, a peu de
choses pres.

Pour ce qui est de Java, Sun a rate le coche sur plusieurs points:
- ils ne sont jamais passe par l'etape normalisation cote comite ANSI/ISO.
A leur decharge, je crois bien qu'ils ont essaye, mais c'etait a l'epoque
ou Microsoft essayait de pourrir java (en diffusant entre autres des
bibliotheques subtilement incompatibles pour les applets), et celui-ci s'est
mis sur les rangs, pour essayer de faire du lobbying pour pourrir le
standard/l'enterrer. Du coup, Sun a laisse tomber le coup.
- Sun a mis des annees a diffuser ses jdk sous une license acceptable... ca
a pris pas mal de temps pour avoir des jdk performantes sur tous les systemes,
et il y a encore des bouts pour lesquelles il n'y a guere que l'implementation
de reference de Sun qui soit "raisonnable". Du coup, pas tres simple de faire
un standard avec du pur produit commercial...

Pour C#, c'est encore une autre histoire. Microsoft jouit d'une reputation
tellement mauvaise que, meme s'ils pondent un standard a peu pres ouvert,
la grosse majorite des gens dans le camp opensource va se mefier, voire
se declarer ouvertement hostiles. Il n'y a qu'a voir les casseroles
que se traine Miguel de Icaza pour avoir "libere" C# en ecrivant mono.

C'est un leitmotiv assez frequent. Il n'y a qu'a voir SQL,
"standard industriel", ou les divers acteurs se sont bien gardes de
normaliser la partie "creation de donnees" (INSERT est un ajout apres coup,
mal foutu, et terriblement peu puissant par rapport aux mecanismes
proprietaires que proposent les diverses bases "professionnelles").

Pour qu'un langage de programmation soit un vrai standard, il faut que tout
le monde puisse jouer, sans que ca coute la peau des fesses... un peu rate
pour Java et C#.

Quant a C++, le probleme est autre: C++ est un langage bien trop complexe
pour jouir d'une adoption large. Il n'y a qu'un faible pourcentage des
informaticiens qui arrivent a faire des trucs corrects avec C++...
et la grammaire du langage est imbitable, au point qu'il n'y a
que relativement peu d'implementations du langage qui tournent de facon
efficace... (on pourrait egalement citer Ada, qui est dans une situation
a peu pres similaire).

Le 14-06-2010, Marc Espie <espie@lain.home> a écrit :

In article <hv4pbg$2as$1@news.cict.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:

[SNIP]

Je me demande entre autre si aujourd'hui, d'autres ne peuvent pas
imposer des standards (communauté Androîd supportée par Google...par
exemple) ? Mais c'est un autre sujet.

Tu as vu la guerre Java/C++/C# ?
Sun est mort, mais C# n'a pas gagné la guerre, loin de là.
Il faut une certaine "puissance de feu" pour faire émerger un
standard, mais ça n'est pas tout.

Une des tres importantes raisons pour lesquelles C est un standard, c'est
que c'est un standard ouvert: pas de problemes de brevets logiciels concernant
des reimplementations du langage. Et sans doute aussi une question d'epoque.
Les compilos C opensource sont "nes avec" le mouvement opensource, a peu de
choses pres.

Pour ce qui est de Java, Sun a rate le coche sur plusieurs points:
- ils ne sont jamais passe par l'etape normalisation cote comite ANSI/ISO.
A leur decharge, je crois bien qu'ils ont essaye, mais c'etait a l'epoque
ou Microsoft essayait de pourrir java (en diffusant entre autres des
bibliotheques subtilement incompatibles pour les applets), et celui-ci s'est
mis sur les rangs, pour essayer de faire du lobbying pour pourrir le
standard/l'enterrer. Du coup, Sun a laisse tomber le coup.
- Sun a mis des annees a diffuser ses jdk sous une license acceptable... ca
a pris pas mal de temps pour avoir des jdk performantes sur tous les systemes,
et il y a encore des bouts pour lesquelles il n'y a guere que l'implementation
de reference de Sun qui soit "raisonnable". Du coup, pas tres simple de faire
un standard avec du pur produit commercial...

Je ne nie pas ce que tu dis, mais j'aurais tendance à dire que, malgré
ces points là, Java a réussi à s'imposer comme "standard de fait".

Pour C#, c'est encore une autre histoire. Microsoft jouit d'une reputation
tellement mauvaise que, meme s'ils pondent un standard a peu pres ouvert,
la grosse majorite des gens dans le camp opensource va se mefier, voire
se declarer ouvertement hostiles. Il n'y a qu'a voir les casseroles
que se traine Miguel de Icaza pour avoir "libere" C# en ecrivant mono.

Même sans être dans le "camp opensource", je pense que des industriels
craignent qu'à un moment, MS se débrouille pour les enferer à nouveau.
Disons que quand on fait du VB, on sait à quoi s'en tenir, mais qu'avec
C#, c'est moins clair.

Pour qu'un langage de programmation soit un vrai standard, il faut que tout
le monde puisse jouer, sans que ca coute la peau des fesses... un peu rate
pour Java et C#.

Quant a C++, le probleme est autre: C++ est un langage bien trop complexe
pour jouir d'une adoption large. Il n'y a qu'un faible pourcentage des
informaticiens qui arrivent a faire des trucs corrects avec C++...
et la grammaire du langage est imbitable, au point qu'il n'y a
que relativement peu d'implementations du langage qui tournent de facon
efficace... (on pourrait egalement citer Ada, qui est dans une situation
a peu pres similaire).

Oui. M'enfin bon, je ne qualifierais quand même pas C++ d'échec.
Il n'a peut-être pas eut le succès que certains en attendait, mais
il a quand même conquis un marché, il est sur la scène depuis des
années, etc.

Le nombre réduit de langage de programmation à large diffusion
fait de chacun une histoire particulière.
Je réagissais juste à l'affirmation du héron suivant laquelle
il suffisait d'être une grosse entreprise pour imposer son standard
(d'ailleurs, j'ai interprété au sans "standard de fait" et non
"norme ANSI/ISO" car cela me semblait plus l'esprit de sa question).

Java est poussé par une entreprise et réussi (à mon avis, c'est une
réussite de diffusion/popularité/usage, sans juger de qualités
intrinsèques).
C# est poussé par l'entreprise la plus puissante du logiciel, et
se plante.
C++ me semble plus le produit d'un homme, qui fédère une communauté
et s'assure de soutients industriels, et qui réussit.

Tout ceci en simplifiant bien sûr pleins de détails. On pourrait
discuter d'Ada, perl, ruby, D, Scala, mais faudrait changer de forum.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0

Le 14-06-2010, Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> a écrit :

Marc Boyer a écrit :

Le 13-06-2010, Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> a écrit :

bpascal123@googlemail.com a écrit :

Tu passes du coq à l'âne. Que vient faire la POO dans les opérateurs
bitwise ? De plus, la POO n'est pas un langage ...

En fait, je me demandais si on pouvait manipuler des bits avec des
langages orientés objets?

Oui.. mais en héritage des langages de bas niveau. C'est jugé par les
puristes comme une erreur, car on peut avoir des langages a objets sans
aucune notion de bits explicites (cf Smalltalk où mêmes les booleens
sont des objets).

Et ils font comment les puristes pour décoder un en-tête IP ?

Ils font des concession avec le monde reel...

Je ne dirais pas les choses comme ça: à mon sens, les manip binaires,
c'est une question d'implantation assez bas niveau, et l'OO essaye
justement (entre autre) de séparer interface et implémentation.
On peut manipuler des en-têtes IP en objet, mais il n'y a pas
de raisons d'avoir des champs binaires dans l'interface de l'objet.

Ou pour échanger des entiers entre deux machines d'archi distinctes ?

.. et ils masquent ces concessions dans de belles classes qui masquent
les détails d'implémentation à ceux qui veulent les utiliser.

Je ne pense pas que ce soit des concessions: séparer l'interface
de l'implantation fait partie du travail en OO.

La POO et les manipulation binaires sont quand même à deux opposés
de la programmation. Chacun sont domaine d'application. Mais il arrive
qu'on ai besoin des deux dans un même code.

Tout à fait, mais pour les débutants en objet on ne leur fait pas jouer
avec la manip de bits directement, mais on leur fait travailler sur des
concepts de plus haut niveau.

Ici il n'est pas question de savoir si la manipulation binaire est utile
ou non. Elle l'est! Mais c'était de répondre à pascal qui se demandait
si c'était important en POO. La réponse est clairement non: on y fait
tout pour s'épargner les détailles scabreux de bas niveau.

Je pense que nous sommes globalement d'accord, sauf un point de vue
sur "puretée" de l'OO.

Maintenant son pb d'origine étant de coder/debugger les drivers linux,
il n'a pas de choix: il devra se palucher les bitmasks à un moment donné
ou un autre. Le truc c'est qu'on arrive pas à savoir si il veut faire du
bas niveau ou du haut niveau au final.

Je pense qu'il ne sait pas non plus.
J'ai le sentiment que comme d'autres débutants, il pense qu'il vaut
mieux un outil bas niveau, simple, pour attaquer les problèmes, qu'un
outil haut niveau, complexe (j'ai pas dit compliqué). C'est oublier
que les problèmes sont difficiles, et que si on a développé des outils
complexes, c'est qu'ils sont plus efficaces. Et que si on a développé
des abstractions du bas niveau, c'est qu'autant l'idée générale est
simple, autant la réalité est diverse et difficile à manipuler.
C'est plus compliqué d'apprendre à se servir d'une scie sauteuse,
d'une scie scirculaire et d'un marteau piqueur que de s'en tenir
à clou/marteau/scie égoïne. Mais pour monter une cloison, on va plus
vite avec les bons outils.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0

Le 14-06-2010, ? propos de
Imposer un standard [Was: informatique/autodidacte-apprendre la manipulation de bits],
Marc Boyer ?crivait dans fr.comp.lang.c :

Java est poussé par une entreprise et réussi (à mon avis, c'est une
réussite de diffusion/popularité/usage, sans juger de qualités
intrinsèques).

Ses qualités intrinsèques, tu vas devoir m'en donner quelques unes.
Je n'ai jamais touché à C# sur Windows ni même architecture Intel.
Je m'en suis tapé sur du Linux/Sparc (à grands coups de Mono). Et
bien, c'est une vaste fumisterie pas stable avec des fuites partout.
C'est essentiellement pour cette raison que C# se plante (parce que
pour le reste C# ou Java, même combat). C# n'est _pas_ portable et
on pourra discuter le jour où mono sera portable. Pour faire tourner
Mono sur sparc, j'ai envoyé une foultitude de patches à Novell (tous
intégrés dans la version actuelle). Malgré cela, si tu es abonné à
la liste de diffusion des bugs de Mono, tu n'as qu'une seule envie,
ne pas utiliser la chose en production tellement il y a de rapports
de bugs par _jour_ !

C# est poussé par l'entreprise la plus puissante du logiciel, et
se plante.

C'est un peu normal : pas vraiment ouvert, réellement utilisable que
sous Windows et processeur x86... Comment veux-tu que ça ne se
plante pas ?

C++ me semble plus le produit d'un homme, qui fédère une communauté
et s'assure de soutients industriels, et qui réussit.

Des compilos C++ fiables existent sur des tas d'architectures et
d'OS. J'ai même quelque part une disquette 5"1/4 avec un compilo C++
pour UniFLEX, c'est dire !

Cordialement,

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.

Marc Boyer écrivit :

Ou pour échanger des entiers entre deux machines d'archi distinctes ?

.. et ils masquent ces concessions dans de belles classes qui masquent
les détails d'implémentation à ceux qui veulent les utiliser.

Je ne pense pas que ce soit des concessions: séparer l'interface
de l'implantation fait partie du travail en OO.

En C aussi (et désolé pour essayer de revenir au sujet du groupe) :
lorsqu'on écrit un morceau de code destiné être utilisé plusieurs fois,
il est de bon ton d'écrire un fichier .h, qui suffit normalement à
décrire l'interface, et l'implémentation est gardée dans du code (qui
peut être regroupé dans des bibliothèques).

C'est plus compliqué d'apprendre à se servir d'une scie sauteuse,
d'une scie scirculaire et d'un marteau piqueur que de s'en tenir
à clou/marteau/scie égoïne. Mais pour monter une cloison, on va plus
vite avec les bons outils.

Ce que ne sont ni le marteau piqueur, ni la grue. Autrement dit, les
outils complexes ne sont pas forcément des outils universels : ce sont
deux concepts assez orthogonaux, ÀMHA.
Le débat est en fait de savoir si la POO (ou C++, ou C) sont universels;
en ce qui concerne la POO, les puristes dont parlait Samuel semblent
trancher dans ce sens ; les Vrais Programmeurs du folklore sont
évidemment de l'avis opposé ; entre les deux... il y a beaucoup d'avis !


Antoine

Le 14-06-2010, Antoine Leca <root@localhost.invalid> a écrit :

Marc Boyer écrivit :

Ou pour échanger des entiers entre deux machines d'archi distinctes ?

.. et ils masquent ces concessions dans de belles classes qui masquent
les détails d'implémentation à ceux qui veulent les utiliser.

Je ne pense pas que ce soit des concessions: séparer l'interface
de l'implantation fait partie du travail en OO.

En C aussi (et désolé pour essayer de revenir au sujet du groupe) :
lorsqu'on écrit un morceau de code destiné être utilisé plusieurs fois,
il est de bon ton d'écrire un fichier .h, qui suffit normalement à
décrire l'interface, et l'implémentation est gardée dans du code (qui
peut être regroupé dans des bibliothèques).

Sauf qu'en C, masquer l'implantation des types de données, c'est
se battre contre le compilateur. Si on veut remplacer une liste
chaînée par une table de hachage, il va falloir espérer qu'aucun
code utilisateur n'a utilisé la représentation interne du type.

Ce qu'on arrive bien à faire avec .h/.c, c'est cacher
l'implantation des algos. Pas le type des données.

Arriver à écrire une fonction "find" qui prend en paramêtre
un critère et tout objet ayant une méthode "first()" et une
autre "next()", c'est pas évident.

Après, ces bases de séparation interface/implémentation, c'est plus
des types de données abstraits (ADT), dont l'OO est un dérivé.

C'est plus compliqué d'apprendre à se servir d'une scie sauteuse,
d'une scie scirculaire et d'un marteau piqueur que de s'en tenir
à clou/marteau/scie égoïne. Mais pour monter une cloison, on va plus
vite avec les bons outils.

Ce que ne sont ni le marteau piqueur, ni la grue. Autrement dit, les
outils complexes ne sont pas forcément des outils universels : ce sont
deux concepts assez orthogonaux, ÀMHA.
Le débat est en fait de savoir si la POO (ou C++, ou C) sont universels;
en ce qui concerne la POO, les puristes dont parlait Samuel semblent
trancher dans ce sens ; les Vrais Programmeurs du folklore sont
évidemment de l'avis opposé ; entre les deux... il y a beaucoup d'avis !

Mon propos, c'est que l'enjeux du code actuel, c'est le passage à
l'échelle, et que le C n'offre pas de support pour traiter cela
(hormis .h/.c, #define, <stdint.h>...).
La POO est le paradigme actuel pour contenir cette complexité. C'est
compliqué, mais le problème est difficile.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0

In article <hv5cuk$afq$1@news.cict.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:

Mon propos, c'est que l'enjeux du code actuel, c'est le passage à
l'échelle, et que le C n'offre pas de support pour traiter cela
(hormis .h/.c, #define, <stdint.h>...).
La POO est le paradigme actuel pour contenir cette complexité. C'est
compliqué, mais le problème est difficile.

Mouais bof. Plus le temps passe, plus je vois le procedural comme du POO
optimise, et la POO comme du procedural avec notation syntaxique en plus.

Pour des structures de donnees complexes, tu aimerais bien des types
abstraits, et pouvoir travailler avec ceux-ci. Idealement, c'est ton
systeme de compilation qui optimise en fonction des besoins, et en particulier
qui fait disparaitre toutes les classes trop statiques. Par exemple, c'est ce
qu'on peut faire a la main en C++ a grand coup d'inlines et de templates,
meme si c'est effroyablement complexe.

A cote de ca, quand tu te ballades dans du code objet a outrances, tu te
perds en lourdeur syntaxique: pas de procedures globales, donc tu dois
te trimballer tous les objets/contextes avec lesquels tu bosses de facon
plus ou moins explicites, et difficulte a savoir ce sur quoi tu bosses
exactement: en fonction du contexte, un nom de fonction t'envoies un peu
n'importe ou.

J'aimerais bien des outils qui me permettent simplement de passer de l'un
a l'autre, d'une part parce que l'objet, ca peut etre lourd cote performances,
mais aussi et surtout, parce que c'est l'enfer a auditer (cote securite
par exemple)...

Le 14-06-2010, Marc Espie <espie@lain.home> a écrit :

In article <hv5cuk$afq$1@news.cict.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:

Mon propos, c'est que l'enjeux du code actuel, c'est le passage à
l'échelle, et que le C n'offre pas de support pour traiter cela
(hormis .h/.c, #define, <stdint.h>...).
La POO est le paradigme actuel pour contenir cette complexité. C'est
compliqué, mais le problème est difficile.

Mouais bof. Plus le temps passe, plus je vois le procedural comme du POO
optimise, et la POO comme du procedural avec notation syntaxique en plus.

Pour des structures de donnees complexes, tu aimerais bien des types
abstraits, et pouvoir travailler avec ceux-ci.

Jusque là, je te suis.

Idealement, c'est ton
systeme de compilation qui optimise en fonction des besoins, et en particulier
qui fait disparaitre toutes les classes trop statiques. Par exemple, c'est ce
qu'on peut faire a la main en C++ a grand coup d'inlines et de templates,
meme si c'est effroyablement complexe.

Ça, c'est un pb de perfs, non ?

A cote de ca, quand tu te ballades dans du code objet a outrances, tu te
perds en lourdeur syntaxique: pas de procedures globales, donc tu dois
te trimballer tous les objets/contextes avec lesquels tu bosses de facon
plus ou moins explicites

Tu peux détailler/illustrer ?

et difficulte a savoir ce sur quoi tu bosses
exactement: en fonction du contexte, un nom de fonction t'envoies un peu
n'importe ou.

C'est le défaut d'une abstraction: ça te cache des détails en te
révellant seulement une interface. Après, si le code derrière l'interface
ne fait pas ce que décrit l'interface, c'est mal conçu.

J'aimerais bien des outils qui me permettent simplement de passer de l'un
a l'autre, d'une part parce que l'objet, ca peut etre lourd cote performances,
mais aussi et surtout, parce que c'est l'enfer a auditer (cote securite
par exemple)...

C'est vrai que je n'ai jamais entendu dire que la sécurité était une
préocupation de l'OO.

Marc Boyer
PS: cros-post + fu2
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0

En fait, je ne peux pas dire ce que je pourrais faire avec les
connaissances que je suis en train d'acquérir et surtout quel niveau
je peux prétendre atteindre. Au niveau des ressources, je suis
comptable de formation, j'ai la chance d'avoir un métier à plein temps
et de gagner un peu d'argent. Je fais en sorte d'éviter les
responsabilités professionnelles et personnelles pour pouvoir
apprendre à programmer tout en privilégiant le fait d'être en forme a u
travail.

Le principal souci comme beaucoup, c'est le temps. Je dois pouvoir
consacrer 4-6 heures de programmation effective par semaine et une
bonne dose de lecture de code chaque jour. Je pense consacrer 2 ou 3
années... Ca devrait correspondre à 20-25h par mois et
approximativement 500hr par an ou 250hr par semestre. Je crois c'est
le volume horaire d'une matière dans l'enseignement supérieur (travail
personnel compris). Mais une formation offre d'autres matières qui
forment un tout ou un cycle.

En tant que comptable, je dispose de connaissances qui devraient me
mener à la gestion de base de données. Je ne sais pas si certains
parmi vous connaissent le monde de la finance mais je crois savoir que
maintenant les ordres d'achats et de ventes (spéculation ou autre)
sont passés automatiquement par des ordinateurs voir l'article du
Canard du enchainé du 12 mai 2010 sur le High Frequency Trading, il y
a un côté hallucinant mais qui ne m'attire pas et je n'ai pas un
niveau en maths qui me permettrait de comprendre les modèles et lois
mathématiques appliqués de la finance, et puis jusqu'au lyçée, plus
les maths étaient abstrait, moins j'étais intéressé...il doit me
manquer quelques bases mais ça ne m'a pas empêché de me rattraper par
la suite quand c'est devenu plus concret avec des problèmes de la vie
de tout les jours qu'on peut avoir en statistiques avec la lois
binomiale, de poisson, normale, le calcul matriciel...

Je me dis que si je suis comptable, ça serait logique de rester dans
un domaine voisin (je crois qu'un langage comme Windev permet des
manipulations avec les bases de données, tout comme Php...).
J'utilise aussi Linux et je suis un peu "frustré" de ne pas pouvoir
accéder au code et programmer des périphériques... Je dois essayer de
rester cohérent surtout si je choisis un chemin plus court et que si
l'autre chemin est plus long, il sera moins probable que je trouverais
quelque chose...mais je suis très intéressé et prêt à passer plus ieurs
mois à pour par exemple comprendre le fonctionnement d'un port série.

heron maladroit :

Bonjour,
Ça fait quatre articles que vous envoyez sur fr.comp.objet, et à mon
avis vous n'êtes pas au courant...

(nota: j'ai placé le suivi un peu au pif sur fr.comp.objet, si vous ne
faites rien vos réponses apparaitront la bas)

Je me dis que si je suis comptable, ça serait logique de rester dans
un domaine voisin (je crois qu'un langage comme Windev permet des
manipulations avec les bases de données, tout comme Php...).

Quite à apprendre j'apprendrais un vrai langage. Parce que Windev ou php
bof.

Maintenant on peut tr^H^Hdiscuter sur ce qu'est un vrai langage !