Juste pour commenter ce point, mais je pense que c'est un peu une histoire de goût ou de débat du vendredi (et comme je suis en congé ce soir... )

rincevent a écrit:

Le n° de départ des tableaux.
- Stoppez qqun dans la rue et demandez lui de compter jusqu'a 100, combien de personnes vont commencer à compter à partir de 0 ? aucune, si les tableaux commencent à 0 au lieu de 1 c'est pour des raisons historiques d'économie de mémoire datant de l'époque où chaque bit comptait, continuer à se faire ch... avec ça maintenant c'est nier que c'est l'ordinateur qui travaille pour l'homme et dire "non, c'est à toi de t'adapter à la machine", à la limite je veux bien mais qu'on ne prétende pas après faire un language moderne facilitant l'écriture du code

Je serai tenté de te dire "ça dépend" du programmeur et de son historique : dans une vie précédente, j'ai fait de la programmation d'automates et de l'assembleur (l'asm je joue encore un peu avec).

Lorsque tu es assez proche de la machine et de sa mémoire, il est logique de considérer un tableau à une adresse, et chaque cellule en fonction de son offset depuis cette adresse. Du coup la première case c'est celle qui est à addr + 0, la seconde est à l'addresse addr + 1, la troisième à addr + 2... du coup tab[0] semble tout à fait logique pour accéder à la première cellule comme le fait C, C++ et quelques autres.

Au contraire, pour quelqu'un n'ayant pas eu cette expérience, il est logique de commencer à compter à 1.

Après certains langages permettent le choix de cette numérotation (cas de "option base" en vb), je n'ai jamais utilisé cette possibilité en PB, peut-être parce que cela n'est possible que pour les tableaux non dynamiques.

Pour le reste, les langages "case insensitive" comme PB ne me gênent pas mais je trouve que ça peut donner de mauvaises habitudes et faire un peu brouillon dans le code quand il y a plusieurs version d'un même identificateur (variable, nom de fonction, ...). Après c'est peut-être plus accessible au néophyte, encore une question d'expérience de programmation.

Et pour ce qui est du terminateur d'instruction... Ce qui est bien avec PB c'est qu'il existe tout en étant optionnel (ça permet de faire des choose-case compacts par exemple), par contre par exemple en C ça permet de faire des instructions multi-lignes sans se taper un '&' à la fin de chaque ligne...

Une histoire de goût, je vous dit

Arf... message apparu en double chez moi, voulu nettoyer, message efface 2 fois, je reposte :

Dadone a écrit:

Les languages "modernes", j'en connais beaucoup qui se prétendent modernes mais je n'en connais qu'un, PB.
Pour rebondir sur ce thème PB a de gros défaut qui n'en font pas un langage moderne.
Un vocabulaire aberrant qui confond tout et n'importe quoi,  une permissivité  totale, tout est déclaré publique par défaut, un passage de paramètre aberrant avec les "open withparm " l'absence de surcharge du constructor() afin de passer proprement les arguments, une redondance totale entre la classe datawindow et le datastore alors qu'il devrait hériter l'un de l'autre, la notion de fonction globale qui est une hérésie, la notion de routine globale idem, l'absence de construction de type énumérée, l'impossibilité de redéfinir les routines des classes locales  et au niveau IDE la contrainte d'héritage qui fait qu'on ne peut peu pas visualiser une classe et ses descendants.
Bref un produit pas très sérieux et qui date.
Je ne connais pas bien PB.net mais il me semble que c'est la seule issue pour sauver ce produit en améliorant les inconvénients listés.
A tout prendre de nos jours, je conseillerais .Net avec la datawindow .net mais ce n'est juste qu'un avis non validé par la pratique.

C'est vrai qu'il y a quelques manques en PB mais de là à dire que ce n'est pas un produit sérieux c'est limite du Troll.

en tout cas un homme seul peut réaliser une appli PB en moins de temps qu'il ne faut à une armée de consultants Java pour choisir le(s) framework(s) à utiliser pour la persistance, pour le déployement, pour la compilation, pour la gestion multi-threadée du Mapping Objet relationnel des classes polymorphes abstraites servant de AbstractFactoryConstructor pour les créations de paradigmes virtuels en Just-In-Time...

enfin moi c'est l'expérience que j'en ai eu, et au final on a une appli qui sais même pas mettre à jour une ligne dans une table (en Java)

Je connais aussi personnellement des gens qui sont occupés à remettre en PB des applis bancaires qui étaient en PB, qu'on a déclarées pas sérieuses et datées et décidé de passer en JAVA, seulement vu que les nouvelles Appli Java n'ont jamais réussi à égaler les performances des applis PB ni même à être assez rapide pour traiter les volumes quotidiens ben on recommence en PB...

PB pour moi c'est un couteau, un très bon couteau très bien aiguisé, ce qui fait que quand on veut couper qqchose ( créer un programme type ERP on va dire) c'est très efficace
Par contre c'est pas fait pour serrer des écrous c'est sûr

JAVA c'est un couteau suisse, on sait tout faire avec, couper, serrer des écrous, plan,ter des agraphes etc., problème, quand on veut juste couper un truc tous les autres outils sont dans le chemin alors qu'on en a pas besoin, certains outils sont bizarrement liés et aucun des outils ne vaut un outil spécialisé (la grande lame d'un couteau suisse ne vaudra jamais un vrai couteau)

my 2 cents.

C'est vrai que la DW est LE principal avantage de PB. mais pas le seul et je mettrai en avant la simplicité de PB comme gros avantage (simplicité de la syntaxe et du language)

par contre .Net / Java c'est un peu chou vert et vert chou non ? en tout cas .NET a été laaargement inspiré de Java au niveau de pas mal de concepts


Sur base de ma toute petite expérience avec ces 2 langages J'aurai tendance à préférer .NET à Java juste parceque en .NET j'ai pas besoin de me demander quel outil / framework utiliser à chaque nouvelle tâche. Et aussi pour Visual Studio qui tue tout comme IDE là j'avoue.

rincevent a écrit:

par contre .Net / Java c'est un peu chou vert et vert chou non ? en tout cas .NET a été laaargement inspiré de Java au niveau de pas mal de concepts

Oui pour la syntaxe de C# quasiment la même qu'en Java.

erasorz a écrit:

rincevent a écrit:

par contre .Net / Java c'est un peu chou vert et vert chou non ? en tout cas .NET a été laaargement inspiré de Java au niveau de pas mal de concepts

Oui pour la syntaxe de C# quasiment la même qu'en Java.

Plus précisément, il existe deux courants principaux de langages.
Ceux dérivés du C :  C++, Java, C#,...
Ceux dérivés du Basic : qui ont donné dbase, Foxpro, PowerScript, VB, ...

rincevent a écrit:

PB est trop permissif et donc encourage un peu beaucoup le dév à l'arrache.

Comme le fait de déclarer des dizaines de variables d'instances toutes public de manière totalement inutiles...

Dernière modification par Dadone (20-08-2013 14:23:16)

Mes 5 cents...

Quand on juge des capacités de PB à faire ceci ou cela, de ses lacunes quant à la religion OO actuelle (oui, c'est de la provoc' ...), n'oublie-t-on pas simplement qu'il n'est pas fait pour ça, qu'il ne s'est même jamais "retourné sur ça" ?
On s'interface avec une db, c'est tout.
Oracle forms, c'était de la belle ouvrage ? Nenni (comme on dit chez nous !) mais ça faisait le job.

Honnêtement, parfois, pour paraphraser un grand stratège,  je me dis que l'informatique est une chose trop sérieuse pour la laisser aux informaticiens.
Quand le gars qui dirige une salle de marché veut une application dans 8 jours, qu'il te file juste le login/password de la DB, tu fais comment avec java ? Et avec .Net ?
Tu lui parles de l'ornithologie comparée entre un hibernate et un odbc ?
Non, hein, tu prends PB.
Ou Delphi, ou Windev...

Le client dirige.
Et ce sera encore longtemps le cas.
Donc tant qu'ils seront serrés sur le timing, on le sera sur l'élégance de "nos bidouilles".

Le reste, c'est de la poésie

Alors, java les a attrapé, un peu sur un mal-entendu (comme disait un autre "stratège"...).
Mais au réveil, les clients sont pas fous et voient bien qu'elle vaut pas le détour, leur bombasse d'un soir

Pour le reste, les décisions se jouent au budget.
Parfois y'a du budget à jetter dans un projet java, parfois pas.
C'est .net l'avenir, car c'est ce qui se rapproche le plus de la logique PB :-)
Déjà que sqlserver était un rejetton de DB Sybase, normal qu'ils continuent à s'inspirer chez crosoft :-)

J'adore les discussion de venredi soir, moi

Il y un début de réponse dans le poste du 20/08/2013.

RaccaR a écrit:

Dadone a écrit:

Il y un début de réponse dans le poste du 20/08/2013.

Revu merci.

Nous sommes deux et restons pour le moment sur deux avis partagés : l'un pour Java, l'autre pour C#.

Peut-être un choix judicieux se ferait-il sur l'outil le plus facile d'utilisation en développement (IDE) et qui nécessiterait le moins de composants à installer en production.

Il n'y a pas photo, C# c'est mieux si vous faites de l'IHM en mode client/serveur.
Il faut comprendre l'historique de Java. A l'origine c'est un langage pour les automates. Comme il était gratuit, le monde universitaire s'en ait emparé comme langage "école" et pour ses propres besoins. Mais ce n'était pas pour faire de l'IHM mais pour faire tout autre chose (réseau neuronaux, IA, analyse du langage, etc..).
Ensuite c'est la machine markéting qui a fait le reste (puisque l'université l'utilise alors c'est que c'est un bon langage, etc..) aidé par de puissantes SSII qui y voyaient une grande sources de profits (ils ont eut raison, un projet Java est en effet très couteux et donc rapporte gros, ...),  plus la touche "WEB" finale (machine virtuelle) pour convaincre les indécis que c'était LE LANGAGE.
Mais le monde de la gestion a des problématiques fort différentes du monde universitaire et Microsoft depuis le début a une vision globale des langages donc également adapté au monde industriel ou de gestion ou pour tout autres besoins
C'est pour cela que C# est en tout point supérieur à Java car dés le départ il était multi-cibles sans compter les moyens financiers gigantesques de MS qui lui ont permit de faire appel aux meilleurs spécialistes mondiaux des langages objets en interfaces événementielles. La contrepartie est que pour maitriser toutes les facettes de la programmation objet .Net faut un gros investissement personnel.

Dernière modification par Dadone (28-08-2013 09:29:14)

RaccaR a écrit:

Merci Dadone,

Vos précisions confortent mon point de vue personnel .

A mon humble avis vous ne trouverez  personne qui maitrise JAVA et C# .NET préférer Java dans un projet client/serveur.
Ceux qui préfèrent JAVA c'est qu'ils connaissent le langage et qu'il ne connaissent pas C# .NET ou qui maitrise nettement mieux Java que C#.
En aucun cas ce peut être un avis objectif....
Pour avoir étudié et développer (un peu) dans les deux et en tant que spécialiste de la programmation objet, je peux vous dire qu'il n'y a pas à hésiter.

Dernière modification par Dadone (28-08-2013 10:25:23)

perso je trouve que la portabilité c'est très surestimé, je ne connais pas de gros projet où on ne connait pas à l'avance la plateforme cible et je n'en connais pas non plus où on se dirait subitement "tiens demain on abandonne windows et on passe tout nos systèmes sur Linux"

Par contre l'enfer des versions en Java c'est l'enfer des versions des frameworks utilisés, et d'après ce que j'ai vu des frameworks à utiliser y en a plein et ils ont tous des incompatibilités entre eux ce qui fait qu'avant même d'espérer écrier une ligne de programme il y a 3 semaines de recherche à faire afin de savoir quelles versions installer pour que tout fonctionne ensemble.

P'tite blague trollesque pour finir : Dire que Java c'est bien parce que ça marche chez tout le monde, c'est comme dire que la sodomie c'est bien parce que ça fonctionne chez tout le monde

xlat a écrit:

C'est pas parce que tu ne connais  pas de gros projet qu'il n'y en a pas (je ne parle pas de SSII avec des projets clients spécifiques mais pustôt dans l'édition logiciel), le fait d'être multi-plateforme permet de toucher une clientèle plus grande (et c'est aussi un Buzz-argument) et peut aussi avoir un enjeux économique (déploiement de licence windows x nombre de postes client par exemple).

Certes, je me suis mal exprimé, disons simplement que si la cible est connue d'avance, ce qui est généralement le cas alors l'argument de la portabilité perds énormément de poids, pour ne pas dire tout.