Reprise du message précédent :

 
je travaille sur plusieurs projets en parallèle sous PROLOG (algorithme A*, résolution de CSP), c'est mon langage de prédilection. D'ailleurs je me demande jusqu'ou tu es allé en PROLOG pour ne pas avoir vu de difficultés. Pour Java et C++ je persiste à dire n'importe qui sans compétence particulière peut coder dans ces langages.

 
C'est qui pour toi "n'importe qui sans compétence particulière ?"
Et quand tu parles de coder dans ces langages, tu veux dire taper du code ou faire une appli qui fonctionne ?

A l'extreme limite, ça pourrait être le Java ça ( et encore, le Java qu'on ne trouve que dans les rèves dse dirigeants de Sun ), mais alors en C++ !!! Il faut bien plusieures années d'experience en C++ pour pouvoir enfin coder correctement et en fesant un minimum d'erreurs.

Osama> Franchement, ton avis sur C++ et Java, c'est n'importe quoi. Il faut des compétences particulières pour programmer.  
Et en voici la preuve : http://forum.hardware.fr/forum2.ph [...] h=&subcat= . Un exemple typique de newbie qui est complètement paumé parce qu'il démarre.
 
Maintenant que les concepts de base de la programmation soient ceux développés dans les langages impératifs comme C++ et Java, et que pour programmer dans des langages plus spécialisés comme Prolog, il faille des compétences supplémentaires, je suis d'accord. Mais ce n'est pas la même chose. Et on peut dire la même chose ("il faut des compétences supplémentaires" ) pour tous les types de langages non impératifs, pas seulement Prolog. Exemple typique : SQL, qui est un langage déclaratif pseudo-fonctionnel.

Et je vois pas pourquoi ça marchait pas pour d'autres langages.
Le Pascal, PHP, Python ou autre n'est pas plus difficile d'accès que le Java ou C++...

ben je crois que tu te plantes méchamment, on en a un beau là qui sait même pas ce qu'est un booléen.  C'est considéré comme compétence particulière?

Ceci dit, je ne renie absolument pas les apports de Prolog en matière de puissance d'expression. Tout ce qui peut réduire la complexité de la programmation est très utile et la manière dont Prolog y arrive est très intéressante.

Biface ! C'est insoutenable ! Je souffre beaucoup.

C'est mon petit côté sadik...
 
Wharf...    
 
Bon OK, je pensais à Ada.
Vous remarquerez, je ne prenais pas trop de risques en disant que j'espérais qu'il fût cité : kadreg l'avait proposé dans le post juste au dessus.    

 
Sachant que coder dans un langage utilisant un ramasse-miettes ou dans un utilisant des désallocations explicites ne représente pas la même chose, je ne vois pas comment vous vous en sortez.
 
Exemple simple, je code en tenant compte du ramasse-miettes et donc sans mettre d'appel à "free". J'utilises un compilo sans ramasse-miettes. Il se passe quoi ? Fuite mémoire ?

En gros, dans ce sens-là, oui.
 
Par contre, dans l'autre sens, si tu mets à un appel à "free" le langage peut tout à fait supporter les implémentations avec ramasse-miettes : ce dernier ignorera tout simplement la demande de libération, ou pourra même s'en servir comme indicateur.
 
Tu peux même imaginer que le langage te permette d'exprimer "pour ce type pointeur-là, je vais faire des désallocations explicites et pour cet autre-ci, non". Et le run-time utilise ou non un GC selon ce que tu as indiqué dans le programme.

Si vous avez pas mal de temps a tuer, y'a ce lien qui est plutot interessant :
http://www.geocities.com/tablizer/langopts.htm
 
Je suis pas d'accord avec tout ce qu'il raconte, mais la page vaut quand même son pesant d'octets.

un beau diagramme sur les langages :
http://people.mandrakesoft.com/~pr [...] iagram.png

 
Il est clair qu on a pas DU TOUT les meme gouts en ce qui concerne la beaute !
 
@->--

http://www.levenez.com/lang/
 
Celui-là est mieux
(mais peut-être moins complet)

Bof... J'ai parcouru 3-4 paragraphes, et à chaque fois, je trouve que ce qu'il dit est limite, voire carrément faux. C'est peut-être valable pour des petites applications, mais dès qu'il s'agit de bons gros systèmes d'information, ça ne tient plus la route en termes de sécurité (de programmation).
 
Exemples :  

De quoi parle-t-il ici ? Des tableaux associatifs de Perl ou du modèle relationnel des SGBDR ? Dans ce dernier cas, il n'a pas dû faire beaucoup d'objet, ou concevoir des BD pour des problématiques un peu complexes. Allez gérer un gestionnaire de workflow dans un SGBDR... C'est très rigolo. Et des fois, vous vous dites qu'en vrai objet, avec des liens entre objets, ça serait 10 fois plus simple.
Et même, dans tous les cas, il n'est pas très compliqué de faire une classe de gestion des tableaux associatifs (d'ailleurs, si je ne m'abuse, cela ressemble beaucoup à une table de hachage). Ce qui résoud le problème.
 

Là encore, ce n'est pas parce qu'habituellement, en programmation objet, on fait reposer le code sur un seul objet receveur que c'est une contrainte stricte. Avec des mécanismes comme la "réflexion", on peut tout à fait disposer de 2 objets receveurs, ce qui offre la même flexibilité que celle dont il parle.
 
Et à propos des SGBD et des systèmes objets :

Effectivement, pour disposer d'un langage de requête objet, il faut un SGBD objet. De la même manière que pour faire des requêtes sur des tables relationnelles, il faut un SGBD relationnel. Un langage de programmation seul ne propose pas de langage de requête optimisant sur les données qu'il permet de manipuler. Et contrairement à ce que l'auteur prétend, la plupart des SGBD objet (sujet que je connais bien) dispose d'un langage de requête type SQL qui n'a pas du tout à rougir du SQL relationnel.
Malheureusement, comme il le dit lui-même, la pénétration des SGBD objet est encore très faible ("OODMS's are in their infancy and are still not selling as well as the "traditional" RDBMS" ). Mais ce n'est certainement pas avec ce genre de discours (je le cite encore : "There is also talk that..." = "Il se dit aussi que..." ) que les SGBD objet vont décoller. Mais de toute façon, depuis que je m'intéresse à ce sujet-là très précisément, j'entends toujours les mêmes arguments fallacieux. Et étant répétés encore et encore sans que personne ne se donne la peine de vérifier (ben oui, ça prend du temps), ils deviennent la "Vérité", quoi que puissent dire les éditeurs concernés. C'est ce qu'on appelle un cercle vicieux...

 
pour haskell et les langages déclaratifs du futur : IO Monads, super flippant pour les débutant et pose un problème : il ne faut pas recopier le monde. Sinon, assez puissant pour utiliser ça dans les exceptions, la concurrence etc.
 
Concernant PROLOG :
il existe aun langage bien plus moderne : curry, il offre l'unification de prolog, un système de types sympa (Hindley-Milner), réécriture de graphes classique des langages fonctionnnels (style haskell), lazyness (un peu obligatoire), fonctions non-déterministes et il doit y en avoir d'autres.
http://www.informatik.uni-kiel.de/~mh/curry/

je viens de jeter un oeil a ca http://www.dcs.gla.ac.uk/~nww/Monad.html
 
mais je suis pas sur d'avoir compris le principe
 
tel que je le vois, c'est un moyen détourner de passer l'etat en parametre, mais je suis pas dans une optique fonctionnelle, donc ca me dérange pas du tout d'avoir des méthodes dont le résultat ne dépends pas uniquement des parametres en entrée

 
C'est pas détourné, tu passes le monde en paramètre et tu reçoit un monde en résultat, donc _c'est_ passer l'état en paramètre.
 
je te conseille http://research.microsoft.com/User [...] toberdorf/ c'est la meilleure introduction que j'ai lue sur le sujet.
 
Mais les monads ne sont pas spécifiquement fonctionnels, c'est surtout du à l'aspect déclaratif (pur) du langage.  
 
Les langages déclaratifs sont voués à augmenter leur part de marché, ils sont largement plus simples à prouver, vérifier, manipuler etc.  

merci, je vais lire ca tranquillement chez moi
 

Marrant, j'y crois pas. Si la preuve était si importante, ca fait longtemps que y'aurait plus que ceux la... comme c'est pas le cas, je vois pas pourquoi ca changerait a moyen terme
 

flag

Ouah la vache, j'ai pas eu le courage de tout lire (comme d'ab).
lol pour le delire du demarrage, maintenant, je crois que le topic est devenu interressant !
 
En fait moi, je voudrai pas forcement defndre un langage, mais plutot donner mon avis general sur la situation.
Qu'est-ce aui est le + important dans un langage :
- la syntaxe sexy
- les API dispos
- l'efficacite
- les outils fournis (IDEs, compilos)
 
finalement, je trouve ca chiant de passer d'un langage a un autre, parce que a chaque fois, on perd qqch.
 
L'ideal serait, un langage de (tres) haut niveau, qui puisse s'adapter ensuite a tous les langages. Comme ca, les lib pourrait facilement etre portees dans un langage specifique (adapte aux besoins) .... mouaif, enfin la, je me rend compte que ce je dis n'a aucun sens !  
Tout ça pour dire, que c'est le gros bousin je trouve dans ces langages, et que ce serait bien qu'il y ait un nouveau concept qui harmonise un peu tout ça ...
 
En tout cas, je pense que c'est un sujet tres chaud, et qu'il y a du boulot pour ceux qui concoivent les langages
 
vouala
 
edit : font chier ces clqvier qwerty  

bah .NET c'est pas un peu ça ?  

Je crois d'abord que chaque language à ses avantages et ses inconvénients: même le camel par exemple à ses avantages en mathématique (bien sûr y'a certains language qui ont bcp d'incovénients et presque aucun avantage mais bon   ). En conséquence, il n'y à pas un language universel capable de tout faire, mais plusieurs language plus ou moins spécifique. Par exemple le PHP est fait pour le web, mais pas pour faire un moteur 3D.
 
Tant qu'a choisir un language, il faut avant tout qu'il soit libre: ceçi pour la pérénitée, la modularitée et la documentation qui en découle.
Il est aussi important qu'il soit portable, cad utilisable sur différentes plates-formes (Mac par exemple).
 
 
Tant qu'a la façilitée de développement, il n'existe pas de plateforme de développement idéale: chacune est plus ou moins difficile. Personnelement, j'ai fait du Pascal, Delphi, Windev, PHP, Javascript et C. A mon humble avis, le C est un peu spartiate, Windev assez sympa et je n'aime pas Delphi (installation et documentation lamentable).
 
 
Je crois que le C reste un language incontournable: même si il est spartiate et un peu bidouille, il est présent sur toutes les plates-formes, très portable, très puissant et à la base de beacoup d'autres languages (PHP et Java par exemple).
 
Le Windev, C#, VB, et Delphi sont à éviter parcequ'ils ne sont pas libre, ce qui pose les problèmes que j'ai déjà survolé, et aussi parceque la portabilitée est très mauvaise.
On peut éventuellement tolérer le javascript car il est utilisé pour de petits projets.

Tu n'as jamais entendu parler de Kylix?  C'est du Delphi portable sous Linux.  La question de la portabilité est donc réglée depuis quelques temps déjà.  Certes, ce n'est pas portable sur TOUT mais la portabilité vers un environnement de type Unix est un grand pas je trouve.  Le fait que ce ne soit pas libre n'est pas si gênant.  Borland est un éditeur engagé.  Les sources du framework sont livrés avec le soft.  Je ne doute pas qu'ils continueront à faire du bon boulot.
 
Quant à dire que leur doc est mauvaise, non, je ne suis pas d'accord.  Je me rappelle bien quelques bugs sur les HLPs de Borland C++ 5 mais sinon rien à dire.
 
Par contre, je suis d'accord de dire que tout langage non libre (sauf Delphi donc ) devrait être purement et simplement ignoré, puisqu'il y a la pérennité du langage qui entre en jeu.
 
Mais le problème n'est pas tellement la pérennité du langage.  Et de savoir de quoi on parle.  D'un côté, il y a le langage lui-même avec sa syntaxe et son comportement.  Et de l'autre, il y a sa bibliothèque standard.
 
C'est surtout elle qui va évoluer.  Il suffit de voir la transformation de VB6 en VB.NET.  La bibliothèque standard qui l'accompagne a purement et simplement été remplacée par une autre.  Alors que la syntaxe n'a (quasi) pas changé.  Pareil pour le comportement.  C'est plutôt l'IDE qui fait des choix par défaut, différents dans l'IDE de VB6 et de VB.NET (exemple: usage de ByVal par défaut remplacé par ByRef).  Celui qui aura codé proprement sans faire usage des comportements par défaut n'aura pas ce problème (et je me flatte de dire que c'est mon cas )

euh franchement j'ai bien essayé de récupérer des applis Delphi avec Kylix et ça à complétement merdé   ...

Pour ce qui est des appli visuelles faut soit utiliser les librairies CLX à la place de VCL, soit foutre des ifdef partout.
Perso j'ai fait un miniprojet sur Kylix, ça a complié sans problèmes dans Delphi.

 
la faute a qui ? TOI ? Delphi ? ou borland ?
 
@->--

bah qu'il en fasse un topic, ça évitera de polluer hors topic ici inutilement
 
on a quelques spécialistes Delphi ici

le niveau de programmation rentre aussi en jeu. Tu es loin d etre un debut en delphi antp ! Par consequent la facon dont tu prepares ton projet est surement tres differente du gars qui commence et qui "Delphi c est comme le Java ca pue des pieds !!". Je pense que meme la connaissance de l outil est importante dans ce cas.
Comme dirai l autre " UN outil c est tres bien encore faut il savoir s en servir !".
 
@->--

je sais pas  

A propos de Kylix, est-ce que le fait que ça tourne sous windows et Linux/i386 ça veut dire que c'est multi-plateforme ?

ça dépend ce qu'on entend par multi-plateformes

En tout cas Microsoft prétend que Windows est multi plates-formes

on l'oublie ce topic

les 'else' de Delphi c'est tout niqué !  

antp pris en flagrant délit de upping d'un topic mort!
Tsss!
A+,

else fait partie du if then, c'est tout

 
c'est moi qui l'ai uppé, pcq justement il faut conserver ce topic pour éviter que d'autres soient pollués

si t'aime pas les else, t'a toujours le case...c plus propre que des nested if/else

     
c'est de l'ada dans les fusées....