On est d'accord, les développeurs n'ont pas à avoir tout en tête, surtout sur des projets gros avec pleins de contributeurs. Pour moi l'ensemble des vérifications (statiques) sur le code, c'est le boulot du compilateur (typage et interface, y compris les schémas BD).
Je suis pas expert IDE mais je suppose qu'il y a potentiellement beaucoup de code redondant avec le compilateur pour faire pleins de vérification directement au niveau IDE (parsing, typage …).
Après sur toutes les tâches de d'accélération du codage (complétion …), de refactoring, et d'exploration du code c'est clair que l'IDE peut beaucoup aider.
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
incr_int(x)=x+1incr_float(x)=x+1.0
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
plus_int(x,y):int=x+yplus_float(x,y):float=x+y
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
plus(x,y)=x+y
est rejeté avec le message suivant:
Add a type annotation for a specialization in one of the following types:
int, int -> int
float, float -> float
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.
Ce n'est pas vraiment un logiciel mais le site citeUlike te permet de gérer une "librairie" d'articles, livres ... avec :
- gestion de tag (recherche et compagnie), notes
- stockage des fichiers (pdf ...),
- ajout direct des références à partir de la page référençant l'article (genre acm, ieee, en 1 clic tu ajoutes la reference complete dans ta librairie), l'ajout manuel restant possible
- exporter sa librairie au format bibtex ou autre
- d'accéder à des références d'autres personnes ayant les même centre d interets
- d'y accéder [d'ou tu veux] à condition d'avoir internet
Il suffit de créer un compte, éventuellement mettre les options "privé" si son travail est sensible.
[^] # Re: IDE
Posté par poluxmoon . En réponse au journal opa-watch: compilation et lancement automatique à l'édition. Évalué à 0.
On est d'accord, les développeurs n'ont pas à avoir tout en tête, surtout sur des projets gros avec pleins de contributeurs. Pour moi l'ensemble des vérifications (statiques) sur le code, c'est le boulot du compilateur (typage et interface, y compris les schémas BD).
Je suis pas expert IDE mais je suppose qu'il y a potentiellement beaucoup de code redondant avec le compilateur pour faire pleins de vérification directement au niveau IDE (parsing, typage …).
Après sur toutes les tâches de d'accélération du codage (complétion …), de refactoring, et d'exploration du code c'est clair que l'IDE peut beaucoup aider.
[^] # Re: "The Right Thing" vs "Worst is Better"
Posté par poluxmoon . En réponse à la dépêche Opa, un nouveau langage pour le développement d’applications Web. É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.
# GED personnel : librairie en ligne
Posté par poluxmoon . En réponse au message GED personnel. Évalué à 1.
Ce n'est pas vraiment un logiciel mais le site citeUlike te permet de gérer une "librairie" d'articles, livres ... avec :
- gestion de tag (recherche et compagnie), notes
- stockage des fichiers (pdf ...),
- ajout direct des références à partir de la page référençant l'article (genre acm, ieee, en 1 clic tu ajoutes la reference complete dans ta librairie), l'ajout manuel restant possible
- exporter sa librairie au format bibtex ou autre
- d'accéder à des références d'autres personnes ayant les même centre d interets
- d'y accéder [d'ou tu veux] à condition d'avoir internet
Il suffit de créer un compte, éventuellement mettre les options "privé" si son travail est sensible.