🚀 go-pugleaf

blc wrote:
> Bruno Desthuilliers wrote:
> 
>> blc wrote:
>>
>> C'est tr�s vrai. C'est pour �a qu'apr�s avoir appris Python, langage 
>> de haut niveau multi-paradigme (imperatif/fonctionnel et 
>> procedural/objet, les deux grands axes), l'OP n'aura pas de 
>> difficult�s majeures � apprendre le C, langage de bas niveau, purement 
>> imp�ratif et purement proc�dural, dont la syntaxe est l'une des plus 
>> simples qui soient.
> 
> Mais qui contient des choses compliquees qui apparemment ne font pas 
> partie de Python..enfin je pense...

Les pointeurs et la gestion manuelle de la m�moire... A part �a, je ne 
vois pas. Par contre, il y a pas mal de choses en Python qui n'existent 
pas en C, et sont tout sauf �vidente � mettre en oeuvre en C... sauf � 
utiliser le C pour impl�menter un langage de plus haut niveau !-)

>> Dis, tu connais Python ? 
> 
> Ben non...mais je devrais, je sais...

Bin... disons que pour en parler, ce serait mieux !-)

> 
>> Le fait qu'il excelle comme langage de script ne l'emp�che pas d'�tre 
>> un langage g�n�raliste complet.
> 
> Je n'ai jamais dis qu'un langage de script etait forcement incomplet...

Je cite:
""" Les langages de script (la plupart) passent sous silence la plupart 
des concepts fondamentaux de la programmation """

>>
>> 1/ Combien peux-tu me citer de langages de programmation dans lesquels 
>> la notion de variable n'existe pas ?
> 
> En fait, je voulais parler de la declaration de variable qui n'est pas 
> obligatoire dans la PLUPART des langages de script...
La d�claration de variable n'a de sens que dans les langages � typage 
statique. Une des caract�ristique des langages de haut niveau - et le 
moins qu'on puisse attendre d'un langage utilis� pour du script est 
d'�tre un langage de haut niveau - est d'avoir un typage dynamique. La 
d�claration des variables n'a donc aucun sens dans ce contexte.

>> 2/ Le typage en Python est beaucoup plus fort qu'en C.
> 
> ??? Je voulais dire que tu peux utiliser des variables sans meme les 
> avoir declarees ce qui me gene un peu...

Pourquoi ? Ca te fait peur ? L'exp�rience semble prouver que les bugs 
d�s � des erreurs de typage sont non seulement parmi les moins courants, 
mais aussi parmi les plus simple � rep�rer et � corriger. Le sage l'a 
dit : "s'il suffisait de d�clarer trois fois les variables pour avoir 
des programmes corrects, je m'y plierais volontier".

> Mais c'est peut etre faux pour 
> Python

Non, Python est un langage � typage dynamique. Donc pas de d�claration 
pr�alable des variables. Moi aussi �a me faisait douter du s�rieux de ce 
langage quand je ne connaissais que des langages � typage statique. Une 
fois qu'on comprend cette philosophie (typage dynamique *fort*), par 
contre, on voit vite le gain de souplesse et de productivit� qu'elle offre.

Attention, par contre, typage dynamique ne veut pas dire typage faible. 
Le principe est que le type est li� � l'objet, pas � l'identifiant. On 
peut donc effectivement lier n'importe quel type d'objet � un 
identifiant. Par contre, on ne peut appeler sur un objet que des 
op�rations correspondant � son type.

Par contraste, en C, le typage statique n'emp�che pas de forcer un 
transtypage. Ce n'est donc pas un typage si fort que �a...

  #include <stdlib.h>

typedef struct {
     int num;
} Toto;

typedef struct {
     char* num;
     Toto *truc;
} Tata;

int main(void)
{
     Tata *tata = NULL;
     Toto *toto = malloc(sizeof *toto);
     toto->num = 42;
     tata = (Tata *)toto;
     return 0;
}

pas d'erreur de compilation avec �a chez moi (gcc 3.2.2, compil� avec 
gcc -Wall -ansi -pedantic -O2 )

Par contre, � l'ex�cution, �a segfault un peu...

>> 3/ La gestion manuelle de la m�moire n'est en rien un 'concept 
>> fondamental' de la programmation. Il y a d'ailleurs relativement peu 
>> de langages - et aucun langage un tant soit peu r�cent - o� la gestion 
>> de la m�moire soit � la charge du programmeur. 
> 
> En C/C++ tu peux faire un peu ce que tu veux je pense...

??? Pas compris, l� ???

>>> Avec un langage de script, on fait les choses vite et mal.... 
>>
>> Ah bon ? Toi peut-�tre, mais ne g�n�ralise pas STP. Un programmeur 
>> s�rieux travaille s�rieusement quelque soit le langage.
> 
> Mon idee c'est qu'un langage de script est trop permissif

Le C est un des langages les plus permissifs qui soit. Rien en C ne 
t'emp�che d'aller lire ou �crire n'importe quel segment de m�moire (avec 
des r�sultats pour le moins impr�visibles), ni de faire passer un Toto* 
pour un Tata* si tu le veux.

Si tu veux un langage peu permissif, c'est ADA qu'il te faut. Et m�me 
avec un langage aussi strict, on peut crasher un fus�e.

> et "corrige" 
> des trucs sans meme nous le dire....

Corrige quoi ?-)

> encore une fois, ce n'est peut etre 
> pas le cas pour Python...

Si tu pense aux entiers qui deviennent des chaines et r�ciproquement en 
fonction du contexte, Python ne fait pas ce genre de choses. C'est un 
langage � typage fort, et si tu tente d'additionner 'toto' et 42, tu 
aura une erreur d'ex�cution. PHP le permet, et c'est AMHA une erreur 
effectivement (je n'aime pas non plus ce genre de typages faibles). 
Encore que pour le moment, �a ne m'ait pas caus� de probl�mes dans mes 
scripts PHP. Je ne sais pas comment fonctionnent Perl et Ruby de ce 
point de vue.

>> Le propre d'un UB, c'est que tout peut arriver - m�me que le programme 
>> *semble* fonctionner. Le fait que le programme semble fonctionner 
>> n'est en rien une preuve de correction. Quant � 'pas si mal', c'est 
>> une norme de qualit� que j'ignorais jusque l�...
> 
> Et pourtant, qd tu as une deadline et que l'on te demande de faire un 
> truc qui fait des choses..tu dis quoi a ton patron??

Que c'est lui le patron, mais que c'est une connerie qui nous retombera 
sur la gueule � un moment ou � un autre.

> Desole, je pourrais effectivement le faire mais je prefere tout bien 
> coder propre et rendre mon truc dans 2 semaines quitte a perdre le 
> client?? 

J'aurais tendance � penser que tu perds plus facilement un client en 
annon�ant des d�lais ing�rables et en lui livrant un paquet de bugs 
qu'en annon�ant un d�lai raisonnable et un livrant un code peut-�tre pas 
100% bullet-proof, mais au moins d�cemment robuste et ais�ment maintenable.

A chaque fois que j'ai pu obtenir un d�lai raisonnable, m�me si un peu 
sup�rieur aux d�sirs du client, le client a �t� finalement satisfait de 
se voir livrer quelque chose de s�rieux.

A chaque fois que le point de vue du patron et/ou du client a pr�valu, 
le temps pass� � corriger les bugs et les erreurs de conception de la 
version Q&D a �t� �gal ou sup�rieur au temps qu'il aurait fallu pour 
coder proprement d�s le d�but. Le client n'a donc pas pu utiliser le 
produit plus t�t, et en plus il �tait f�ch�.

Le probl�me est de faire l'�ducation des patrons et des clients. H�las, 
ce n'est pas gagn� :(

> Sincerement, je serais enormement etonne qu'a un moment ou a un 
> autre tu ne te sois pas surpris a coder comme un cochon pour gagner du 
> temps par manque de temps..;-)

Je n'ai pas dit �a, et j'ai souvent h�las �t� oblig� de livrer du code 
malpropre - avec g�n�ralement les r�sultats �voqu�s ci-dessus.

Par contre, je ne consid�re pas �a comme une norme de qualit�. Et avec 
un langage comme le C, o� il n'y a justement aucun garde-fou, le concept 
de '�a semble marcher' ne me satisfait gu�re, puisque je ne sais 
r�ellement pas ce qui peut arriver en cas d'UB... bon, g�n�ralement on a 
soit des r�sultats al�atoires, avec un bug dur � tracer, soit un 
segfault franc et massif. Mais dans d'autres contextes - embarqu�, par 
exemple - ce pourrait avoir des cons�quences plus lourdes.

>> Avant de d�crire Python comme un langage "jouet", 
> 
> Je parlais des langages de scripts en general Et tu conviendras que a 
> part python (que je ne connais toujours pas depuis le debut du post),

Tu devrais, pourtant !-) Allez hop, au boulot :
http://www.python.org

> souvent il ressemble a ca...

A quels langages pense-tu ?

>> utilise le pendant quelques mois. On en reparlera � ce moment l�. Ou 
>> va demander aux d�veloppeurs de Zope pourquoi ils utilisent un langage 
>> "jouet" pour d�velopper un serveur d'application.
>>
>> Quant aux mauvaises habitudes, on peut les prendre avec n'importe quel 
>> langage. Encore une fois, c'est plus un probl�me de s�rieux que de 
>> langage.
> 
> Si le langage ne te force pas a etre serieux....c'est plus facile de ne 
> pas l'etre, c'est uniquement ce que je voulais dire. 

Dans ce cas, c'est ADA qu'il faut conseiller, pas le C !-)
Ce qui n'a pas emp�ch� un module en ADA de crasher une fus�e europ�enne 
bien connue.

> Maintenant, si je 
> t'ai fait du mal en critiquant indirectement Python, je suis desole..,-)

Tu ne m'a pas fait mal !-)

Non, ce qui me f�che est ce discours selon lequel un langage de haut 
niveau ne serait pas un langage s�rieux. Avec ce type d'arguments, on 
devrait tout programmer en assembleur ou en langage machine !-)

Il existe effectivement des langages 'jouet', et qui revendiquent ce 
statut (je te recommande Brainf**k, c'est assez farce).

Par contre, le fait qu'un langage soit r�ellement un langage de haut 
niveau (en terme d'abstraction) n'en fait pas un jouet, bien au 
contraire. Dans la majorit� des cas, le temps d'un d�veloppeur est plus 
pr�cieux que le temps machine. Il est donc pr�f�rable de sacrifier un 
peu de performance machine au profit de la productivit� du d�veloppeur.

De plus, dans mon domaine (informatique de gestion), les probl�mes de 
perf sont plus souvent li�s au SGBDR, � l'interface graphique ou au 
r�seau. Pour le premier cas, � part faire du SQL correct et travailler 
sur la structure de la base - ou au pirte changer de SGBDR - il n'y pas 
beaucoups de solutions. Pour les deux autres, les langages de haut 
niveau s'appuient g�n�ralement sur des biblioth�ques en C ou C++, donc 
les performances sont quasiment �quivalentes.

Je ne pr�tend pas que Python (ou Common Lisp, ou Ruby, etc) soient la 
panac�e. Aucun outil n'est r�ellement universel. Il ne me viendrais pas 
� l'id�e de proposer Python pour de la prog syst�me ou de l'embarqu�.

Bon, l� dessus �a devient plus que limite HS pour ce ng, donc x-post et 
fu2 vers f.c.dev

Bruno