Feelin : Soumission de syntaxe
-
Gofromiel a écrit :
Cela dit, et au risque de me faire taper sur les doigts (je m’en fiche j’en ai plein), le C++ ça à pas l’air bien-bien. Je n’ai vu aucun gros projet l’utiliser pour son développement, et je parle de Cairo, GTK+, Gimp ou Firefox. Bon je vois que ceux là, mais c’est déjà pas mal. On dirait que le problème vient de la portabilité… ou alors les gens n’aiment pas le C++ et barka.
Au boulôt, j’ai écrit une appli. dans le domaine de la santé entierement en C++ et franchement content de ne pas avoir été obliger de le faire en C. La puissance du modèle objet m’a été grandement utile.
Perso j’aime beaucoup le Javascript et le PHP, mais alors c’est à des années lumière de langages propres et soyeux
Effectivement le mélange code dans l’interface HTML…
En parlant de Feelin, des nouvelle du portage MOS ?
Sur Feelin.fr, il n’y a pas de version MOS et comme la dernière version date de novembre, est il prévue une prochaine release avec une verion MOS ?
@vince: Je suis bien d’accord ! Après 6 mois de distance avec Feelin pour cause de création de travail, je m’y remets tout doucement, et même si cela ne sert à rien en ces temps de CoreDuo2, ça fait toujours plaisir de programmer et d’utiliser l’AmigaOS, même sous WinUAE (surtout sous WinUAE en fait).(surtout que j’ai consolidé le système de compilation et qu’il me faut un cobaye)
Je peut être le cobaye si tu veux…
A++ Vince.
C’est amusant comme certains pensent qu’un langage orienté objet est une condition nécessaire (et suffisante ?) à faire de la programmation objet. Je ne vise personne en particulier
Tu as tout à fait raison il n’est pas nécessaire d’avoir un langage objet pour faire de l’objet… Tout comme tu peux te servir de ton couteau comme d’un tourne-vis ou de ta tasse à café comme d’un marteau, ceci dit avoir le bon outils pour le bon travail ça aide quand même
« One point » pour Alex
Moi je suis pas contre les langages objets (enfin sauf le C++, mais trop long a dire pourquoi ici). Mais faut pas tout melange.
Je suis contre les developpeurs qui ne savent pas utiliser leurs outils.
D’ou l’extension suivante a la remarque d’Alex:
Ce n’est pas son outil qu’on mesure la competance de l’ouvrier.
Oui enfin, sauf que programmer objet en C, ce n’est en rien du bricolage.
Faut tout de même un peu jouer au McGyver pou pouvoir avoir des fonctionnalités qui sont déjà de base dans un langage objet : polymorphisme avec vérification de type, surchage des méthodes, héritage simple, héritage multiple, héritage public, privé et protégé, restriction de visibilité des variables et fonctions membres, etc… Bref tou ça existe *de base* dans les langages objets, le programmeur n’a pas à le coder pour l’avoir. Mais c’est possible… Autant que de programmer en assembleur en C++, c’est juste un peu plus difficile à mettre en oeuvre.
Tiens pour la petite anecdote au début les compilateurs C++ se contentaient de générer du code C qu’il fallait ensuite compiler avec son compilateur C standard. C’étaient des sortes de précompilateur
Alors coté débugguage, le C++ remporte la palme de l’obfuscation, sur tous les plans : noms de variables décorés, méthodes virtuelles, exceptions, polymorphisme et autres surcharges d’opérateur qui peuvent facilement brouiller les pistes lors d’une relecture/débugguage du code. On n’évoquera pas ceux qui abusent de l’écriture complète du code dans les headers au lieu de n’exposer que l’interface des classes. En fait, le C++ est un bon choix pour une personne qui veut vraiment conserver son job et s’assurer que personne ne pourra jamais reprendre son projet et ainsi le remplacer.
Et sans rapport direct, j’adore aussi obtenir 100 pages de log d’erreurs pour une petite erreur de frappe liée à une variable utilisant les templates (d’ailleurs c’est tellement imbuvable que certains ont écrit des « filtreurs » de messages d’erreurs
).Et pour être bien clair, je ne déteste pas le C++ et je le pratique tous les jours, mais de là à dire qu’on gagne du temps avec, je trouve que le pas est un peu grand.
Bon, alors un petit module Python pour Feelin, ça vous dit pas ? En plus c’est orienté objet, le Python
Fab1 a écrit :
Alors coté débugguage, le C++ remporte la palme de l’obfuscation, sur tous les plans : noms de variables décorés, méthodes virtuelles, exceptions, polymorphisme et autres surcharges d’opérateur qui peuvent facilement brouiller les pistes lors d’une relecture/débugguage du code. On n’évoquera pas ceux qui abusent de l’écriture complète du code dans les headers au lieu de n’exposer que l’interface des classes. En fait, le C++ est un bon choix pour une personne qui veut vraiment conserver son job et s’assurer que personne ne pourra jamais reprendre son projet et ainsi le remplacer.
Et sans rapport direct, j’adore aussi obtenir 100 pages de log d’erreurs pour une petite erreur de frappe liée à une variable utilisant les templates (d’ailleurs c’est tellement imbuvable que certains ont écrit des « filtreurs » de messages d’erreurs
).Et pour être bien clair, je ne déteste pas le C++ et je le pratique tous les jours, mais de là à dire qu’on gagne du temps avec, je trouve que le pas est un peu grand.
Ah, encore l’héternel débat toujours aussi passionné autour des languages…
Pour moi, un langague restera toujours un outil et que ce soit C, C++, C# ou C–
de toute facon il y aura toujours moyen d’écrire du code lisible ou illisible (macros, templates et autres plaisirs…).Comme disais mon père :’Met la tête avant les outils’.
Tout est une question de méthodologies et de documentations.
Le bon outil au bon moment fera toujours gagner du temps.
Ce ne sera jamais l’outils qui fera la qualité du code mais l’utilisation qu’en fera le codeur.
Sur cela, merci de ce débat qui nous rajeunis de 10 ans
Comment débogues-tu ? Avec un action-replay qui désassemble le code
?Les noms de variable décorés tu le vois pas si tu as un débogueur digne de ce nom (d’ailleurs j’en connais pas qui ne le gère pas).
Les méthodes virtuelles je vois pas le problème avec un débogueur tu vois le code qu’il exécute et donc la méthode appelée soit-elle virtuelle ou non d’ailleurs.
C’est pareil pour le polymorphisme d’ailleurs et les surcharges d’opérateurs.
L’histoire du code dans les fichiers d’entête si le type est un porc il fera la même chose en C….
Et sans rapport direct, j’adore aussi obtenir 100 pages de log d’erreurs pour une petite erreur de frappe liée à une variable utilisant les templates (d’ailleurs c’est tellement imbuvable que certains ont écrit des « filtreurs » de messages d’erreurs
).Tu programmerais pas sous VS6 toi par hasard
? Parce que effectivement le compilateur C++ n’est pas un modèle du genre et la STL fournie est plus que questionnable (d’ailleurs on se demande s’ils ne l’on pas fait exprès pour pas qu’on l’utilise M’enfin bon on est vraiment hors-sujet là : au début le fil portait sur la syntaxe dans Feelin :sweat:
Tiens pour relancer un autre hors-sujet je vois que Centaurz parle d’un module Feelin pour Python, ne connaissant pas bien Python (ma dernière pratique de ce langage fut à ses débuts en 2000 c’est vous dire
j’aimerais savoir si vous pensez qu’il serait possible de faire une implémentation de TkInter qui utiliserait GadTools/Feelin/Reaction/MUI ? Je veux dire par là ne conserver que les APIs et réécrire tout ce qui va derrière.EDIT : quand un type est un « porc » ça s’écrit avec un ‘c’ et non un ‘t’
Alex,
j’ai l’habitude de lire le code avant de lancer systématiquement le debuggueur, mais tu as raison, en C++, il n’y a souvent qu’en lançant le debuggueur qu’on sait quels pièges l’auteur a placé tout au long du source.
Sinon je code sous vc++6 oui, mais aussi sous gcc(2,3,4) et c’est pas vraiment mieux côté messages d’erreur (mais oui, c’est toujours mieux que vc++, la stl est plus ou moins conforme, et le compilateur aussi, selon les versions…
).Fin du HS!
Fin du HS!
Optimiste va !
Sinon pour les cobayes (merci à eux), je termine le nettoyage de la version courante et je mets ça sur mon site. Faites chauffer vos compilateurs !
++
- Vous devez être connecté pour répondre à ce sujet.
