Après des années d’efforts, nous sommes heureux d’avoir libéré le code d’une nouvelle technologie Web nommée Opa. La licence choisie est la GNU Affero General Public License version 3 (AGPLv3).
Cette dépêche a pour but de vous expliquer ce qu’est, et n’est pas, Opa.
Opa, c’est quoi ?
Opa est une technologie de développement d’applications Web distribuées. C’est un nouveau langage de programmation fortement couplé à une bibliothèque Web standard qui remplit toutes les fonctions : de serveur d’applications Web, à serveur de base de données.
En un mot, Opa ne dépend pas des piles serveurs actuelles (à la Apache / PHP / MySQL / Symfony). Un code source Opa est compilé en un binaire autonome du service, qui se contente d’une distribution GNU/Linux nue (même micro) pour l’exécution.
Opa est spécialement conçu pour le Web et spécifie l’ensemble des aspects de l’application :
- le code client comme le code serveur sont écrits en Opa : le compilateur détermine automatiquement les parties client et serveur (des annotations existent pour lui forcer la main), traduit le code client en JavaScript et automatise les échanges entre client et serveur ;
- la structure de la base de données et les requêtes sont également écrites en Opa : là aussi, le compilateur analyse les requêtes pendant la compilation et génère le code d’accès aux données.
Pourquoi un nouveau langage ?
En développant Opa, nous avions deux objectifs :
- rendre le Web sûr (et en conséquence sécurisé) : pour cela, il fallait idéalement réécrire proprement l’ensemble des technologies serveur en une, pour minimiser la quantité de code nécessaire (et faire une implémentation propre) ;
- rendre le Web simple à programmer : nous voulions notamment distribuer automatiquement code et données… et cela imposait de fait un nouveau langage.
Mais le résultat est là : un Webchat distribué s’écrit (sans bibliothèque chat existante…) en 20 lignes de code en Opa, un Wiki guère plus… et déjà de nombreuses petites (et plus grandes) applications Web ont été très rapidement écrites en Opa.
Opa fait‐il le café ?
Désolé, mais non. Opa n’est pas fait pour écrire autre chose qu’une application Web ou un service Web. En effet, l’adhérence entre le compilateur et la bibliothèque standard est forte, et cette dernière est entièrement dédiée au Web. De même, le modèle applicatif est celui de serveurs distribués et de multiples clients qui discutent via les protocoles Web.
Opa n’est aujourd’hui pas non plus fait pour s’intégrer directement avec des langages ou des bases de données existants. Pas de liaison ODBC ou de sérialisation de valeurs PHP pour l’instant. La façon d’interagir avec l’existant est au niveau service Web, via SOAP, REST et / ou WSDL.
Le code, les binaires, la doc
Le code source d’Opa est maintenant disponible sur GitHub. Les premiers paquets (Debian / Ubuntu, tarball, Mac OS X) et la documentation sont disponibles sur le site opalang.org.
Nous espérons que vous allez rejoindre la communauté des développeurs Opa : nous serions ravis que vous développiez des applications en Opa, nous aidiez à créer des paquets pour votre distribution favorite, contribuiez à la documentation, et en parliez sur votre blog, si vous trouvez, comme nous, qu’Opa est la manière la plus plaisante d’écrire et d’exécuter des applications Web à l’heure du cloud ;).
Aller plus loin
- Site Opalang (1832 clics)
- Manuel Opa avec des exemples de code (1083 clics)
- Liste d’applications en Opa (603 clics)
- Dépôt sur GitHub (103 clics)
- La FAQ du projet (180 clics)
# Support des navigateurs
Posté par spider-mario . Évalué à 8.
Ça n’aime pas Konqueror et j’imagine que d’autres navigateurs sont délaissés.
À côté de ça, Wt supporte les navigateurs en mode texte sans JavaScript (en en profitant tout de même lorsqu’il est présent).
[^] # Re: Support des navigateurs
Posté par SigNix . Évalué à 4.
Je me suis toujours demandé combien de personne utilisait Wt car il est très pratique.
Quels serait les différence avec Opa en dehors du langage ?
Wt s’exécute très bien tout seul comme Opa.
Il est compilé comme Opa (mais à partir de c++ plus commun).
Peut-on utiliser des librairies externe dans Opa ?
Quels taille font les binaires (ça peut servir comme info sur des "Linux micro") ?
Bon dév a tous
L'initiative de simplifier la programmation web ne peut que favoriser un internet partagé alors bravo :-)
[^] # Re: Support des navigateurs
Posté par |-| . Évalué à 1.
Le mieux serait de mettre un ticket sur github pour le support Konqueror... voire un patch ;) En tout cas, cela doit être faisable assez facilement.
Pour les navigateurs sans JS, ce n'est pas la cible d'Opa et pour le coup l'adaptation serait grande.
Par contre, il me semble qu'Opa est beaucoup plus puissant pour écrire des applications web complexes, cf. http://www.webtoolkit.eu/wt/src/simplechat vs https://github.com/Aqua-Ye/OpaChat/blob/master/src/main.opa
[^] # Re: Support des navigateurs
Posté par MrLapinot (site web personnel) . Évalué à 5.
Quand même un peu plus des 20 lignes annoncées dans la dépêche pour le chat...
[^] # Re: Support des navigateurs
Posté par |-| . Évalué à 3.
C'est vrai que 20 lignes, c'est l'exemple de la home opalang.org qui a des fonctionnalités en moins que le lien que j'ai posté (sauvegarde de l'historique dans la db, date des messages, etc.).
[^] # Re: Support des navigateurs
Posté par SigNix . Évalué à 1.
Je ne suis pas sur qu'on puisse comparer ces deux codes car les objectifs et résultats ne sont pas les même. De même tout dépend ce qu'on appelle complexe.
Un point que je n'avait pas noter c'est le coté déploiement facile dans le cloud.
Si il est facile de se monter un cloud opa (avec répartition de charge ) ce serait un vrai plus de pouvoir coder son application et de la déployer d'une seule ligne comme dans la documentation (http://opalang.org/resources/book/index.html#_a_first_peek_at_opa)
L'API à l'air d'implémenter beaucoup de chose. Est-ce facile à étendre ?
Si Wt vise à implémenter une programmation MVD avec le système signal/slot type Qt, j'ai plus de mal à cerner Opa en dehors du fait que c'est objet (ou que ca y ressemble). Qu'en est-il de l'héritage, la sérialisation et autre joyeusetés ?
Existe-t-il d'ailleurs des plugins de coloration syntaxique pour Opa sur un IDE ?
Bon j’arrête avec mes questions et tenterais d'y répondre plus tard.
[^] # Re: Support des navigateurs
Posté par barmic . Évalué à 1.
Qu'est ce qui rend Opa plus simple à répartir que Wt ?
Tu peut très bien lancer 15 fois la même appli Wt et mettre un nginx en frontal.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Support des navigateurs
Posté par |-| . Évalué à 3.
Je ne pense pas que cela suffise à distribuer des applications.
Comment est distribuée la base de données avec nginx ? Que deviennent les sessions ? Dans le cas d'un chat, les messages que l'on verrait ne seraient pas les mêmes suivant le serveur... à moins que le code de l'application ne prenne en charge à la main cette distribution.
Un des aspects d'Opa est que cette distribution est faite automatiquement.
[^] # Re: Support des navigateurs
Posté par barmic . Évalué à 2.
La distribution de la base de données c'est quelque chose qui se gère dans le SGBD et pas dans l'application.
Je crois (je ne suis pas expert) que les sessions ne changent pas d'instance du serveur.
Oui tu a raison à moins de faire du polling de la base de données.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Support des navigateurs
Posté par Bruno Michel (site web personnel) . Évalué à 10.
J'ai quelques questions à ce sujet :
[^] # Re: Support des navigateurs
Posté par |-| . Évalué à 4.
Réponse oubliée dans le feu de la discussion... et pourtant ce sont d'excellentes questions.
L'application jetleague.com est actuellement déployée sur 14 machines Amazon.
Le code actuellement disponible permet l'utilisation d'un serveur DB partagé derrière plusieurs serveurs web en front-end (topologie "en étoile"). Ce type d'architecture simple n'engendre pas de surcoût en terme de communication réseau.
Nous sommes en train de travailler sur les fonctions de gestion avancée des bases de données Opa (réplication, distribution, élasticité). Nous avons des prototypes qui marchent mais n'ont pas été mis en production et ne sont pas sur "master" : on devrait pusher ça dans les mois qui viennent.
Pour les topologies "en étoile", tout dépendra du degré d'utilisation (notamment en écriture) des données partagées. Normalement, cela correspond à pas mal d'usages -- et nous sommes également en train de travailler sur les optimisations de la db -- les performances devraient encore rapidement augmenter dans les mois qui viennent.
[^] # Re: Support des navigateurs
Posté par Hugo . Évalué à 3.
Je vais tenter de répondre à certaines de tes questions:
Opa propose un mécanisme assez cool de 'binding'. Je t'encourage à parcourir l'annexe B du livre: http://opalang.org/resources/book/index.html#_bindings_with_other_languages
Pour résumer: Javascript et OCaml c'est gratuit (ou presque) et pour les autres langages, tu passes par OCaml. Le problème est que tu te retrouves avec du code; pas exécutable client ET serveur. (OK c'est pas toujours ce qu'on veut, mais bon ...).
Opa est un langage fonctionnel.
Les modes proposés sont Emacs et Vim:
http://opalang.org/resources/book/index.html#_setting_up_your_editor
[^] # Re: Support des navigateurs
Posté par Alex . Évalué à 4.
Je connaissais pas wt, c'est plutot sympa, surtout pour moi qui ne supporte pas le html (et qui suit donc une bille en dev web)
Par contre le choix de c++ m'étonne un peu, j'aime bien et j'utilise souvent ce langage, mais pour de la dev web ça me parait lourd.
[^] # Re: Support des navigateurs
Posté par fredix . Évalué à 8.
C++ lourd ? ca se voit que tu n'as jamais développé du web avec un langage script :)
[^] # Re: Support des navigateurs
Posté par GeneralZod . Évalué à 5.
Wt est destiné principalement au marche de l'embarqué donc sur des machines où les ressources sont très limités (puissance de calculs, mémoire etc ...) et l'intégration avec du code existant natif. On peut même dire que la cible de Wt sont surtout des développeurs C et C++ qui ont très peu l'habitude de travailler sur des applications web et donc Wt leur propose un environnement familier pour développer des applications web complexe et un tant soit peu robuste.
[^] # Re: Support des navigateurs
Posté par gnumdk (site web personnel) . Évalué à 2.
Oui, en même temps, de l'aveu même des devs KDE, KJS est une grosse merde...
Avec Webkit, cela fonctionne très bien.
[^] # Re: Support des navigateurs
Posté par spider-mario . Évalué à 1.
Pas chez moi.
# Mais sinon
Posté par windu.2b . Évalué à 10.
Ça marche bien, Opa ?
[^] # Re: Mais sinon
Posté par ᴼ ᴹᴬᴺᴺ . Évalué à 2.
Bist du meinen Enkel ?
207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶
[^] # Re: Mais sinon
Posté par Michaël (site web personnel) . Évalué à 3.
Bist du mein Enkel? :) Opa sollte wieder zur Schule! :)
[^] # Re: Mais sinon
Posté par rogo . Évalué à 3.
Opa, camarades, Opa, camarades, Opa Opa Opa.
[^] # Re: Mais sinon
Posté par bubar🦥 (Mastodon) . Évalué à 1.
Opa win fray
...
[^] # Re: Mais sinon
Posté par Grunt . Évalué à 2.
http://www.youtube.com/watch?v=yxhwyK9OJMI ?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# lisibilité
Posté par stopspam . Évalué à 10.
niveau compréhension, on repassera :
_
rest(topic) =
(
match HttpRequest.getmethod() with
| {some = method} ->
match method with
| {post} -> _ = save_source(topic, HttpRequest.get_body()?"") Resource.raw_status({success})
Quand je vois un truc comme ça et que je ne comprend pas, j'ai l'impression de passer pour le dernier des débiles.
Sans rire, est-ce que c'est :
* de l'ASCII Art ?
* un jeu où il faut trouver quel caractère spécial utiliser ?
* un besoin de créer une nouvelle profession ?
[^] # Re: lisibilité
Posté par |-| . Évalué à 5.
Effectivement, ce code devrait faire partie de la bibliothèque standard et aurait pu être écrit différemment... mais est tout de même logique.
Le pattern matching est une des features d'Opa.
La syntaxe actuelle est
match expr with
| pat1 -> e1
| pat2 -> e2
Les patterns sont le plus souvent des records qui sont une façon de faire du polymorphisme en Opa.
Ici { some = method } est un motif de record qui contient un champ some dont la valeur est method.
Il aurait été préférable d'écrire :
match HttpRequest.getmethod() with
| {some = {post}} ->
save_source(topic, HttpRequest.get_body()?"")
Resource.raw_status({success})
qui revient à compacter les deux pattern matching en un. Ici, on est dans le cas où getmethod renvoie un résultat et la méthode est post.
On exécute alors les deux intructions : save_source(...) et raw_status qui retourne la valeur success.
Au passage, le HttpRequest.get_body()?"" veut dire valeur de retour de get_body ou chaîne vide s'il y a une erreur.
Bien sûr, un langage doit être appris mais on s'y fait vite et si on aime, on a ensuite du mal à écrire autre chose ;)
[^] # Re: lisibilité
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
opa c'est de l'ocaml en fait ?
"La première sécurité est la liberté"
[^] # Re: lisibilité
Posté par |-| . Évalué à 2.
C'est un nouveau langage (avec un nouveau système de types notamment), implanté en OCaml.
[^] # Re: lisibilité
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
ce n'est pas de l'ocamlp4 ?
"La première sécurité est la liberté"
[^] # Re: lisibilité
Posté par Hugo . Évalué à 1.
Opa est loin d'être juste une sur-couche syntaxique à OCaml. (n'hésite pas à regarder le code source :) ). ocamlp4 est utilisé mais ça n'est pas significatif.
[^] # Re: lisibilité
Posté par Shuba . Évalué à 5.
C'est pas parce que ce n'est pas une syntaxe C-like que c'est illisible. Si tu as déjà fait des langages fonctionnels tels OCaml, ça se comprend assez bien.
[^] # Re: lisibilité
Posté par Victor . Évalué à 6.
Pour avoir fait du Caml ou du Scala (oui, un seul suffit :), c'est tout à fait lisible.
C'est juste de la programmation fonctionnelle en fait.
[^] # Re: lisibilité
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
le pattern matching de type n'est pas forcément fonctionnel, non ?
"La première sécurité est la liberté"
[^] # Re: lisibilité
Posté par Hugo . Évalué à 1.
De ce que je comprends de ta question, la réponse est non.
Pour préciser un peu: en OCaml et en Opa, le pattern matching se fait sur des valeurs et peut 'binder' (lier) des variables. On ne matche pas des types mais les valeurs d'un type.
Le pattern matching agit en profondeur: il permet de discriminer des valeurs structurées.
Même si le switch de C n'agit que sur des constantes, rien n'empêche d'imaginer une construction similaire pour ce langage ... non fonctionnel.
[^] # Re: lisibilité
Posté par Ontologia (site web personnel) . Évalué à 2.
Moi j'appelle ça du pattern matching de type, pas de valeur dans les types...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: lisibilité
Posté par Hugo . Évalué à 1.
Dans ton exemple, Plus et Nbr sont de type expre et pas de type Plus (ou Nbr), non?
Tu "matches" donc avec une valeur de type expre et pas un type.
Tu ne peux pas discriminer sur le type à runtime (int et float par exemple).
[^] # Re: lisibilité
Posté par Victor . Évalué à 2.
yep, j'ai fait un raccourci malheureux, le langage est fonctionnel, l'exemple est du pattern matching.
Et donc effectivement, comme répond Hugo juste après, on pourrait très bien imaginer du pattern matching en C.
Moins complexe, Scala n'est pas que fonctionnel, et a du pattern matching.
[^] # Re: lisibilité
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
J'ai souvent vu les 2 liés, mais je suis très étonné de ne pas le retrouver dans des langages impératifs.
"La première sécurité est la liberté"
[^] # Re: lisibilité
Posté par Hugo . Évalué à 2.
Je suis d'accord. D'autant qu'une fois qu'on y a goûté, on a du mal à s'en passer ... je dis 'on' je dis 'je'.
[^] # Re: lisibilité
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Cela évite pas mal de if alambiqué, si on ajoute à ça les map/fold, cela permet de se passer des boucles et autres if habituel responsable de tellement d'erreurs.
"La première sécurité est la liberté"
[^] # Re: lisibilité
Posté par opadikt . Évalué à 2.
Au niveau syntaxe, il y a quelques raccourcis par super intuitifs au début, mais très pratiques, voire addictifs à l'usage. J'ai juste deux exemples qui me viennent à l'esprit, là, maintenant, mais il y en a d'autres:
Les tildes: p.ex. le code ci-dessus aurait pu être écrit:
ou de façon équivalente (juste le pattern):
Le sucre, consiste juste à dire que
~aveut direa=aet~{a b c ...}veut dire{~a ~b ~c ...}. Dans cet exemple simple, ça ne paraît pas très utile, mais dans une grosse appli métier où il faut tout le temps matcher des gros records, ça sauve la vie.Les applications partielles:
en Caml, p.ex., si on écrit
On peut faire l'application partielle sur le premier argument, p.ex.:
Super. Par contre, si on veut faire l'application partielle sur le 2ème:
C'est l'échec.
En Opa.
C'est homogène, c'est joli, et quand on y a goûté, on a du mal comprendre pourquoi il n'y a pas ça partout.
Le système de type a quelques features assez cool aussi, mais je ne veux pas trop spoiler. Je vous laisse découvrir ;-)
[^] # Re: lisibilité
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"List.map(f(1, _), [1, 2, 3])"
Est-ce que cela passe à l'échelle ? comment faire pour appliquer 2 liste sur 2 paramètres d'un fonction ?
"La première sécurité est la liberté"
[^] # Re: lisibilité
Posté par Laurent Laborde (site web personnel) . Évalué à -1.
quand on connait erlang ca se comprend sans lire la doc :p
# JSF
Posté par barmic . Évalué à 2.
Je suis pas un grand fan de Java face à des langages comme python, perl ou ruby, mais pour ce qui est du web, je trouve le framework JSF particulièrement agréable. Il permet d'obtenir des interfaces web complexes de manière aussi simple que du HTML tout simple.
Je trouve l'idée excellente mais il n'existe pas d'alternative à ma connaissance dans d'autres langages. C'est bien dommage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Ocsigen
Posté par alfcemieukiti . Évalué à 2.
À noter dans le même style le projet Ocsigen qui utilise directement OCaml et qui est libre depuis le début. Je ne connais pas bien Opa (qui me semble très bizarre), mais en tout cas Ocsigen permet de faire des choses vraiment impressionnantes !
Ocsigen
[^] # Re: Ocsigen
Posté par |-| . Évalué à 1.
Bienvenue sur linuxfr.
Nous connaissons bien Ocsigen, qui est un framework web pour OCaml là où Opa est une approche différente : Opa est un nouveau langage dédié au web, ce qui permet de mieux gérer la distribution, d'avoir un système de types mieux adapté au web et inclut plus de composants, notamment la base de données.
Nous aimons bien OCaml, qui est probablement un des meilleurs langages pour implanter un compilateur : d'ailleurs, nous avons implanté Opa en OCaml (probablement le plus gros projet jamais développé dans ce langage) mais nous pensons qu'OCaml n'est pas le langage le plus adapté au développement web.
Maintenant qu'Opa est libre, comparez !
[^] # Re: Ocsigen
Posté par GeneralZod . Évalué à 5.
C'est le genre d'affirmations bancales qui a tendance à me rendre méfiant sur un projet.
C'est marrant de mentionner qu'Opa est en OCaml, parce que justement un projet concurrent en l'occurence haXe l'est aussi. Quelles sont les différences entre les deux frameworks (au sens large) ? Pourquoi ne pas avoir collaboré avec haXe ?
http://haxe.org/
[^] # Re: Ocsigen
Posté par |-| . Évalué à 4.
haXe est un projet très intéressant, écrit par quelqu'un que je n'ai jamais rencontré mais qui a énormément contribué dans la communauté OCaml.
Je pense que les objectifs sont différents : haXe étant un langage ayant pour but d'écrire des applications multiplateformes, en particulier des jeux.
Opa a pour but d'écrire des applications et services web distribués.
[^] # Re: Ocsigen
Posté par Christophe Turbout . Évalué à 3.
ça a l'air franchement différent comme principe quand même ...
je me sens aussi effectivement plus proche de haxe niveau syntaxe et philosophie
mais peut-on avoir un retour sur une vraie appli en dehors des quelques exemples
relativement triviaux fonctionnellement (mais pas simple côté syntaxe !!!)
comment se passe la gestion de la bd par exemple quand elle est lancée sur plusieurs
serveurs ?
avez-vous des benchs sur l'utilisation d'une appli avec les fonctionnalités et la charge
en fonction des utilisateurs histoire de se faire un peu une idée ?
car le cloud c'est super on peut vite monter en charge mais les tarifs montent vite
en charge aussi donc un peu de données concrètes c'est pas mal pour choisir une plateforme.
[^] # Re: Ocsigen
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Quel est la taille de Opa pour dire que c'est le plus gros en ocaml ?
"La première sécurité est la liberté"
[^] # Re: Ocsigen
Posté par |-| . Évalué à 3.
find . -name "*.mli" | xargs wc -l
32719 total
find . -name "*.ml" | xargs wc -l
174434 total
find . -name "*.opa" | xargs wc -l
64070 total
Et Js, C, scripts, etc.
Ceci dit, j'ai toujours été partisan qu'un logiciel bien écrit a le moins de lignes possible... et je peux vous assurer que c'est l'objectif qu'on a visé avec Opa. Les réécritures de parties du code ont notamment fait fortement diminuer le nombre de lignes du code d'Opa au cours des deux dernières années - et c'est une bonne chose.
[^] # Re: Ocsigen
Posté par Mehdi Dogguy . Évalué à 3.
En taille, ça semble plus petit que Coq (http://coq.inria.fr)…
$ find . -name ".ml" -or -name "*.v" | xargs wc -l | tail -n1
384130 total
J'ai compté les .v comme tu as compté les .opa. Sans les .v, ça donne :
$ find . -name ".ml" | xargs wc -l | tail -n1
202903 total
Après, parler de taille code n'est pas vraiment intéressant, je trouve.
[^] # Re: Ocsigen
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Il ne faudrait pas oublier MLDonkey quand même, qui est certainement le projet le plus connu en OCaml (et va fêter ses 10 ans cette année d'après Wikipédia).
[^] # Re: Ocsigen
Posté par Sufflope (site web personnel) . Évalué à 7.
Sans oublier des projets absolument pas grand-public, du genre des validateurs de programme d'ordinateur de bord de fusée... Donc l'affirmation me semble particulièrement audacieuse en effet.
# Base de données
Posté par barmic . Évalué à 9.
Il est dis qu'Opa gère la base de données. Qu'est ce que cela signifie ? C'est fait comme dans une bibliothèque type hibernate ou SQLAlchemy (de l'ORM pour langage fonctionnel) ou tente il de reconstruire la roue avec son propre SGBD ?
S'il se connecte à une base de données existante vers quel SGBD est-il compatible ?
Se limite il au SQL ou gère-t-il aussi des bases de données no-SQL ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Base de données
Posté par |-| . Évalué à 3.
Très bonne question.
C'est difficile à expliquer rapidement car cela change de l'existant, mais Opa est une technologie qui inclut tous les aspects de la programmation web, y compris la db.
Sur un schéma différent de ce qui existe, puisqu'il n'y a pas en Opa de "moteur de db" à runtime.
A la place, le code d'un programme en Opa spécifie la nature des données qui sont stockées de manière persistante, les accès en lecture et en écriture à ces données.
Lors de la compilation, le compilateur génère du code compilé pour accéder et modifier ces données sur le disque. Toutes les requêtes spécifiées dans le code d'une application Opa sont donc compilées statiquement et utilisent une bibliothèque de graphes distribuées, spécifique à Opa.
D'une certaine façon, cette "base" appartient au monde NoSQL, dans la famille des bases de données de graphes distribuées.
[^] # Re: Base de données
Posté par case42 (site web personnel) . Évalué à 3.
Et ca se passe bien quand je veux mettre a jour une application et que les structures de données ont quelque peu évoluées?
[^] # Re: Base de données
Posté par AltGr . Évalué à 2.
Les modifications simples sont gérées de façon automatique par le système (au lancement du programme, il présentera les modifications de base de données ; celles-ci sont appliquées si l'option --db-force-upgrade a été spécifiée).
Pour des modifications plus complexes, il est possible d'écrire un programme de migration qui fera la transition.
# Node.js
Posté par itwars (site web personnel) . Évalué à 0.
Dans le genre, il y a Node.JS, j'ai réalisé plusieurs articles sur mon blog sur cet outil : http://www.it-wars.com/categorie8/dev l'énorme avantage de Node.js est qu'il utilise Javascript, que tout le monde connait. On peut l'utiliser côté serveur et côté client !!! La "compilation" est réalisée par V8 engine de Google.
Il permet de réaliser des applications temps réel, utilise peut de ressource système, je le fais même tourner sur mon plugcomputer Seagate Dockstar à base de processeur ARM : http://www.it-wars.com/article181/installer-node-js-sur-le-seagate-dockstar !
Pour les infos regarder le repo GitHub de NodeJS : https://github.com/joyent/node ou le site http://nodejs.org/ !
[^] # Re: Node.js
Posté par GeneralZod . Évalué à 10.
Node.js temps-réel ? c'est la meilleure blague que j'ai entendu ce mois-ci.
Tu fais bien de préciser que Node.js utilise V8 qui utilise un garbage collector de type "stop-the-world" et incompatible avec le critère déterministe d'une application temps-réel (et ça ne qualifie pas pour autant le système sous-jacent).
[^] # Re: Node.js
Posté par Bruno Michel (site web personnel) . Évalué à 7.
En fait, dans le monde du web, temps-réel a une autre signification que dans l'embarqué. Ça veut principalement dire être capable de garder beaucoup de connexions ouvertes en parallèle pour être capable de pousser une information dès qu'elle est disponible. Les mots-clés sont streaming HTTP, long-polling, websocket, comet, etc. Et dans ce domaine, node.js se débrouille bien.
[^] # Re: Node.js
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 5.
Ça n'a rien à voir avec le web. C'est surtout une mauvaise compréhension de la part des journaleux et des marketeux qui ont utilisé cette expression à tort et à travers. En informatique, temps réel a une signification bien précise. Et avec du web, il est totalement impossible de faire du temps réel. Un peu comme en physique, un événement instantané ne peut pas exister. Mais on nous vend bien du café instantané.
[^] # Re: Node.js
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Et avec du web, il est totalement impossible de faire du temps réel.
Tu ne peux pas faire de temps réel dur. C'est vrai mais du "mou", tu peux: skype, streaming vlc, téléphonie ip, etc...
"La première sécurité est la liberté"
[^] # Re: Node.js
Posté par barmic . Évalué à 7.
Tu connais la différence entre le web et internet ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Node.js
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
y' aucun streaming vidéo purement web qui doit assurer un minimum de latence pour voir la vidéo sans saccade ?
"La première sécurité est la liberté"
[^] # Re: Node.js
Posté par barmic . Évalué à 3.
Et un bureau c'est fait en bois ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Node.js
Posté par |-| . Évalué à 2.
D'une certaine manière, beaucoup de personnes qui ont regardé Opa de près pensent que les deux "concurrents" d'Opa sont : Node.js et Scala+Lift.
Ce serait bien de construire un comparatif entre Opa, Node.js et Scala. A priori :
- le principal avantage de Node est de reposer sur un langage très connu
- le principal avantage de Scala est d'être compatible avec Java
- Opa et Scala sont bien meilleurs que Node en terme de détection d'erreur à la compilation et de qualité du code en général
- Opa est plus expressif que Node ou Scala
[^] # Re: Node.js
Posté par case42 (site web personnel) . Évalué à 1.
J'ai une question sur Opa que je ne savais trop ou placer alors je la mets la:
Moi j'utilise Node.js pour faire un serveur websocket. Est-ce qu'Opa pourrait faire ca aussi? Quid des performances comparées a V8 qui est quand même très agressivement optimisé, c'est le moins que l'on puisse dire.
[^] # Re: Node.js
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Un collègue me dit que Opa fait 80 requêtes/seconde sur un Hello World contre 1200 pour nodejs, et que ça leake pas mal de mémoire. Mais ça serait pas mal d'avoir un benchmark un peu plus sérieux.
[^] # Re: Node.js
Posté par Hugo . Évalué à 5.
Il est toujours difficile de comparer des solutions très différentes en terme de fonctionnalités. Le HelloWorld standard de Node.js met en oeuvre un serveur HTTP "brut" sans table de cookies ni logs. La page servie est une (courte) page HTML sans Javascript. En terme de fonctionnalités, ce test se compare donc plus légitimement à un serveur Apache -- ou encore au serveur HTTP bas niveau utilisé en interne par les serveurs Opa.
A l'inverse, le langage OPA est optimisé pour écrire des applications Web fortement dynamiques. Les pages servies par Opa incluent par défaut un runtime Javascript riche, permettant notamment de sérialiser en "temps réel web" des valeurs arbitraires du langage entre client et serveur.
Il y a quelques jours, nous obtenions les résultats suivants en utilisant "siege" sur différents "hello world" en mono-coeur avec un paramètre de concurrence 100.
Apache2/html 4200 0.023OPA HTTP server with no cookies and no logs 4000 0.025Node.js (has no cookies and no logs) 3600 0.028OPA HTTP server with cookies and logs 2900 0.034Apache2/PHP (has logs) 1800 0.055OPA server 1500 0.067A noter que le temps effectif de chargement d'une page dépend du temps d'exécution du runtime Javascript par le navigateur (non testé ici).
Il faut savoir aussi que les tests de type "siege" allouent un grand nombre de cookies en continue, ce qui se traduit par une fuite mémoire apparente. Différentes options sont disponibles pour limiter de façon conservative le nombre de cookies actifs à un instant donné. Un paramétrage plus sûr sera activé par défaut dans la prochaine release.
[^] # Re: Node.js
Posté par Victor . Évalué à 2.
Et puis Scala/Lift l'aspect web n'est que présent sous forme de librairie, dans Opa il semble que le compilateur soit "web-aware".
Ce qui permettrait des trucs bien à priori, mais qui à mon avis pourrait être expressible en Scala avec les types.
[^] # Re: Node.js
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
La partie client est compilé vers du javascript et la partie serveur ? En code natif ?
"La première sécurité est la liberté"
[^] # Re: Node.js
Posté par itwars (site web personnel) . Évalué à -1.
Le code est du javascript dans Node.js, mate les quelques exemples sur mon blog : http://www.it-wars.com/categorie8/dev. Tu fais ton script côté serveur, tu le démarres et il attends les requêtes sur un port, que tu attaques en direct ou via un proxy nginx par exmeple :)
Coté client tu utilises javascript avec du websocket ou autre pour communiquer avec la servelette du serveur :)
[^] # Re: Node.js
Posté par Hugo . Évalué à 3.
La partie serveur est effectivement compilée vers du code natif.
(en passant par du OCaml)
[^] # Re: Node.js
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
j'imagine que les performances doivent être assez bonne par rapport à du ruby ou du php non ?
"La première sécurité est la liberté"
[^] # Re: Node.js
Posté par Hugo . Évalué à -1.
Le rapport compilé/interprété est souvent en faveur du compilé, oui :)
[^] # Re: Node.js
Posté par itwars (site web personnel) . Évalué à 1.
Le problème de Scala, c'est l'overhead mémoire sur des machine cible a faible quantité de RAM. Sur le DockStar que j'utilise pour héberger mon blog je n'est que 128Mo et Node.js tourne nickel !
# THIS IS A DEMO. NOT LICENSED FOR ANY PURPOSE OTHER THAN EVALUATION.
Posté par Gui13 (site web personnel) . Évalué à 6.
En testant sur Mac, j'ai ce message quand le lance un serveur:
C'est à cause de binaires pas à jour ou bien?
[^] # Re: THIS IS A DEMO. NOT LICENSED FOR ANY PURPOSE OTHER THAN EVALUATION.
Posté par Hugo . Évalué à 3.
Ça, ça sent le paquet d'avant la release open-source. Je crois effectivement que tes binaires ne sont pas à jour.
# "The Right Thing" vs "Worst is Better"
Posté par Ontologia (site web personnel) . Évalué à 10.
Je reprend la typologie de http://www.dreamsongs.com/Files/AcceptanceModels.pdf
M'excuserez le franglais, que j'assume.
OPA :
Design model:
Implementation:
Environment:
Language requirements:
Verdict:
Même pour un type comme moi qui a qq milliers de lignes en ocaml (dont je suis loin de maitriser toute la syntaxe), la syntaxe d'OPA est vraiment bizare.
Sur IRC, il y a un mois, vous me disiez que vous pensiez à une syntaxe à la Java/C. Je ne suis pas sûr que ce soit indispensable.
Mais la syntaxe est vraiment à penser, les concepts derrières sont intelligents et puissant. Ya moins de sophistiction mathématique qu'en OCaml, et ça peut
aider à l'adoption.
Déjà, les dev sont habitués à mettre les template séparé du code.
Le template a aussi l'avantage d'être compréhensible du designer, et lui permet de mettre au point sa CSS dans son coin.
Je vois bien que c'est beau de mettre son code dans un seul fichier, mais c'est de la philosophie The Right Thing et pas Worst is Better ( http://en.wikipedia.org/wiki/Worse_is_better ). C'est toujours la seconde qui a marché.
Je vous comprend, je suis comme vous, je préfère The Right Thing mais la masse aime Worst is Better
La masse aime Céline Dion et Britney Spears aussi, hein.
Le concept
type message = { ... }
C'est trop camelien !
Pourquoi pas message is { ... } ?
C'est chaud à comprendre
C'est de la pure invention/impro, hein :-)
En gros, c'est une syntaxe à mot clé.
Ca, pareil, c'est trop camelien
Pour comprendre que c'est un pattern matching par défaut, bon courage...
Pitié, évitez de reprendre les opérateurs chiant de ocaml pour les flottants !
2. Le modèle de perf
On a pas trop d'info sur le modèle de perf.
Dans son modèle, Gabriel explique que le modèle de perf doit être simple. Ce qui signifie qu'en gros le langage doit être rangé dans la catégorie Rapide, Moyen ou Lent.
Mais les trucs du style Lent dans tel cas, rapide dans tel autre, les gens aiment pas trop...
3. Les concepts derrière
Il y a beaucoup trop de concept camelien derrière. Prenez 2 ou 3 dev web PHP de base, d'un niveau moyen, et cuisinez les 1 après midi chacun pour voir comment ils conçoivent l'architecture d'un site.
Quand on regarde le code, on a beaucoup de mal à comprendre dans quel sens ça tourne, et ça le dev de base, il a besoin de ça...
Vous verrez que le pattern matching, s'il est simple ça va, mais le _ -> toto(coucou) en plein milieu d'un code html , évitez..
Bon voilà, plein de choses à dire, mais critiquez d'abord mon intervention, on discutera :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par Hugo . Évalué à 2.
Effectivement, plein de chose à dire, c'est cool merci :)
J'aime bien la proposition de syntaxe pour le 'do' (sans être fan du '-') mais l'idée de créer une sorte de bloque "attentionjesuissequentiel" me plait bien (un peu à la OCCAM).
Mais pour le coup, pourquoi ne pas prendre le ';' pour un 'do'.
Ta proposition de te rapprocher de la syntaxe caml en enlevant les parenthèses et les virgules des appels de fonctions, perso je ne suis pas contre (ni pour, d'ailleurs), mais c'est justement ce qui peut alors perturber l'utilisateur lambda^W PHP.
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Au début, j'aimais bien le coté dépouillé des appels ocaml sans parenthèse ni virgule, puis, il suffit d'imbriqué 2 appels de fonction pour voir revenir les parenthèses, qui serait inutile avec virgule. Donc, bon.
C'est vrai aussi qu'il est plus facile de lire un code à mot clef. Je sais que la mode est de diminuer les mots clef mais essayer de lire un code ocaml à voix haute pour comprendre.
"La première sécurité est la liberté"
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par erdnaxeli (site web personnel) . Évalué à 0.
Pour du code vraiment sans parenthèses, allez voir du côté du haskell. Le « $ » et le « . » sont vraiment très pratiques.
Ceci en OCaml
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par ZankFrappa . Évalué à 1.
Y'a des trucs pour ça dans OCaml Batteries.
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
C'est moche par rapport à des virgules non ?
"La première sécurité est la liberté"
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par venator . Évalué à 1.
À titre de comparaison, en OPA on aurait :
ou bien — en utilisant les opérateurs « pipe »
|>et composition@:[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par poluxmoon . Évalué à 3.
Pour préciser un peu le fonctionnnement des opérateurs arithmétiques (+,-,etc) en Opa.
Ces opérateurs sont 'localement surchargés' pour être applicable à la fois à des entiers ou des flottants (comme dans la plupart des langages).
Cependant comme Opa est un langage avec inférence des types, de temps en temps il faut indiquer sur quel type de nombres travaillent les opérateurs (via les constantes et les coercions de type).
Par exemple
définit deux fonctions travaillant respectivement sur des entiers et des flottants en utilisant le même opérateur
+. Comme les constantes numériques (1 et 1.0) sont explicitement entières ou flottantes, le choix de l'opérateur (entier ou flottant) est automatique.Même remarque pour
où les coercions de type fournissent assez d'information pour déterminer le bon opérateur.
La surcharge ne se propage pas implicitement. Par exemple
est rejeté avec le message suivant:
En effet pour surcharger la fonction (ou l'opérateur), il faut l'indiquer explicitement dans la définition. (p.ex. @specialize_strict(Int.
+,Float.+) pour définir+).Pour l'instant on encourage pas l'utilisation de cette directive, car n envisage de faire évoluer ce mécanisme pour le rendre plus générique.
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par |-| . Évalué à 3.
Merci pour cette excellente analyse.
Je partage notamment tout à fait ce que tu dis sur le rôle de la syntaxe. Nous avons récupéré énormément de feedback à ce sujet lors de discussion précédentes, cf. http://dutherenverseauborddelatable.wordpress.com/2011/05/30/crowdsourcing-the-syntax/
Et nous avons une proposition de meilleure syntaxe que nous allons ajouter à Opa. La syntaxe actuelle sera conservée en plus, même si elle n'est pas mise en avant et nous proposerons des outils de traduction de syntaxe (dans un sens ou dans l'autre).
Pour le second point, la quantité d'information que l'on connaît sur l'application en tant que telle nous ouvre la porte à énormément d'optimisations que l'on peut faire -- pour être très très bons en perf. Notamment sur un mode sans optimisation, par défaut ce qui semblait être le critère pour la "masse" des développeurs web.
Pour les concepts, nous avons bien fait du field testing avec des développeurs PHP ;) Et en fait le concept d'interface à la Opa et de "tout est récursif à toplevel" passe très bien. Ce qui manque, c'est un bon IDE pour mettre ce concept en valeur, mais là aussi les travaux sont en cours et on sortira quelque chose prochainement.
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
L'IDE est vraiment primordial : recherche automatique dans la library, refactoring (création d'une méthode par sélection d'un bloc de code), génération du code des parties chiantes du langage (import java, et setter/getter par exemple), compilation à la volé avec signalement des 2 parties contradictoires.
La présence de toutes ces features est vraiment un énorme plus pour le développement.
"La première sécurité est la liberté"
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par barmic . Évalué à 1.
C'est là que l'on voit l'un des intérêts d'environnement comme Java et .Net qui intègrent plusieurs langages totalement compatible à l'exécution.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par Hugo . Évalué à 3.
C'est vrai ... mais au delà de plusieurs syntax, c'est plusieurs paradigmes !! C# et F# par exemple.
Après, plusieurs syntaxes pour plusieurs syntaxes, je ne (avis perso) suis pas forcément pour: au delà d'une certaine taille de projet, on passe plus de temps à relire et modifier le code des autres que de taper du code neuf. S'il faut se tordre le cerveaux car l'auteur utilise des choses qu'on lit mal ou pire qu'on ne connait pas ... on perd plus de temps qu'autre chose ...
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par qstone . Évalué à 5.
Magnifique pour un vendredi, une pièce de choix !
Tu m'apprends qu'en tant que "dev web", je suis "nul". Mais je reconnais que j'ai "du mal à comprendre qu'on pourrait faire mieux". Ce discours me rappelle exactement celui qu'on servait il y a quelques années à toute personne qui avait l'outrecuidance de ne pas être emballé et convaincu dès les premières secondes par le "fais-ton-moteur-de-blog-en-10min" de Ruby On Rails.
Mon gagne pain ce sont des appli métier de taille modeste (1 à 3 années.homme), en Java (boouh). Pas pour le plaisir de jouer les Pierre Tramo, mais juste parce que l'on peut faire des choses simples et pragmatiques avec les bonnes techno Java (comme JSF, déjà cité plus haut).
Comme je suis très intéressé par un "accroissement net de la productivité de la programmation" pour moi-même et mon équipe, je te serai infiniment reconnaissant de me démontrer en quoi ce changement de langage/paradigme/framework peut m'aider (pour simplifier, on négligera le temps de formation et le risque que je ferai prendre à ma boîte à miser sur un produit quasi inconnu avec lequel aucun "gros" projet n'a semble-t-il été encore réalisé)
Tu peux éviter de me répondre, t'en sortir par une pirouette ou même me moinsser, j'en tirerais la même conclusion, à savoir que la révolution du développement n'est pas encore pour demain...
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Disons que son expérience professionnel, lui a fait prendre conscience du niveau moyen du développeur web. Il y a des exceptions partout.
"La première sécurité est la liberté"
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par Bruno Michel (site web personnel) . Évalué à 6.
cough, ça fait déjà beaucoup de temps pour des applis de taille modeste. Je vis dans le monde Ruby on Rails et un projet de taille modeste, c'est plutôt 1 à 3 mois.hommes. Maintenant, je ne sais pas si c'est parce que nous avons des définitions différentes de "taille modeste" ou s'il y a un écart très significatif de productivité entre Rails et Java.
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pour information, linuxfr, c'est un projet de quelle taille ?
"La première sécurité est la liberté"
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par GeneralZod . Évalué à 1.
débuté en 2009, mise en production en 2011, do the math !
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par Bruno Michel (site web personnel) . Évalué à 4.
C'est toujours assez difficile de comparer un projet fait le soir où j'ai fait des choses qui sortent de mon domaine de compétences avec un projet professionnel fait dans de bonnes conditions.
Ça pris 2 ans et la CSS a été faite par un contributeur dans le cadre du concours. Je dirais à la louche que ça doit faire dans les 6 mois.hommes, mais vraiment à la louche.
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par qstone . Évalué à 8.
Les applications métier peuvent être très complexes, si le métier est complexe !
Quand tu fais un logiciel de gestion pour une profession assez spécifique, où on te balance un cahier des charges de plusieurs kilos (grammes, pas bits), et que tu peux pas vendre ton logiciel tant qu'il ne passe pas la certification qui sanctionne le respect du cahier des charges, t'es clairement pas dans le domaines de projets à 3 mois.homme
Je pense que ta remarque est très pertinente, car une bonne partie du débat est là : le "dev web" c'est autant le script kiddie qui va réécrire le nouveau moteur de blog qui va tout tuer, que le gars qui bosse en équipe de 100 ou plus sur des applis pharaoniques.
D'un côté de l'échelle, on n'arrive pas à appréhender une telle complexité, alors on voit ça comme des bandes de blaireaux qui se complaisent dans la complexité avec leurs technos pachidermiques et déplacées.
De l'autre, on a du mal à comprendre pourquoi à l'autre bout ça s'excite comme une puce à chaque fois qu'une nouvelle et obscure techno pointe le bout de son nez avec l'éternelle promesse, presque jamais tenue, de "tout écraser".
Différents besoins, différents outils, c'est tout. Si j'étais en SSII et qu'on me mettait sur un projet de 3mois.homme, je pourrais me dire "pourquoi pas". Là pour donner un exemple concret je dois ajouter à mon application une fonctionnalité toute bête sur laquelle je ne compte pas passer bien longtemps : je dois éditer des étiquettes avec un QRCode que je dois générer. En Java, je cherche vite fait, je trouve ça et grâce à Apache_Maven c'est fini avant de commencer. Avec opa, je commence par où ?
Pour te donner une idée sur un projet bien plus petit, car ça m'intéresse de pouvoir comparer, j'ai écrit un système de mise à jour automatique à distance de nos applications en 10j.h . Ca comprend le client de mise à jour en CLI, le serveur de mises à jour (bêtement une surcouche à https), une interface web d'admin. On upload les archives des releases et le client ne télécharge que le différentiel entre sa version en cours et la courante. Les accès sont contrôlés par un système de certificats électroniques (générés depuis l'interface d'admin), les mises à jour sont loguées et il est prévu (mais c'est pas fini) un mécanisme de remontées d'infos (stats) des machines client vers chez nous. 10 jours pour ça, ça me semble pas exagéré, non ?
Si tu sais estimer ça en Ruby, ça m'intéresse ! En fait je suis friand de nouvelles technos, c'est jusque que j'ai un côté pragmatique qui m'empêche de m'emballer trop vite. Mais si je peux concilier les 2, c'est encore mieux !
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Non, effectivement, ça paraît assez raisonnable.
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par Hugo . Évalué à 3.
Très bon argument en faveur de Java: la richesse des APIs proposés. J'espère qu'on arrivera à une telle richesse en Opa!
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par opadikt . Évalué à 1.
J'espère surtout que la communauté libre va contribuer ;-)
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par barmic . Évalué à 4.
Je pense que le développement web a une mauvaise image car il a commencé à exister assez tardivement avec des trucs assez basiques (mise en place de formulaire, création de lien plus ou moins dynamiques,...) avant de passez progressivement à ce qu'il est aujourd'hui : un domaine de développement complet avec ses concepts à lui, ses bonnes et ses mauvaises pratiques, ses technologies spécifiques, etc.
JEE a un ensemble d'outils hallucinants ce qui aide beaucoup le développement dans tout les domaines (Maven que tu cite en est un exemple important). Après personnellement j'aime pas le langage Java, je préfererais faire du JEE en groovy par exemple qui me permettrait d'écrire moins de code et de me prendre un peu moins la tête. Mais je comprends bien que dans l'entreprise où je travail, ils ne se lancent pas dans ce genre de choses au pied levé.
Là où les python/PHP/ruby ont un avantage sur JEE c'est dans leur légèreté au niveau par exemple pour le rechargement sans passer par JRebel.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Questions
Posté par Vassia . Évalué à 3.
Bonjour à tous,
Je ne suis développeur mais, curieux, je cherche à comprendre. Opa est séduisant, néanmoins je m'interroge :
[^] # Re: Questions
Posté par Hugo . Évalué à 3.
Opa est disponible sou deux licences:
* AGPL, et la communauté en bénéficie.
* Licence propriétaire et ainsi le financement d'Opa est assuré.
C'est possible. Après, un langage c'est un paradigme, une syntaxe et des APIs. Le point commun avec OCaml se trouve sur le paradigme et c'est tout. Le reste est encore à découvrir. Ceci dit, à toi de nous dire si tu 'rentres' dedans facilement :)
C'est une bonne question. Ces mêmes critères s'appliquent mais mon expérience de "gros" projet en Opa est limité. D'autres que moi sont plus à même de te répondre sur ce point.
Pas essayé. Mais si le compilateur OCaml cible une architecture, peu de raison que ça ne soit pas possible (le format des dates peut-être?)
Ça c'est pas moi :)
[^] # Re: Questions
Posté par Ontologia (site web personnel) . Évalué à 2.
On peut pas dire que je sois encore confirmé en Ocaml, mais ça commence à rentrer.
J'ai un peu joué avec Ocsigen, et je vais faire un gros site avec. C'est très bien pensé, mais assez extrémiste comme idée, son gros point faible est de ne pas pouvoir séparer les templates.
Autre gros point faible, c'est pas pensé pour AJAX, j'attend la 2.0 pour voir ça.
Sinon, c'est assez bien fait, le code est très conçis, avec une logique bien spéciale.
C'est vraiment à essayer, même si c'est pas évident au début.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Questions
Posté par |-| . Évalué à 1.
Tu es le bienvenu pour essayer Opa et faire une comparaison ;)
Les aspects Ajax et Web 2.0 sont gérés au coeur d'Opa puisque tous les échanges client/serveur sont automatisés avec un "slicer" qui sépare le code client du code serveur.
[^] # Re: Questions
Posté par |-| . Évalué à 1.
Concernant ARM, il faut :
1) Faire le port 32 bits d'Opa : ce n'est pas compliqué mais il faut le faire proprement car tous les clés de la db sont des int natifs, et en 32 bit on a vite fait le tour... Il faut donc porter une partie du code pour utiliser les int64 explicitement.
2) Ensuite, le portage sur ARM devrait être faisable, car notre backend gère la plateforme en théorie, ce qui veut juste dire qu'il faudra passer du temps à débugger certaines choses.
Sur les deux sujets, les contributions de la communauté sont plus que bienvenues !
En particulier, si on n'a pas fait le port 32 bits, c'est qu'il nous a été peu demandé par les utilisateurs d'Opa avant notre passage en open source, mais c'est une demande que l'on voit émerger rapidement.
[^] # Re: Questions
Posté par barmic . Évalué à 3.
Ça signifie que tout les « objets » (pas au sens « orienté objet ») persistés ont un clef uniques ? Quel que soit leur type ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Questions
Posté par Hugo . Évalué à 1.
Non. Les clefs de la db sont des chemins d'accès dans un arbre. Les int sont utilisés à l'intérieur des fichiers de stockage.
# Encore une comparaison avec une autre technologie (Erlang)
Posté par ZankFrappa . Évalué à 8.
Bonjour
Je suis assez impressionné, autant par l'ambition que vous affichez (une toute nouvelle plate-forme avec à la fois son langage de développement (qui est plutôt différent de ce que l'on trouve dans la nature), son serveur web, sa base de données…) que par les exemples disponibles sur votre site. J'ai déjà entendu parler du projet il y a plusieurs mois mais je n'ai jamais pris le temps de tester quoi que ce soit. J'espère que je ne serai pas déçu. ;)
J'ai une légère expérience du développement avec la technologie Erlang (un langage fonctionnel dynamique, orienté concurrence et distribution, qui tourne sur sa propre VM et affiche de bonnes performances dans l'utilisation côté serveur). Récemment, cette technologie a connu un certain succès, et les gens se sont mis à l'utiliser pour un peu tout et n'importe quoi (que ça soit légitime, comme des serveurs web ou des bases de données (CouchDB), ou pas trop, comme pour des frameworks web (Nitrogen)).
La première fois que j'ai entendu parler d'Opa, je me suis dit qu'il semblait être en concurrence (haha) directe avec Erlang, même si apparemment personne n'a fait de rapprochement pour l'instant. En effet, avec la plateforme OTP intégrée à Erlang, il est assez facile de produire des applications embarquant à la fois une base de données (comme Mnesia, qui est intégrée à la bibliothèque standard et qui tourne plutôt bien, ou d'autres bases plus traditionnelles), un serveur web (là ils sont légion : Inet, Yaws, Mochiweb… certains ont même de très bonnes performances), et un framework web (comme Nitrogen ou Chicago Boss — je connais à peine le premier, en réalité. Je trouve ses idées intéressantes mais il manque un peu de maturité à mon avis). De plus, le mécanisme de nœuds intégré au langage facilite la conception d'applications réparties (c'est transparent, du moins pour le développeur, de communiquer avec des processus légers situés sur un autre serveur).
Comment comparez-vous votre technologie à celle-ci ? Je pose cette question pour savoir si vous connaissiez déjà un peu Erlang (sans doute au moins de nom), et pour avoir votre opinion sur les deux univers. Je ne remets absolument pas en question votre travail : il y a bien assez de place pour les deux technologies, qui ne se disputent clairement pas un marché de niche. Mais je pense que c'est une interrogation légitime, car même si le développement web en Erlang est une idée encore assez jeune (et pas forcément des plus intéressantes), tout ce qui concerne le backend me semble en revanche plutôt fiable. Qu'en est-il pour Opa ?
[^] # Re: Encore une comparaison avec une autre technologie (Erlang)
Posté par opadikt . Évalué à 2.
Oui, Erlang est une super technologie et un modèle pour certains aspects d'Opa.
Le concept de session en Opa, par exemple, en est directement inspiré.
Erlang est aussi un modèle pour les aspects cloud, robustesse, qualité de service.
Actuellement, il y a encore du travail en cours sur ces aspects là dans Opa.
Mais dès maintenant, pour faire du web, je choisis Opa... ;-)
# j'ai pas pu tester
Posté par ybabel . Évalué à 0.
J'ai voulu installer, mais c'est que pour AMD64.
J'ai attrapé le code source, tenté de compiler mais il me demande "ocamlopt" ... bon après j'ai pas le temps de me lancer la dedans ... donc je stoppe en attendant un build pour x86.
[^] # Re: j'ai pas pu tester
Posté par ZankFrappa . Évalué à 1.
ocamlopt est le compilateur OCaml, si ça peut t'aider.
[^] # Re: j'ai pas pu tester
Posté par |-| . Évalué à 2.
Pour l'instant, le code ne compile que sur AMD64 - il faut faire une passe sur le code d'Opa pour porter certains entiers en 64 bits (au lieu de natif) pour que ça marche bien (ou alors la taille de la base sera très limitée et les dates risquent d'être mal gérées.)
Volontaires bienvenus ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.