[Mavie interest="average" skippable="true"]
Je suis en ce moment à la recherche du "langage idéal" pour mes ptits besoins (développer une appli client/serveur avec une belle interface graphique). Voici un aperçu de mes exigences :
- multiplateforme (au moins linux et ouinouin)
- permettant de créer une interface graphique (donc avec un toolkit multiplateforme aussi, genre GTK ou WxWindow)
- avec accès à une base MySql
- langage orienté objet, de "haut niveau" (exit le C/C++ !), pourquoi pas un langage de script d'ailleurs,
- syntaxe claire (désolé, mais Perl c'est au-dessus de mes forces !)
- raisonnablement rapide (Java, merci d'être passé, à bientôt)
La cerise sur le gâteau serait d'avoir un IDE complet avec création d'interface à la souris et tout et tout.
J'avais 2 candidats bien partis : FreePascal (et son IDE Lazarus, mais pour l'utilisation de MySql c'est la m---e) et PHP/PHP-GTK, super en plus je connais bien le PHP.
Pis voilà qu'au détour d'un coin sombre du net, je tombe sur Pike[1] ("brochet" en Anglais, d'ailleurs j'aime bien le brochet)
[/MaVie]
Pike est un langage de script, compilé en langage intermédiaire à l'exécution, avec une syntaxe proche de Java/C#, disposant de pas mal de modules en standard (Sql, GTK, etc.), existe pour Windows (installeur clicclicclic) et linux (j'ai cru lire quelque part que ce serait même dans les dépots Debian )
Halléluiah !
Pour modérer l'enthousiasme, il faut dire qu'il n'existe pas d'IDE (un fichier de config emacs est parait-il fourni), et y'a pas autant d'utilisateurs de Pike que de PHP ou Python par exemple.
[1] http://pike.ida.liu.se/(...) site officiel
Journal connaissez-vous Pike ?
11
mar.
2005
# j'y connais mais...
Posté par Philippe M (site web personnel) . Évalué à 3.
Born to Kill EndUser !
[^] # Re: j'y connais mais...
Posté par Nap . Évalué à 3.
De mon coté je me demande si gtk# marche sous win... quelqu'un a déjà essayé ?
[^] # Re: j'y connais mais...
Posté par Croconux . Évalué à 4.
Breveter peut être pas (je ne vois rien d'"innovant" dans une API qui puisse justifier l'acceptation d'un brevet). En revanche MS peut en changer n'importe quand et casser la compatibilité. Une réimplémentation des APIs d'un concurrent sera toujours à la traine par rapport à l'original. Ce sera toujours une version dégradée et je ne trouve pas que ça donne une bonne image du libre.
[^] # Re: j'y connais mais...
Posté par Thomas Douillard . Évalué à 2.
Le risque c'est surtout qu'ils créent une nouvelle API et que mono ne puisse pas suivre tout de suite, ce qui n'empècherait pas l'ancienne API de fonctionner toujours.
[^] # Re: j'y connais mais...
Posté par qstone . Évalué à 6.
Effectivement ton prof d'info a un peu abusé d'excitants, l'implémentation de Windows.Forms (l'API windows pour l'interface graphique) est loin d'être finie dans Mono. Sur le site ils parlent d'essais en couplant mono et wine, mais faut aimer les montages au chatterton !
# Projet en Pike : Caudium
Posté par Nim . Évalué à 4.
[private]
En plus c'est des anciens des dinos de l'iteam qui le maintiennent :)
[/private]
[1] http://caudium.net/home.html(...)
# Pike/Roxen
Posté par Psychofox (Mastodon) . Évalué à 2.
http://www.roxen.com/products/webserver/(...)
[^] # Re: Pike/Roxen
Posté par Psychofox (Mastodon) . Évalué à 3.
http://docs.roxen.com/pike/7.0/index.xml(...)
# Perl n'est pas assez clair? O_o
Posté par Mr_Moustache . Évalué à 7.
C'est une idée reçue de penser que tout programme Perl n'est pas maintenable ou complétement incompréhensible.
Perl est un langage très simple qui permet d'en faire ce que tu en veux comme tu le veux. Il est assez permissif mais peut être très strict.
La syntaxe en elle-même est semblable à n'importe quel langage du genre (PHP,...)
Je t'encourage a tenter d'écrire quelques lignes avec les pragmas suivant:
use strict;
use warnings;
Tu verras que tes programmes seront clairs.
[^] # Re: Perl n'est pas assez clair? O_o
Posté par pifou . Évalué à 5.
Pour en revenir au sujet du journal, je conseillerais à qstone d'essayer plutôt un langage comme Python ou Ruby (en attendant Perl6 peut être). Python à l'avantage d'être facilement abordable pour les personnes venant du monde procédurale (C, C++ ...) et d'avoir beaucoup de bibliothèques disponibles. Ma préférence va pour Ruby qui est totalement objet (aux structures de contrôles près) et qui permet une liberté d'expression assez formidable (tout en restant lisible à mon avis).
L'avantage du libre est d'offrir un grand choix de langage dans lesquels on trouve souvent son bonheur.
[^] # Re: Perl n'est pas assez clair? O_o
Posté par Antoine . Évalué à 2.
Python aussi est totalement objet.
>>> dir(-5)
['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__', '__delattr__', '__div__', '__divmod__', '__doc__', '__float__', '__floordiv__', '__getattribute__', '__getnewargs__', '__hash__', '__hex__', '__init__', '__int__', '__invert__', '__long__', '__lshift__', '__mod__', '__mul__', '__neg__', '__new__', '__nonzero__', '__oct__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__', '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__str__', '__sub__', '__truediv__', '__xor__']
>>> (-5).__abs__()
5
[^] # Re: Perl n'est pas assez clair? O_o
Posté par pifou . Évalué à 2.
Comment fais-tu déjà pour accéder à une méthode définie dans une classe mère (le super de Java, Ruby ...) ? super(Class, self).meth(args) ? ben dit donc ça ne fait pas tellement notation objet tout ça !
Comment fais-tu pour savoir si un objet contient bien une méthode ? hasattr(objet, "methode") ? ça fait pas objet non plus comme notation si ?
Bref, je ne vais pas refaire la discussion Python VS Ruby mais si ça t'interresse va regarder par là : http://linuxfr.org/comments/517442.html#517442(...)
Python et Ruby sont des langages de scripts mais la comparaison devrait s'arrêter là, ils n'ont pas du tout la même philosophie. Après qu'on préfére l'un ou l'autre c'est une question de goût, mais de la à dire que Python est totalement objet c'est un peu gros. Je pense que justement c'est une des forces de Python de ne pas être pur objet, ça permet à un plus grand nombre de développeur de s'appropier ce langage sans être perturber (par rapport à Ruby où tu peux par exemple redéfinir la méthode + de Fixnum pour réaliser une soustraction au lieu d'une addition).
[^] # Re: Perl n'est pas assez clair? O_o
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 5.
et ta méthode 'dir' elle est définie dans quelle classe ?
Les méthodes dir, super, hasattr se trouvents dans le module __builtins__.
Ce qui ne veut pas dire que python ressemble à l'orienté-objet auquel tu aspires mais bien que tout fait partie d'une classe.
[^] # Re: Perl n'est pas assez clair? O_o
Posté par jerome (site web personnel) . Évalué à 5.
En Python, tout est supposément un objet, avec, ou pas, propriétés et méthodes inhérantes à cette condition.
Voir http://www.python.org/doc/current/ref/objects.html(...)
N'en demeure pas moins que Ruby est un superbe langage.
Pour répondre à qstone plus particulièrement, peut être que python est une bonne réponse à ses attentes. Glade est un outil pour construire sa GUI en GTK, un petit coup de http://glc.sourceforge.net/(...) pour générer du python avec les bindings qui vont bien, C'est parti !
[^] # Re: Perl n'est pas assez clair? O_o
Posté par Antoine . Évalué à 2.
Et alors ? Comment fais-tu pour additionner deux nombres en Ruby ? x + y ?
Ca fait pas objet non plus comme notation si ? ;)
[^] # Re: Perl n'est pas assez clair? O_o
Posté par pifou . Évalué à 3.
class Fixnum def +(value) self*value end end puts 2+3 # 6 puts 2.+(3) # 6Bref la syntaxe 'x + y' est une forme raccourci de la syntaxe objet 'x.+(y)'.[^] # Re: Perl n'est pas assez clair? O_o
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Perl n'est pas assez clair? O_o
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 2.
Puis sans compter les len(machin) trop laid
En fait, len(machin) c'est exactement comme le + de ruby. C'est une façon simple d'écrire quelquechose qu'on pourrait très bien écrire façon objet : machin.__len__().
On aime, on aime pas mais qu'on ne vienne pas dire que ce n'est pas objet parceque c'est aussi faux que de dire que "2 + 3" n'est pas objet en ruby.
Enfin bon, python était pas fait pour être objet au départ, et ça se voit.
C'est sûre, il y a des "restes", essentiellement c'est la présence des self partout. Mais au niveau OO, il a sacrément bien évolué et est devenu un langage complètement OO.
Personnellement, si je devais râler sur quelque chose, ce serait plutôt sur l'ajout des décorateurs qui s'est fait dans la version 2.4. Je n'en conteste pas l'utilité mais je trouve la syntaxe choisie très moche et surtout pas du tout explicite.
[^] # Re: Perl n'est pas assez clair? O_o
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
Non, si c'était pareil on pourrait faire un machin.len(), pas un machin.__len__() ... Ca fait une sacrée différence. S'il faut modifier l'analyse syntaxique/lexicale à chaque fois qu'on veut une nouvelle methode sous pretexte qu'on veut un raccourci, on est mal barré tiens...
Et j'utilise python, je tente de faire de l'objet avec, mais faut pas pousser mémé, ruby c'est quand même beaucoup plus propre pour ça (et que ça me pousse même à m'y mettre doucement). Le seul truc c'est que actuellement j'ai des besoins de perfs et ruby, c'est pas encore l'extase pour ça.
[^] # Re: Perl n'est pas assez clair? O_o
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 2.
S'il faut modifier l'analyse syntaxique/lexicale à chaque fois qu'on veut une nouvelle methode sous pretexte qu'on veut un raccourci, on est mal barré tiens...
Donc en ruby, si on définit la méthode 'plus' qui comme son nom l'indique additione deux nombres. On peut faire "x plus y" et on aura "x + y" ? Je l'ignorais, je vais quand même l'essayer parcequ'alors là je serais épaté.
Bon j'ai jamais fait de ruby donc soyez indulgents:
Il semblerait donc bien certains opérateurs en ruby sont traités différement que s'ils étaient de simples méthodes. Donc l'analyse lexicale est différente pour ceux-ci, donc je revendique à python le droit d'ajouter à cette liste le raccourci len !
Et j'utilise python, je tente de faire de l'objet avec, mais faut pas pousser mémé, ruby c'est quand même beaucoup plus propre pour ça (et que ça me pousse même à m'y mettre doucement). Le seul truc c'est que actuellement j'ai des besoins de perfs et ruby, c'est pas encore l'extase pour ça.
Goûts, couleurs, tout ça ... Moi par exemple, j'adore python mais je lui préfère quand même le scheme par ce qu'il pousse (c'est un euphémisme) à la programmation fonctionnelle, qu'on peut faire de l'OO avec, que le développement est encore plus rapide avec, mais bon c'est pas demain la veille qu'il sera un standard de l'industrie (malgré le fait qu'il puisse être assez rapide).
[^] # Re: Perl n'est pas assez clair? O_o
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
Pour scheme on s'en fiche, il ne joue pas du tout dans la même cours, alors que ruby et python eux ont plutôt tendance à être au même niveau.
[^] # Re: Perl n'est pas assez clair? O_o
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 1.
Tu le fais exprès ou tu n'arrives pas à voir la différence entre un opérateur de base (+ - * etc) et des fonctions telles que len() ou str() ? (str() int() etc en python, non merci...).
Ben je dois vraiment être con faut croire. Mais non, je ne vois pas de différence entre (+ - * / etc) et les fonctions len, str, int ... tout ce que tu veux.
Pourquoi dans un langage qu'on définit comme full OO, faire de différence entre certaines méthodes ? Ou places tu la barre ? La limite que tu imposes est arbitraire et donc ton argument n'est alors qu'affaire de définition.
Et d'ailleurs, ce genre d'argument, on pourrait aisément le transformer en un "Mais tu le fais exprès tu ne vois pas de différences entre les types de base (int str list etc) et les types tels que listes triées, chaine en majuscule, ..." pour justifier le non héritage des types de base (ce qui est mal TM).
Pour scheme on s'en fiche, il ne joue pas du tout dans la même cours, alors que ruby et python eux ont plutôt tendance à être au même niveau.
Je n'ai mentionné le scheme que pour faire écho à mon "Les goûts, les couleurs", car mon gout est de préférer le scheme qui est effectivement dans une autre cour.
Mais finallement dans l'argument, il a quand même sa place car lui sa pureté ne peut pas être prise en défaut. Il y a les literaux et il y a les fonctions. Point barre après tu te débrouilles, pas de fonctions spéciales, pas d'opérateurs particuliers qui méritent un traitement différent, rien ...
[^] # Re: Perl n'est pas assez clair? O_o
Posté par pifou . Évalué à 2.
- La méthode commence par un symbole non alphanumérique (*, +, -, ', =, %, /, >, < ...) : notation pointée facultative pour permettre une écriture plus conventionnelle des opérations (arithmétiques, booléennes ...)
- La méthode commence par un symbole alphanumérique : obligation d'utiliser la notation pointée : 2.plus 3
Après pour éviter cette "bidouille" il n'y a qu'un seul moyen propre, c'est de faire comme dans SmallTalk et préférer la notation "objet méthode" à la notation pointée "objet.méthode". Hélas, Ruby devant être compréhensible par un développeur lambda (comme Python) il parait logique d'éviter de perturber ce dernier en lui imposant une syntaxe trop particulière même si cette dernière est finalement plus propre (et surtout plus facile à parser :). C'est dans le même but que dans Ruby les structures de contrôles (if-then-else, while ...) ne sont pas des méthodes des classes True et False.
De toute façon, plus j'utilise de langage objet (Java, Eiffel, C++, C#, Python ...), plus je me rends compte qu'ils évoluent de plus en plus vers SmallTalk. Bref, je suis sûr que si demain Microsoft (ou un autre grand éditeur) resortait SmallTalk tout le monde trouverait ça merveilleux. Bref, SmallTalk est sortit 30 ans trop tôt :/.
Pour en revenir à Ruby et Python, ça n'est pourtant pas difficile de comprendre la différence de philosophie : un de ces 2 langages a été conçus dès le départ pour être un langage de script objet et l'autre non. Du coup, Python se retrouvent à trainer une compatibilité qui nuit à mon avis à son évolution vers du full OO. Mais d'un autre coté comme je l'ai dit plus haut, c'est surement ce qui a permis à Python d'être autant utilisé à travers le monde aujourd'hui, il a réussi à fédérer les gens vennant du monde procédurale (C...), du scripting (Shell, Perl ...) et du monde objet (Java, C++ ...). Python est le vrai premier langage de script orienté objet à avoir su s'imposer face à Perl. C'est l'étape décisive avant de pouvoir convertir les gens à des langages full OO.
Enfin, je ne comprend pas cette levée de bouclier des gens faisant du Python quand on dit que Ruby est beaucoup plus orienté objet que leur langage préféré. Ce n'est pas obligatoirement un mal. Ça me fait pensé à cette époque pas si lontaine où on n'avait pas le droit de critiquer Java en tant que langage objet.
Bref, cette discussion commence à me fatiguer ... je vais me coucher :)
[^] # Re: Perl n'est pas assez clair? O_o
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 2.
C'est pourtant pas très difficile, il y a 2 cas :
- La méthode commence par un symbole non alphanumérique (*, +, -, ', =, %, /, >, < ...) : notation pointée facultative pour permettre une écriture plus conventionnelle des opérations (arithmétiques, booléennes ...)
- La méthode commence par un symbole alphanumérique : obligation d'utiliser la notation pointée : 2.plus 3
Je sais faire la différence, mais l'astuce c'est qu'elle réside uniquement dans les yeux de celui qui regarde car comme tu le dis plus loin, cette différence est une "bidouille" (tout à fait acceptable et même bienvenue, j'en conviens).
Donc pour résumé moins point de vue:
- une fonction est une fonction qu'elle s'appelle "+" ou "plus"
- pour simplifier la vie des programmeurs il existe des bidouilles (+,-,*, ...)
- len en python est une de ces bidouilles.
Ce n'est donc pas à ce niveau que python est moins OO que ruby à d'autres pourquoi pas, je ne connais pas assez bien ruby pour en parler. Mais à ce niveau là sûrement pas, puisque conceptuellement ils font la même chose.
Enfin, je ne comprend pas cette levée de bouclier des gens faisant du Python quand on dit que Ruby est beaucoup plus orienté objet que leur langage préféré. Ce n'est pas obligatoirement un mal. Ça me fait pensé à cette époque pas si lontaine où on n'avait pas le droit de critiquer Java en tant que langage objet.
Tu sais moi que python soit plus ou moins object que ruby je m'en balance, les gens utilisent encore ce qu'ils veulent. Ce qui m'importe dans cette histoire c'est qu'on ne dise pas de trucs qui sont visiblement faussés par un a priori.
[^] # Re: Perl n'est pas assez clair? O_o
Posté par Jean Canazzi . Évalué à 3.
C'est moins lisible mais ça fait bien objet :-)
[^] # Re: Perl n'est pas assez clair? O_o
Posté par qstone . Évalué à 6.
C'est une affaire de goûts, mais plus un langage propose des raccourcis indigestes, moins je l'aime. OK on n'est pas obligé de les utiliser, mais ça veut dire que tôt ou tard on y aura affaire (exemples de code sur le net, etc.).
J'aime pas le if-then-else raccourci du C (et dérivés) (test ? actionSiVrai : actionSiFaux)
Du peu de tutoriel Perl que j'ai lu, y'avait déjà trop de $%, $$a et autres $_ à mon goût. J'ai décroché quand j'ai vu qu'on pouvait remplacer les délémiteurs usuels par d'autres (pour définir les chaines caractères, un truc du genre qq!chaine! )
Je suis d'accord pour dire qu'on peut écrire de bons softs bien propres en Perl, mais personnellement je n'accroche pas.
[^] # Re: Perl n'est pas assez clair? O_o
Posté par Croconux . Évalué à 3.
Le gros problème d'un langage permissif qui autorise whatmille astuces de syntaxe c'est que pour maintenir le code d'un autre développeur il faut maitriser toutes les astuces que les autres développeurs ont pu utiliser. Dans une boite on peut imposer des coding rules mais dans le cas de logiciels libres developpés par des équipes différentes, au final il faut connaitre chaque subtilité du langage car sur le nombre de personnes la quasi totalité des possibilités sera utilisée. Plus la langage propose d'astuces et plus c'est le bordel (C++ ?).
L'autre chose que je reproche à Perl et à plusieurs autres langages c'est cette manie de vouloir optimiser au maximum le nombre le nombre de caractères à taper. Je préfère un code plus expansif qui se lit sans difficulté qu'un truc qui fait la même chose en une ligne et qui demande un grand effort de lecture. Et ça se ressent jusque dans le nommage des variables et méthodes. Là au un perliste ou un C-iste écrirons des "authusr()", en Java, Pascal ou autre on préfèrera appeler la même méthode "getAuthentifiedUser()". C'est plus long à taper mais ça se lit tout seul. Il faut garder à l'esprit qu'en général mis à part pour du code jetable, une même ligne de code sera écrite une fois mais relue des dixaines de fois et ce par moultes personnes différentes. Dans ma boite, on a une grosse appli métier codée en Delphi et même un marketeux ne sachant pas programmer est capable en regardant le code de dire ce que ça fait.
[^] # Re: Perl n'est pas assez clair? O_o
Posté par Mr_Moustache . Évalué à 3.
Et pour comprendre un code, on peut y placer des commentaires.
En ce qui concerne les conventions d'écriture, le problème sera le même avec tous les langages. Ce sont des conventions, chacun fait ce qu'il veut (surtout dans le cas du nommage des variables et des fonctions).
Je n'omais aucunement les divers problèmes qu'entraine l'utilisation du Perl.
En l'occurence, ce n'était pas le sujet. On peut trouver des choses à redire à chaque langage, c'est ce qui fait qu'il y en a autant.
Je me bats contre une idée reçue précise.
# Python
Posté par Sébastien Munch . Évalué à 5.
Il fait tout ce que tu dis, et même plus !
[^] # Re: Python
Posté par blobmaster . Évalué à 4.
http://c2.com/cgi/wiki?PythonIde(...)
http://www-106.ibm.com/developerworks/linux/library/l-pide/(...)
J'aime bien BOA...
Et puis n'oublios pas quelques liens que j'aime bien :
http://www.ogre3d.org/modules.php?op=modload&name=Downloads&(...)
http://www.progx.org/index.php?section=articles&article=Python/(...)
http://www.linux-center.org/articles/9812/python.html(...)
http://www.zope.org/(...)
http://fr.diveintopython.org/(...) (qui semble mort aujourd'hui mais ne l'était pas hier)
[^] # Re: Python
Posté par icyfemur . Évalué à 3.
C'est un peu plus scrict, mais il faut savoir qu'un compilateur scrict permet d'éviter bien des erreurs à l'exécution... cf Ada par exemple. Dommage que pour ce dernier, il n'existe pas plus de bibliothèques.
Une autre chose que je reproche à Java, Python et à Ada, c'est le problème des imports circulaires. Si le fichier A a besoin du fichier B, et réciproquement, et bien il faut faire des ruses de sioux pour que ça marche. En Java, à ma connaissance, il n'y a pas ce problème. Qu'en est t'il de C#, que je n'ai jamais essayé ?
[^] # Re: Python
Posté par . Takhi . Évalué à 5.
[^] # Re: Python
Posté par Antoine . Évalué à 3.
Ah ?
$ cat > a.py
aa = 5
from b import bb
print bb
$ cat > b.py
bb = 6
from a import aa
print aa
$ python a.py
6
5
6
$ python b.py
5
6
5
(bon, le double print est un peu bizarre...)
# Eiffel, Ruby
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
D'abord, deux langages différents qui répondent à tes critères :
- Eiffel qui un langage objet de haut niveau, de typage statique, qui supporte la généricité, la covariance, la conception par contrat, l'héritage multiple (finement géré) et qui a une syntaxe simple et claire. Avec l'édition communautaire ou free d'EiffelStudio (http://www.eiffel.com/downloads/)(...) tu as un IDE multi-plate-forme, et bien fournie. Sinon tu as la distribution libre d'Eiffel: SmartEiffel auquel tu dois rajouter des lib extérieures comme Gobo par exemple. Un point supplémentaire à Eiffel : il s'interface facilement avec du C (normal, le compilateur applatit le tout en C de façon transparente).
- Ruby qui est aussi un langage objet de haut niveau, de typage dynamique , qui supporte l'héritage simple, les closures, ..., et qui a une syntaxe claire. Tu as un plugin pour développer en Ruby avec Eclipse. A la différence de Python, la documentation des lib est claire et tout est vraiment objet (il n'y a pas de fonctions ou procédures qui se baladent tout seules comme ça). Le crédeau de Ruby : prendre plaisir à programmer (être le meilleur ami du pogrammeur).
[^] # Re: Eiffel, Ruby
Posté par GuieA_7 (site web personnel) . Évalué à 1.
Pour Eiffel, dont j'ai entendu beaucoup de bien, il me semble avoir lu qu'il y avait quelques incompatibilités génantes entre la version officiellle et la version libre SmartEiffel. Qu'en est-il vraiment ??
[^] # Re: Eiffel, Ruby
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
De plus la syntaxe 'EXPRESSION if CONDITION' vient en fait de Perl et elle n'est pas moche. Elle est même claire lorsque tu la lis (si l'expression est évidemment courte). Par contre que tu ne l'apprécies pas est autre chose, c'est une affaire de goût.
Sinon, pour Eiffel, il y a effectivement des petites différences chiantes entre les librairies de SmartEiffel et celles officielles (standardisées) qui ne sont en fait que des lib de bases !
Mais là où ça se gâte est qu'il n'y a pas de standardisation avec les libs souvent utiles pour les dev de tous les jours (par exemple sur les collections/containeurs). Aussi, chaque fournisseur (VisualEiffel, SmartEiffel, etc.) développent chacun à leur façon les libs supplémentaires. Gobo a tenté de fournir une réponse à cette problématique en définissant des librairies pour quelque soit le compilateur Eiffel.
Le problème avec SmartEiffel est que c'est une distribution pour la recherche et donc elle introduit pas mal d'incompatibilités par rapport à l'"officiel" sachant en plus que Eiffel est en cours de standardisation à l'ECMA et que de nouvelles caractéristiques sont définies. Et chacun l'implémente à sa façon.
Exemple sur les agents : SmartEiffel l'implémente avec une structure contravariante tandis que VisualEiffel l'implémente avec une structure covariante. Bien sûr, conceptuellement chacun a raison même si la version de SmartEiffel me parait plus ... propre.
[^] # Re: Eiffel, Ruby
Posté par jcs (site web personnel) . Évalué à 3.
La version 2.1 du compilateur est sortie début février et comprend désormais un support réseau (certes minimaliste) dans l'API standard.
[^] # Re: Eiffel, Ruby
Posté par mmMMOoooOMMmm . Évalué à 2.
# Java ?
Posté par Antonio Da Silva (site web personnel) . Évalué à 3.
On peut connaitre les fondements de ta remarque ? Si ce n'est le vieux mythe de 'Java s'est lent' ?
regarde un peu http://www.thinlet.com(...)
[^] # Re: Java ?
Posté par qstone . Évalué à 4.
L'outil est destiné à fonctionner sur des ordinateurs pas récents ( 5 ans et plus, donc faut pas s'attendre à avoir énormément de ram), pas forcément entretenus (=pas mal de saloperies au démarrage), etc.
Dans ce contexte, oui java c'est hyper-lent, au moins à démarrer (charger la jvm etc.) surtout quand il s'agit d'applis graphiques. Il y a très peu d'algos ou de calculs complexes sur lesquels les différences serait moins évidentes.
J'aime énormément java, je trouve ça très clean, mais quand je dois faire une appli qui doit être déployée sur des machines pauvres en ram, j'hésite.
J'essaierai thinlet à l'occasion, je ne connaissais pas (j'ai surtout utilisé AWT)
[^] # Re: Java ?
Posté par Antonio Da Silva (site web personnel) . Évalué à 3.
Tu aurais pu l'indiquer dans la demande, ça ne lui aurait pas nui.
Autre piste, pour faire du graphique et de l'accès à Mysql : rebol ( http://rebol.com/(...) , http://www.rebolfrance.org(...) ) plus le driver mysql libre ( http://www.softinnov.org/rebol/mysql.shtml(...) )
[^] # Re: Java ?
Posté par Pinaraf . Évalué à 2.
De plus, le défaut de Java c'est que swing sous linux c'est... merdique on va dire : pourquoi ils utilisent pas qt ou gtk plutôt que de tout coder le toolkit eux même ? :(
[^] # Re: Java ?
Posté par Franck . Évalué à 3.
[^] # Re: Java ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
oui Java est peu performant en consommation mémoire (surtoût) et CPU (dépend de l'appli et de la JVM).
Dire que Java est lent n'est pas un mythe c'est une réalité mais cela vient principalement de la JVM. Par exemple, une JVM d'IBM te produira des performances qui peuvent remettre en cause l'assertion "Java est lent".
Par contre la force de Java est donné par son but : "write once, run everywhere", par sa syntaxe simple et compréhensible par bcp de monde (parce que dérivé du C), et de s'appuyer sur des conceptions à peu près compréhensibles par bcp.
# en conclusion...
Posté par qstone . Évalué à 1.
Pour la petite histoire, je vais donc certainement développer mon appli avec Pike, sa syntaxe et sa logique me vont très bien :o) J'avais pas vu si bien depuis Java (couché le Troll, couché ! C'est une appréciation personnelle ici !)
Si jamais j'ai donné des idées à certains, sachez que le mieux (que j'aie trouvé à ce jour) pour éditer du Pike c'est jEdit (ok y'a Emacs, m'enfin...bon... Oh et puis j'en ai marre des trolls !).
http://www.jedit.org site de jEdit
http://www.update.uu.se/~peterl/html/sub_hobbies/comp/articles/jEdit/ l'article de Peter Lundqvist sur l'utilisation de jEdit pour Pike
En bonus gratuit supplémentaire : quelques plugins pour jEdit à ne pas rater :
- ProjectViewer : pour gérer un projet
- BufferTabs : afficher les fichiers ouverts sous forme d'onglets (cf. photos d'écran de Peter Lundqvist)
- Console : pour exécuter vos fichiers sans quitter jEdit
- ErrorList : pour récupérer les messages d'erreur de la console comme tout IDE qui se respecte
# Ferite
Posté par Marc Quinton . Évalué à 1.
[^] # Re: Ferite
Posté par qstone . Évalué à 1.
Par contre dès qu'on part vers ces langages, la documentation fait cruellement défaut. Pike ça va, mais il parait que c'est loin d'être à jour, Ferite c'est assez succint, freepascal et lazarus c'est pas la joie non plus... Dommage !
[^] # Re: Ferite
Posté par Marc Quinton . Évalué à 1.
Ferite est le petit frere dans le sens ou il semble moins aboutit. Voila ce que je voulais dire.
# Capitaine Pike
Posté par Bruce Le Nain (site web personnel) . Évalué à 1.
Il est amusant de penser qu'en France, cette série n'a jamais percé (ou plutôt ces séries, car durant ces 40 dernières années il y a 5 séries basée sur cet univers, 10 longs-métrages, et des dessins animés) . Au contraire, elle a été dépréciée à tel point qu'il était ridicule ne serait-ce que de la conaître. Mais une fois la frontière passée, cette ségrégation tombe.
Malheureusement, un univers aussi riche, complet et prolifique que celui de Star Trek devrait être sous licence libre ;) Mais cet univers est protégé par la paramount, qui ne compte certainement pas le lâcher comme ça.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.