# [OFF] Choisir un langage de script/code

## Enlight

Yop, ça fait quelques temps que je joue avec Bash et j'aimerai bien passer à autre chose.

J'ai regardé différents codes sources pour me faire une idée et voilà ce qui en est sorti:

-> python, totalement imperméable

-> ruby j'y ai cru en lisant le book mais arrivé au machin genre truc.bidule( gnarf, prout).chose( blah) j'ai senti la nausée arriver

-> perl m'a parru sympa mais les trucs genre `machin ->#&@!` on a l'impression de se faire insulter

La syntaxe du C pour le peu que j'en ai vu, j'aime bien, surtout la manière dont les fonctions et les structs sont envisagés. Par contre y'a vraiment beaucoup trop à apprendre pour le peu de temps libre que j'ai... puis vu que je suis du genre a pas aimer me relire ce serait chiant de lancer à chaque fois une compile pour se rendre compte que j'ai pas fermé une parenthèse   :Confused: 

Bref en gros si y'a un langage de script assez puissant, pas orienté objet (parceque j'y cale que dalle, j'ai été élevé au TI-Basic moi!!!), structuré mais avec un minimum de hiérogliphes qui vous vient à l'esprit, ce serait cool de m'en faire part.

----------

## _droop_

Salut,

Moi je te conseillerais quand même python (c'est le langage utilisé par portage), enfin ca te forcerait à apprendre quelques concepts sur les objets...

Sinon perl c'est très bien, pas dûr à apprendre, efficace... Par contre, la forme varie beaucoup selon les codeurs et ca peut devenir vraiment imbuvable si t'as pas l'habitude.

Voilà, j'espere que ca t'aide un peu...

----------

## ultrabug

Python sans hésitation !

C'est simple, fluide et terriblement puissant. Je te conseille ca pour y aller tout en douceur :

http://www.ulg.ac.be/cifen/inforef/swi/download/python_notes.pdf

Ensuite, ce sujet étant assez récurent, si tu as besoin de plus d'avis etc, je te conseille ce lien (du forum) :

https://forums.gentoo.org/viewtopic-t-363438-start-0-postdays-0-postorder-asc-highlight-livre+programmation.html

voila  :Smile: 

----------

## Trevoke

Tu connais cette chanson, je crois. Les Beatles ont fait une reprise "Let it Be"...  :Smile: 

 *Quote:*   

> When I find my code in tons of trouble,
> 
> Friends and colleagues come to me,
> 
> Speaking words of wisdom:
> ...

 

----------

## Enlight

Aaaaah Trevoke, tu viens d'egayer une journée de m..., mais j'ai du me mordre bien méchament pour pas péter de rire au boulot!

Tiens c'est vrai quid de lisp ou tcl?

----------

## lbr

Excellent lien dans ta signature Enlight, quelques JAVA-addict du boulot apprécieront !

----------

## Enlight

 *lbr wrote:*   

> Excellent lien dans ta signature Enlight, quelques JAVA-addict du boulot apprécieront !

 

 :Mr. Green:   :Mr. Green:   :Mr. Green: 

----------

## Bigneotux

Sinon, le CAML pourrait aussi t'intéresser, il est encore plus facile à appréhender que le python et c'est du pur bonheur à utiliser.

----------

## Enlight

 *Bigneotux wrote:*   

> Sinon, le CAML pourrait aussi t'intéresser, il est encore plus facile à appréhender que le python et c'est du pur bonheur à utiliser.

 

Ah? et c'est scripté ou compilé??? Il me semble que kernel_senseï m'en avait dit grand mal.

----------

## Bigneotux

On peut le compiler, ou faire des scripts, ou le compiler en byte-code.

J'ai oublié de préciser que j'utilise OCaml, qui est une variante qui ajoute le support des objets à Caml.

----------

## billiob

Et le TCL/TK ? Sinon, CAML est pas mal, je l'apprends au bahut, mais il assez dur pour débuter car il est très strict  (mais c'est peut-être une vision scolaire que j'ai). 

Mais faudrait surtout voir quels sont tes projets de code !

----------

## Enlight

 *billiob wrote:*   

> Et le TCL/TK ? Sinon, CAML est pas mal, je l'apprends au bahut, mais il assez dur pour débuter car il est très strict  (mais c'est peut-être une vision scolaire que j'ai). 
> 
> Mais faudrait surtout voir quels sont tes projets de code !

 

Tout ce qui concernerait l'administration système, j'ai envie de me uner une LFS avec des outils perso, donc je pense qu'il faudrait que je puisse manipuler des bases de données, tout ce qui est strings, sockets etc... si y'a des modules graphiques c'est pas de refus non plus.

pour ce qui est de tcl/tk, c'est comment? orienté objêt ou pas? En fait je comprends pas l'interêt de l'OO...

----------

## billiob

pour le tcl/tk, ça peut être orienté objet avec SNIT, sinon, c'est avec ça qu'on code aMSN, donc niveau interface graphique, c'est pas très beau !

Sinon, la gestion des sockets est interne à tcl, donc par rapport au réseau c'est pas mal.

Néanmoins, je pense qu'il faille que tu te tournes vers python qui a vraiment pas mal de possibilités (et pyGTK/QT pour une interface graphique).

----------

## scout

 *Enlight wrote:*   

> Bref en gros si y'a un langage de script assez puissant, pas orienté objet (parceque j'y cale que dalle, j'ai été élevé au TI-Basic moi!!!), structuré mais avec un minimum de hiérogliphes qui vous vient à l'esprit, ce serait cool de m'en faire part.

 

J'ai fait du RPL sur ma HP48, puis de l'assembleur quand j'étais petit.

Ensuite au lycée j'ai fait de mon côté un peu de C et de javascript.

En 1ere et en terminale j'ai suivi l'option info où on a fait du pascal et du delphi.

En prépa MP option info j'ai continué le pascal, et j'ai aussi fait du maple et du mathematica de mon côté.

En cours d'info en école d'ingé on m'a fait faire du Java, j'ai fait un peu de perl de mon côté.

puis en Ecole d'appli j'ai fait un bon paquet de C pour du traitement d'images. On m'a fait faire du lisp pour un cours d'IA

et cette année Sleeper m'a mis la puce à l'oreille au niveau de ruby.

J'ai jamais autant joui de ma vie de programmeur qu'en programmant en ruby. C'est tout ce que j'ai à dire.

Le deuxième truc le plus jouissif de tout ce que j'ai fait c'est Mathematica.

Le troisième c'était le RPL sur HP

J'ai jamais fait de Caml mais je pense que j'aurais bien aimé aussi.

Donc juste pour dire que la conception orientée objet c'est très très bien pour programmer. J'estime qu'en C tout le monde passe son temps à faire des structures pour imiter ce style. là où ruby et Mathematica et Caml font très fort, c'est au niveau des traits fonctionnels: la possibilité de jouer avec les fonctions comme avec les autres objets et entitées du language de programmation. ça te permet de passer des fonctions en argument à d'autres fonction.

Objet + traits fonctionnels = plaisir intense

si tu passes à coté de l'un des deux éléments de cette somme, ce serait vraiment dommage.

ruby et OCaml combinnent les deux.

je trouve qu'avec les languages de script en général on arrive très vite à faire quelquechose d'utile.

j'ai fait du ruby et du perl et le gros défaut du perl c'est que t'arrives pas à comprendre le programme que t'as fait le semaine dernière. En ruby, même les gens qui ne connaissent pas le language comprennent ce qui se passe.

Les autres languages ont tous leurs avantages respectifs, par exemple j'aime le C, mais il y a autant de différence entre mon amour pour le C et mon amour pour le ruby, qu'entre mon amour pour un 4x4 avec un gros moteur (un truc qui passe partout et qui roule vite sur l'autoroute, mais qui est chiant à garer en ville) et un mon amour pour kart (un truc qui va pas très vite mais ou t'as 1000 fois plus de sensations)

Tout dépends de si tu veux programmer pour prendre ton pied ou pour faire utile

----------

## zarasoustra17

Dans l'optique de l'administration système avec possibilité d'interface graphique, Python et Perl semble les mieux indiqués, d'ailleurs Gentoo utilise Python et Debian utilise Perl, maintenant rebol et ruby ont l'air sympa aussi...

Si tu ne tiens pas à faire de l'OO, rien ne t'y oblige pour ce que je sache (c'est à dire avec Python) mais une fois que tu commence à maîtriser, tu te demandes comment tu as pu t'en passer avant...

Personnellement, j'ai redécouvert la programmation avec Python et je trouve que c'est le meilleur langage pour apprendre, un des plus généralistes et des plus puissants pour plus tard, en plus tu peux le combiner avec du C, du C++, du Perl...

----------

## Enlight

Ben honnetement je pensais me mettre à ruby suite à des postes de sleeper et scout que j'avais déjà lu, mais je crois que c'est carrément au concept d'orienté objêt que j'ai besoin dêtre introduit... ça me dépasse vraiment.

je veux dire tu prends ton tuto de C et de ruby (un bouquin écrit par un mec un peu décalé avec plein d illustrations)...

déclarations de variables... ok

les mots clefs... ok

puis en C t'as tes libs, un coup de man tu sais à quoi ça sert et comment ça s'utilise, en ruby (où autre OO tu te fais assomer par des fonctions super louches   :Confused:  vraiment je cale pas   :Embarassed: 

Sinon bah en 1ère/T S et un peu en DPECF j'ai fait info aussi, j'ai d'ailleurs toujours du executer mes codes devant les profs incrédules pour qu'il m'enlève la bulle et m'accorde les points   :Twisted Evil:  par contre comme dit entre le droit et la compta/finance, on a pas vraiment été éduqué aux différents langages   :Sad: 

----------

## El_Goretto

Je sais pas si c'est encore en kiosque, mais ya un hors série du magasine login sur python ("pour débutant et initiés"). Je l'ai toujours pas sorti de son emballage, mais çà peu être une bonne intro (enfin, sauf si ya des bons tutos sur le net).

Pour le lisp, j'ai vu que tu en as parlé, et tout de suite, je dirais: non! J'ai quasiment été traumatisé par un prof qui voulait qu'on fasse tout en quasiment une ligne. Alors oui, c'est style, mais au delà d'un quintal de parenthèses pour 20 caractères alphanumériques, moi je craque.

Et franchement, l'OO, çà a l'air d'être une gros mot comme çà, mais çà peut se comprendre en qq minutes chrono. Après, la connaissance  les "libs" propres au langage que tu veux maitriser, çà vient avec la pratique (et le surf sur le net).

----------

## bong

Perso, je pense pas que l'OO puisse s'apprendre vite fait avec un tuto, il faut vraiment avoir quelqu'un pour t'expliquer ce que sont les concepts d'heritage, de polymorphisme, de specialisation, etc.. (les modules de genie logiciel que je vais manger au semestre prochain sont bien là pour me le rappeler   :Confused:  )

Disons que programmer en objet ne s'aborde pas du tout de la meme maniere qu'une programmation procedurale. En C, tu peux rapidement balancer des lignes de code pour obtenir un truc qui marche, si on fait pareil avec un langage objet, c'est mort et c'est là qu'intervient le langage de modelisation (uml pour les intimes) et là, le plus gros du boulot consiste à mettre en forme les interactions entre chaque classe, le codage represente moins de la moitié du temps necessaire a construire une appli...

Désolé pour cette tartine sans doutes pas très claire...   :Laughing: 

----------

## Enlight

 *bong wrote:*   

> Perso, je pense pas que l'OO puisse s'apprendre vite fait avec un tuto, il faut vraiment avoir quelqu'un pour t'expliquer [...]

 

Devine qui va s'y coller!   :Mr. Green:   :Mr. Green:   :Mr. Green: 

----------

## Dais

J'ai un peu touché à l'orioenté objet, et je ne considère pas que c'est les termes employés et leur principe qui posent problème à l'apprentissage ..

Non, je pense plutôt que c'est l'aspect concret de l'OO qui est difficile d'accès. On voit le principe, mais comment bien s'en servir dans le code de tous les jours ? Je ne doute pas de l'efficacité de la chose, mais des exemples concrets ça peut faire du bien quoi  :Razz: 

----------

## kopp

 *scout wrote:*   

> 
> 
> J'ai jamais autant joui de ma vie de programmeur qu'en programmant en ruby

 

 ... et oui, c'est bien triste une vie de programmeur....

désolé j'ai pas pu resister

vous inquitez pas, la porte est déjà ouverte et j'y vais tout seul comme un grand...

----------

## alctraz

 *Enlight wrote:*   

> -> perl m'a parru sympa mais les trucs genre `machin ->#&@!` on a l'impression de se faire insulter

 

Je trouve ca super utile moi, tu sais directement de quelle type de variable il s'agit. Ca peut parraitre plus lourd mais ca simplifie bcp la lecture du code, etc...

----------

## Trevoke

Apprends awk et sed.

Quand t'auras maitrise ca, *la* tu pourras passer a autre chose.

----------

## kwenspc

 *Enlight wrote:*   

> Tiens c'est vrai quid de lisp ou tcl?

 

lisp...lol comme langage de script on a déjà fait plus simple. C'est horrible ce langage. Y a que les vieux nerds à la RDS qui s'amusent encore avec. Franchement le concept est "marrant" (en se forcant un peu) mais ça va vite te gaver de faire de parenthèses. pi bon ce langage n'a d'interêt que si tu maîtrises la recursivité...chose qui est anti-productive (les cas en prod où on met de la recursivité sont TRES rares). enfin bref c'est à chier quoi.

tcl...y a encore des programmeurs en tcl?  :Laughing:  (pourtant c'est assez simple comme langage)

Sinon python c'est sympa. Mais sans plus. j'aime bien mais de là à avoir la trique...quand même pas. Jamais essayé ruby par contre. D'après ce qui s'entend ici et ailleurs, et ce qui se lit dans les journaux le ruby va faire bientôt sa ptite révolution (qui est en marche)...faut voir  :Mr. Green: 

mais bon c'est vrai le seul, le vrai comme langage c'est le C (l'asm à la rigueur)...    :Razz:  (oui je sais c'est pas des langages de scripts et alors?)

----------

## Syl20

 *alctraz wrote:*   

>  *Enlight wrote:*   -> perl m'a parru sympa mais les trucs genre `machin ->#&@!` on a l'impression de se faire insulter 
> 
> Je trouve ca super utile moi, tu sais directement de quelle type de variable il s'agit. Ca peut parraitre plus lourd mais ca simplifie bcp la lecture du code, etc...

 

+1.

A part le shell, je ne connais que perl, mais c'est justement une particularité que j'apprécie beaucoup.

A tel point que je suis en permanance obligé d'enlever des "$" dans mes scripts shell, quand j'utilise des variables... L'habitude.  :Embarassed: 

Inconvénients du perl :

- Si on est un peu bordélique, le code devient pénible à lire. Utilisation du module "strict" vivement conseillée.

- C'est un peu lourd, à l'exécution...

Avantages (par rapport au shell) :

- Orienté texte. Pour bosser en ligne de commande, c'est très pratique.

- La syntaxe est facile à comprendre. Plus facile en tout cas que awk.  :Laughing: 

- Les modules. C'est plus facile et rapide d'utiliser un module que de réinventer la poudre.

- C'est répandu. On trouve facilement de la doc et des exemples... Surtout pour des scripts CGI.

- Ca fonctionne partout. Pas besoin de gérer les différences de sorties de commandes quand on bosse sur plusieurs UNIX différents.

Pour les bases (un site que je consulte régulièrement, pour les expressions régulières, par exemple) :

http://www.ftls.org/fr/initiation/perl/

----------

## Starch

 *Dais wrote:*   

> J'ai un peu touché à l'orioenté objet, et je ne considère pas que c'est les termes employés et leur principe qui posent problème à l'apprentissage ..
> 
> Non, je pense plutôt que c'est l'aspect concret de l'OO qui est difficile d'accès. On voit le principe, mais comment bien s'en servir dans le code de tous les jours ? Je ne doute pas de l'efficacité de la chose, mais des exemples concrets ça peut faire du bien quoi 

 

Supposons un groupe de joyeux aventuriers : le Guerrier, le Voleur, l' Elfe.

Tous sont aventuriers, ils dérivent donc de la classe Aventurier.

Chacun a ses propres caractéristiques de vie, endurance etc...

Mais à la fin d'une partie, chacun gagne des points d'expériences, en fonction de ses propres caractéristiques.

Aventurier contient donc la méthode : gagneExperience(), surchargée par chacune des classes filles.

```

Aventurier[] aventuriers =  { new Guerrier(), new Voleur(),  new Elfe() };

for (int i = 0; i < 3; ++i)

  aventuriers[i].gagneExperience();

```

Si tu ne comprends pas ça, tu n'as pas compris la programmation orientée object.

PS : Pour la question à la base du post : Perl. Pour une raison. C'est standard sur quasiment toutes les plateformes Unix-like.

----------

## Enlight

 *Starch wrote:*   

> 
> 
> ```
> 
> Aventurier[] aventuriers =  { new Guerrier(), new Voleur(),  new Elfe() };
> ...

 

Où l'argc de gagneExperience = 1 et l'argv pointe sur aventurier[i], la fonction se contentant d'incrémenter aventurier[i] c'est bien ça? Si c'est bien ça je pense saisir le concept, mais je trouve ça laid et totalement contre-intuitif.

Je préfère alors un syntaxe à la perl genre variable = fonction(arg1,...,argn), ta syntaxe correspondait à quel langage?

----------

## scout

Pour reprendre un peu ce qu'expliquait Strach, la POO te permet d'écrire des fonctions plus lisibles et avec moins d'arguments pour le même boulot. Je m'explique: on pourrait écrire une fonction gagneExperienceGuerrier(Guerrier g); une gagneExperienceVoleur(Voleur v); et une gagneExperienceElfe(Elfe e); etc ...

ensuite si tu dois faire une fonction BattreContreUnMonstre, qui te fait te battre et te fait gagner de l'éxpérience, alors il va falloir appeller gagneExperience???? à la fin de ta fonction, reste à savoir laquelle ... donc tu va te taper un test du style: si c'ets un guerrier alors appeller la fonction associée, si c'est un elfe, etc ...

Ou alors tu écris une gagneExperience(Aventurier a); et tu teste si l'aventurier est un Guerrier, un voleur, etc ...

En POO, tout le monde descend de la classe Aventurier et tu n'as pas à faire de test sur le type: tu sais que ton gars réponds à un appel de gagneExperience qui est spécifique à chaque type d'aventurier et la bonne fonction sera appellée automatiquement.

Donc pour moi ça permet de donner des noms identiques à des fonctions qui effectuent le même type d'action, alors qu'en C t'es obligé de leur donner des noms différents si elles ne prennent pas les mêmes arguments.

Deuxième chose, si tu fais de gros projets, il y a forçément à un moment ou a un autre des fonctions qui prennent plein d'arguments. La solution c'est de grouper les arguments en structures, pour ne pas avoir des déclarations de fonctions à rallonge. La POO généralise cette pratique et l'utilise à tort et à travers pours AMHA une meilleur lisibilité des programmes.

----------

## bong

 *Enlight wrote:*   

> 
> 
> totalement contre-intuitif.

 

Scandale!

Si tu pense une chose pareille, tu n'est definitivement pas apte à programmer en objet.

Le but de l'exemple de Starch est de te montrer que la programmation objet met en avant le principe de specialisation et de delegation des taches.

ici, tu manipule trois instances de trois classes qui derivent d'aventurier.

Tous sont des aventurier et tous peuvent gagner de l'experience a leur maniere mais ce n'est pas ton probleme, tu lui dit juste qu'il en gagne.

Au contraire, moi je trouve ça hyper intuitif, mais moi c'est pas toi (philo inside   :Laughing:  )

----------

## Starch

 *Enlight wrote:*   

>  *Starch wrote:*   
> 
> ```
> 
> Aventurier[] aventuriers =  { new Guerrier(), new Voleur(),  new Elfe() };
> ...

 

Non. Ce qu'il faut bien saisir (mais c'est pas évident parce que je n'ai peut-être pas été assez clair), c'est que gagneExperience représente ici 3 méthodes bien distinctes, qui manipulent des attributs spécifiques à chaque classe, mais la signification de fonction est la même. (je sais je suis pas clair). Heureusement d'autres le sont plus ;p

L'idée derrière le concept de polymorphisme, c'est de faire la même chose, mais d'une manière différente.

----------

## marvin rouge

/me suit cette discussion avec bcp d'interet, parce que /me y comprend rien a la POO.

 *Starch wrote:*   

> Non. Ce qu'il faut bien saisir (mais c'est pas évident parce que je n'ai peut-être pas été assez clair), c'est que gagneExperience représente ici 3 méthodes bien distinctes, qui manipulent des attributs spécifiques à chaque classe, mais la signification de fonction est la même. 

 Et comment tu fais cette distinction ? tu fais un test pour chacun des aventuriers quand tu declares gagneExperience ?

Si je comprend bien ton exemple, on a une classe Aventurier, qui contiend certaines "methodes" (gagneExperience, meursViolemment ...) et ces methodes sont communes a toutes les classes filles : Guerrier, Elfe, Voleur.

Maintenant, supposons que j'ai 2 nouveaux aventurier: Sorcier et Mage. Tous les deux vont etre des classe filles de Aventurier, donc on va pouvoir leur attribuer gagneExperience (il faut rajouter 2 tests dans cette fonction pour determiner comment ils en gagnent). C'est ca ? 

Mais ces 2 nouveaux aventuriers, ils ont une propriete supplementaire: faireUneBouledeFeu, ce que ne peuvent pas faire Guerier, Elfe ou Voleur. Comment on s'en sort ? On fait une methode faireUneBouledeFeu() dans la classe Aventurier, ou bein on cree une classe fille de Aventurier (Magot) qui contient cette methode ... 

Hum, j'ai vraiment un probleme de vocabulaire.

----------

## Kangourou

Nop justement. En fait dans la classe Aventurier, la methode gagneExperience est seulement déclaré, pas défini. Tu la défini apres dans chaque classe fille. Pareil quand tu tu rajoute un sorcier, elle va etre encore une fois redefini dans cette classe.

Ensuite quand tu va arrivé sur:

```
aventuriers[i].gagneExperience();
```

 de l'exemple de tout a l'heure, si l'aventurier est un guerrier, c'eslt le gagneExperience de la classe aventurier qui sea executé, si c'est un sorcier, ca sera celle de la classe sorcier. Ca permet de donné un nom générique a une methode que tu devra executé quelques sois la classe fille, mais avec un code différents a l'interieur. Ca evite les tests pour voir la classe que tu a, puisque t'appelle toujours le même nom de méthode.

Quand à la boule de feu du sorcier, elle ne sera pas défini dans la classe aventurier et guerrier, seulement dans sorcier, comme toute les méthodes spécifiques à une classe.

J'espère que j'ai pas été trop flou   :Embarassed: 

----------

## kwenspc

eh ben ça a furieusement dévié!   :Smile: 

dites pour la POO y a plein de tutos sur le net...

----------

## Enlight

 *kwenspc wrote:*   

> eh ben ça a furieusement dévié!  
> 
> dites pour la POO y a plein de tutos sur le net...

 

Pas vraiment, en fait, si quelqu'un me convainc de l'intérêt de l'O.O. ce sera ruby, sinon perl. Je pense avoir à peu près saisi le concept, mais pour que notre (nos en fait) gagneExperience ai(en)t un intérêt, il(s) faut qu'il(s) 'utilise(nt) les attributs du {mage,guerrier,etc...}

mais :

1) l'utilité au quotidien me parrait limitée

2) pas besoin de langage O.O. pour faire un truc de ce genre

----------

## marvin rouge

 *Kangourou wrote:*   

> Nop justement. En fait dans la classe Aventurier, la methode gagneExperience est seulement déclaré, pas défini. Tu la défini apres dans chaque classe fille. Pareil quand tu tu rajoute un sorcier, elle va etre encore une fois redefini dans cette classe.
> 
> Ensuite quand tu va arrivé sur:
> 
> ```
> ...

 Rha, je crois que je comprends. C'est encore plus fort. Merci. 

 *kwenspc wrote:*   

> dites pour la POO y a plein de tutos sur le net...

 Oui, mais un tuto, tu lui poses une question pour savoir si t'as compris, et ben il repond pas ...

----------

## bong

 *Enlight wrote:*   

> 1) l'utilité au quotidien me parrait limitée
> 
> 2) pas besoin de langage O.O. pour faire un truc de ce genre

 

 :Crying or Very sad:  ARRGLL!! (cri étranglé d'horreur)

Bon, pour ne pas paraitre extremiste, je veux bien t'accorder que pour de petites applications, la poo n'est pas toujours utile mais des que l'on travaille sur un projet de plus grande envergure où l'on manipule beaucoup de données du même genre (j'entent par la: de la même famille mais qui different un peu) la poo est d'un grand secour.

Un autre exemple concret, par exemple un simulateur de circulation:

En pseudo C:

```

struct voiture{...}

avancer_voiture();

struct moto{...}

avancer_moto();

struct camion{...}

avancer_camion();

main{

    ...

    voitures[]; motos[]; camions[];

    for(...; i++){

        avancer_voiture(voitures[i]);

    }

    for(...; i++){

        avancer_moto(motos[i]);

    }

    for(...; i++){

        avancer_camion(camions[i]);

    }

}
```

C'est tres lourd car tu dois en permanence distinguer chaque type de donnee..

En peudo c++:

```

class vehicule{

    avancer();  //methode (fonction) vide a definir plus loin;

}

class voiture derive de vehicule{

    avancer(); //methode pour avancer la voiture

}

class moto derive de vehicule{

    avancer(); //methode pour avancer la moto

}

class camion derive de vehicule{

    avancer(); //idem!

}

main{

    vehicules[]; // contient n'importe quel type de vehicule..

    for(...; i++){

        vehicules[i].avancer();

    }

}
```

Au final, c'est tout de même bien plus comprehensible.....

----------

## Kangourou

Enlight, c'est vrai que pour faire un petit script la POO est pas vraiment utile, mais dès que t'a un truc un poil plus costaud, c'est quand même le jour est la nuit.  Je te conseille franchement d'y jeter un oeil, c'est vraiment tout benef   :Wink: 

Sinon j'ai tester Ruby à cause de vous, et je suis moi aussi tomber amoureux   :Embarassed:  Je sens que je vais m'y mettre sérieusement   :Very Happy: 

----------

## kwenspc

Oui et puis rien n'oblige de faire de la POO avec un langage qui à la base est OO. On peus très bien faire des scripts procédurals avec du ruby ou du python.

en plus python ça peut avoir un interêt sur le cv alors que perl...

----------

## Enlight

 *kwenspc wrote:*   

> ...
> 
> en plus python ça peut avoir un interêt sur le cv alors que perl...

 

Tu peux dévelloper stp? En même temps, vu ma profession je doute que ça apporte un grand plus mais sait-on jamais...

----------

## Starch

 *Enlight wrote:*   

> Je pense avoir à peu près saisi le concept, mais pour que notre (nos en fait) gagneExperience ai(en)t un intérêt, il(s) faut qu'il(s) 'utilise(nt) les attributs du {mage,guerrier,etc...}
> 
> 

 

Oui.

 *Enlight wrote:*   

> 
> 
> mais :
> 
> 1) l'utilité au quotidien me parrait limitée
> ...

 

Ca dépend ce que tu fais.

 *Enlight wrote:*   

> 
> 
> 2) pas besoin de langage O.O. pour faire un truc de ce genre
> 
> 

 

Certes... Mais bon faire de l'objet sans langage adapté c'est pénible.

Tu peux utiliser lex et yacc pour parser  un fichier, mais une bonne regexp est tellement plus pratique...

C'est dur d'appréhender le concept de polymorphisme au début. Mais ça t'évite les

```

switch (type) {

  case GUERRIER:

     {block}

     break;

  ...

```

Et l'héritage ? Je ne te parle pas du semi-elfe, qui hérite de Elfe et de Homme, qui en plus si il est à tendance Guerrier...

 *kwenspc wrote:*   

> 
> 
> en plus python ça peut avoir un interêt sur le cv alors que perl...
> 
> 

 

Pour Zope...

Mouais bon...

Faut le vouloir faire du web après... C'est vite lourd, chiant comme la mort, en utilisant un proto de merde totalement

inadapté aux applications qu'on veut lui faire faire.

</mode le_http_c_est_pourrave>

----------

## Bob_Le_Mou

Une chose est sûre : choisir un langage pour "scripter" c'est pas simple et dépend de tes besoins, de tes "goûts" en matière de programmation, etc.

Si je peux te donner un conseil au départ, choisis-en un et reste sur celui là. 

Plus tu le maitriseras, plus tes scripts seront efficaces et utiles.

Avec l'expérience, tu pourras jetter un coup d'oeil sur les autres langages.

perl (je connais plutôt bien), python (je connais un peu) , ou ruby (je connais pas du tout): tout ces langages offrent l'avantage d'être bien documenté et de disposer de larges communautés d'utilisateurs et de tutoriels d'excellente qualité ainsi que de larges eventails d'extensions (au sens générique du terme) qui te permettront d'enrichir pas mal tes scripts.

/my life

Pour ma part, j'utilise Perl pour 95% de mes réalisations sous Linux, et Windows (au boulot) et j'ai du mal à le lâcher.

Il est vrai que quelquefois, j'ai du mal à relire mes scripts. 

Mais, en prenant le temps de bien documenter et d'user voir d'abuser des commentaires on gagne un temps précieux d'une part à la relecture et d'autre part pendant la phase d'"apprentissage" du langage...

/my life

----------

## sireyessire

 *bong wrote:*   

>  *Enlight wrote:*   1) l'utilité au quotidien me parrait limitée
> 
> 2) pas besoin de langage O.O. pour faire un truc de ce genre 
> 
>  ARRGLL!! (cri étranglé d'horreur)
> ...

 

enfin personne ne t'oblige à définir plein de fonctions avancer() en C ...

tu peux en definir une qui prend un pointeur sur une struct de ton choix et qui a un champ type et après c'est qu'un switch() dans la fonction avancer() ce qui rend aussi le truc très lisible.

En fait c'est assez souvent l'histoire de "schtroumpf vert ou vert schtroumpf", le seul avantage de l'objet (même si je l'utilise vraiment très peu: C rules) c'est qu'un gros newb s'il suit les règles n'écrira pas un truc trop horrible, c'est tout.

en autre C:

```
struct vehicule {

char* type;

...

};

avancer(struct vehicule* V){

if(strcmp(vehicule->type,"voiture")==0){

do this;}

if(....
```

l'avantage de cette technique est que les differents avancer sont regroupés donc tu peux bien voir les différences, mais l'avantage de l'objet c'est que pour en rajouter un c'est juste une nouvelle classe à faire... donc chacun a son pour et son contre. En bref, unissez vous, et codez mieux!   :Wink: 

----------

## vishnoo

Enlight cherche un langage de script à la base, donc bon, les deux "universels" sont perl et python quand même.

Les deux sont très puissants (ils tendent même à se rapprocher au niveau du bytecode), offrent une base de programmes déjà faits importante (surtout perl avec CPAN je trouve) et permettent de faire bien plus que de simples scripts...

Alors maintenant, comment éviter le troll, hein ? Disons que la différences entre les deux est question d'esthète...

Pout "débuter" je trouve quand même que Python sera plus clair et structurant. Un bon lien là-dessus.

PS. pour l'aspect objet, chaque chose en son temps, non ?

----------

## Bob_Le_Mou

 *Quote:*   

> Les deux sont très puissants (ils tendent même à se rapprocher au niveau du bytecode), offrent une base de programmes déjà faits importante (surtout perl avec CPAN je trouve) et permettent de faire bien plus que de simples scripts... 

 

Tout a fait d'accord. 

 *Quote:*   

> Alors maintenant, comment éviter le troll, hein ? Disons que la différences entre les deux est question dle troll, hein ? Disons que la différences entre les deux est question d'esthète...
> 
> Pout "débuter" je trouve quand même que Python sera plus clair et structurant. 

 

Je serai un peu plus nuancé. Le souci (ou l'avantage) avec Python, c'est que tout est objet, et que enlight sera tout de suite confronté à l'assimilation des concepts de la programmation orienté objet, ce qui si on a pas le temps n'est pas forcément le plus évident.

Je trouve Perl pas forcément plus abordable, mais sa syntaxe reste classique, j'ose dire presque naturelle (j'ai osé  :Mr. Green:  ) si on pige 2 ou 3 trucs au départ, le tour est joué...

Mais bon, tu as raison c'est une question d'esthète...

----------

## Starch

 *sireyessire wrote:*   

> 
> 
> en autre C:
> 
> ```
> ...

 

Le désavantage c'est que si t'as une r11 et une 306, tu dois réécrire le code commun à voiture dans les deux...

----------

## sireyessire

 *Starch wrote:*   

> 
> 
> Le désavantage c'est que si t'as une r11 et une 306, tu dois réécrire le code commun à voiture dans les deux...

 

j'ai pas compris le problème là. tu peux faire un OU dans la condition du if.

----------

## Starch

 *sireyessire wrote:*   

>  *Starch wrote:*   
> 
> Le désavantage c'est que si t'as une r11 et une 306, tu dois réécrire le code commun à voiture dans les deux... 
> 
> j'ai pas compris le problème là. tu peux faire un OU dans la condition du if.

 

effectivement...

Je n'y avais pas pensé (1).

```

if (vehicule->type == voiture || vehicule->type == r11 || vehicule->type == 306)

  do this;

if (vehicule->type == r11)

  do that;

if (vehicle->type == 306)

  do this different that;

...

```

C'est sur que si on a 50 voitures, c'est optimal cette solution :/ (2)

[1] Ce n'est pas ironique.

[2] Là ça l'est.

----------

## Sleeper

 *kwenspc wrote:*   

> 
> 
> lisp...lol comme langage de script on a déjà fait plus simple. C'est horrible ce langage. Y a que les vieux nerds à la RDS qui s'amusent encore avec. Franchement le concept est "marrant" (en se forcant un peu) mais ça va vite te gaver de faire de parenthèses. pi bon ce langage n'a d'interêt que si tu maîtrises la recursivité...chose qui est anti-productive (les cas en prod où on met de la recursivité sont TRES rares). enfin bref c'est à chier quoi.
> 
> 

 

Lisp est tres bien .. Pas complique et beau .. Y'a encore que Ruby qui me plait autant ....

Quand a la recursivite, il faut voir de quelle recursivite tu parles .. terminale ou non-terminale ??? S'il est vrai que la recursivite non-terminale n'est pas utilisee il n'en est pas de meme de la terminale .. qui a l'avantage d'allier la simplicite d'ecriture aux oerfs  :Smile: 

 *Quote:*   

> 
> 
> mais bon c'est vrai le seul, le vrai comme langage c'est le C (l'asm à la rigueur)...    (oui je sais c'est pas des langages de scripts et alors?)

 

Un bon dev utilise l'outil qui va bien ... Utiliser le C opur des scripts qui vont massivement parser du texte ... est d'une inefficacite crasse en terme de temps de developpement ... et j'adore le C.

----------

## kernelsensei

Moi jusqu'à présent, j'ai fait uniquement du bash, mais là, suite a une discution avec scout, je me mets a ruby qui me parrait assez cool !

----------

## Enlight

Pour l'instant je suis parti sur Perl, mais j'ai l'impression de pas mal stagner, en même temps comme j'essaye de jouer avec socket bind et cie c'est un peu normal... la decouverte absolue, mais au moins le jour où je les réutilise en C je devrait pas être trop paumé.

----------

## Ey

 *Enlight wrote:*   

> Pour l'instant je suis parti sur Perl, mais j'ai l'impression de pas mal stagner, en même temps comme j'essaye de jouer avec socket bind et cie c'est un peu normal... la decouverte absolue, mais au moins le jour où je les réutilise en C je devrait pas être trop paumé.

 

Oui effectivement ça c'est pas vraiment ce pour quoi les langages de scripts sont fait.

Après c'est vrai que selon les cas ça peut être utile quand même mais bon, en première aproche ça se fait plutôt en C ou tout autre langage procédural qui est quand même beaucoup plus adapté à la programmation système (je précises procédural parce que j'ai eut un cours de programmation système où le prof était un mordu de ocaml, et je peux te dire que c'est vraiment contreproductif de faire des appels systèmes avec un langage fonctionnel...)

Bon sinon pour reprendre le sujet original, si tu veux faire des scripts, le principal c'est que la syntaxe et les concepts du langage ne te rebute pas trop. Après si je dois donner mes préférences c'est bash, perl, C ou C++ selon les cas.

- bash/perl pour des choses adaptées aux scripts : pas mal d'appels d'autres programmes avec des utilisation de redirection d'entrée sortie sans se fatiguer. bash est assez puissant et peu répondre à beaucoup de cas mais bon c'est vrai qu'il atteint ses limites et que perl dispose d'une librairie de modules très impressionnante.

- ensuite quand c'est pas vraiment adapté pour un script je passes au C/C++ (objet ou pas selon mon humeur en fait surtout...)

Après savoir si objet c'est mieux ou pas, je dirais simplement que selon ce que je codes le choix me parrait naturel mais si je devais essayer de rationnaliser disons que si j'ai des structures plutot évoluée je passes à de l'orienté objet (donc c++) parce que ça simplifie pas mal le boulot et ça évite de devoir se taper des fonctions avec des noms qui font soit 3 lignes soient sont imbitables... Par contre si les structures sont relativement simple et que le but est plutot d'être efficace là je reste en C parce que ça évite de compliquer sans vraiment de raison (je dis pas que l'orienté objet est forcément plus compliqué, simplement que l'approche quand on code en langage orienté objet à tendance à produire une architecture complexe qui n'est pas nécessaire dans ce cas précis.

Bon j'espère que j'ai été suffisament clair. Comment ça pas du tout ?  :Very Happy: 

----------

## ghoti

 *kernel_sensei wrote:*   

> Moi jusqu'à présent, j'ai fait uniquement du bash, mais là, suite a une discution avec scout, je me mets a ruby qui me parrait assez cool !

 

En effet, ruby, c'est amusant et au moins aussi puissant que perl et python réunis. 

Point de vue syntaxe, c'est assez proche de python mais sans en avoir les contraintes. Perso, je ne supporte pas python à cause de 2 bêtes choses :

1) les "blocs" qui ne se terminent pas : moi, il me faut un début et une fin et le marquage par indentation me trouble profondément ( sans doute trop habitué aux langages classiques  :Wink:  )

2) la nécessité d'indiquer le paramètre "self" dans la déclaration des méthodes, ce qui trahit sa "pseudo orientation objet".

Ruby n'a pas cette contrainte car c'est de l'oo pur et le pointeur est implicite.

Deux défauts tout de même :

- en raison de son origine japonaise, certaines docs ne sont accessibles que dans cette langue et pour moi c'est du chinois  :Wink: 

- cette même raison lui donne un certain retard de notoriété par rapport à python : la communauté ruby est extrêmement active mais relativement moins nombreuse que celle de python. Par contre, il semblerait qu'au japon, ruby a purement et simplement explosé python ...

----------

## kernelsensei

Bah, la doc en jap ça me fera bosser mon jap tout en faisant du ruby  :Wink: 

----------

## ghoti

Ah ben évidemment, si tu pratiques le soleillevant, d'amusant ça doit devenir panardesque !

Encore un petit bémol tout de même, juste pour jouer l'avocat du diable : je sais, c'est paranoïaque mais il me semble parfois que c'est fort "orienté ouinouin". 

Impression ou ...   :Question: 

----------

