[F] [mOved] Mon langage est mieux que le tien - Page 5

Je crois que je n'ai jamais aussi bien choisi un nom de topic pour un fork

Bien vu, et je crois que j'ai jamais vu un fork marcher si bien. D'ailleurs, sur ce forum, c'est vraiment étonnant que ça n'ait pas eu lieu plus tôt.
Et j'en garde en réserve pour la suite, j'ai passé mon après-midi à éplucher la doc de CMake, je me demande s'il en a vraiment une plus grosse que Make. A voir.

Et j'ai lu toute la doc de KDevelop aussi (qui utilise CMake par défaut (comme tout KDE)), comme ça je peux organiser un véritable championnat du monde de la e-biroute à la maison, avec d'un côté les langages, d'un autre les IDE (C::B vs Codelite vs Kdevelop), et enfin les build-systems (Make vs CMake vs Autotools vs build-systems maison de C::B ou encore Codelite).

Elle est pas belle la vie ??

Attention à l'indigestion, tout de même ^^

(cmake génère les makefiles ou équivalents, je ne suis pas spécialiste de la question mais pour moi c'est pas le même outil ? cmake serait plutôt au même niveau qu'autotools)

./120 Là en revanche je laisse passer les fonctionnalités pour les préférences : je préfère largement créer moi même mes bases de données, et ensuite les utiliser pour générer du code, que l'inverse.
Pour les fonctionnalités cependant, CakePHP a un système de validation où durant que scaffolding il détecte le type (int, varchar, date...) et propose de créer des règles pour confirmer le type lors de l'entrée de données (ainsi CakePHP envoie une erreur avec ses propres termes avant même que SQL ne vienne gueuler "je ne m'attendais pas à ça".
J'aime beaucoup ce système (je ne sais pas pour Django) car il lève automatiquement des erreurs lors de l'enregistrement des formulaires (avec les messages persos kivonbien sous les input fautifs) sans qu'on s'occupe de vérifier manuellement les inputs et de faire des générations de messages d'erreur.

Juste au passage, parce que j'aime l'Équilibre, l'une des grosses fautes de CakePHP est la doc (le "cookbook"). Pour débuter, c'est génial. Pour bien se lancer, c'est super. Pour faire des trucs très spécifiques quand on creuse des cas particuliers, c'est très mal fait. Bien des gourous CakePHP confirmeront qu'à un stade avancée, question doc on en est plutôt à se lancer dans le try-and-error. Parcourir les commentaires de l'API en devient plus instructif.
Je ne sais pas à quel point Django est facile d'accès. Mais il est vrai que je serais tenté de m'essayer à d'autres langages en tant que dev web si, comme je l'ai évoqué, ils sont effectivement conçus pour le web (n'importe quel langage saurait générer une page HTML si on lui demandait) et si ça ne me coûtait pas (ASP.NET est trop contraignant en gratuit à se limiter à des versions "Express" des technos Microsoft)

Intéressant, mais, trop long pour ce soir, oué

apparemment cmake est mieux parce ça génère des makefiles pas récursifs, donc ça va plus vite pour savoir ce qui est rebuildé.

C'est aussi beaucoup plus simple d'écrire un fichier pour CMake :

cmake_minimum_required(VERSION 2.8)
project(ng)

set(include_system_dir /usr/include)
set(include_SDL2_dir ${include_system_dir}/SDL2)

include_directories(${include_system_dir} ${include_SDL2_dir})

add_compile_options(-std=c11)

file(GLOB srcfiles src/*.h src/*.c)

add_executable(ng ${srcfiles})

target_link_libraries(ng SDL2 SDL2_image)

install(TARGETS ng RUNTIME DESTINATION bin)

Même moi j'y arrive, c'est pour dire...

Ah tiens, un site à fabriquer du troll en série : http://development-software.findthebest.com/

./126 : j'ai pas lu bien loin mais les premiers points sont quand même particulièrement stupides. Bouh le C++ n'a pas de RTTI et n'a pas de garbage collector, c'est un gros défaut dans sa conception. Sans blague. J'imagine que l'auteur n'est pas idiot et sait très bien pourquoi, ça fait un peu mauvaise foi d'ajouter ces points dans les défauts du langage.

J'ai pensé la même chose. Par contre, quand il parle de la syntaxe de mort-vitant à damner un saint, j'ai aussi pensé la même chose.

Oui, il y a plein de choses exactes mais le fait d'avoir forcé le trait en présentant comme défauts des choses qui sont des choix délibérés (et justifiés) décrédibilise tout l'article je trouve ; ça ne m'a même pas envie de le lire en entier.

Meowcate (./125) :
./120 Là en revanche je laisse passer les fonctionnalités pour les préférences : je préfère largement créer moi même mes bases de données, et ensuite les utiliser pour générer du code, que l'inverse.

mais comment fais-tu quand le schéma bouge (tu rajoutes une colonne, ou en supprimes une) ?

Pour les fonctionnalités cependant, CakePHP a un système de validation où durant que scaffolding il détecte le type (int, varchar, date...) et propose de créer des règles pour confirmer le type lors de l'entrée de données (ainsi CakePHP envoie une erreur avec ses propres termes avant même que SQL ne vienne gueuler "je ne m'attendais pas à ça".J'aime beaucoup ce système (je ne sais pas pour Django) car il lève automatiquement des erreurs lors de l'enregistrement des formulaires (avec les messages persos kivonbien sous les input fautifs) sans qu'on s'occupe de vérifier manuellement les inputs et de faire des générations de messages d'erreur.

Heureusement qu'il y a une vérification des formulaires et des entrées en bases de données, ça me semble même être le minimum en 2014

Je ne sais pas à quel point Django est facile d'accès. Mais il est vrai que je serais tenté de m'essayer à d'autres langages en tant que dev web si, comme je l'ai évoqué, ils sont effectivement conçus pour le web (n'importe quel langage saurait générer une page HTML si on lui demandait) et si ça ne me coûtait pas (ASP.NET est trop contraignant en gratuit à se limiter à des versions "Express" des technos Microsoft)

Je ne comprends pas ce que c'est qu'un langage conçu pour le web
Y a juste besoin de fonctions qui prennent une requête HTTP et qui renvoient une réponse HTTP. Je ne vois pas trop ce que tu as besoin de plus (à part un certain nombre de fonctions pratiques pour traiter le HTML)

(sinon, tous ceux que je connais qui ont essayé django ont trouvé ça facile d'accès)

Zeph (./133) :
Oui, il y a plein de choses exactes mais le fait d'avoir forcé le trait en présentant comme défauts des choses qui sont des choix délibérés (et justifiés) décrédibilise tout l'article je trouve ; ça ne m'a même pas envie de le lire en entier.

Zeph (./131) :
./126 : j'ai pas lu bien loin mais les premiers points sont quand même particulièrement stupides. Bouh le C++ n'a pas de RTTI et n'a pas de garbage collector, c'est un gros défaut dans sa conception. Sans blague. J'imagine que l'auteur n'est pas idiot et sait très bien pourquoi, ça fait un peu mauvaise foi d'ajouter ces points dans les défauts du langage.

Bah écoute je suis quand même un peu d'accord que ça mérite d'être mentionné. C'est clair que le c++ est super connu, mais en général c'est bon à savoir qu'un langage n'est pas dynamique et n'a pas de GC. Ça signifie qu'il n'est pas adapté à certains types de développements. Après on est d'accord que c'est une question de terminologie mais au fond c'est un désavantage (un truc bien que le c++ n'a pas), de même que la consommation du compilo, alors que l'avantage est la vitesse d'exécution.

C'est certes un inconvénient, mais ce n'est pas une erreur de conception pour autant.

Le fait d'avoir un Garbage Collector c'est pas vraiment lié à "un type de développement". Tu peux *relativement* simplement faire faire tout ce que tu fais avec un garbage collector, mais sans garbage collector. (L'inverse n'étant pas automatiquement vrai)
Il n'y a qu'un seul réel avantage (de taille) aux systèmes à garbage collector, c'est que tu peux *la plupart du temps* coder à l'arrache sans te soucier de la mémoire. i.e. ça simplifie l'écriture de code simple. (Et même dans un projet complexe, il y a beaucoup de code simple)
Faut voir aussi le revers de la médaille et voir que c'est à double tranchant. Y'a tout plein de raisons pour lesquelles avoir un garbage collector, sans être totalement indésirable (encore que ça dépende de la plateforme en question), est un sérieux handicap. Et ça, même les petit gars de chez .NET le reconnaissent.
Le C++ a juste choisi la voie qui laisse certaines libertés à l'utilisateur pour gérer la mémoire. Et en tant que successeur objet du C, ça se défend parfaitement, même si ça rend indéniablement le langage plus complexe à maîtriser.

enfin bon les templates à rallonge et la surcharge surprise des opérateurs, c'est quand même bien relou.

franchement en lisant cette FQA je suis content de faire plus de java que de C++ (et encore plus de C que ces deux)

GC > oui, disons plutôt que devoir gérer la mémoire à la main est un inconvénient.

Compensé par le fait que ça peut être plus efficace, mais ça reste un inconvénient.

./135 et suite : c'est pas une histoire de connu ou pas, ce que je trouve complètement con c'est de lister des éléments qui font partie des fondamentaux du langage dans quelque chose qui est censé mettre en avant des erreurs de conception. Bien sûr qu'il n'y a pas de garbage collector en C++, le langage est *fait* pour te permettre de gérer toi-même ta mémoire. C'est comme si j'expliquais que Python est vraiment mal pensé parce que le typage est dynamique et que par défaut le langage ne propose pas de gérer sa mémoire soi-même. Bien sûr que c'est vrai, mais ça fait partie de l'identité du langage et tout le reste a été construit à partir de là, c'est débile d'aller le lister comme une "erreur" qu'il aurait été possible de "corriger".

AMiserableFileClass file("f1.txt");
//use file... now we want to close it, but there's no close() method, so:
file.~AMiserableFileClass();
//open another file
new (&file) AMiserableFileClass("f2.txt");

omagad.

Mais heu... Est-ce qu'on ne peut pas simplement faire ça avec un scope anonyme ?

./139 > Je dirais plutôt que le fait que ce soit ou non un inconvénient est complètement dépendant de la situation.

Zeph (./140) :
./135 et suite : c'est pas une histoire de connu ou pas, ce que je trouve complètement con c'est de lister des éléments qui font partie des fondamentaux du langage dans quelque chose qui est censé mettre en avant des erreurs de conception. Bien sûr qu'il n'y a pas de garbage collector en C++, le langage est *fait* pour te permettre de gérer toi-même ta mémoire. C'est comme si j'expliquais que Python est vraiment mal pensé parce que le typage est dynamique et que par défaut le langage ne propose pas de gérer sa mémoire soi-même. Bien sûr que c'est vrai, mais ça fait partie de l'identité du langage et tout le reste a été construit à partir de là, c'est débile d'aller le lister comme une "erreur" qu'il aurait été possible de "corriger".

Par contre, je me demande s'il est possible de faire un langage aussi puissant que le C++ (et surtout aussi performant) tout en étant moins difficile à appréhender. J'attends de voir ce que donnera Rust de Mozilla, il me semble que c'est exactement son but.

./142 > Un score ? Ou un scope plutôt ?

Mmm, en pratique, je ne trouve pas le C++ tellement exceptionnellement performant.

oué un scope, sauf qu'apparemment, parfois tu peux pas.

Operator overloading provides strong source code encryption (the time needed to figure out what a+b actually means is an exponential function of the number of types, implicit conversions, template specializations and overloaded operator versions involved).

(désolé, mais c'est tordant)

ur evil printf("0x%08xn", x)edit: convert all yotd::dec << std::endl; statements to this: std::cout << std::hex << std::setfill('0') << std::setw(8) << x << s

./143 : En prenant les bonnes idées des nombreux langages qui ont été inventés entre temps y'a surement moyen de faire quelque chose de beaucoup mieux. Après, je ne sais pas ce qui fait qu'un langage devient connu et utilisé. Par exemple le D est mature, a plusieurs implémentations de compilo, et possède beaucoup de fonctionnalités intéressantes qui le rendent plus concis et plus simple que le C++ pour des performances équivalentes. Pourtant à ma connaissance il n'a aucun succès.

./144 > Oui, pardon (autocorrect à la con)
Sinon, la performance du C++ est partiellement théorique. Ça dépend déjà de la trogne du code que tu vas pondre, et puis ensuite juste de la puissance optimisatrice de ton compilateur.

./143 > Je me demande aussi si c'est possible de faire un truc ± aussi complet tout en étant plus simple. Typiquement, y'a pas mal de trucs que je trouve sympa en C++ (le const-correctness par exemple, mais c'est pas le seul truc ) mais je vois assez mal comment ces fonctionnalités pourraient être ajoutées à un autre langage (genre C#) sans augmenter sensiblement la complexité du code à produire ou sans trahir les garanties originales du langage.
Après, je pense qu'il y a moyen de faire quelques trucs dans le style de l'inférence de type (en gros, du boulot d'analyse effectué par le compilateur lui-même) pour améliorer certaines choses, mais ça aurait quand même une limite.

./146 > En C# et VB.NET on a de la surcharge d'opérateurs, et y'a très peu de problèmes avec. Là où ça devient le bordel, c'est quand n'importe qui détourne la fonctionnalité pour en faire n'importe quoi… (Qui a dit C++ ?)
C'est surtout une question de discipline au final. Toute liberté que tu fourniras au développeur sera nécessairement mal utilisée par x ou y, mais je ne pense pas que ça suffise à invalider l'utilité de cette liberté

GoldenCrystal (./148) :
Sinon, la performance du C++ est partiellement théorique.

On est donc d'accord

http://yosefk.com/c++fqa/fqa.html#fqa-6.2

GoldenCrystal (./148) :
Toute liberté que tu fourniras au développeur sera nécessairement mal utilisée par x ou y, mais je ne pense pas que ça suffise à invalider l'utilité de cette liberté

Voilà, et c'est souvent ce genre de chose qui est repprochée dans la faq anti-cpp, ou dans le quote de squalyl plus haut.