Göedel, Esher, Bach

Gödel, Esher, Bach

Göedel, Esher, Bach

Dans le cadre du concours organisé par Alias sur le thème de l’l’été de l’échec, je vais aujourd’hui vous parler du livre Gödel, Esher, Bach, Les Brins d’une Guirlande Éternelle de Douglas Hofstadter, un livre très intelligent que je n’ai jamais fini de lire.

Comme son titre l’indique, cet ouvrage tisse les parallèles entre les œuvres de trois personnages très importants: Gödel, un mathématicien, le compositeur Bach et l’artiste Esher, connu pour ses images paradoxales. Le livre a eu très une bonne réputation auprès des scientifiques et il est de bon ton de l’avoir dans sa bibliothèque.

Le problème du livre, c’est qu’il est long (880 pages, avec annexes, index, et bibliographie) et ardu à lire. Les idées exprimées ne sont pas si complexes que ça, dans la partie que j’ai réussi à lire, il s’agit fondamentalement du théorème d’impossibilité de Gödel et d’explications sur la récursivité qui se retrouve beaucoup dans Bach et Esher. Le problème c’est que le style se situe exactement dans la vallée aride entre un bon roman et une bonne thèse, soit trop d’histoire, soit pas assez.

Summer of Fail

Les hypothèses sur ce qu’il faut expliquer où non ont aussi mal vieilli: le texte date de 1979; vingt ans après, en pleine révolution informatique, les notions d’univers nichés et de récursivité étaient beaucoup plus naturelles, le grand public avait vu Matrix. Je suppose qu’aujourd’hui les gens ferraient le rapprochement avec Inception

Entre temps, j’ai parlé avec différents geeks, qui sous le couvert de l’anonymat ont admit qu’eux non plus n’ont pas terminé ce livre. Peut-être qu’un jour j’essayerai à nouveau de le lire et que le style m’ennuiera moins, mais probablement pas cette année.

Flattr this!

Summer of Fail

Conversions Bibliographiques…

Summer of Fail

Alias a proposé sur son blog un thème de billets, intitulé summer of fail ; l’idée étant de raconter un truc qui n’a pas marché. Il y a là évidemment matière à de nombreux billets, mais une partie de mon cerveau s’est coincé sur le mot été, et donc les évènements qui me viennent à l’esprit sont ceux qui ont eu lieu en été, ou tout du moins ceux où je pense qu’ils ont eu lieu en été. Enfin.

Alors que j’étais encore étudiant à l’université de Genève, j’avais un petit boulot dans un laboratoire dans une autre faculté. Principalement je faisais la maintenance d’un parc de Macintosh, nettoyage des systèmes, mises à jours et backups principalement. Une des applications utilisées par beaucoup de gens était Filemaker, qui était notamment utilisé pour garder une liste des références bibliographiques.

Un des problèmes qui était apparu, c’est que les gens avaient utilisé différent formats pour les références : Bibτεχ d’une côté, OneNote de l’autre. Même avec le même format, les entrées étaient inconsistantes, parfois c’était (nom, prénom), parfois l’inverse, certains entrées séparaient les noms avec des virgules, alors que d’autres ajoutaient un and à la fin, avec ou sans Oxford comma, et évidemment il y avait des noms à particules dans un peu près toutes les langues européennes.

Le directeur du laboratoire m’a demandé un jour si je pouvais créer un outil pour mettre de l’ordre dans ce zoo. J’avais un superbe IDE (CodeWarrior), j’étais en train de terminer mes études, j’allais enfin écrire un vrai programme, je lui ai dit que cela ne devrait pas poser de problème et je me suis mis au boulot.

Évidemment, au moment où j’ai commencé à programmer, je n’avais qu’une idée vague de l’ampleur du problème ; après plusieurs semaines j’ai fini par jeter l’éponge, chaque fois que j’ajoutais la logique pour gérer un cas spécifique un autre cas étrange apparaissait, ou bien je créais une régression. Le problème n’était toujours pas résolu lorsque j’ai quitté l’université.

Ce fut mon premier programme qui manipulait des données non normalisées, or la normalisation de données est typiquement le genre de choses dont on ne parle pas à l’université, avec le recul, je vois assez bien comment j’aurais pu attaquer ce problème:

  • Comprendre mieux les données d’entrée, lire plus sur les formats Bibτεχ et OneNote, faire des statistiques et une liste de cas pathologiques, avoir une personne à qui poser des questions sur ces formats.
  • Comprendre mieux les attentes du client : est-ce que convertir 95% des données et avoir une liste d’entrées nécessitant un traitement manuel aurait été acceptable ?
  • Avoir des tests unitaires pour ne pas se retrouver sans cesse avec des régressions.

Évidemment, à l’époque tout cela m’était largement inconnu…

Flattr this!

Swift Logo

A first look at Swift

Swift Logo

Apple’s announcement of the Swift language was quite a surprise, while the company had extended Objective-C in the past, it had not dabble in programming languages since Dylan and Applescript, so I was quite curious to see what this is about.

Swift is presented as the successor of Objective-C, but drops the C compatibility while keeping a C-like syntax, in a way similar to Go or Rust, Swift borrows ideas from many existing languages: Objective-C, Python, but also Rust and C♯. Compared to say Python, the language is actually pretty complex, as it has many features. Gone are the days were languages tried to be minimalistic, here the goal is clearly to implement features for common programming patterns.

Given the fact these day I mostly code in C++11 and Python 2.7, I found the language to have interesting features:

  • Compiled language, with the goal of being faster than Objective-C. Uses LLVM as compilation back-end.
  • References and Value types. Swift borrows from C♯ that classes are reference types and structs are value types, passed by copy to functions and methods. This means that complex data can live on the stack and be contiguous in collections. This makes a big performance difference and is also a big theme in C++11 and C++14.
  • Strong typing with type inference, with a differentiation between variable and constant, one declared with var, the other with let, no duck typing for functions, but the language supports templates and protocols (interfaces). Types can be extended outside of the original declaration and this can be used to make them adopt new protocols.
  • Enum types can be based on any raw type (not only integers), and can have associated data depending on the enum value, so they also implement the functionality of union.
  • Switch statement based on any types, with the complex matching rules, so you can branch on ranges, or conditional expressions. Something that the Rust language has.
  • Optional types everywhere. Swift has no pointers, and no magic None/Nil value like Python has, Conditional types express the idea of something of type X or nothing, a feature you would implement using a pointer and check for null, this is the same as the boost:optional template in C++, but more integrated into the language, as there is an optional access operator.
    Consider an object A which has a field b which can contain a value of type B which has a field c, which can contain a value of type C. If you have an value a of type A and you just want to read the field a.b.c, you have to add a lot of if statements, or try accessing it and handle exceptions. In Swift you just call a?b?c which returns you can optional of type C. This is really nice because this kind of access is pretty common (for instance in protocol buffers).
  • Lot of syntactic sugar: nice loops, tuple decomposition, i.e let (x, y) = getCoordinates(), clean range expression [1..9], integers can contain underscore to be more legible like 1_000_000, string interpolation can contain arbitrary expressions (including function calls) "sin \(x) = \(sin(x))"

We will see how the language performs in practice, I suspect its impact will mostly be determined by the way Apple releases the language, if it is free, it might get wider adoption. Regardless of the success of Swift, I think many of the ideas in the language are good ones, and so I hope this will lend support to the languages which already have those features, and encourage other languages to adopt them.

Flattr this!

Polycristalline-silicon-wafer

Un monde de fleurs

Polycristalline Silicon Wafer

On parle beaucoup ces temps d’énergies renouvelables, et l’on commence à voir des panneaux solaires sur le toits des bâtiments. Produire l’énergie a proximité de là où elle est consommée a le grand avantage d’éviter une grosse infrastructure de transport et les pertes qui y sont associées. Produire de l’énergie au milieu du désert est facile, transporter efficacement le courant électrique vers la civilisation implique des installations complexes.

La continuation logique de cette tendance est de l’étendre à toutes les surfaces : murs des bâtiments, voire même routes. C’est logique vu qu’on parle de surfaces importantes à proximité des lieux de consommation. Il y a des problèmes techniques, bien sûr : les panneaux doivent être solides, peu onéreux à la production, faciles d’entretien, mais je soupçonne que le réel problème est social.

Est-ce que vous avez regardé les murs des bâtiments autours de vous récemment ? Une partie non négligeable de la surface est occupée par différentes marques territoriales : publicités et affiches sauvages ou non, graffitis. Les routes pour leur part sont constellées de chewing gum. Si les murs et les routes sont des panneaux solaires, toutes ces taches résultent dans des pertes de production électrique.

Pour l’instant, un graffiti est au pire quelque chose de moche, le mur sur lequel il a été dessiné reste parfaitement fonctionnel, la déprédation n’est qu’esthétique. Couvrez le mur de panneaux solaires, et le graffiti devient une destruction de moyen de production, quelque chose qu’il sera plus difficile à tolérer.

Les bâtiments vont probablement devoir se muer de mini-forteresses en surfaces de fleurs artificielles, chacune collectant de l’énergie, c’est très beau, mais cela implique aussi une société qui protège les murs, au lieu de murs protègent la société.

Polycristalline-silicon-wafer © Georg Slickers Creative Commons 3.0 Attribution – Partage dans les Mêmes Conditions 3.0 non transposé.

Flattr this!

Le Miel – Slobodan Despot

Le Miel

Le Miel – Slobodan Despot

Même si la Serbie est géographiquement proche de la Suisse, c’est un pays que je connaissais mal, le chaos de la guerre en Yougoslavie n’apportant que très peu de clarté à la situation. Le miel de Slobodan Despot donne une perspective personnelle sur la guerre vue du point de vue Serbe.

Au travers de Vera l’herboriste, le roman raconte le voyage de Vesko la teigne dans une région devenue pays étranger, à la recherche de son père oublié dans les montagnes. Comme le nom l’indique, le miel joue un rôle central dans l’histoire, c’est une des choses que j’ai remarqué en Serbie, commandez une tisane au café et on vous la servira avec non pas du sucre, mais du miel.

Le Miel

Gallimard NRF
ISBN : 978-2-07-014284-2

J’ai beaucoup aimé ce roman : court (126 pages), l’histoire est passionnante, parfois comique, parfois dramatique, le thème intéressant. Le style m’a rappelé celui de Nicolas Bouvier : riche et fluide. Bref, c’est une lecture agréable qui donne un éclairage intéressant sur la Serbie, et que je recommande chaudement.

Flattr this!