Citation: Pour moi je n'ai pas de nom, mais une liste de qualités qui
existent ou n'existent pas encore:
C'est parfait, c'est le type de réponse que j'attendais.
* pourquoi pas un langage qui peut faire machine virtuelle et
compilation native selon les choix ?
Est-ce que quelqu'un y a seulement pensé ?
Mais bon sang, n'y a-t-il que moi qui réfléchi dans ce monde de brutes ?
Je ne sais pas si c'est techniquement possible, ça. Et quel serait
l'intérêt ?
* le côté multiplateforme serait également très apprécié; de préférence
sans les particularités que j'ai découvert avec le python du genre: si
tu es sur linux, il y a telle ligne que tu dois ajouter au début de
chacun de tes fichiers, ou si tu es sur windows tu dois faire gaffe au
win32 en ajoutant telle
ou telle installation particulière, etc...
Et sur ce plan, il me semble que le pure basic a fait pas mal d'effort
qu'il faudrait ne pas oublier de louer.
Ca je pense q'un moment donné, malheureusement, c'est inévitable. IL y a
trop de différences entre les systèmes.
Si tu veux vraiment que ça fonctionne sans différence, alors tu es
obligé de prendre la logique java: un tronc commun plus ou moins
conséquent qui gomme toutes les différences. Là où java pourrait être
amélioré, c'est que le dit tronc commun ne soit pas monolythique et que
seules les parties utilisées soient inclues dans le programme compilé.
GCC a essayé avec son compilateur pour java qui s'appelle GCJ, mais
c'est un échec, le tronc commun est trop gros et trop monolythique pour
que ça fonctionne bien.
* Insensible à la cass. Pour moi c'est primordial. Cela fait un soucis
de moins quand on programme. Je tiens à éviter les cheveux blancs le
plus longtemps possible.
Ca c'est un point de vue de syntaxe avec lequel j'ai déjà dit que je
n'étais pas d'accord, prétextant l'habitude. Mais ça se défend.
* surtout pas d'accolade... Pitié... en tout cas, pas pour délimiter les
blocks de code. Car, j'en ai marre des codes spaguettis.
C'est bizarre, moi c'est l'inverse de toi. J'ai l'impression que les
codes sont d'autant plus spaghetti dans les langages à la begin/end. Le
then obligatoire après un if même quand il n'y a qu'une seule
instruction en lua par exemple, ça me saoule, et ça me donne
l'impression d'avoir du code encore plus spaghetti parce que du coup je
ne sais que faire de ces 12 end qui se suivent.
De nouveau, c'est sûrement juste une histoire d'habitude.
* qui offre plusieurs façon de faire les choses, qu'on ne soit pas
obligé par exemple de passer par uniquement les expressions régulières
pour faire de la recherche de texte, ou par les DataTables pour savoir
quelle est la liste des tables d'une base de données. Confert lua,
confert .net.
Dans ce domaine, c'est ruby qui devrait te plaire, leur philosophie de
base est de te laisser le choix de faire parmi plein de possibles.
ET le fameux perl avec la citation historique de son créateur: tehre's
more than one way to do it (il y a plus d'une façon de le faire)
Point commun, les deux sont à fond dans les regex !
A noter que les regex, c'est aussi un truc qu'il faut apprivoiser. C'est
assurément pas quelque chose de facile à prendre en main, mais une fois
qu'on en a l'habitude, on a envie de les mettre partout, parce que ça
permet juste de résoudre à peu près tous les problèmes de manipulation
de texte qu'on peut avoir beaucoup plus facilement que de penser en
terme de procédural, de conditions et de substring/concaténation.
* le dynamisme dans les déclaration. Qu'on puisse en cours d'exécution,
créer une fonction, un objet, une classe, voir une API...
Dans les langage interprétés, cela peut se faire en bidouillant, mais je
n'ai pas connaissance d'un langage qui ailles aussi loin.
Ce serait selon moi le langage ultime pour créer une véritable
intelligence artificielle, le rêve de tout programmeur fou.
Créer des API et des fonctions à la volée, tu peux dans pas mal de
langages interprétés. Pour le coup, php a un truc bien, tu peux faire à
peu près ce que tu veux avec une série de méthodes/fonctions magiques.
Et avec les langages dit objets à prototype comme lua et javascript, tu
peux personnaliser tes objets un par un si tu veux, pour qu'ils aient un
comportement spécifique ou pour les faire coller à une API précise.
C'est un des gros avantages des langages objets à prototype.
* des bibliothèques qui font le café... ou presque. Qui permettent de
manipuler le plus bas niveau comme le plus haut niveau.
Comme par exemple faire souffler les ventilateurs à un instant t pour
lever la jupe de la secrétaire.
Les bibliothèques, gros débat aussi. C'est sûr qu'un langage sans bonnes
bibliothèques, ce n'est plus grand chose aujourd'hui.
Idéalement, on ne devrait pas choisir tel ou tel langage parce qu'il a
telle bibliothèque qu'il n'y a pas dans un autre langage, mais il faut
reconnaître que ce n'est pas facile !
* multiparadigme. Pour ma part je choisirais : procédural, modulaire,
orienté objet, et fonctionnel. Rien que ça.
C'est aussi 4 qualités que je tiens à avoir: à la fois du procédural et
de l'objet, une petite pointe de fonctionnel, et le tout suffisament
modulaire bien entendu.
* qui n'oblige pas à faire des déclaration de prototypes de fonctions.
C'est un truc que je n'ai jamais compris.
Pourquoi nous faire ch... à le faire quand le compilateur peut
simplement scanner notre code pour en créer une liste ?
Deux remarques à ce propos.
La première, c'est qu'une liste de prototypes, ça peut être drôlement
utile pour construire une API et la diffuser sans être obligé de publier
tout le code.
Par exemple si je prends une bibliothèque comme QT, WXWidgets, FMOD,
BASS..., je veux pouvoir te la vendre sans pour autant que tu puisses
modifier mon code. Pour que tu puisses l'utiliser, il faut que je te
fournisse une liste des fonctions utilisables, mais pas le code des
dites fonctions parce que sinon, tu n'aurais pas besoin de l'acheter car
tu pourrais refaire la tienne.
Dans les langages où on n'a pas clairement cette séparation, c'est
compliqué. Par exemple si je veux te vendre une bibliothèque en python,
je peux bien de passer les fichiers .pyc, python n'y trouvera aucun
inconvénient, mais si tu veux tu peux facilement les décompiler,
retrouver quasiment le code source original, et du coup après tu fais ce
que tu veux et tu n'as plus besoin de moi. Et en plus, je dois faire une
documentation de chaque fonction séparément... pas forcément pratique.
IL y a plein de bibliothèques C/C++ où les fichiers .h qui contiennent
les prototypes font aussi office de documentation directement, et ça
suffit très bien.
* une documentation disponible et compréhensible. Dans certaines
documentations, on a l'impression de lire des philosophes.
A ce demander si le but est d'être compris ou de nous embrouiller.
Tu peux développer ? Je ne vois pas trop qui tu vises et où tu veux en
venir avec ça.
Progliste :
Pour se désinscrire de la liste :
mailto:[email protected]?subject=unsubscribe
Pour voir les archives de la liste :
http://www.mail-archive.com/[email protected]/
Je vous rappelle que les pièces jointe sont activés leur taille est limité à 2 MO
Pour accéder aux fichiers de la liste
http://outils.archive-host.com/partage.php?id=2Qar9Hy6ftzr
Ou en utilisant la nouvelle page de partage :
http://outils-n.archive-host.com/partage-fm0m7b947vglikp9Efpso94gt
Pour y ajouter des fichiers demandez-moi le ou sur la liste ou en privé, je
vous répondrez en privé.
