L'année 2011 va bientôt arriver et je souhaite partager avec vous quelques suggestions de langages pour ceux qui voudraient suivre ce conseil :
- Ruby (disponible sous Licence Ruby et GPL) reste mon langage préféré et je ne saurais trop vous conseiller de le découvrir !
- Reia (disponible sous licence MIT) est un langage avec une syntaxe inspirée de Ruby qui tourne au-dessus de la machine virtuelle d'Erlang, permettant ainsi de profiter du meilleur des deux mondes.
- Go (disponible sous Licence BSD) est un langage assez jeune mais déjà très intéressant, avec notamment la programmation concurrente à base de Goroutines.
- Io (disponible sous Licence BSD) est un langage de programmation qui s'appuie sur les prototypes, avec des inspirations venant de Smalltalk, Self, Lisp et Lua.
- Scala (disponible sous Licence BSD) pourrait être le futur pour les développeurs Java et propose déjà des avancées très pertinentes comme son modèle d'Actors ou son travail sur le typage.
- F# (disponible sous Licence Apache) est un langage de programmation fonctionnelle, fortement inspiré d'OCaml et issu des laboratoires de Microsoft.
Au fait, je n'ai pas encore choisi quel langage j'allais étudier en 2011, donc n'hésitez pas à défendre votre langage favori dans les commentaires ;-)
Aller plus loin
- The Pragmatic Programmer, from journeyman to master (54 clics)
- Liste des langages de programmation sur wikipedia (66 clics)
- 12 nouveaux langages de programmation en 12 mois (49 clics)
- 7 langages en 7 semaines (51 clics)
# Seven languages in Seven weeks
Posté par Ronan BARZIC . Évalué à -3.
http://pragprog.com/titles/btlang/seven-languages-in-seven-w(...)
(C'est édité par le gars qui a écrit The Pragmatic Programmer)
[^] # Re: Seven languages in Seven weeks
Posté par Bruno Michel (site web personnel) . Évalué à 10.
[^] # Re: Seven languages in Seven weeks
Posté par Xavier Maillard . Évalué à 2.
Voilà, c'est fait. J'en ai quelques uns ici et c'est toujours un plaisir de les lire et les relire.
# Erlang
Posté par 2bass . Évalué à 4.
Dans le monde des langages fonctionnel, erlang est très intéressant, et a l'immense avantage de fonctionner en production depuis des années.
Je ne tenterai pas trop F#, peut être Scala avec le sympathique framework qu'est play: http://www.playframework.org/documentation/1.1/scala
[^] # Re: Erlang
Posté par Bruno Michel (site web personnel) . Évalué à 6.
Parce que la syntaxe d'Erlang est assez affreuse ;-)
[^] # Re: Erlang
Posté par Rémi Birot-Delrue . Évalué à 4.
[^] # Re: Erlang
Posté par barmic . Évalué à 10.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Erlang
Posté par Jerome Herman . Évalué à 7.
Je ne suis pas d'accord. La syntaxe d'Erlang est déroutante, déjà parce que c'est de la programmation fonctionnelle, mais surtout parce que Erlang est très fortement orienté communication. Mais la syntaxe Erlang est parfaitement limpide une fois qu'on a compris le truc.
Ce qui manque VRAIMENT à Erlang ce sont des bibliothèques...
[^] # Re: Erlang
Posté par JoeltheLion (site web personnel) . Évalué à 10.
[^] # Re: Erlang
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Et on devient familier au bout de combien de temps ? Nan, parce que ça fait quelques années que je fais du templeet et je trouve la syntaxe affreuse. Franchement, quelle idée d'utiliser un caractères à la con comme le tilde pour quelque chose d'aussi courant que appeler une fonction, mais peut-être qu'un jour je comprendrais :-)
[^] # Re: Erlang
Posté par case42 (site web personnel) . Évalué à 1.
[^] # Re: Erlang
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Erlang
Posté par jeberger (site web personnel) . Évalué à 2.
[^] # Re: Erlang
Posté par j_kerviel . Évalué à 2.
config standard LinuxC'est quoi une config standard Linux ?
Un kernel vanilla avec toutes les options ?
Vu que ça parle de clavier, je suppose que tu parles de distribution GNU/Linux. Dans ce cas, la « config standard », c'est la config par défaut ? Latin-0 ? Latin-9 ? Une autre ?
Et c'est la config standard d'Ubuntu (la plus répandue) ? Une autre distrib ?
[^] # Re: Erlang
Posté par jeberger (site web personnel) . Évalué à 4.
- Slackware
- RedHat
- Mandrake/Mandriva
(Ubuntu n'existait pas encore à l'époque où j'ai commencé à utiliser ces distribs, il est apparu pendant que j'étais sous Mandrake)
- et maintenant ArchLinux.
On peut aussi noter que c'était vrai sous SunOS, HPUX, IRIX et Solaris (sauf que là ce n'est pas moi qui administrais les machines donc je ne peux pas dire si les admins avaient fait une configuration particulière).
PS: Latin-0 et Latin-1 concernent l'affichage mais n'ont rien à voir avec le clavier. Le clavier c'est XkbModel: pc105, XkbLayout: fr
[^] # Re: Erlang
Posté par jeberger (site web personnel) . Évalué à 2.
[^] # Re: Erlang
Posté par Mimoza . Évalué à 3.
[^] # Re: Erlang
Posté par karmatronic . Évalué à 1.
[^] # Re: Erlang
Posté par gasche . Évalué à 8.
La syntaxe d'Erlang est, pour des raisons historiques, inspirée de la syntaxe de Prolog. Le problème c'est que la sémantique de l'Erlang moderne ne correspond pas du tout à celle de Prolog, et que des choses qui étaient donc très bien pour Prolog sont des problèmes pour Erlang.
D'habitude les critiques qu'on peut faire sur une syntaxe sont... purement syntaxiques (il y a une ambiguïté à tel niveau, etc..), donc fondamentalement peu importantes. Mais dans le cas d'Erlang il y a de vrais problèmes sémantiques bêtement liés à la syntaxe, comme par exemple :
- impossibilité de définir des fonctions locales récursives
- impossibilité d'avoir des patterns linéaires. L'interprétation de la clause de filtrage "X => ..." dépend donc complètement de l'environnement : si X est défini, c'est un test d'égalité, sinon c'est un motif universel. Ça rend tout raisonnement équationnel (et donc la plupart des manipulations de code) difficile.
Le deuxième point est par ailleurs corrigé par Reia, qui propose (ou proposait la dernière fois que j'ai regardé) deux syntaxes pour les patterns, une linéaire (une variable est toujours un motif universel) et une non-linéaire.
[^] # Re: Erlang
Posté par rhizome . Évalué à 2.
À un niveau plus terre à terre, le trouve aussi qu'il n'est pas toujours évident de s'y retrouver entre la virgule, le point-virgule et le point, notamment lorsqu'on a des fun ou des case et qu'on souhaite modifier le code.
[^] # Re: Erlang
Posté par Jerome Herman . Évalué à 4.
Attention ! En Erlang fun n'est pas une fonction mais un état fonctionnel. C'est à dire un objet avec du code, des valeurs et à peu prêt tout ce qu'on veut dedans (y compris si on le souhaite des fonctions récursives).
Il est donc normal que ça ne puisse pas s'appeler soi-même. (récursion d'un état, ça ne veut pas dire grand chose).
À un niveau plus terre à terre, le trouve aussi qu'il n'est pas toujours évident de s'y retrouver entre la virgule, le point-virgule et le point
A part quand ça intervient comme séparateur dans un constructeur, c'est pas très compliqué généralement c'est
Bloc
cas 1 -> action 1, action 2, action 3;
cas 2 -> action 4, action 5, action 6;
cas 3 -> action 7, action 8.
[^] # Re: Erlang
Posté par gasche . Évalué à 3.
Ton argumentation n'est pas bonne. Tu nous donnes des détails sur les choix de représentation par Erlang des fonctions locales (bien sûr, dans tous les langages les fonctions locales sont représentées par des fermetures, c'est à dire quelque chose avec du code, des valeurs issues de l'environnement, etc.).
Mais ça m'est égal, moi, la façon dont Erlang représente ses fonctions locales. Je peux déclarer des fonctions locales (anonymes), et j'aimerais définir des fonctions locales récursives, sans utiliser un combinateur de point fixe codé à la main qui tue les performances et limite la lisibilité.
Par ailleurs il est possible de définir la récursion sur certaines valeurs (par exemple en OCaml), et les "objets fonctionnels" semblent tout indiqués pour supporter cette fonctionnalité.
[^] # Re: Erlang
Posté par Jerome Herman . Évalué à 3.
J'insiste vraiment sur le fait que ce n'est pas une fonction locale. C'est un état. Tu peux utiliser cet état ou tu veux dans ton code, le passer en paramètres d'une autre fonction d'un autre module etc. Au niveau de la représentation c'est très similaire, mais au niveau de la logique ça n'a rien à voir. Généralement ca n'est utilisé que lorsqu'on a besoin de gérer des pools ou de faire gaffe à des problèmes de concurrence. On a des fonctions qui pondent des fun et d'autres fonctions qui les exploitent à la chaîne.
et j'aimerais définir des fonctions locales récursives, sans utiliser un combinateur de point fixe codé à la main qui tue les performances et limite la lisibilité.
Je ne sais pas quel est le problème que tu cherches à résoudre, mais je pense que tu te trompes sur la solution a utiliser en Erlang. A mon avis tu cherches à dupliquer la logique d'un autre langage en Erlang. Même si les vrais programmeurs peuvent coder en fortran dans n'importe quel langage, c'est quand même généralement déconseillé.
[^] # Re: Erlang
Posté par gasche . Évalué à 1.
Dans ce cas, Erlang n'est pas satisfaisant du tout en tant que langage fonctionnel (un langage fonctionnel sans fonctions locales, c'est presque de la publicité mensongère).
En même temps, ton discours "tu peux l'utiliser où tu veux dans ton code, le passer en paramètre ..." est exactement celui que l'on utilise pour décrire des fonctions de première classe. Des fonctions quoi.
Ensuite tu dis que de toute façon, ces trucs là sont très peu utilisés en Erlang, ce n'est pas idiomatique de s'en servir. Très bien (tant mieux pour vous les programmeurs Erlang, qui n'êtes pas dérangé par cette limitation), mais peut-être que si la syntaxe était mieux pensée sur ce point, les gens pourraient s'en servir de temps en temps.
Je ne sais pas quel est le problème que tu cherches à résoudre.
Un exemple serait plus parlant. Imagine que j'ai une fonction Erlang un peu grosse, qui définit une fonction locale (parce que cette fonction utilise des variables définies plus haut dans le bloc, et qu'elle n'a de sens que dans ce contexte donc polluerait inutilement le niveau global).
(Désolé pour l'indentation, je ne sais pas comment faire simplement avec le markup LinuxFR)
truc(args) ->...
F = fun(N) ->
N * (N + 1) / 2
end,
...
Maintenant il se trouve que ma spécification change un peu, et j'ai besoin d'utiliser non pas (1 + 2 + .. + n) mais (1 * 2 * .. * n). J'ai envie d'écrire :
truc(args) ->...
F = fun(N) ->
if
N > 1 -> N * F(N-1)
true -> 1
end
end,
...
Mais je ne peux pas, car `F` n'est pas définie dans le corps de la fonction.
J'aimerais avoir une syntaxe pour faire ça, par exemple :
F = fix Fac(N) ->
if
N > 1 -> N * Fac(N-1)
true -> 1
end
end
[^] # Re: Erlang
Posté par Jerome Herman . Évalué à 3.
Non, je dis que fun est une sauvegarde d'état, qui ne doit en aucun cas être prise pour une fonction locale. Après comme on est dans un langage fonctionelle fort (i.e pas de porte de sortie pour faire un peu de procédural ici ou là) toutes les fonctions peuvent être considérée comme locale.
En même temps, ton discours "tu peux l'utiliser où tu veux dans ton code, le passer en paramètre ..." est exactement celui que l'on utilise pour décrire des fonctions de première classe. Des fonctions quoi.
Non un état ets en quelque sorte l'inverse d'une fonction
Si on a F : x-> pleins_de_trucs.
alors F est la fonction et x est l'état.
Sauf que contrairement à un matching standard ton etat peut posséder de la logique propre à lui (mais toujours totalement dissociée de la logique de F)
mais peut-être que si la syntaxe était mieux pensée sur ce point, les gens pourraient s'en servir de temps en temps.
La logique Erlang va vraiement à l'encontre de fonctions locales telles que tu les souhaites. Chaque morceau doit être patchable à chaud, distribuable etc. Dans cet optiques de nombreux choix ont été faits, un de ces choix est de dire que les variables ne sont pas modifiables et que les scopes sont tous locaux à la fonction qui s'execute. Vouloir faire de la récursion en local au sein d'une fonction n'est donc pas très utile...
Un exemple serait plus parlant. Imagine que j'ai une fonction Erlang un peu grosse, qui définit une fonction locale (parce que cette fonction utilise des variables définies plus haut dans le bloc, et qu'elle n'a de sens que dans ce contexte donc polluerait inutilement le niveau global).
Déjà je t'arrête, il n'y a pas de niveau global à polluer. Fais ta fonction/ton module tranquillement. Autre particularité d'Erlang, il y a 99 chances sur 100 qu'il gère mieux la concurence que toi. Il faut donc faire autant de fonctions que possible sans que ca gène trop la lisibilité.
Mais je ne peux pas, car `F` n'est pas définie dans le corps de la fonction.
Non, tu ne peux pas parceque F n'est pas une fonction locale au sens langage C du terme, mais un etat. F(N-1) ne veut rien dire, puisque F(N) a déjà été appelé et que l'état a déjà été assigné. C'est pour çà que le compilo te jette. De façon générale tu n'as aucun moyen de faire appel à la logique à l'intérieur de F, vu que cette logique n'a pas de nom par laquelle l'appeler (c'est le truc des fonctions locales d'ailleurs). Fondamentalement vu que tu ne peux pas l'appeler, tu vas avoir du mal à faire de la récursion dessus.
J'aimerais avoir une syntaxe pour faire ça, par exemple :
La méthode la plus simple est d'utiliser le keyword apply sur une fonction d'un module extérieur.
D'abord un module avec al fonction factorielle dedans :
-module(m).
-export([fact/1]).
fact(N) when N>0 ->
N * fact(N-1);
fact(0) ->
1.
Ensuite on applique gentillement dans la fonction
mafonction (X,Y,Z) ->
...
Mafact = apply (m,fact,A)
....
On a 0 passage d'arguments en dehors de la fonction.
A noter que c'est un très mauvais exemple, Dans le cas ou l'on connait à l'avance le nombre d'arguments (et pour la factorielle il y a pas photo), il est TOUJOURS préférable de faire appel à la fonction du module directement.
donc pour écrire le code :
mafonction (X,Y,Z) ->
...
Mafact = m:fact(A)
....
De façon générale fun et apply sont utilisés dans des cas très particuliers, à savoir quand on ne sait pas à l'étape de compilation ce qui va se passer ou quand on est obligé de bloquer une ressource, de faire un commit ou de chercher une cohérence par rapport à un élément extérieur au langage lui même.
[^] # Re: Erlang
Posté par gasche . Évalué à 4.
« La logique Erlang va vraiement à l'encontre de fonctions locales telles que tu les souhaites. Chaque morceau doit être patchable à chaud, distribuable etc. »
J'ai l'impression qu'il n'y a aucun rapport. On peut définir localement des fonctions, je veux définir des fonctions locales récursives, c'est tout, c'est totalement indépendant de la question de la modification à chaud du code (qui se fait à un niveau plus grossier, comme la déclaration toplevel, le module, etc.).
« Non, tu ne peux pas parceque F n'est pas une fonction locale au sens langage C du terme, mais un etat. F(N-1) ne veut rien dire, puisque F(N) a déjà été appelé et que l'état a déjà été assigné. C'est pour çà que le compilo te jette. »
Qu'est-ce que c'est que cette histoire ? Une fonction locale définie avec "fun" peut bien-sûr être appelée plusieurs fois, par exemple quand on la passe à la fonction "map" qui l'applique à tous les éléments d'une liste. Je ne comprends pas ce que tu essaies de dire.
Pris d'un doute, je suis allé consulter la spécification Erlang de 1999 (qui est vieille, d'accord) et la sémantique de Core Erlang publiée en 2004, et les deux ne mentionnent aucune bizarrerie de ce genre : une fonction locale est décrite comme une fermeture classique, qui capture son environnement, et qu'on peut ensuite appliquer comme une fonction globale.
D'ailleurs Core Erlang contient une construction pour les déclarations récursives locales (letrec)... Ce qui tend à confirmer que c'est bien juste un problème de syntaxe, et que conceptuellement c'est tout à fait possible.
Enfin je suis tombé sur cette discussion de la mailing-list Erlang, datant de 2000 : Do we need a letrec construct ? : http://www.erlang.org/pipermail/erlang-questions/2000-Octobe(...)
I think a variant of letrec could be useful in many cases where one wants
local functions, not cluttering the module-level namespace, even if the
problem does not involve tricky recursion like in your example (and it is
not difficult to handle letrec in the compiler, as long as only function
definitions are allowed).
« La méthode la plus simple est d'utiliser le keyword apply sur une fonction d'un module extérieur. »
Oui... précisément il faut passer par une fonction non-locale définie au toplevel d'un module. Moi je voudrais faire ça en local (il n'y a pas de raison...).
[^] # Re: Erlang
Posté par Xavier Maillard . Évalué à 3.
On écrit plutot:
-module(m).
-export([fact/1]).
fact(0) -> 1.
fact(N) when N>0 -> N * fact(N-1);
et pour davantage de performances, on utilise une fonction tail recursive (avec un petit accumulateur):
-module(m).
-export([fact/1]).
fact(N) -> fact(N,1).
fact(0,Ac) -> Ac;
fact(N,Ac) when N > 0 -> fact(N-1,N*Ac).
[^] # Re: Erlang
Posté par gasche . Évalué à 2.
Il y a des langages qui autorisent le filtrage non-linéaire, où une variable apparaît plusieurs fois, et dans ce cas la sémantique est "accepte cette clause de filtrage si les différentes valeurs liées par la variable sont égales". Par exemple le pattern `(x, x)` n'accepterait que les couples dont les deux composants sont égaux. Cette approche a en particulier été popularisée par Prolog qui l'utilise comme une des base de la programmation (parce qu'en prolog il n'y a pas vraiment de "motifs" et de "résultat", les variables sont au même niveau et unifiées entre elles). C'est assez naturel, le problème c'est que dans un langage fonctionnel il n'y a pas forcément de notion canonique d'égalité qu'on puisse utiliser (qu'est-ce que ça veut dire, que deux fonctions sont égales ?).
Erlang, comme prolog, utilise une forme de filtrage encore plus étendue : le test d'égalité se fait quand la variable est déjà liée dans le motif courant, mais aussi quand elle est déjà liée dans l'environnement : si tu rencontres la variable X dans un motif, la signification du motif dépend de si la variable X n'existe pas déjà dans le programme (alors elle est fraîche et on la lie), ou de si la variable X est déclarée et que le motif est dans sa portée (alors c'est un test d'égalité).
En pratique cela veut dire que quand tu vois un motif en Erlang, tu ne peux pas connaître sa signification sans lire tout le code "au dessus" pour repérer toutes les déclarations de variable, et savoir si les variables du motif sont déjà dans l'environnement ou non. En particulier, si tu coupes-colle du code d'une fonction à une autre, ton code a des risques de devenir complètement faux pour des raisons subtiles qui sont difficiles à repérer, et dont le compilateur ne pourra pas t'avertir.
Ce comportement (que j'appelle non-linéaire) est utile et expressif. Mais parfois, ce n'est pas le comportement qu'on veut : on veut dire "je ne veux pas savoir si X existe déjà ou non, donne le nom X à cette nouvelle variable et oublie l'ancienne le cas échéant". C'est utile, ça aide le raisonnement local, bref on en a besoin. Et Erlang ne le propose pas (sauf dans le cas de la syntaxe "fun (motif) -> expression end"), ce qui est un défaut. Reia propose deux syntaxes, une pour les filtrages non-linéaires d'Erlang, et une pour les filtrages linéaires (il me semble que c'est "*X". À vérifier).
[^] # Re: Erlang
Posté par gasche . Évalué à 1.
Quant à ce que tu appelles les patterns linéaires, peux-tu indiquer des langages qui les permettent et éventuellement à quoi cela ressemble ?
[^] # Re: Erlang
Posté par Xavier Maillard . Évalué à 1.
Peux-tu montrer un exemple parce que j'ai du mal à comprendre pourquoi il te faudrait relire tout le code pour savoir si X est liée ou non.
[^] # Re: Erlang
Posté par gasche . Évalué à 4.
server_loop(Name, Data, Fun) ->
receive
{rpc, Pid, Q} ->
case (catch Fun(Q, Data)) of
{'EXIT', Why} ->
Pid ! {Name, exit, Why},
server_loop(Name, Data, Fun);
{Reply, Data1} ->
Pid ! {Name, Reply},
server_loop(Name, Data1, Fun)
end;
{cast, Pid, Q} ->
case (catch Fun(Q, Data)) of
{'EXIT', Why} ->
exit(Pid, Why),
server_loop(Name, Data, Fun);
Data1 ->
server_loop(Name, Data1, Fun)
end;
{eval, Fun1} ->
server_loop(Name, Data, Fun1)
end.
La partie intéressante est "{Reply, Data1}" : pourquoi appeler cette variable Data1 ? Parce que le nom Data est "déjà pris". Si on mettait Data ici, le code deviendrait complètement faux. Pour choisir le nom à mettre dans le motif, on a du faire une opération non-locale : regarder l'ensemble des noms existants dans l'environnement. Si on coupe-colle le "case (catch Fun(Q, Data) .. end) à un autre endroit il faut faire bien attention de vérifier que les variables Why, Reply et Data1 ne sont pas déjà dans la portée de l'endroit où on les ajoute.
Encore une fois, le comportement "variable existante = test d'égalité" de Erlang est parfois bien pratique (si on sait définir l'égalité). Le problème c'est qu'il soit imposé (pour de simples raisons syntaxiques), qu'on ne puisse pas choisir un comportement local plus prédictible quand c'est plus adapté.
[^] # Re: Erlang
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
En fait, c'est du pattern matching plus qu'un test d'égalité.
Ça retourne l'objet matché, et fait potentiellement des déclarations si des noms de variables non associés sont utilisés.
[3=3,_=3,3==3,{Z,_}={42,3}].
==> [3,3,true,{42,3}]
Z.
==> 42
Si je fais
1=2j'obtiens** exception error: no match of right hand side value 2[^] # u
Posté par gasche . Évalué à 3.
On peut ainsi définir l'égalité ainsi :
Eq = fun(X,Y) ->case Y of
X -> true;
_ -> false
end
end.
Ça marche aussi quand les variables sont déjà définies par le pattern :
Eq2 = fun(X,Y) ->case {X,Y} of
{Z,Z} -> true;
_ -> false
end
end.
(Je pense que tu le sais et que notre incompréhension est juste due à une question de formulation, mais histoire de mettre les choses à plat : )
Un motif fait à la fois un "filtrage" (j'accepte certaines entrées et j'en rejette d'autres), et a un effet sur l'environnement (si j'accepte, j'enrichis l'environnement avec de nouvelles variables liées). La sémantique du motif qui n'est qu'une variable (les motifs plus compliqués comme ceux sur les tuples étant défini par composition des sémantiques des sous-motifs qui les composent) est :
- si la variable n'existe pas dans l'environnement, accepter toujours et enrichir l'environnement avec un lien (variable -> entrée)
- si la variable existe déjà dans l'environnement, accepter seulement si l'entrée est égale à sa valeur dans l'environnement, et ne pas enrichir l'environnement
[^] # V
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
C'est juste que = n'est pas un opérateur d'égalité (ou d'assignation), mais de « matching » (ou d'assignation).
Pour moi, un opérateur d'égalité rend une valeur vraie en cas d'égalité, et une valeur fausse en cas de différence. Comme je le faisais remarquer,
X=3, % assigne
Y=4, % assigne
X=Y. % lance une exception
montre bien qu' = n'est pas un test d'égalité.
C'est un truc que je trouve laid, mais auquel on s'habitue vite, car ça a ses avantages pratiques quand on code.
[^] # Re: V
Posté par Benoit . Évalué à 3.
Nul part dans ce que fait remarquer bluestorm il n'est question du fonctionnement de l'opérateur "=". La remarque de bluestorm concerne le fonctionnement du filtrage dans Erlang.
En Erlang, quand tu utilises dans une règle de filtrage une variable à portée, le compilateur considère que tu filtres sur sa "valeur" et utilise donc la relation d'égalité (pas l'opérateur =) sur le type que tu es entrain de matcher pour savoir si la règle est satisfaite.
Prenons l'exemple de la règle (x,x) dans le filtrage d'un couple quand la variable x n'est pas définie. Selon le langage, on va distinguer trois comportements.
Le premier est celui d'Ocaml. Le compilateur refusera cette règle arguant que tu affectes à la variables x deux valeurs potentiellement différentes.
Le second est celui d'Erlang. Il commencera par affecter le premier élément du couple à x. Ensuite, puisqu'il rencontre la variable x déjà définie dans l'espace de nom courant, il test l'égalité entre le deuxième élément et la valeur de x. Si il obtient vrai, il considère la règle satisfaite sinon il passe à la suivante.
Un troisième comportement consiste à affecter à x la première valeur. Puis, puisque on rencontre x à nouveau, lui réaffecter la seconde valeur en "oubliant" la première.
Bluestorm reproche à Erlang de ne pas permettre d'utiliser ce troisième comportement. Là, on pourrait rétorquer qu'après tout, c'est un choix d'implémentation du filtrage. Il n'y a qu'à s'y plier.
Dans un sens, c'est vrai. Néanmoins, ce comportement est parfois pénible pour le programmeur parce qu'il l'oblige à connaître parfaitement les variables à portée quand il écrit une règle de filtrage.
En effet, considérons un exemple moins "extrême" que la règle (x,x). Quand je filtre un couple, j'utilise souvent la règle (a,b).
En Ocaml, je n'ai jamais de problème. Si a et b sont déjà définis, le filtrage les réaffectent dans un nouvel espace de noms.
En Erlang, pour peu que je n'ai pas fait attention aux variables à portée, je n'ai pas le comportement attendu. Et là, c'est le drame.
Reia met tout le monde d'accord en introduisant deux syntaxes permettant d'utiliser l'un ou l'autre des comportements au choix.
[^] # Re: V
Posté par gasche . Évalué à 3.
Dans les détails, moi je ne réclame pas ton "troisième comportement" (qui me semble moins bien que les deux premiers; il faudrait au moins afficher un warning) mais plutôt avoir le choix entre le premier et le second, comme fait Reia.
Par contre, il y a quelque chose d'important que j'ai aussi essayé de faire passer, c'est que les deux premiers comportements ne sont pas symétriques. C'est mieux d'avoir les deux mais, si on choisit l'un des deux, il vaut mieux choisir le premier. Choisir le second et l'imposer est un grave défaut, mais choisir le premier et ne pas permettre le second est une limitation relativement négligeable.
En effet, les deux langages considérés possèdent la possibilité d'ajouter une "garde" au filtrage. Le comportement du pattern `{X, X}` de Erlang peut facilement se réécrire en `{X, Y} ... when X == Y`. C'est moins joli, un peu plus pénible à lire et à écrire, mais c'est une modification locale : elle n'affecte que le motif, et pas le reste du code. Elle est par ailleurs plus fine puisqu'elle permet de spécifier l'égalité souhaitée (sachant qu'il n'existe en généralité pas d'égalité canonique qu'on puisse choisir naturellement et dont le comportement soit satisfaisant dans tous les cas).
Dans l'autre sens (si on ne propose que le deuxième comportement), la modification à faire pour obtenir le premier comportement est globale : il faut regarder l'ensemble de l'environnement de la fonction pour choisir des noms convenable. Une modification locale est plus coûteuse (en temps, en réflexion, en mémoire mobilisée chez le programmeur, en risque de bugs, en travail de maintenance...) donc avoir seulement ce comportement est un problème.
Heureusement, comme l'a souligné Jerome Herman, le style idiomatique Erlang encourage les fonctions plutôt courtes, qui contiennent peu de déclarations locales. La portée de l'environnement à considérer quand on analyse un motif reste donc raisonnable en pratique. Mais il n'empêche que ça reste un problème global (à l'ensemble d'une déclaration toplevel) et non local, et qu'on a donc un exemple concret où la syntaxe *gène* la sémantique.
[^] # Re: Erlang
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
-module(toto).
-export([main/0]).
%% Retourne {false,3}
foo() ->
X = 3, % Assigne
R = case {1,2} of
{X,_} -> true; % teste si la première projection vaut 3. Vrai si oui,
_ -> false % Faux si non.
end,
{R,X}.
%% Retourne {true,1}
bar() ->
case {1,2} of
{X,_} -> X = X; % teste si la valeur est une paire, si oui, lie X et 1, puis
% vérifie via pattern match si X = X est vrai.
_ -> X = ohmygod % assigne ohmygod à X sinon
end, %% Maintenant, X vaut 1, alors qu'on est sorti de la portée du CASE
{true,X}.
% Que retourne cette fonction?
% quux() ->
% X = 41,
% X = 42.
main() ->
%io:format("~w, ~w, ~w~n",[foo(),bar(),quux()]).
io:format("~w, ~w~n",[foo(),bar()]).
[^] # Re: Erlang
Posté par reno . Évalué à 3.
# Apprendre un langage par an, et..?
Posté par makidoko . Évalué à 3.
Chaque langage présentant ses spécificités, le mélange des genre risque même d'être plus préjudiciable qu'autre chose, à mon sens.
Autant, apprendre plusieurs langues peut permettre de s'en sortir avec des confusions, autant plusieurs langages risquent de donner lieu à quelques combats épuisants et perdus d'avances contre les compilateurs et autres interpréteurs.
[^] # Re: Apprendre un langage par an, et..?
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Au contraire, apprendre des langages différents permet d'apprendre de nouvelles façons de programmer, y compris pour les langages que l'on maitrisait déjà. Par exemple, je connaissais relativement bien Ruby, puis quand j'ai appris un langage de programmation fonctionnel, mon style en Ruby a changé : j'ai utilisé plus souvent des méthodes comme map et inject, et j'ai tendance à écrire des méthodes avec beaucoup moins d'effets de bord. Bref, je trouve mon style en Ruby bien meilleur et j'ai probablement plus progressé que si je n'avais fait que du Ruby sur cette même période.
Par contre, je te rejoins sur un point, apprendre plusieurs langages peut présenter des risques de confusion. Il faut donc mieux éviter de vouloir se lancer dans plein de langages tant que l'on n'en maitrise pas correctement un, et il vaut mieux choisir des langages avec des paradigmes différents : programmation fonctionnelle contre orientée objets, typage statique vs typage dynamique, le choix est vaste ;-)
# Pharo
Posté par laurent laffont (site web personnel) . Évalué à 4.
Et si vous voulez quelque chose qui fasse "hype", il y a Newspeak http://newspeaklanguage.org/
[^] # Re: Pharo
Posté par Duncan Idaho . Évalué à 2.
Ça l'air pas mal du tout. Problème, la documentation semble un peu hors-datée.
Pas mal de lien ici : http://www.smalltalk.org/smalltalk/learning.html pointent vers des pages qui n'existent plus.
J'ai potassé le livre "Pharo by example", mais je n'arrive pas à retrouver la même interface (et comme c'est un livre qui dit qu'il faut cliquer sur "A" pour avancer, si on trouve pas "A", on avance pas, c'est assez frustrant. http://pharobyexample.org/
Tu as un pointeur pour un super débutant ?
On est obligé de programmer dans l'éditeur au look OSX ?
[^] # Re: Pharo
Posté par laurent laffont (site web personnel) . Évalué à 4.
Pharo By Example image (recommended for use with the book)
Pharo By Example 2 en cours d'écriture est ici: https://github.com/SquareBracketAssociates/PharoByExample-en(...)
Livre collaboratif qui débute: http://book.pharo-project.org/
Des screencasts: http://www.pharocasts.com/
Autre site plus général: http://www.world.st/
Mailing-lists: http://forum.world.st/
Et dans les paramètres tu peux changer l'apparence de l'IDE.
Bienvenue !
# Goto++
Posté par Zarmakuizz (site web personnel) . Évalué à 8.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Goto++
Posté par Serge Julien . Évalué à 1.
[^] # Re: Goto++
Posté par Christophe HENRY (site web personnel) . Évalué à 0.
wget ftp://ftp.gotopp.org/gpp/gotopp.zip
unzip gotopp.zip
cd gotopp-0.30
svn info
Chemin : .
URL : http://localhost/svn/gotopp/tags/0.30
Racine du dépôt : http://localhost/svn/gotopp
UUID du dépôt : 9acad811-dc05-0410-ab1b-f2ca2dc53e28
Révision : 20
Type de nœud : répertoire
Tâche programmée : normale
Auteur de la dernière modification : sidoine
Révision de la dernière modification : 17
Date de la dernière modification: 2006-01-03 23:55:08 +0100 (mar. 03 janv. 2006)
# Différents langages
Posté par gasche . Évalué à 8.
Oz, et l'excellent livre Concept, Techniques and Models of Computer Programming.
OCaml ou SML (parce que .NET, on sait pas si c'est le mal, mais on se doute bien qu'un peu quand même)
Haskell (mais après avoir appris OCaml ou SML) ou éventuellement Clean
Coq ou Agda (ou Epigram) (mais après avoir appris un langage fonctionnel statiquement typé)
Forth ou Factor
un Lisp (Common Lisp ou Scheme, principalement) ou éventuellement Dylan
C ou un assembleur
Smalltalk, ou Ruby ou Python ou Javascript ou Io
[^] # Re: Différents langages
Posté par Sylvain Forêt . Évalué à 4.
Les langages comme Forth et Factor son très amusant à apprendre, parfaits pour les vacances, quand on veut se changer les idées, faire quelque chose de nouveau, différent, exotique ... tout en restant devant son écran.
Mais dans cette famille de langages, je préfère PostScript.
Ça permet de faire de joli dessin directement à partir de votre éditeur de texte favori.
http://amath.colorado.edu/documentation/postscript/ThinkingI(...)
http://www.cappella.demon.co.uk/psfiles/pracpost.html
[^] # Re: Différents langages
Posté par Perthmâd (site web personnel) . Évalué à 1.
Par ailleurs, parce qu'il vaut toujours mieux préférer l'original à la copie, je pense que OCaml est supérieur à F#. (Et puis le tout objet, c'est hideux).
Sinon, dans les langages rigolos, il y a ATS.
Et dans les langages exotiques, il y a Unlambda, parce que call/cc, c'est bien.
[^] # Re: Différents langages
Posté par gasche . Évalué à 1.
¹: à discuter. Mais plus utilisables que tout ce qu'on faisait avant dans le genre
Pour moi, la construction d'automates pour calculer des propriétés de mots (le modulo deux d'un nombre binaire par exemple) est aussi une forme de programmation, bien que ce ne soit pasnon plus Turing-complet.
[^] # Re: Différents langages
Posté par dave . Évalué à 2.
http://www.lri.fr/~filliatr/tp_caml.fr.html
http://fabien.viger.free.fr/liafa/caml/
Et tout ça pour dire que ocaml fait vraiment très plaisir à utiliser, et les performances sont au rendez vous. Par contre, ça me fait presque peur.
De telles performances, et une telle expressivité, quel est le revers de la médaille ?
Ceci dit, les profs qui proposent des choses là dessus, ce sont surtout des algo d'AI, ou des problèmes de math/concepts informatique.
Ce n'est pas pour rassurer les partisans des « vraies choses en informatique » :)
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: Différents langages
Posté par Maclag . Évalué à 2.
Le seul reproche qu'on peut faire à OCaml, c'est son manque de bibliothèques.
Pour le reste, c'est le seul (et oui LE SEUL) langage que j'ai essayé d'apprendre et qui m'a donné envie de le pratiquer pour de vrai.
(Bon, j'ai pas été exhaustif, mais j'ai regardé plus ou moins vite fait le C, le C++, le Python et le Ruby).
[^] # Re: Différents langages
Posté par Duncan Idaho . Évalué à 2.
Mais je fais ce reproche à plein plein de langage. C'est con, je fais du traitement du langage, il me faut un langage de programmation capable de gérer du chinois, du français et de l'hindi en même temps, il y en a assez peu qui font l'affaire finalement (même python me prend un peu la tête avec ça, mais pour le coup c'est sans doute un problème d'interface chaise-clavier).
[^] # Re: Différents langages
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Lisaac ne l'utilise pas encore mais j'ai du mal à voir ce qui est plus complexe que changer la gestion interne des string.
"La première sécurité est la liberté"
[^] # Re: Différents langages
Posté par Bruno Michel (site web personnel) . Évalué à 5.
PHP 6 dont la principale nouveauté devait justement être la prise en charge en interne d'Unicode a finalement été annulé. Après plusieurs années de développement, il restait encore bien trop de problèmes à résoudre pour espérer pouvoir sortir une version avant un paquet d'années. Ce n'est donc probablement pas si simple que ça d'ajouter sa prise en charge à un langage existant.
Un petit lien sur le sujet : http://schlueters.de/blog/archives/128-Future-of-PHP-6.html
[^] # Re: Différents langages
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Différents langages
Posté par Bruno Michel (site web personnel) . Évalué à 2.
[^] # Re: Différents langages
Posté par Étienne . Évalué à 2.
Visiblement, il y a plusieurs problèmes :
* Augmentation de l'utilisation mémoire
* Baisse des performance
* De nombreux scripts ne fonctionnent plus
Étienne
[^] # Re: Différents langages
Posté par gasche . Évalué à 3.
Ce qui est vrai, c'est que le type "string" continue à considérer qu'il manipule des tableaux d'octets. Ça n'empêche pas de manipuler des chaînes UTF8 en utilisant le type string (plutôt que les types spécialisés de Camomile, repris par la bibliothèque Batteries), mais du coup certaines fonctions ne marchent pas tout à fait comme on veut, par exemple String.length renverra le nombre d'octets et non pas le nombre de caractères. On fait largement avec.
Enfin, certaines bibliothèques ou outils n'ont pas pris en compte les questions liées à UTF8. Par exemple il me semble que le générateur de lexeurs standard, ocamllex, ne gère pas bien les entrée UTF-8. Mais il existe un lexeur pensé pour ça, ulex.
Bref, le support d'UTF8 dans OCaml est satisfaisant, dans le sens où bien qu'UTF-8 ne fasse pas partie de la spécification du langage ou des types built-in, on peut tout à fait travailler sur de l'UTF-8 et ça marche très bien.
Si tu veux faire du "bête traitement de texte" où la fatigue liée à l'utilisation d'une bibliothèque spécialisée surpasse la difficulté de la tâche à effectuer au départ, ce n'est pas une bonne idée. Mais si tu veux faire des opérations et manipulations un peu compliquées sur tes données, et que la question de l'encodage n'est au final qu'un détail, il n'y a pas de raison de se gêner.
(D'ailleurs beaucoup d'outils de linguistique computationnelle sont développés en OCaml)
[^] # Re: Différents langages
Posté par Amber . Évalué à 2.
Je rappel aux divers trolls que le langage est sous licence libre, et que depuis les premières releases le projet est mono friendly.
Libre à vous de ne pas l'utiliser ou le tester mais ne venez pas vous plaindre que ça n'existe pas.
[^] # Re: Différents langages
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Une syntaxe de merde, des erreurs cryptiques genre « machin has type int instead of type int » (Je sais plus comment, mais on pouvait créer des erreurs de même), l'absence de macros (j'ai pas touché à camlp4)…
Cela dit, j'aime bien, hein. J'en ai fait pendant longtemps.
Mais ces temps-ci, je trouve plus agréable de programmer en Haskell (pour son côté paresseux), Gambit-C Scheme ou Common Lisp (pour leur expressivité)…
[^] # Re: Différents langages
Posté par Maclag . Évalué à 2.
Ouai, en fait tu préfères Haskell parce que t'es une feignasse!!
----------------> [ ]
[^] # Re: Différents langages
Posté par Philippe F (site web personnel) . Évalué à 2.
[^] # Re: Différents langages
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Java et sa jvm n'inlinant pas les getter, c'est forcément une cata en terme de performance.
"La première sécurité est la liberté"
[^] # Re: Différents langages
Posté par lasher . Évalué à 2.
[^] # Re: Différents langages
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
J'ai du optimiser du code java pour le concours ai-contest, cité plus haut, et j'ai compris que le jit ne fait que l'équivalent simple d'une compilation (genre gcc -1). Des optimisation assez stupide, comme inliner à la main, avait des effets important sur les performances. Supprimer les new et les remplacer par des reset avait aussi une grosse importance.
"La première sécurité est la liberté"
[^] # Re: Différents langages
Posté par lasher . Évalué à 2.
[^] # Re: Différents langages
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En même temps, il annonce 1.5 de compile jit sur mon programme, gcc prendrait bien plus de temps. Même si gcc est lent, il n'y a rien de magique.
"La première sécurité est la liberté"
[^] # Re: Différents langages
Posté par Ontologia (site web personnel) . Évalué à 3.
J'espère être réaliste en disant que dans deux ans on aura une stable (une version est en train d'être réécrite là)..
Mais pour le moment, comme le dit Nicolas, Lisaac c'est pour le type qui veut de la perf tout en utilisant des choses qu'il a l'habitude de faire en Ruby et sans être obligé de coder en C++.
Le compilateur actuel suffit très bien pour faire ça.
C'est mon cas en ce moment, parce que je code un jeu web et c'est vrai que c'est un langage dans lequel on est assez vite à l'aise en fait*, et dans lequel on peut inventer toutes sortes de choses assez couillues, surtout avec les blocks et l'héritage qui un monde énorme à défricher.
M'enfin c'est une question de gout, les pointeurs et les références, ça me fait fuir, certains adorent. Donc pour la perf, beaucoup de gens utiliseront encore C++
*Je dis ça parce que j'avais jamais vraiment codé beaucoup en Lisaac, et j'en fait à haute dose depuis quelques semaines, en debugant le compilateur en passant.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Différents langages
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Tu réécris DLFP en Lisaac ?
[^] # Re: Différents langages
Posté par Gniarf . Évalué à 2.
[^] # Re: Différents langages
Posté par Ontologia (site web personnel) . Évalué à 2.
De toi, dont je lis toujours les commentaires avec grand intérêt, je m'attendais à mieux :-(
Je voulais juste dire que on peut créer des structures de contrôles, créer des fonctions de fonctions (curryfication), jouer avec l'héritage, etc...
Toute chose qu'on ne peut faire avec C++, sans perdre de perfs.
En ce qui me concerne, mais c'est juste personnel, j'apprécie cela quand je code.
Joyeux noël !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Différents langages
Posté par Duncan Idaho . Évalué à 1.
Il y a un tutorial d'enfer en ligne pour Haskell:
http://tryhaskell.org/
Jusque là ça ressemble beaucoup à OCaml (ce qui est vraiment un avantage).
Yeah \o/
[^] # Re: Différents langages
Posté par Krunch (site web personnel) . Évalué à 1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Différents langages
Posté par Gabriel . Évalué à 3.
Tuto tellement bon qu'il a généré son petit frère, pour Erlang
http://learnyousomeerlang.com/
# LISP
Posté par rangzen (site web personnel) . Évalué à 5.
Au moins pour comprendre les algos qu'il a utilisé.
[^] # Re: LISP
Posté par BAud (site web personnel) . Évalué à 10.
[^] # Re: LISP
Posté par monde_de_merde . Évalué à 3.
Par contre c'est rudement malin d'avoir faire ça en Lisp. Toute personne n'ayant pas la compétence "Faire abstraction de parenthèse" au niveau maximum ne pourra pas le copier !
Futé futé.
[^] # Re: LISP
Posté par rangzen (site web personnel) . Évalué à 3.
[^] # Re: LISP
Posté par Bruno Michel (site web personnel) . Évalué à 3.
[^] # Re: LISP
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
On code en Scheme/Lisp avec des éditeurs qui gardent/indiquent le balancement correct de parenthèses. Tu peux même avoir une coloration différente en fonction de la profondeur.
Et d'ailleurs, les parenthèses font le même effet visuel que l'indentation, mais rendent impossible une erreur dans un programme à cause d'une indentation foireuse…
[^] # Re: LISP
Posté par lolop (site web personnel) . Évalué à 2.
Non, mets tout sur la même ligne et l'effet visuel n'a rien à voir.
Ce qui fait le même effet que l'indentation... c'est l'indentation, qui permet de repérer plus facilement s'il manque une parenthèse (ou une accolade suivant le langage).
Et pour le "rendent impossible une erreur dans un programme à cause d'une indentation foireuse… " si l'indentation est foireuse et que les parenthèses sont correctes, alors c'est que l'indentation ne reflète pas visuellement la façon dont tu penses que ton code est structuré. Peut-être que le code est correct, mais quelqu'un qui le relis risque de passer à coté de la structure de ton code, parce que l'indentation est plus visuelle que les parenthèses.
Avantage aux parenthèses ou accolades: les outils automatiques peuvent remettre en ordre l'indentation du code pour qu'il soit lisible.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: LISP
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Mais oui, je conçois que ma phrase était rentre-dedans.
L'avantage, c'est que l'indentation qui découle du parenthésage et la structure du code sont interdépendants.
Le coup classique du
if test1 then if test2 then foo else barrelève alors plus de la faute grave que de la faute d'étourderie. Si ton langage est basé uniquement sur l'indentation, quelques espaces en plus ou en moins sur leelse barrisquent d'avoir un effet pervers sur ton code… (nota : en CL ou Scheme, on utilisera(when test1 (if test2 foo bar))ou(if test1 (when test2 foo) bar)pour rajouter une couche de clarté à ce que la commande d'indentation automatique de ton éditeur aura déjà exprimé pour toi.[^] # Re: LISP
Posté par CrEv (site web personnel) . Évalué à 7.
en fait ça retire tout ambiguïté au fait que c'est illisible, non ?
[^] # Re: LISP
Posté par lolop (site web personnel) . Évalué à 2.
Si les parenthèses/accolades ne reflètent pas l'indentation, alors il y aura un jour une divergence entre la compréhension du code par un lecteur humain et la compréhension du code par la machine. Peut-être pas par l'auteur, qui sait ce qu'il a écrit et pourquoi, mais par un autre, qui essaiera de comprendre ce que fait le code.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: LISP
Posté par daimrod . Évalué à 2.
Je conseille cet article qui explique très bien le pourquoi de la chose:
[http://www.defmacro.org/ramblings/lisp.html]
[^] # Re: LISP
Posté par lolop (site web personnel) . Évalué à 3.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: LISP
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 6.
C'est pas un problème !
C'est même un avantage certain !
Vu que les parenthèses reflètent la structure du code, tu peux, de manière automatique et sans ambiguïté, recréer l'indentation, la bonne seule et unique qui correspond à l'intention du programmeur (s'il a écrit ce qu'il voulait écrire), et à celle de toute personne qui sait lire un programme.
Donc, impossible de se tromper, vu que l'indentation *dépend* du parenthésage, et que le parenthésage est en bijection avec la structure intentionnelle du code.
[^] # Re: LISP
Posté par MsieurHappy . Évalué à 2.
Je le lis actuellement, et m'amuse bien. Que c'est rafraîchissant de programmer des petits jeux (mais pas que) pour découvrir le langage, le tout accompagné d'amusantes illustrations. Sans pour autant remettre en question la qualité technique de l'ouvrage !
Common Lisp y est à l'honneur, mais ça donne les clefs au lecteur pour appréhender les autres dialectes populaires, tel Scheme et Clojure.
Simple but refined, guaranteed to blow your mind.
[^] # Re: LISP
Posté par Serge Julien . Évalué à 1.
# Perl 6
Posté par Krunch (site web personnel) . Évalué à 8.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Perl 6
Posté par jbbourgoin (site web personnel) . Évalué à 4.
C'est vraiment un langage étonnant !
Je suis en train de le découvrir avec le calendrier de l'Avent Perl6 : https://perl6advent.wordpress.com
Il y a des choses bien pratiques comme ce système très simple de création d'arguments pour des programmes "en ligne de commande" (je reprends les exemples de perl6advent ) :
$ cat add.pl
sub MAIN($x, $y) {
say $x + $y
}
$ perl6 add.pl 3 4
7
$ perl6 add.pl too many arguments
Usage:
add.pl x y
Et des choses très amusantes comme l'opérateur de séquence :
> my @Fibonacci := 0, 1, * + * ... *; 1;
1
> @Fibonacci ...^ * > 10000
0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765
> @Fibonacci[30]
832040
Et plein d'autres trucs bien évidemment.
[^] # Re: Perl 6
Posté par dave . Évalué à -2.
Peut être avec un nouveau nom ils seraient resté crédible, mais après toutes ces modifications, continuer à appeler ce langage perl, c'est un peu bizarre. À au fait j'ai entendu dire que
P. E. R. L. = Pathetically Eclectic Rubbish Language
Ça n'empêche rien au fait que je ne connais pas le langage, et gagnerai peut être à l'utiliser, mais je trouve sa syntaxe un peu trop à mi-chemin entre le pote de bistrot et l'ésotérisme..
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: Perl 6
Posté par barmic . Évalué à 4.
Je ne te connais pas, mais t'a l'aire d'un mec pas intéressant du tout. Peut être que si tu changeait de pseudo ça irais mieux mais là j'ai pas envie de te connaître.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Perl 6
Posté par reno . Évalué à 1.
C'est un langage assez difficile a apprendre, les débutants font donc du code assez horrible, ça c'est assez normal, par contre là ou c'est plus génant c'est que les gens expérimenter en Perl ont développer chacun leur propre style et là niveau maintenance c'est pas terrible!
[^] # Re: Perl 6
Posté par rogo . Évalué à 3.
Larry Wall, créateur de Perl.
Si on veut que les gens expérimentés programment tous de la même façon, alors il faut définir un "coding standard". Sinon, que ce soit Perl, Ruby, C ou PHP, chaque développeur fera sa propre cuisine. A une moindre échelle, même en Java ou C#, langages bien plus contraignants, si personne n'impose de conventions, c'est le bazar.
A propos de l'acronyme "Pathologically Eclectic Rubbish Lister", il est de Larry Wall lui-même. C'est amusant de voir cette auto-dérision utilisée à charge.
Si vous avez essayé Perl sans rien en ressortir de positif, c'est bien dommage. Je comprends qu'on n'apprécie pas sa syntaxe, mais il y a plein de principes intéressants qui ont très fortement influencé d'autres langages. Personnellement, je recommande souvent Perl et un langage Lisp ou Haskell pour encourager à voir la programmation autrement.
Sinon, je suis étonné que l'importance de l'objectif n'aie pas encore été mentionnée. Pour de l'admin sys, je n'ai rien trouvé qui vaille Perl. Mais Ruby, Haskell, PHP ou C++/Qt ont leurs points forts dans d'autres domaines. Même Java, paraît-il ;-)
[^] # Re: Perl 6
Posté par reno . Évalué à 3.
Donc si j'ai le choix entre faire du Perl ou du Ruby|Python, je ne choisirai pas Perl, malheureusement je n'ai pas le choix à cause de la base installée en Perl: de mon point de vue, Perl est le COBOL des langages de scripts.
Pour ce qui est de voir le coté programmation par script, bof, a par le poids de l'existant, je ne vois pas trop ce que Perl apporte par rapport a Ruby ou Python.
[^] # Re: Perl 6
Posté par jbbourgoin (site web personnel) . Évalué à 2.
Mouarf !
Il faudrait déjà savoir ce qu'est un "langage de scripts" pour pouvoir dire ce genre de chose ;)
Si par langage de scripts il faut entendre : "langage conçu pour réaliser de petits programmes servant de glu entre différents programmes".
Alors soit Perl n'est pas un langage de scripts, car il sait faire bien plus que cela, soit il en est un mais alors TOUS les langages de programmation sont des langages de scripts.
Il est vrai que Perl est un excellent langage de progra généraliste, mais est également une très bonne glu ;)
[^] # Re: Perl 6
Posté par daimrod . Évalué à 5.
(-->[])
[^] # Re: Perl 6
Posté par Quzqo . Évalué à 1.
Un équivalent doit être possible en bash d'ailleurs...
Le plus souvent cryptique, ça permet tout de même de faire des choses très intéressantes sans tout une chaine de compilation derrière
Indépendamment, La syntaxe d'un langage est aussi affaire de goût.
Pour ma part, j'ai toujours adoré Perl et ses expressions régulières.
A contrario, j'ai horreur de Ruby.
On ne doit pas être sur les mêmes "Rails" :)
[^] # Re: Perl 6
Posté par leoboy . Évalué à 2.
On peut écrire des choses illisibles dans bien des langages, mais ce n'est jamais obligatoire. Ce n'est pas un prérequis pour qu'un script Perl fonctionne, en tout cas.
[^] # Re: Perl 6
Posté par Emmanuel de Beauvoir . Évalué à 1.
Mais ce langage est redoutable d'efficacité pour faire le lien entre des opérations d'administration sur un système (Linux, HP-UX, Solaris etc... et Windows). Bref pour remplacer bash + awk .... (pas taper! (troll détecté)).
Cette facilité à faire du lien, c'est aussi une facilité à faire du vite et "crade", bien connu de nombreux admins sous pressions (pas taper! ...).
Il est alors assez inquiétant de s'apercevoir, en relisant son propre code, datant de seulement quelques mois (et rédigé un jour de grande forme ;) ) que l'implémentation semble très obscure (ceci sans avoir abusé de substances illicites).
Et, je ne parle pas d'un code pondu il y a des années, par un débutant (ou pire un super "bon"), pressé de passer à autre chose.....
Je préfère des langages où il n'y a pas 36000 façons de faire une chose.
[^] # Re: Perl 6
Posté par jbbourgoin (site web personnel) . Évalué à 4.
Tout le monde que Perl c'est illisible, donc Perl est illisible. (sur ce point il est ex-æquo avec ce pauvre LISP qui dispose pourtant de la syntaxe la plus simple qui soit)
Tout le monde dit que Perl c'est un truc fait pour faire des petits scripts auxquels qu'on ne retouche jamais, donc on le répète.
Bien souvent, ceux qui répètent ces âneries n'ont jamais touchés sérieusement à Perl.
La vérité c'est que la communauté Perl a mis en place des "bonnes pratiques" depuis longtemps. Les idiomes sont connus. Faire du Perl "maintenable" et lisible (pour quelqu'un qui connaît un peu le langage évidemment), c'est FACILE.
Dernièrement est sorti un français un petit ouvrage qui s'intitule Perl Moderne, ça devrait dépoussiérer le cerveau de nombre de lecteurs de nombreux clichés.
Je préfère des langages où il n'y a pas 36000 façons de faire une chose.
Là oui, c'est un vrai argument.
On compare dans ce domaine deux langages : Python et Perl. On a bien raison, ils sont sur ce point réellement antagonistes.
Perl est un langage conçu pour pouvoir être parlé de diverses manières, un peu comme une langue vivante. Il y a le langage familier, grossier, ordurier, noble, technique etc.
Python est langage conçu pour n'être parlé que d'une manière. Un peu comme les langues mortes encore utilisée dans des cadres très spécifiques.
Ainsi en Perl quasiment TOUT est réellement possible : programmation objet (divers modèles de OO), programmation fonctionnelle, orientée aspect programmation en latin ;) etc. Tout de diverses manières.
En Python, il faut se limiter aux choix de GvR :
GvR n'aime pas la progra concurrente ? Hop un GIL !
GvR n'aime pas les récursions terminales ? Zou, à la trappe :)
GvR ne croit pas en la progra fonctionnelle ?
Etc. etc,
Perl et Python sont vraiment des langages de caractère, c'est certains ;)
Entre un langage qui offre les moyens de faire ce que l'on veut de diverses manières et un autre qui vous impose les convictions de son concepteur, il y a sans doute de nombreux intermédiaires.
Mais une chose est certaine, ces deux langages là ont leur caractère ;)
P.S. : j'ai coutume de dire que Python pourrait très bien être un sous-ensemble de Perl...
[^] # Re: Perl 6
Posté par reno . Évalué à 2.
Bof, certains des clichès invalides, tu les as ressorti toi même (je ne me souviens pas avoir lu dans ce sujet que Perl n'était utilisé que pour de petit programmes et c'est faux hélas).
>> Tout le monde que Perl c'est illisible, donc Perl est illisible. (sur ce point il est ex-æquo avec ce pauvre LISP qui dispose pourtant de la syntaxe la plus simple qui soit) <<
Si tu manges sans sel ce n'est pas très bon, si tu manges trop salé, ce n'est pas bon non plus.
Créer un langage qui soit utiliser pour faire des programmes lisibles 'par défaut', c'est comme faire la cuisine c'est un équilibre délicat: il ne faut pas être trop artificiel comme Lisp ou trop 'baroque' comme le Perl, ceci dit il y a encore pire que le Perl: APL!
>> Faire du Perl "maintenable" et lisible (pour quelqu'un qui connaît un peu le langage évidemment), c'est FACILE <<
Je ne dirais pas facile, mais juste "pas difficile".
Le problème c'est que:
1) ce n'est pas le comportement par défaut donc les débutant ne le font pas
2) ce n'est pas vraiment encouragé car beaucoup d'exemples que tu trouves sur le web n'utilisent même pas les bases comme 'use strict' et autre.
3) très peu de programmeurs expérimenté le font, car ils préfèrent utiliser leur idiome..
Donc ce qui est facile en théorie, est rarement appliqué en pratique..
[^] # Re: Perl 6
Posté par lasher . Évalué à 3.
use strict;
use warnings;
# code avant ...
my $content;
# $! n'est pas expliqué dans le code car on apprend très vite qu'il est équivalent à
# ce que renvoie perror() ...
open (my $fh, '<', $file) || die "Could not open $file: $!";
# "Slurps" the file into $content. Making $/ local undefines it for the local scope
# and stops it from separating the file into "lines" with the '\n' character.
{
local $/;
$content = <$fh>;
}
# code après ...
Ce code est idiomatique (on le trouve un peu partout dans pas mal de tutoriels/bouquins), et nécessaire (le fichier à lire était un fichier binaire -- une image). Évidemment, ce code a vite été mis dans une fonction slurp ... :)
Le code était maintenable, car il était de toute manière lu et partagé par d'autres qui pouvaient avoir besoin de jeter un œil. Et contrairement à ce que tu sembles dire, un débutant peut parfaitement avoir de bonnes bases : il suffit qu'il ait été bien formé -- en l'occurrence je sortais plus ou moins d'IUT, où l'on m'avait appris à correctement nommer mes variables, indenter mon code et le modulariser ... Bref, ce qu'il faut savoir faire en C, Java, ou autres langages.
[^] # Re: Perl 6
Posté par ZankFrappa . Évalué à 3.
Ça fait quelques mois maintenant que je n'ai pas lu de Perl 6, et si je me souviens bien de l'opérateur * servant à plein de choses différentes, j'ai un peu perdu les réflexes que j'avais acquis. Notamment, comprendre la définition de la liste Fibonacci ne me semble pas évident (je veux dire, comprendre pourquoi ça marche). En Haskell, en revanche, avec plus de mots et moins de symboles, ça donne
> let fibo = 0 : 1 : zipWith (+) fibo (tail fibo)
> takeWhile (< 10000) fibo
[0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765]
> fibo !! 30
832040
Et si j'ai des doutes sur le comportement d'une fonction (par exemple que je ne connais pas zipWith), son type m'aide bien souvent à deviner ce qu'elle fait :
> :t takeWhile
takeWhile :: (a -> Bool) -> [a] -> [a]
> :t zipWith
zipWith :: (a -> b -> c) -> [a] -> [b] -> [c]
[^] # Re: Perl 6
Posté par jbbourgoin (site web personnel) . Évalué à 1.
[^] # Re: Perl 6
Posté par ZankFrappa . Évalué à 4.
# F# et Linux
Posté par sifu . Évalué à 4.
J'ai toujours un peu l'impression que c'est juste histoire de dire que cela peux fonctionner sous Linux ...
De plus quand je vois monodroid ou monotouch, j'ai comme l'impression que je suis pas un fan de Novel !
# Code Complete
Posté par swilmet . Évalué à 2.
Bon maintenant il est un peu plus gros que The Pragmatic Programmer (900 pages contre 350).
Les libristes ils lisent quoi d'habitude dans ce sujet ? (bon OK vous allez me répondre : le code d'autres programmes ;)
[1] http://www.amazon.fr/Code-Complete-Steven-C-McConnell/dp/073(...)
[^] # Re: Code Complete
Posté par claudex . Évalué à 4.
Au moins The C Programming Language et The Art of Computer Programming
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Code Complete
Posté par koxinga . Évalué à 2.
[^] # Re: Code Complete
Posté par ZeroHeure (site web personnel) . Évalué à 3.
http://www-cs-faculty.stanford.edu/~knuth/news.html
Pour ma part je viens de lui envoyer une correction - ça y'est c'est la gloire, j'ai trouvé une faute chez Knuth! bon c'est juste une correction sur son site web, ça ne vaut pas un 0x$1.00, mais il y a un début à tout. ;-)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Code Complete
Posté par swilmet . Évalué à 1.
[^] # Re: Code Complete
Posté par Yusei (Mastodon) . Évalué à 2.
C'est bien le thème de "the art of computer programming", non ?
[^] # Re: Code Complete
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Aux conquérants de l’inutile!
Posté par Unixfix le Gaulois . Évalué à 0.
Je trouve d’autre part que cette tendance lourde chez les étudiants informaticiens de se passionner pour tel ou tel nouveau langage d’ailleurs plutôt infantile et pas forcément utile pour leur avenir professionnel.
La plupart des informaticiens semblent d’ailleurs ignorer que la plupart des programmes demandés dans l’industrie automatisent en fait une technique et un savoir faire particulier. Le programme n’est qu’un outil qui facilite le travail et non une fin en soi.
Dans la société où je travailles, nous avons souvent de sérieux problèmes à faire comprendre aux informaticiens que nos spécifications doivent être respectées de façon impérative car dictée par des critères technologiques et ergonomiques. Il est tout à fait possible que notre point de vue ne leur simplifie pas la tâche mais après tout c’est la vie et on ne leur demande pas d’être des spécialistes en ce qui nous concerne en électrotechnique.
D’autre part j’ai souvent remarqué que l’intérêt pour tel ou tel langages est souvent lié à la liberté (certains diront créativité !) laissée aux programmeurs pour rendre leur « œuvre » accessible qu’à eux-mêmes.
[^] # Re: Aux conquérants de l’inutile!
Posté par Maxime (site web personnel) . Évalué à 5.
Le programmeur passionné a envie de choisir le langage adapté en fonction du projet. Mais je comprend que le laisser coder dans un super langage que lui seul connait risque d'être un problème.
Je me suis intéressé à un certain nombre de langages différents et c'est grâce à cela que je suis aujourd'hui capable de comprendre plus rapidement de nouveaux langages. L'informatique est ma passion et si je trouve ça passionnant d'apprendre un nouveau langage, grand bien m'en fasse. Je ne vois pas pourquoi tout ce que j'apprends devrait être forcément utile professionnellement si je le fais sur mon temps libre. On me fait manger déjà assez de Java/EJB/WS/WSDL/CORBA/JSP/... en cours.
[^] # Re: Aux conquérants de l’inutile!
Posté par Unixfix le Gaulois . Évalué à 4.
En ce sens d’ailleurs je ne suis pas d’accord avec ce point de vue et comme je l’ai titré plus haut est une approche de conquérants de l’inutile.
Etant un informaticien devenu ingénieur en productique je vois les choses autrement et personnellement j’ai un autre avis sur la question : Comment en pratique un programmeur devrait augmenter son portfolio de connaissance.
Au lieu d’apprendre un nouveau langage de programmation, la plupart des informaticiens devraient plutôt parfaire leur connaissance du langage …humain que ce soit sous forme écrite ou verbale.
Une spécification mal comprise, interprétée de travers voire pire « améliorée » donnera quelque soit le langage de programmation utilisé un résultat non conforme. Le fait d’apprendre x langages de programmation n’apportera pas vraiment de valeur ajoutée aux connaissances.
En pratique d’ailleurs je conseillerai plutôt aux programmeurs d’approfondir plutôt leur connaissance dans le domaine où leur application sera utilisée, car cela permet d’éviter les erreurs les plus grossières et aussi de poser les bonnes questions quand une spécification est incomplète voire imprécise.
[^] # Re: Aux conquérants de l’inutile!
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Le livre traite de comment devenir un meilleur programmeur. Après, on peut l'appliquer dans un contexte professionnel ou sur son temps libre, libre à chacun de choisir.
> Au lieu d’apprendre un nouveau langage de programmation, la plupart des informaticiens devraient plutôt parfaire leur connaissance du langage …humain que ce soit sous forme écrite ou verbale.
Il y a aussi quelques conseils à ce sujet dans le livre The Pragmatic Programmer ;-)
> En pratique d’ailleurs je conseillerai plutôt aux programmeurs d’approfondir plutôt leur connaissance dans le domaine où leur application sera utilisée.
Tiens, encore un conseil présent dans The Pragmatic Programmer.
> Une spécification mal comprise, interprétée de travers voire pire « améliorée » donnera quelque soit le langage de programmation utilisé un résultat non conforme.
Oui, mais bon, j'ai vu tellement de spécifications mal écrites, incomplètes, inconsistentes ou qui changent à de multiples reprises que j'ai du mal à croire que s'en tenir stricto sensu à des spécifications est le chemin de la réussite. Après, cela doit sûrement dépendre du domaine.
[^] # Re: Aux conquérants de l’inutile!
Posté par Unixfix le Gaulois . Évalué à -2.
En cela ta dépêche est très réductrice car l'aspect que tu mets en exergue semble n’être qu’une petite partie de l’ouvrage en question.
J’ai surtout l’impression que tu te sers du bouquin comme « alibi » pour énumérer les langages de programmation que tu aimerais apprendre et attendait des commentaires des avis sur ceux-ci.
[^] # Re: Aux conquérants de l’inutile!
Posté par intralunaire . Évalué à 2.
http://pragprog.com/the-pragmatic-programmer/extracts/tips
[^] # Re: Aux conquérants de l’inutile!
Posté par CrEv (site web personnel) . Évalué à 7.
peut-être parce que la dépêche traite du choix d'un langage à apprendre pour 2011 et non du bouquin...
> J’ai surtout l’impression que tu te sers du bouquin comme « alibi » pour énumérer les langages de programmation que tu aimerais apprendre et attendait des commentaires des avis sur ceux-ci.
Attends, je reprend le contenu de la dépêche :
> l'un m'a particulièrement marqué : il est souhaitable d'apprendre un nouveau langage de programmation tous les ans
> je souhaite partager avec vous quelques suggestions de langages
> je n'ai pas encore choisi quel langage j'allais étudier en 2011
> je n'ai pas encore choisi quel langage j'allais étudier en 2011
Ha ok, en fait c'est bien ça, tu viens juste de comprendre la dépêche.
Si on met ça en relation avec un autre post disant que souvent on trouve la solution sois même sauf qu'il faut tout lire ... ça fait sourire ;-)
[^] # Re: Aux conquérants de l’inutile!
Posté par Thomas Douillard . Évalué à 2.
L'électrotechnique ça a l'air d'un truc très bas niveau pour un informaticien. Les spécifications en question ressemblent à quoi ? Qu'est ce qui est le plus susceptible de foirer dans la communication informaticien / électrotechnicien de ton point de vue ?
[^] # Re: Aux conquérants de l’inutile!
Posté par Quzqo . Évalué à 1.
Ca permettrait déjà de se comprendre au niveau de l'équipe de réalisation et d'anticiper ("Risques & Opportunités", le truc qui passe à 10000 au-dessus des têtes en général hormis le PM)...
Produire des spécifications intelligibles serait aussi un sujet à débattre (avec celui de savoir les lire) :)
Bref, le développeur (terme bien vague) devrait être le trait d'union entre architecture et intégration à minima... pas seulement un technicien (avec moult langages) hors pair.
[^] # Re: Aux conquérants de l’inutile!
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -2.
[^] # Re: Aux conquérants de l’inutile!
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Cela me rappelle le format PAR de découpage de fichier qui a été proposé en certification : cela a permit de trouver un bug dans la façon de calculer un hash (de mémoire).
Dans la vrai vie, on a un prototype qui sert à écrire une spécification. Celle-ci est elle-même prototypé, pour la valididé, la compléter. Ensuite, peut commencer le vrai développement (avec des bouts des étapes d'avant).
"La première sécurité est la liberté"
[^] # Re: Aux conquérants de l’inutile!
Posté par claudex . Évalué à 5.
Ça doit venir du fait que la plupart du temps les spécifications sont données sans vraiment réfléchir et parfois même contradictoire, il est donc normal de les adaptés dans ce cas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Aux conquérants de l’inutile!
Posté par Unixfix le Gaulois . Évalué à 3.
Ce cas arrive certes mais dans ce cas les adapter de son propre chef est en fait la plus mauvaises des solutions !
La seule et bonne réaction est de la signaler et de demander des précisions. Même si parfois le simple bon sens permet de trouver « tout seul » la solution, celle-ci se trouve à un autre endroit du cahier des charges que par manque de temps ne fut que survoler.
[^] # Re: Aux conquérants de l’inutile!
Posté par claudex . Évalué à 6.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Aux conquérants de l’inutile!
Posté par coid . Évalué à 6.
Leur avenir professionnel, ce n’est pas ton problème.
Mon dieu, que de soucis…!
Vivement que les étudiants comprennent que leur destin est de faire la pute…
[^] # Re: Aux conquérants de l’inutile!
Posté par highleaf . Évalué à 1.
Description un peu crue mais tellement réaliste, informaticien c'est accepter de travailler beaucoup, d'être mal payé, d'être stressé en permanence et de bosser pour des gros cons qui ne comprennent rien ;)
[^] # Re: Aux conquérants de l’inutile!
Posté par Gniarf . Évalué à 4.
oui, entre la maison les loisirs et d'autres types de postes (R&D, etc) il y a de quoi faire
[^] # Re: Aux conquérants de l’inutile!
Posté par ZankFrappa . Évalué à 4.
Fort heureusement tout le monde ne se destine pas à l'industrie. D'autres embrassent pleinement cette citation du SICP, "It's extraordinarily important that we in computer science keep fun in computing."
# Langage
Posté par kalki . Évalué à -10.
Avec le C++ ou java, on peut déjà tout faire on peut meme faire une intelligence artificielle :)
Si ca ce n'est pas le but de l'informatique, l'informatique qui est le dernier métier, métier qui va aussi disparaitre
Et si vous faisiez plutot de l'intelligence artificielle ? Pour créer vos programmes tout seul, avec une interface "humanoide" ou virtuel pour le client : et une grosse temporisation car "il faut pas aller trop vite avec le client" sinon il croirait qu'il a payé pour rien.
NON , ca ne vous dis pas ?
Non ?
Bon alors je vous conseille de vous mettre à réfléchir a propos de l'économie, et aussi du rapport capital / travail : le salaire quand il n'y a pas besoin d'émployé : et qu'il n'y a pas de revenu, ou d'allocation universelle.
Bonne réflexion :)
[^] # Re: Langage
Posté par Maxime (site web personnel) . Évalué à 2.
[^] # Re: Langage
Posté par kalki . Évalué à -9.
La réalité ne tardera pas à vous toucher
# Je rêve d'un langage de script
Posté par syj . Évalué à 1.
- Langage objet
- Typage fort (dans le sens, toutes les variables doivent être déclaré et être au moins du type Objet universel tel que l'Object de Java).
- Jamais de déclaration implicite genre:
bidule = 10;
- Supporte l'introspection d'objet.
- Gestion de package géré au niveau de la vm avec contrôle au chargement de la signature: un truc du genre:
import log.jar, 1.2 , http://log.jar/download, {Signature SHA256}
- Garbage collector
- Machine virtuel avec contrôle d'accès aux ressources systèmes qui permet un contrôle via bac à sable.
- Syntaxe type C++ ou Java
Bref , Java sans Oracle ou Microsoft :)
[^] # Re: Je rêve d'un langage de script
Posté par Yusei (Mastodon) . Évalué à 4.
[^] # Re: Je rêve d'un langage de script
Posté par Bruno Michel (site web personnel) . Évalué à 4.
[^] # Re: Je rêve d'un langage de script
Posté par jfmartin . Évalué à 1.
# Approfondir aussi
Posté par fred (site web personnel) . Évalué à 2.
Mais ce qui peut tout aussi être enrichissant c'est d'approfondir un vieux langage que l'on croit connaître.
Par exemple prenez un vieux langage comme Python, vous savez qu'il est le fruit d'un travail de recherche. Et, à priori, ses concepteurs sont des personnes respectables.
Dès lors il est intéressant de s'interroger sur les choix qu'ont faits ces personnes.
Exemple : pourquoi imposer l'indentation du code dans la syntaxe du langage ? Vous savez que de toutes façons dans un cadre professionnel on vous demandera d'appliquer des règles de codage, parmis lesquelles il y en aura forcément une qui traitera d'indentation.
Alors pourquoi ce choix d'indentation ? N'est-ce pas pour faire en sorte que votre code soit le plus lisible par le plus grand nombre ?
Ce que vous voyez comme une contrainte à votre encontre s'avère être en sorte une aide pour que d'autres puissent facilement relire votre travail et apprendre en s'affranchissant des questions de tabulations, d'éditeur...
De même, le C, les pointeurs de fonctions, sizeof truc, etc.
Bonnes fêtes de fins d'année !
Fred
[^] # Re: Approfondir aussi
Posté par reno . Évalué à 3.
Un lien sur ce sujet: un enseignant a experimenté avec le même langage avec ou sans indentation significative et il a trouvé que ses étudiants apprenaient mieux avec l'indentation significative.
Interessant je trouve: pour une fois que quelqu'un a une approche 'scientifique' des langages:
http://lambda-the-ultimate.org/node/2695
Une remarque cependant: >> à priori, ses concepteurs sont des personnes respectables <<
La respectabilité des concepteurs n'implique pas malheureusement qu'il ne sont pas capables de faires des *grosses* erreurs dans leurs langages..
J'ai énormément de respect pour Dennis Ritchie, il n'empèche que je considère qu'il a fait (au moins) deux grosses erreurs sur le C:
- variables non initialisée par défaut plutôt qu'en option: où comment créer une source majeur de bug et de problème de sécurité pour un faux gain de performance (*)
- syntaxe différente entre la déclaration de variable et l'utilisation,
comment compliquer la lecture de programme sans gain particulier.
*: puisque si les tests montrent que l'initialisation des variables prend trop de temps, alors on pourrait les annoter pour les déclarer non-initialisée.
# D a la place de Go
Posté par reno . Évalué à 3.
[^] # Re: D a la place de Go
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Mainstream || hype || marginal
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
À mon avis, je pense qu'il faut d'abord faire le point sur soit-même. Savoir où on en est dans les langages qu'on connais, quels sont les paradigmes qu'on y applique et lesquels on ignore totalement.
Par exemple, le C++ a de nombreux paradigmes, et de nombreuses techniques sont liées à ces approches. Elles permettent d'emprunter plusieurs voies pour appréhender et résoudre un même problème. Mais telle ou telle approche sera plus apparente dans un autre langage. Par exemple, la programmation fonctionnelle en Javascript m'a permis de comprendre et de maîtriser le contenu des en-têtes algorithm et functional. Python me permet d'avoir une approche plus directe et d'explorer la programmation orientée objet sans devoir souffrir du typage statique. Même si en Python, l'absence d'encapsulation (ce qui me pousse à considérer Python comme un langage absolument pas orienté objet) et le passage par référence par défaut (sauf exception) est parfois surprenant.
PHP m'a permis de manger quelques temps. C'est le premier langage dans une optique professionnelle que j'ai assimilé. C'est là encore un autre but dans l'apprentissage du langage : quel est la technologie qui me permettra de bien manger (parce que bon, du boulot pour les développeurs, il y en a beaucoup).
Un troisième objectif peut être la découverte absolue. Apprendre un nouveau langage dont on sait déjà ce qu'on va y trouver n'est pas forcément très intéressant. Le conseil du livre cité est agrémenté d'arguments et de raisons pour lesquelles il faut apprendre de nouveaux langages, mais pas seulement. L'auteur conseil aussi de s'intéresser à d'autres champs de connaissances. C'est ainsi qu'on produit des réponses originales, inédites, à des problèmes qui n'ont reçu que des réponses insatisfaisante.
Pour l'année à venir, je pense continuer à apprendre C++0x et Python 3. Mais aussi solidifier mon expérience en Javascript. Car comme c'est parti, 2011 sera l'année du Javascript (HTML5, Node.JS, MongoDB, CouchDB, etc).
On en a pas parlé, mais les langages de traitement de flux texte (awk, XSL) et de grammaire (bison, EBNF) sont autant de langages délaissés parce qu'on en voit pas l'utilité intrinsèque. Jusqu'à ce qu'on en ai besoin.
Et pourquoi pas un peu d'assembleur ? :D
[^] # Re: Mainstream || hype || marginal
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Question inutile.
Tu prends Scheme/Common Lisp, c'est fait pour tous les usages :)
T'as du fonctionnel, de l'impératif, de l'objet, du concurrent (à la Erlang, avec Termite/Gambit-C), etc.
Ça marche pour les calculs matheux (maxima), pour le jeu vidéo (abuse, farmageddon (sur iphone !)), pour comparer les prix les moins chers de vols en avion (itasoftware), pour animer la tête de Gollum dans Le seigneur des anneaux (Mirai), pour faire des serveurs webs ultra rapides (teeteepeedee), des WM (stump), etc.
[^] # Re: Mainstream || hype || marginal
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Remarque, je bosse pour une de celle qui fait du Ocaml. Donc,cela existe.
"La première sécurité est la liberté"
[^] # Re: Mainstream || hype || marginal
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
[^] # Re: Mainstream || hype || marginal
Posté par Amber . Évalué à 1.
# Lilypond
Posté par H. Guillaume . Évalué à 2.
Mon langage de programmation est musicale : lilypond.
Guillaume
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 3 type de langage a connaitre:
Posté par daimrod . Évalué à 3.
En fait il te manque un langage fonctionnel (Haskell, OCaml) et un Lisp (que je ne sais pas trop comment définir méta-
[^] # Re: 3 type de langage a connaitre:
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Ne serait-ce que prolog (puis langage synchrone, comme dit dans mon message plus bas).
Lisp, c'est pas tant la peine si c'est juste pour apprendre les concepts et qu'il a déjà l'objet, l'impératif et le fonctionnel en poche.
[^] # Re: 3 type de langage a connaitre:
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Le jour ou tu découvre comment fonctionne un map ou un grep (en perl); tu découvres un moyen de résoudre des problèmes de façon utlra concise. Passer des fonctions en paramètres changent beaucoup de choses.
Tu as aussi les contrats (assert() en C et Java, les bloc [] en smarteffel ou en lisaac, qui s'hérite). Ils te permettent de poser tes conditions sur les entrées/sortie de ton code, cela évite de faire trop de programmation défensive, qui finit par couter et facilite de beaucoup les tests en proposant une série "d'Oracle" qui te donne un vrai ou faux dans un test.
Lisaac apporte un plus par rapport à Java c'est de pouvoir faire plein de petit objet, plein de niveau d'héritage, sans perte de performance.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 3 type de langage a connaitre:
Posté par Krunch (site web personnel) . Évalué à 3.
(define (compose f g) (lambda (x) (f (g x))))
La construction Scheme ci-dessus retourne une fonction appelée "compose". Cette fonction prend deux arguments f et g qui sont eux même des fonctions et retourne une fonction qui est la composée (composition ?) f(g()).
Pour faire ce genre de chose en C, tu vas t'amuser.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: 3 type de langage a connaitre:
Posté par barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: 3 type de langage a connaitre:
Posté par Krunch (site web personnel) . Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: 3 type de langage a connaitre:
Posté par ZankFrappa . Évalué à 2.
Pense à l'itérée d'une fonction par exemple.
[^] # Re: 3 type de langage a connaitre:
Posté par barmic . Évalué à 2.
Le problème au C pour faire ça en plus du fait qu'il n'est pas fonctionel c'est son typage static et pas de réflexivité, sinon dans l'absolue tout est possible avec le fameux void *.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: 3 type de langage a connaitre:
Posté par Krunch (site web personnel) . Évalué à 2.
J'ai pas dit que c'était pas possible en C. Mais c'est bien plus compliqué et donc en pratiquer tu vas programmer autrement.
Je ne suis pas sûr de voir ce qu'est que « l'itérée d'une fonction » non plus.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: 3 type de langage a connaitre:
Posté par Bruno Michel (site web personnel) . Évalué à 2.
[^] # Re: 3 type de langage a connaitre:
Posté par Krunch (site web personnel) . Évalué à 2.
int (*compose(int (*f)(int), int (*g)(int)))(int) { int composed(int x) { return f(g(x)); } return &composed; }Si tu connais des gens qui écrivent du C comme ça, je demande à voir quand même.pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: 3 type de langage a connaitre:
Posté par Moonz . Évalué à 2.
(int(^)(int)) compose((int(^)(int)) f, (int(^)(int)) g) {
return ^(int x){ return f(g(x)); }
}
Et oui, c’est utilisé en pratique, notamment chez Apple (forcément) dans libdispatch par exemple.
[^] # Re: 3 type de langage a connaitre:
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: 3 type de langage a connaitre:
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
@selection = map {$_ if ($_> 10)} @array;
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 3 type de langage a connaitre:
Posté par 2PetitsVerres . Évalué à 6.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: 3 type de langage a connaitre:
Posté par Olivier Abad . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 3 type de langage a connaitre:
Posté par gasche . Évalué à 1.
[^] # Re: 3 type de langage a connaitre:
Posté par MsieurHappy . Évalué à 1.
Il est certes très utile de comprendre comment fonctionnent les entrailles de la machine, mais l'abstraction a pour but précisément de se détacher du fonctionnement concret de l'ordinateur, et d'offrir un moyen plus élaboré d'aborder les problèmes et d'exprimer plus élégamment leur solution.
L'ordinateur étant une machine à automatiser, autant automatisé ce qui peut l'être également en programmation.
Un nouveau langage pourquoi faire ? Une boucle est une boucle, un test un test etc.
Il y a des langages sans boucle! Alors évidement, il sera toujours exécuté par les mêmes instructions fondamentales du processeur. Mais l'expressivité n'est vraiment pas à négliger.
Ça m'a fait directement penser à l'expérience d'Ontologia: https://linuxfr.org/comments/1138809.html#1138809
Pour ma part, l'apprentissage de différents langages de programmation m'a énormément ouvert d'horizons quant à la manière d'affronter un problème.
Le langage qui a le plus marqué mon esprit est Haskell, et les concepts de programmation fonctionnel en général. Et quand j'utilise un langage de haut-niveau qui n'offre pas cette expressivité, je me sens très frustré. Et Java est probablement un des langages qui m'est le plus pénible tellement il est inexpressif et rigide, sans offrir de réelle contre-partie qualitative.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 3 type de langage a connaitre:
Posté par Shuba . Évalué à 2.
À l'opposé, des langages aux paradigmes différents proposent des modèles de parallélisme bien plus évolués : Scala et ses agents, Haskell a une STM, Erlang est conçu pour le message passing, etc.
Avec une différence fondamentale entre la programmation "classique" et la programmation parallèle : si avant on bénéficiait du modèle de Turing pour nous dire que de toute façon, on savait que tout était faisable, là c'est tout sauf le cas, on ne sait toujours pas (à ma connaissance) s'il est possible d'avoir la même classe de calculabilité en distribué qu'avec un seul process. D'où le fait qu'aller chercher des paradigmes différent pourrait aider à mieux appréhender ce problème.
Pour résumer mon post long et plutôt mal structuré en une phrase : on peut continuer à coder en impératif, mais alors il faudra peut-être dire adieu au doublement de la puissance de calcul tous les 18 mois.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# Synchrones
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Ça aussi, c'est fun !
(Ni intercal ou unlambda, mais c'est une autre histoire…)
[^] # Re: Synchrones
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Synchrones
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Mais j'ai eu des cours d'Esterel et de Lustre autrefois, et je trouve que c'est sympa la programmation synchrone ou réactive.
[^] # Re: Synchrones
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Synchrones
Posté par Perthmâd (site web personnel) . Évalué à 1.
http://linuxfr.org/2010/12/20/27690.html#1193039
# C'est dans les vieux pots qu'on fait les meilleurs bugs
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Object Pascal, Ada et Eiffel, par exemple, méritent certainement un peu d'attention.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.