Journal
Ce journal contient 8 entrées.
Java for Everything
Les critiques récurrentes envers Java sont, la plupart du temps, infondées. Celle de la verbosité est particulièrement absurde, le concept d'autocomplétion est plus vieux que moi. On retrouve aussi le grand débat "bytecode interprété vs. code compilé", qui n'intéresse que ceux qui ignorent l'existence des mécanismes de compilation à la volée. Java est un langage qui évolue depuis sa création, aussi bien au niveau de sa syntaxe (p. ex. l'opérateur diamant, le multicatch, le try-with-resource, les lambda) que de son SDK (p. ex. NIO, streams, gestion de la concurrence), mais il continue à être jugé sous le prisme de ses premières versions.
Globalement, et cela est vrai pour tout langage, les critiques portent soit (i) sur la façon dont les logiciels sont implémentés en utilisant le langage, soit (ii) sur des points de détail plus ou moins significatifs. Ce sont ces détails qui permettront, justement, de déterminer le meilleur langage en fonction des besoins.
La question "quel est votre langage de programmation préféré" est particulièrement intéressante. Apprendre un langage, c'est assez facile, mais maîtriser son écosystème (librairies, techniques avancées, environnements d'exécution, compilateurs, débogueurs, etc.) est un exercice long et complexe. D'où des développeurs qui vont finalement toujours utiliser leurs langages/outils préférés dans n'importe quelle situation et inventer des arguments abracadabrantesques pour justifier leurs choix (ou invalider celui des autres).
A la vérité, je n'ai pas encore trouvé un "bon" langage, tous ceux que j'ai essayé et que j'utilise au quotidien sont tout juste "potables". A un moment donné ou à un autre, tous ces langages m'ont agacés pour tel ou tel problème de syntaxe, de logique, de performance ou d'incomplétude. Le langage idéal, à mon sens, est celui qui permet de décrire rapidement les idées (concrètes) que l'on cherche à implémenter sans forcément avoir à gérer les limitations propres aux structures du langage, à ses primitives, à ses librairies et à son environnement. Peut être y a t'il de l'espoir dans les domain-specific language, du fait de leur spécialisation.
Globalement, et cela est vrai pour tout langage, les critiques portent soit (i) sur la façon dont les logiciels sont implémentés en utilisant le langage, soit (ii) sur des points de détail plus ou moins significatifs. Ce sont ces détails qui permettront, justement, de déterminer le meilleur langage en fonction des besoins.
La question "quel est votre langage de programmation préféré" est particulièrement intéressante. Apprendre un langage, c'est assez facile, mais maîtriser son écosystème (librairies, techniques avancées, environnements d'exécution, compilateurs, débogueurs, etc.) est un exercice long et complexe. D'où des développeurs qui vont finalement toujours utiliser leurs langages/outils préférés dans n'importe quelle situation et inventer des arguments abracadabrantesques pour justifier leurs choix (ou invalider celui des autres).
A la vérité, je n'ai pas encore trouvé un "bon" langage, tous ceux que j'ai essayé et que j'utilise au quotidien sont tout juste "potables". A un moment donné ou à un autre, tous ces langages m'ont agacés pour tel ou tel problème de syntaxe, de logique, de performance ou d'incomplétude. Le langage idéal, à mon sens, est celui qui permet de décrire rapidement les idées (concrètes) que l'on cherche à implémenter sans forcément avoir à gérer les limitations propres aux structures du langage, à ses primitives, à ses librairies et à son environnement. Peut être y a t'il de l'espoir dans les domain-specific language, du fait de leur spécialisation.
ChucK => Strongly-timed, On-the-fly Music Programming Language
ChucK est un langage de programmation open-source et multiplateforme, pour la synthèse audio temps réel. Il se présente sous la forme d'une syntaxe spécifique, conçue pour exprimer simplement des opérations de synthèse audio (oscillateurs, effets, etc.) évoluant au cours du temps (logique temporelle) et les connecter les uns aux autres. De plus, le langage offre un modèle de programmation concurrente simple d'emploi.
Un petit exemple tiré de la documentation :
// on crée une signal sinusoïde que l'on connecte au "digital/analog converter"
SinOsc s => dac; // sine oscillator
while(true)
{
// on choisit une fréquence aléatoire entre 30 et 1000 Hz
Std.rand2f( 30, 1000 ) => s.freq;
// on avance de 100 millisecondes dans le temps
100::ms => now;
}
Un petit exemple tiré de la documentation :
// on crée une signal sinusoïde que l'on connecte au "digital/analog converter"
SinOsc s => dac; // sine oscillator
while(true)
{
// on choisit une fréquence aléatoire entre 30 et 1000 Hz
Std.rand2f( 30, 1000 ) => s.freq;
// on avance de 100 millisecondes dans le temps
100::ms => now;
}
Esoteric programming language - Wikipedia, the free encyclopedia
Comme j'ai fait référence à Brainfuck et à Chicken dans le post précédent, voilà une liste de langage de programmation exotique/ésotérique, certains d'entre eux étant de vrais langages et d'autres étant conçus uniquement pour être difficile à lire ou à écrire :)
Mes petits préférés :
http://en.wikipedia.org/wiki/LOLCODE
LOLCODE, avec ses instructions basées sur les idiomes Kikoolol.
http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29
Whitespace, un langage où les instructions sont codées par des espaces, des tabulations et des sauts de ligne.
http://www.dangermouse.net/esoteric/piet.html
Piet, dont les programmes sont des bitmaps qui ressemblent aux oeuvres abstraites de Piet Mondrian.
http://en.wikipedia.org/wiki/Ook_Ook
Ook Ook, une syntaxe alternative du Brainfuck qui encode les noms d'instruction dans des combinaisons de "Ook" (les lecteurs de Terry Pratchett comprendrons).
Et le grand prix revient au Malbolge (http://en.wikipedia.org/wiki/Malbolge), un langage type assembleur pour une machine virtuelle trinaire où chaque instruction a un comportement arbitraire qui peut dépendre à la fois des valeurs des registres mais aussi des adresses. De plus, un programme exécuté est naturellement polymorphe, les instructions étant ensuite remplacées par d'autres une fois exécutées.
D'autres détails amusants viennent perturber la compréhension des programmes, tant et si bien qu'il a fallu, je cite, "deux ans au premier programme Malbolge pour apparaître. Le programme n'a même pas été écrit par un être humain : il a été généré par un algorithme de recherche par faisceaux conçu par Andrew Cooke et implémenté en Lisp."
Mes petits préférés :
http://en.wikipedia.org/wiki/LOLCODE
LOLCODE, avec ses instructions basées sur les idiomes Kikoolol.
http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29
Whitespace, un langage où les instructions sont codées par des espaces, des tabulations et des sauts de ligne.
http://www.dangermouse.net/esoteric/piet.html
Piet, dont les programmes sont des bitmaps qui ressemblent aux oeuvres abstraites de Piet Mondrian.
http://en.wikipedia.org/wiki/Ook_Ook
Ook Ook, une syntaxe alternative du Brainfuck qui encode les noms d'instruction dans des combinaisons de "Ook" (les lecteurs de Terry Pratchett comprendrons).
Et le grand prix revient au Malbolge (http://en.wikipedia.org/wiki/Malbolge), un langage type assembleur pour une machine virtuelle trinaire où chaque instruction a un comportement arbitraire qui peut dépendre à la fois des valeurs des registres mais aussi des adresses. De plus, un programme exécuté est naturellement polymorphe, les instructions étant ensuite remplacées par d'autres une fois exécutées.
D'autres détails amusants viennent perturber la compréhension des programmes, tant et si bien qu'il a fallu, je cite, "deux ans au premier programme Malbolge pour apparaître. Le programme n'a même pas été écrit par un être humain : il a été généré par un algorithme de recherche par faisceaux conçu par Andrew Cooke et implémenté en Lisp."
Guess the Programming Language | Tutorialzine
Un petit jeu où l'on doit déterminer à quel langage appartient un petit bout de code. J'ai fait un superbe 20/20 (je savais bien que lire un tuto Erlang me servirait un jour !).
Après sur le principe ce n'est pas très difficile. Scala, Go, Groovy, etc. ressemblent à du Java. C et C++ se reconnaissent facilement avec leurs pointeurs, tout comme Objective C avec ses abominables paramètres. Perl ressemble à du PHP. C# ressemble à Java. Quant à Brainfuck et Chicken, pas la peine d'en parler :p
Après sur le principe ce n'est pas très difficile. Scala, Go, Groovy, etc. ressemblent à du Java. C et C++ se reconnaissent facilement avec leurs pointeurs, tout comme Objective C avec ses abominables paramètres. Perl ressemble à du PHP. C# ressemble à Java. Quant à Brainfuck et Chicken, pas la peine d'en parler :p
mrb: Types Are The Truth
Pour ceux qui ne comprennent pas le principe de "type erasure", ou qui veulent en apprendre plus à ce sujet.
"Most compilers for full-scale programming languages actually avoid carrying annotations at run time: they are used during typechecking (and during code generation, in more sophisticated compilers), but do not appear in the compiled form of the program."
"Most compilers for full-scale programming languages actually avoid carrying annotations at run time: they are used during typechecking (and during code generation, in more sophisticated compilers), but do not appear in the compiled form of the program."
Visual Programming Languages - Snapshots
Une petite liste de langages de programmation visuels, c'est à dire des langages dont la syntaxe concrète n'est pas exclusivement textuelle (code source) mais plutôt composée de symboles graphiques (boîtes et flèches, par exemple) et de textes disposés visuellement pour former des programmes.
Emotion Markup Language (EmotionML)
Dans la lignée de http://benjaminbillet.fr/news/?link=d5gwd et http://benjaminbillet.fr/news/?link=d5gwe voilà le format de description d'émotion imaginé par le W3C. Par contre, on dirait que ce n'est pas une blague et que ce format est destiné à l'informatique orientée émotion, ou informatique affective (affective computing).
http://fr.wikipedia.org/wiki/Informatique_affective
Fallait oser <<
http://fr.wikipedia.org/wiki/Informatique_affective
Fallait oser <<
Syntax across languages (One Big Page)
En rapport avec mon lien d'hier, voilà les correspondances de plusieurs éléments de syntaxe usuels à travers différents langages. La liste est véritablement impressionnante.
Ce journal est basé sur Ginger, un gestionnaire de lien minimaliste développé dans le cadre d'un stage de perfectionnement. Pour plus d'informations, consulter le wiki consacré à mes projets personnels.