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

Je pense que c'est surtout dû a son expatriation en territoire hostile

Meowcate (./74) :
PHP n'est pas beau. Il est bordélique, plein de redondance, il manque de logique. Ce qui est important au fond est que ça fonctionne, et ça fonctionne rapidement.

Et puis un jour, tu passeras à un langage un peu plus moderne (Ruby + RoR ou Python + Django), et tu te rendras compte de tout le temps perdu à réinventer la roue, à débugguer des pièges du langage, ou à contourner des limitations du langage…

Godzil (./85) :
Ya une vrai interface quand meme:

http://www.esato.com/news/openmoko-an-iphone-alternative-for-developers-1737

Par contre il faut aimer le paradigme doigt/stylet ecriture en 2pt

Vu l'image, il faut aussi aimer le design des années 1990

./92 >

En fait tout ça me rappelle un peu ce mouvement incroyablement désespérant, complètement affligeant mais malheureusement réel.

Tiens, tu fais ton Kevin, tu sais mieux que les gens ce qui est bon pour eux ?

pourtant, un langage complètement redondant, il devrait être plus sûr....


nan?

(./94 > Non, du tout, j'ai juste lu plus que la première page de commentaires…)

./95 > Ouais, cet argument marche au moins pour le XML… Mais pas généralisable au reste

Pas d'accord. Dans son champ d'application (créer facilement des petites applis natives Windows), VB <= 6 n'était pas mauvais du tout. Oui le langage était critiquable, mais vu son âge ça n'a rien d'exceptionnel. Le C est critiquable aussi...

VB.NET est mieux conçu, mais sa dépendance à .NET n'en fait pas un remplaçant valable de VB <= 6.

ah non pour avoir fait des deux, le C est moins critiquable que VB6

./97 > Mais où as-tu vu que je critique VB6 ? Non parce qu'ayant personnellement pratiqué (ça ou le VBA, de toutes façons c'est +/- le même moteur derrière), je pourrais facilement, si tu veux qu'on en vienne là
Ce qui est affligeant, c'est l'attitude des gens, et ce ne sont à priori pas des développeurs de "petites applis natives Windows" (Tel que je lis leur posts, plutôt de gros bloatware corporate mal fichus qui emmerdent les utilisateurs)

Alors à moins qu'ils soient tous débiles, tu crois pas qu'ils aient quand même un peu leurs raisons, et même que peut-être, ils savent de quoi ils parlent ?
Ils n'ont tout simpement pas les même besoins que toi, non ?
Enfin, lire ce topic sans retenir qu'on a tous nos goûts, besoins et habitudes en programmation, et vouloir pontifier "ça saybian ça saypabien", amha c'est mort d'avance

GoldenCrystal (./99) :
Mais où as-tu vu que je critique VB6 ?

GoldenCrystal (./93) :
En fait tout ça me rappelle un peu ce mouvement incroyablement désespérant, complètement affligeant mais malheureusement réel.

Tu m'excuseras, mais avec une telle phrase dans un topic qui parle de langages de prog, ça me semblait logique que tu critiques le langage

Non, je pense comme toi qu'il avait ses qualités, à l'époque. Mais depuis on a fait mieux en tout point. (Simplicité et fonctionnalités)
Enfin sinon, vous avez clairement pas lu les commentaires, mais c'est pas grave, je laisse tomber…

GoldenCrystal (./102) :
Mais depuis on a fait mieux en tout point. (Simplicité et fonctionnalités)

Y'a quoi d'équivalent qui génère du code natif ?
Le seul langage comparable que je connaisse, c'est Delphi, et il est mourant.

Ouais enfin, que ce soit du code natif ou du PCode, y'avait quand même un runtime à installer qui était le même dans les deux cas (Runtime qui se faisait sans cesse écraser par le premier installeur venu d'une version précédente de VB6… Et ne parlons même pas des nombreuses dépendances sous forme de dll & ocx qui devaient impérativement être installées en exemplaire unique dans le répertoire système… Joie et bonheur )
À ce titre, tu cites Delphi, qui compilait en vrai code natif, et pour le coup c'était bien un cran au dessus de VB6… En dehors du mode natif uniquement, c'était plus l'équivalent de VB.NET ou même C#. Par contre c'était beaucoup plus compliqué à prendre en main. (Après s'il est mourrant malgré son passage à .NET, ça doit sans doute venir de là)

Sinon je t'avoue que non, y'a pas masse de langages simplissimes qui génèrent un assembleur natif. Aujourd'hui la mode est aux langages dynamiques tels que Ruby, Python et JavaScript. Ceux-ci te permettent également de faire du code rapidement et simplement (à des degrés variables selon le langage), mais ils requièrent également un runtime avec interpréteur ou compilateur JIT.
Honnêtement, je ne pense pas que la capacité à générer du code purement natif soit le critère le plus déterminant dans le choix d'un langage. Des critères comparables, mais beaucoup plus intéressants sont l'utilisation mémoire et la performance du code généré… (Et là, je pense que n'importe quel langage à JIT arrive facilement à exploser le VB6 niveau perfs )

GoldenCrystal (./104) :
(Après s'il est mourrant malgré son passage à .NET, ça doit sans doute venir de là)

...et au fait que MS a débauché son chef de projet pour créer .NET, ça a pas dû aider non plus

GoldenCrystal (./104) :
(Et là, je pense que n'importe quel langage à JIT arrive facilement à exploser le VB6 niveau perfs )

Mouais, ben rien qu'en matière de temps de démarrage et réactivité de l'UI, je n'ai encore jamais vu de truc en .NET ou Java qui ait des perfs comparables à du VB6 (sur la même machine). Ça n'est peut être pas perceptible sur une machine actuelle, mais sur un vieux PC ça saute aux yeux. Et pourtant VB est loin de générer du code natif aussi optimisé qu'un compilateur C.

Niveau conso mémoire, c'est encore plus flagrant...

C'est pour ça que je parlais de code natif.

./103 le vb6 ne génère pas de code natif mais du p-code qui a besoin de msvbvm60.dll

en génération de code natif on a C++ et wxwidgets, avec wxsmith ou équivalent c'est aussi simple que vb. presque. je vous merde.

('spèce de codeblocks fan, pfff, codelite forever va )

GoldenCrystal (./93) :
En fait tout ça me rappelle un peu ce mouvement incroyablement désespérant, complètement affligeant mais malheureusement réel.

En meme temps VB.net est un VisualBasic fait a l'arache, mais fini et pas complet, et Microsoft n'a jamais reussi a refaire un soft aussi simple d'utilisation qeu VB6 et inf.

Il est tellement facile et rapide avec VB6 de faire une appli demo/test qui marche que VB.net c'est affligeant tellement c'est...

tiens j'me rappelle, j'ai commencé avec VB3 en fait, qu'est ce que j'en ai codé des tites merdouilles avec ça

c'était cool, y'avait juste un exécutable à lancer pour avoir tout l'IDE, et ça marchait sous win 3.1 <3

Zerosquare (./105) :

GoldenCrystal (./104) :
(Et là, je pense que n'importe quel langage à JIT arrive facilement à exploser le VB6 niveau perfs )

Mouais, ben rien qu'en matière de temps de démarrage et réactivité de l'UI, je n'ai encore jamais vu de truc en .NET ou Java qui ait des perfs comparables à du VB6 (sur la même machine). Ça n'est peut être pas perceptible sur une machine actuelle, mais sur un vieux PC ça saute aux yeux. Et pourtant VB est loin de générer du code natif aussi optimisé qu'un compilateur C.
Niveau conso mémoire, c'est encore plus flagrant...

Tu as essayé en compilant avec .NET Native ?

Nan

flanker (./92) :
Et puis un jour, tu passeras à un langage un peu plus moderne (Ruby + RoR ou Python + Django), et tu te rendras compte de tout le temps perdu à réinventer la roue, à débugguer des pièges du langage, ou à contourner des limitations du langage…

Je ne suis pas sûr de comprendre. Les exemples que tu me donnes sont des implémentations au moyen de librairies, quand PHP est avec ASP[.NET] (et dans la limite de mes connaissances) les seuls langages conçus pour le web.Ruby n'est pas du web. Python n'est pas du web. Il n'y a pas des fonctions natives comme header() ou move_uploaded_file(). Du coup utiliser des compléments, je dirais que je pourrais aussi bien y ajouter des frameworks PHP pour rendre ce dernier plus propre et plus strict par le suivi des conventions du framework donné.
Par ailleurs, pour l'avoir déjà évoqué, mon framework préféré (et de travail) est CakePHP, qui imite le fonctionnement de Ruby/RoR (ActiveRecords, Scaffolding, plugins, et fortement OO), mon jugement est peut-être biaisé dans l'idée que je ne fais plus beaucoup de PHP "pur" depuis plus d'un an.

Il leur manque surtout la fonction gzgetss, et aucun langage ne pourrait prétendre être "web" sans elle

Meowcate : je suis tout à fait convaincu par tes arguments (honnêtement), mais pour de ne pas recopier dans ce topic ce qui a déjà été évoqué un grand nombre de fois ailleurs, voilà un article (déjà posté sur yN) qui résume à mon avis très bien ce veulent dire les gens par "PHP est un mauvais langage de programmation" : http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Note que ça n'a absolument aucune influence sur ta façon de développer, qui est peu représentée sur yAronet mais probablement appréciée dans beaucoup d'entreprises dont celle dans laquelle tu travailles.

(voilà même le trollic d'époque, pour les nostalgiques : topics/147877-f-high-tech-php-et-autres-langages)

squalyl (./106) :
./103 le vb6 ne génère pas de code natif mais du p-code qui a besoin de msvbvm60.dll

Mmm ? Sûr ?
Il me semble que les exécutables compilés avec VB<=5 étaient en P Code mais que le VB6 était bien du code natif ?!

Tiens, je ne connaissais pas le terme de scaffolding. Et au final, je trouve ça assez moche comme idée. Si j'ai bien compris l'idée, on décrit sa table SQL dans un fichier (.xml, .yml ou équivalent), et ça génère du code pour l'utiliser. Du coup, que se passe-t-il quand on modifie le code, puis la description (sur un autre bout de description) et qu'on veut régénérer le code ? Comment se passe la migration de la base ?

Quant aux fonctions header et move_uploaded_file, on peut s'en passer facilement

./108 > Heu... Tu déconnes la ?
Une appli demo avec VB.NET ça se fait en quelques clics exactement comme au temps de VB6... Le désigner Windows Forms est très similaire à celui de VB6; tu peux lier tes composants aux données comme en VB6; et tout le reste, c'est du bonus.
(Faudrait franchement citer un exemple de "demo" car connaissant les deux je sais à quel point tu ne pouvais pas faire grand chose simplement en VB6 )
.114 > C'est comme tu dis, mais le VB6 avait aussi la possibilité de générer du PCode.

Oui voilà, c'était une option ^^

flanker (./116) :
Si j'ai bien compris l'idée, on décrit sa table SQL dans un fichier (.xml, .yml ou équivalent), et ça génère du code pour l'utiliser.

Je t'explique cela rapidement, du moins pour CakePHP :
La base de données est conçues selon des conventions précises (non obligatoires, mais préférable pour automatiser certains comportements du framework, et surtout que le scaffolding fonctionne on the fly). Par exemple les ids sont tous "id", les noms de tables sont en anglais au pluriel de ce qu'elles décrivent (ex : cars, people...), les clés étrangères sont de forme la table visée au singulier avec le suffixe id (car_id, person_id...).
Bref.
Ceci fait, il est possible de générer automatiquement de nombreux éléments : tout d'abord les models où le script de génération prévoit ce qui est attendu mais demande toujours confirmation ("vu les clés étrangères, je suppose que « people has one cars » et que « cars belongs to people »). Puis les controllers avec une base de CRUD (on peut même y ajouter un CRUD spécifique pour le back admin), et enfin les vues correspondantes. On peut même aller jusqu'à automatiser la création de tests unitaires.

Maintenant, pour ce que tu trouves moche, il s'agit de génération d'une base de code pour déployer rapidement des idées, et surtout ce qu'on écrit en permanence (créer les models, controllers, les lier entre eux...). Pour tout le reste, c'est à toi de bosser, il n'est pas question de régénérer le code de nouveau par la suite. Tu changes des éléments dans la base ? tu vas modifier manuellement tes models. Cela simplifie la création de ce que tu aurais de toute façon dû créer, tu peux donc tout à fait t'en passer, mais je peux déjà dire que si l'économie en temps est variable (1 à 3h en moyenne sur mes projets), le vrai plaisir st de ne pas avoir à refaire toujours les mêmes trucs au lancement de chaque projet.

Par ailleurs, le code généré est suffisant pour permettre d'avoir une application fonctionnelle si elle se limite à des CRUD simples, en particulier pour du prototypage.

Je préfère largement la méthode Django, du coup Tu écris des classes (qui doivent hériter de models.Model) dont les attributs seront les colonnes des tables.
from django.db import models class Poll(models.Model): question = models.CharField(max_length=200) pub_date = models.DateTimeField('date published') class Choice(models.Model): poll = models.ForeignKey(Poll) choice_text = models.CharField(max_length=200) votes = models.IntegerField(default=0, min_value=0)
Là, on fait deux tables, dont la seconde aura une référence à la première. Tu n'as rien de plus à faire (et surtout pas à créer les tables, Django s'en charge pour toi via une commande), il n'y a aucune ambiguïté et c'est utilisable immédiatement quelque soit le moteur SQL choisi. Ça permet également d'avoir pas mal de garanties sur les données (genre le nombre de votes ne sera jamais négatif), générer plusieurs colonnes avec un seul champ, …

source