Daniel Kvasnička

UPDATE: Added generic-cl as suggested on Reddit.

Before last year’s Advent of Code started I declared on Twitter that I was going to do it in Common Lisp. And so I "did" (with a couple of 2016 challenges in CL as well). Yes, quite a bit of the challenges are missing. I hope to get back to them some time 😇

This writeup will be a summary of what I liked, what I did not like and finally a set of libraries for various purposes I used and found interesting. There are a couple of lists like that on the net (especially https://awesome-cl.com/, which I have actually submitted PRs to during my work on this article) but I wanted one that would include a couple of comments based on my personal experiences -- basically I’ll be making a purely subjective list of things I don’t want to forget about and it so happens that it will be publicly available on my blog 🤓

Just so you know, the views here will be expressed from the PoV of a long time Clojure and Racket fan.

Pros & Cons

Let’s start with what I liked:

Speed -- the best CL implementations are fast, while still allowing you to maintain a very readable, high level idiomatic code. With SBCL, the most popular implementation, you are basically getting one of the fastest lispy experiences possible. We obviously need to address the elephant in the room here and that’s Cloure. Clojure, thanks to JVM, can be faster than Common Lisp. However the speed often times comes at the cost of writing a relatively ugly “C wrapped in parens” style of code and/or you need enough data to get good amortization while JITting.

Debugging and optimization -- this one kind of relates to the first point as well. Common Lisp contains very powerful debugging, introspection and optimization tools that are part of the base lang spec. It does not matter what kind of implementation you use or whether you are using the IDE everyone thinks is the coolest right now... Hell, you can even disassmble your program to see the actual ASM code that your CPU will juggle.

Stability of the language -- there are people who can express this better so I’ll just link to the appropriate section of the magnificent article Steve Losh wrote in 2018:

My advice is this: as you learn Common Lisp and look for libraries, try to suppress the voice in the back of your head that says "This project was last updated six years ago? That's probably abandoned and broken." The stability of Common Lisp means that sometimes libraries can just be done, not abandoned, so don't dismiss them out of hand.

Specification & standard (kinda applies to Scheme as well) -- This is a tricky issue that has started many flamewars in the past, not just in the Lisp world (see the Spring vs Java EE battle). Having to adhere to a spec brings limitations but there are 2 counterarguments I can think of in the case of CL:

The power of macros means you can overcome almost all cases of stalled innovation without performance penalty. Look at the loop macro and how it was essentially completely covered with zero-cost abstractions.

The myriads of Clojure-like languages all suffer from the same problem: You cannot use libraries or any of the cool tools in the ecosystem. Yet, they themselves do not have anywhere near the traction necessary to be widely used production languages. CL shows that you can have a standard and still have enough room for differentiation and innovation.

Lisp-2 -- yep, you read that right. I would have never expected to say this (and I believe I’ve actually shunned Lisp-2 on this very blog some time ago?) but I actually like that functions in Common Lisp live in a separate namespace, for a very simple reason: code is read way more ofthen than it is written. When I look at code and see that seemingly annoying funcall I know it’s not just a top level defunned function and that I need to trace its origins somewhere else. Similar principle applies for the #' prefix (also makes life easier for syntax highlighters).

Next, the annoyances:

Widespread mutability and imperativeness -- Mutability is good if used in specific cases where it makes sense and if quarantined properly. However in CL mutability is king. It's not as much a problem of the language or implementations (you don't have to write mutable code) as it is a problem of the historical baggage -- it was never customary in the CL land to look bad at code that creates a mutable collection, then puts stuff in it in an imperative cycle and returns it from a function out to the dark and cold world... Purely functional collections exist but CL is not built around them. This is where Clojure shines.

CL Sequences apparatus not being user-extensible -- Common Lisp has a concept of sequences which puts a roof over lists and vectors and allows the user to use one function for both. However this facility, for some reason, is not easily extensible. This leads to many libraries implementing various new data structures and using completely custom API to do simple things like getting the size of a collection because (defmethod length ((seq my-epic-data-structure)) ...) signals COMMON-LISP:LENGTH already names an ordinary function or a macro. Fortunately there are libraries that are trying to solve this and to be honest it is not that much of a PITA anyway, because using a different function name for a special data structure has positive readability and performance implications. This applies to Racket too, to some degree. This lack of extensibility might have technical reasons I don't know of and if that is the case I'd be curious to learn and understand them.

LOOP -- I hate loop. Fortunately, this is an issue only if you have to deal with legacy code. The iteration story in CL is so good that you'll basically never have to write a single line of loop if you don't want to. My favourite comment on the topic is this one.

Destructuring not being 1st class citizen (enough) -- CL has macros with annoyingly long names to do destructuring and does not have the concept built-in deep enough for it to be ubiquitous in e.g. function definitions like you can see in JS or Clojure. Fortunately -- you guessed it -- libraries solve this issue satisfactorilly.

Interesting tools and libraries

What follows is a set of libraries that I tried and found useful -- libraries that helped me make a lot of annoyances (almost) irrelevant. I'll include one or two libraries that I have not used yet but would like to as they seem cool to me:

Platform tools

Quicklisp -- primary source of packages for CL. There is also Ultralisp, which is a faster-moving package distro.

Roswell -- this became my go-to tool for managing implementations and also packages. It can install packages from Quicklisp as well as GitHub repos in a manner similar to how go get works for example.

Qlot -- project-local dependencies manager that works well with Roswell. Think npm for Common Lisp. Can get dependencies from other Git repos, not just GitHub.

General purpose

Alexandria -- this is the utilities library in the CL world. It's so widespread that it's almost a standard thing.

Serapeum -- the Serapeum of Alexandria was an ancient Greek temple; referred to as the daughter of the Library of Alexandria. You get the idea ;) As you can see, the library is massive and I include it in most programs I write.

rutils (API) -- another impressive assortment of functions and macros. I would especially like to point out the with macro in the rutils.bind package, which is a kind of an extensible über-let.

metabang-bind -- another let on steroids. Unlike with it can bind arrays/vectors out of the box but is a little bit more chatty (and probably not as actively maintained).

cl-losh -- this is a library that its author explicitly does not want you to use. Sorry, Steve :) Your library is way too good for me to abide by your orders. What I found especially useful is the library of extensions for iterate, the de-facto replacement for LOOP we'll discuss later.

CL21 (and its very recent revival named 20XX) -- very interesting attempt at refreshing some of the more antiquated aspects of CL. It can be used as a library only to cherry-pick good stuff but it's probably less painfull to go all in and write programs "in" CL21 if it makes sense for a particular package.

cl-str -- Modern, simple and consistent Common Lisp string manipulation library.

Iteration & sequence procesing

iterate -- IMHO overall the best of iteration libraries for Common Lisp. A significantly lispier alternative to LOOP. Allows for very idiomatic, concise and understandable iteration code, is extensible and widely accepted and extended.

series -- the original transducers library (yes, those transducers). When used in tandem with taps (see my fork with a bugfix as well) it allows the programmer to write very succinct "top level" code (e.g. the main driver of a program that reads from a stream and delegates work to other parts of the code), or complex pipelines in general.

for -- another extensible LOOP replacement, this time a bit closer to Racket's ecosystem of for comprehensions.

gmap -- this is probably one of the most underrated/under-popularized pieces of gear I've come across in the Common Lisp land (tracing its origins back to 1980!). Combines mapping, filtering and reducing into a neat transducer-ish extensible construct and has a built-in support for FSet, a functional collections library we'll talk about later. The same Lisp project also contains new-let ...guess what is it supposed to be 😉 Yeah, let is the new loop.

generic-cl -- provides a generic function wrapper over various functions in the Common Lisp standard, such as equality predicates and sequence operations. An answer to on of my critical points above (defines generics that overlay CL builtins).

You can also find many small iteration helper tools scattered across the general purpose libraries we discussed in the previous section. Mapping from X to Y, reducing all kinds of things etc...

Math

cl-geometry -- 2D computational geometry library, which made work on Day 3 of AoC 2019 very enjoyable for me.

Data structures

FSet -- functional library of sets, maps and bags that has a natural and clean API and as we already mentioned, it comes with the added bonus of being written by the same guy who wrote gmap.

cl-containers -- a massive collection of (mostly tree-based) data structures and algorithms, useful when you need stuff like sorted map etc.

graph-utils -- graph data structure and algorithms

sycamore -- fast purely functional data structures

random-access-lists -- useful library for when you need a listy data structure and you don't want to pay O(n) when accessing elements in it.

array-operations -- library for concisely expressing operations on (multidimensional) arrays. Being used to the Racket array library it took me a while to get used to some of the specifics but it indeed is very powerful and fast.

Static typing & contracts

Apart from the built in tools for specifying types statically you can also use these to strenghten your safety net:

defstar -- Macros for easy inclusion of type declarations for arguments in lambda lists. Can replace defun, defmethod, defgeneric and others.

cl-algebraic-data-type -- a library for defining algebraic data types in a similar spirit to Haskell or Standard ML, as well as for operating on them

quid-pro-quo -- A contract programming library for Common Lisp in the style of Eiffel’s Design by Contract

Testing

These are the two testing libraries I tried out. I prefer parachute, the API feels more natural to me. There are others and it's getting worse 😉

rove

parachute

OOP

In addition to the following libraries you should check CLOS-related sections of almost all of the general purpose util libraries we discussed above. They contain stuff to help make CLOS a bit less verbose.

defclass-std -- a macro that atempts to give a very DRY and succint interface to the common DEFCLASS form. The goal is to offer most of the capabilities of a normal DEFCLASS, only in a more compact way.

sheeple -- prototype-based OOP in Common Lisp? 😱 Because we can!

Verdict

Martin Malý - zřejmě v reakci na popularizační hackathon/happening mající za cíl přitáhnout pozornost a možná napsat státu kousek e-shopu - napsal článek Státní paradox, který je podle mého soudu zbytečný, plný klišé, informačně vyprázdněný a "ředí” snahu učinit přítrž abusrdnímu rozkrádání v oblasti státních IT zakázek. Zde je pár poznámek k některým částem jeho textu.

všichni nadávají státu, že platí nesmyslné částky za dodávky, ale zároveň kdyby byli v roli osloveného dodavatele, tak jim nedělá problém předraženou zakázku přijmout

Ignoratio elenchi. Hezké, ale zbytečné.

Přitom právě požadavky na dostupnost, bezpečnost, certifikace a záruky šponují cenu na násobky “běžných tržních cen pro běžná komerční řešení”.

Důkaz? Chci vidět jak by řešení se stejnými parametry vyvinuté v prostředí relativně dobře fungujícího trhu pro tržní subjekt muselo stát stejné peníze.

v něčem, co spíchla firma, která už neexistuje, zato za levno?

Strawman a false dilemma jak řemen. Kdo něco takového navrhuje?

A jaké má použít dodavatel softwaru pro vaše auto? A jaké má použít dodavatel softwaru pro stát?

Možná to nesleduju dost detailně, ale nevšiml jsem si že by někdo řešil v čem bude IS napsán. Osobně je mi jedno jestli to bude stará nebo nová technologie. Jako fanoušek Common Lispu asi těžko budu patřit mezi ty co by se pohoršovali že to nepojede na super vymazleném Node.js frameworku měsíce, jehož první commit na GitHubu má ještě mlíko na bradě...

Hlavní problém tady ale je, že tohle jsou nesmyslná srovnání - tyto use casy (NASA, auto) mají svoje praktická specifika, která výběr technologií určují. Stejně tak to má být u státní zakázky, “státní” samo o sobě není argument. NASA nepoužila C či assembler protože byla "státní".

Vždycky bude platit, že chceme, aby stát své systémy stavěl extrémně robustně, protože jde o nás, a zároveň budeme nadávat na to, že to je předražené a mastí si na tom kapsy furt pět stejných firem

Opět false dilemma.

Stejně tak budeme vždy vyčítat státu, že rozhazuje peníze na svůj vlastní provoz. A na druhou stranu mu vyčteme, že nedokáže přitáhnout na patřičná místa prověřené odborníky z praxe.

A znovu.

Samozřejmě tlak na zeštíhlení státu, omezení byrokracie, oříznutí prostoru na korupci a ucpání míst, kudy prosakují prachy ven, je v pořádku a nutný. Jen, víte, i tady platí, že nemůžete mít nejlepší koláče nejlevněji.

Palivovník jsme si představili a teď je na čase napsat něco pro ty z vás kolegů vývojářů, kterým v hlavě zní ono slavné “v čem je to napsané?!” :)

První nápad napsat podobnou aplikaci se mi zrodil v hlavě asi před dvěma lety. Sice jsem už tehdy prakticky koketoval s Clojure, ale postavit na tom aplikaci jsem si netroufnul, takže první nástřel jsem začal psát s pomocí Neo4J, Springu a JSF 2. Z různých důvodů, z nichž si pamatuju asi jen svojí přirozenou “projektovou promiskuitu”, se tohle moc nerozvinulo — alespoň pokud můžu soudit podle toho, na co se teď koukám na disku :) Čas šel dál, dělal jsem všecho možné a na všem možném, ale ideu Palivovníku jsem měl pořád někde vzadu v hlavě. A tak jednoho dne, když už jsem byl dostatečně zamilován do Clojure a věděl jsem, že už můžu risknout v tom psát něco víc než malé podpůrné moduly, rozhodl jsem se projekt oživit. Než jsem se dostal do releasovatelné fáze, uběho samozřejmě hodně času, protože jsem se - jak je mým zvykem - věnoval všemu možnému. Pokusím se teď popsat stěžejní technologie, na kterých Palivovník běží — pěkně odspoda nahoru.

Neo4J

Vše kromě údajů o tankování je uloženo v grafové databázi Neo4J. Praktičnost, s jakou grafové databáze pomáhají vyjádřit (a pak opět číst) informace o propojeném světě, mě fascinuje. Uživatelé, auta, značky, motory… vše je spolu spojeno vztahy, které se dají nějak vyjádřit a pevně věřím, že pokud se projekt malinko rozjede, bude velmi zajímavé sledovat, co za síť se v tomto grafu uvaří.

MongoDB

Světem vývoje SW milovaná nebo nenáviděná. I vztah tohoto projektu a Monga byl z počátku docela turbulentní. Měl jsem totiž jakousi (z mého dnešního pohledu zcela špatnou) touhu projekt nepřekombinovat a použít pouze jednu databázi. Pořád jsem si říkal, že cpát tam více než jednu DB je neobhajitelné hračičkovství, ale čím dál jsem nad typy dat uvažoval, bylo mi jasné, že pokud si chci zachovat flexibilitu (hlavně co do budoucího dolování dat), nějaké kombinaci se prostě nevyhnu.

Mongo tedy ukládá všechna tankování a také odvádí část výpočtů potřebných pro statistiky (část je přímo v Clojure, kde je to nesrovnatelně příjemnější psát). Důvody, proč jsem ho použil:

hotová a zadarmózní podpora na OpenShiftu, kde aplikace běží

schopnost uložit tankování i s jednotlivými fázemi jako jeden dokument

schopný agregační framework a podpora MapReduce (to první již aktivně používám, druhé možná přijde vhod)

podpora pro geo data (u každého tankování lze zadat adresu)

kvalitní a prověřená knihovna pro Clojure od kluků z ClojureWerkz

velká komunita, dostupnost informací a znalostí

Asi by mě docela bavilo místo Monga nasadit můj oblíbený Riak, ale to už by skutečně hračičkovství bylo — minimálně v téhle fázi :)

Clojure

Celý server je napsán v jazyce Clojure, který asi netřeba nikomu představovat. Zkušenost s dlouhodobým vývojem v tomto jazyce lze asi nejlépe popsat anglickým slovem eyeopener. Způsob, jakým mi tenhle znovuzrozený funkcionální Lisp neleze do cesty, jak mě nechává soustředit se na problém místo na programovací jazyk, je bezprecedentní — tedy pro mě byl, když jsem se do toho ponořil. Prostě data-driven no-bullshit get-the-thing-done platforma. Zapomněl jsem na nějaký buzzword?

Konkrétněji jsou použity knihovny Compojure, lib-noir, Enlive, Monger, Neocons a Midje na testy. Je tam samozřejmě pár dalších drobků, ale všechno to vypisovat nemá smysl.

CoffeeScript

V Coffee se mi píše docela dobře, je to takové trochu zenovější psaní než v JS. Jeho třídnímu objektovému modelu se vyhýbám a používám CS spíš jen jako syntaktický cukr, abych se z JS nezcvoknul a aby se na to dalo koukat :)

AngularJS

Vím, teď je nejvíc kůl React (a je!), ale když jsem s projektem začínal, tak fakt nebyl :) Angular je dobrá konzervativní volba pro trošku komplexnější věci na klientovi, kde nestačí to pobastlit v jQuery. Doplňuje ho tedy jQuery, Promise.js a Moment.js na práci s datumy a časy.

Graf na dashboardu dělá C3.js, což je moc povedená knihovna hotových grafů nad slavnou dé trojkou. Je dost možné, že v budoucnu se nevynu práci přímo s D3 — na to jsem zvědav.

If you are not embarrassed by the first version of your product, you’ve launched too late.

S tímto citátem Reida Hoffmana (spoluzakladatel sítě LinkedIn) na rtech bych vám chtěl představit jednu malou aplikaci: Palivovník.

Není to žádný pokus o startup, je to prostě něco, co mi chybělo a tak jsem si to napsal. Jde o aplikaci na zaznamenávání tankování paliva do vašeho auta a sledování vývoje průměrné spotřeby a dalších statistik.

Jak se Palivovník liší od ostatních služeb na trhu?

Hlavní důvod, proč jsem se rozhodl si takovou aplikaci napsat sám, byla potřeba vést záznamy o tankováních, při nichž šel do nádrže více než jeden druh paliva - typicky benzín a E85. Už mě nebavilo si nejdřív něco počítat na kalkulačce a pak to zadávat někde na webu jako jedno palivo — přirozeně se ztrátou informace. Palivovník tedy umožňuje ke každému tankování zadat libovolný počet fází. To v budoucnu umožní hlavně výpočty statistik závislých třeba na podílu konkrétního paliva na provozu auta.

Chtěl jsem něco, co bude vizuálně a graficky absolutně primitivní a čisté. Nejsem grafik ani “UXák”, takže nečekejte nějaké minimalistické grafické orgie — prostě jsem se snažil, aby aplikace dělala co má a nelezla do cesty. U konkurenčních webů jsem vždy měl jakýsi pocit přeplácanosti.

Chtěl bych něco, co se do budoucna bude chovat trochu jako sociální síť. Nějaké nápady mám a Twitter nebo Fejsbůk z toho určitě dělat nechci :)

Potřeboval jsem se jako programátor vyblbnout :) Jak konkrétně? Čtěte v blogpostu nazvaném Jak píšu Palivovník?.

So I was going through the book Clojure High Performance Programming and I thought I might share a line or two about why I think this book is a good read.

First, this really isn't just a book of recipes for writing faster Clojure programs by only exploiting what the standard library or 3rd party libraries have to offer. What I like about this book in general is the back-to-the-basics approach. You don't start with Clojure internals, you don't even start with JVM internals. Not even the OS. You start with bare metal. Getting to know (or refreshing the knowledge of) how CPUs work, how they interact with the RAM, where are the usual bottlenecks. Well, these things actually aren't covered right at the beginning of the book (which baffled me a bit) but you start getting the global picture once you go through them.

Other than that the book offers a good intro into the performance characteristics of persistent data structures in Clojure (yes, all the big-O stuff included) or how numerics in Clojure work and what is their relationship to the underlying Java implementations. A lot of interesting snippets showing not-that-well-known or darker corners of the Clojure language. Very important part of the book is the one on Clojure concurrency primitives - atoms, agents, refs - as these can be real bottlenecks when used improperly. You also get to know Clojure's explicit parallelization features, like parallel mapping or reducers and all that stuff.

There is a lot of things this book goes over, sometimes only glossing over. Some might (or actually do) think that this is the biggest drawback of the book. But to me this isn't a problem - on the contrary. All the things motivate me to fire up Google and start studying more on what might not be exactly a deep dive in right in the book.

[první díl zde]

Druhý den začal pravděpodobně nejlepší přednáškou celé konference, resp. určitě to byla přednáška s nejlepším potenciálem dostat lidi do varu.

Keynote: Narcissistic Design - Stuart Halloway

Stu je jeden z hlavních lidí kolem Clojure. Je zakladatelem (spolu s Richem H.) firmy Relevance (dnes Cognitect), která vyvíjí databázi Datomic a poskytuje k ní i k Clojure profesionální support. Narcissistic design je sada best practicess, kterou by se měl řídit každý programátor, který se nechce nikdy strachovat o práci. Sebestřednost a vysoce infekční komplexita (samozřejmě ta accidental) jsou perfektní pojistky toho, že vás bude firma nadosmrti potřebovat, abyste se o vyvinutý SW starali... Aneb: It's all about me! Tento talk už byl jednou nahrán na Reaktor Dev Day ve Finsku a i kdybyste neměli čas koukat na přednášky, tahle je must see (i když na EuroClojure padlo pár perel navíc, jelikož Stu věděl, že ho nikdo nenahrává - tuším, že se k tomu i přiznal ;). Zmíním tedy jen pár neocenitelných rad, které odteď sídlí v mém zlatém fondu vývoje SW (je to mix toho, co Stu přímo říkal a toho, jak si to já interpretuju - po shlédnutí videa uvidíte, co vám bude dávat smysl a co třeba ne):

Hodně objektového programování, hodně stavu a hlavně - settery! Těch není nikdy dost. Ať je trocha adrenalinu. Život začíná po třicítce ...eee, po konstruktoru.

Kašlete na komunikaci skrze data, vystavujte API - nuťte lidi používat váš jazyk! 

Žádná asynchronicita a hlavně žádné fronty! Těsná vazba je váš kamarád, tvrdě synchronní komunikace třešnička na dortu!

Proboha, hlavně žádné obyčejné datové struktury, které může každý zpracovat jak se mu líbí! To by tak hrálo! Odteď objekty! VŠUDE! CustomerBean, CustomerDto. Na každou blbost udělejte DTOčko. Vždycky. A ty settery, nezapomeňte...

Hodně statického typování a to hlavně napříč subsystémy. V souvislosti s tím je dobré i používat věci jako Java RMI, CORBA apod. Dynamické jazyky jsou hračky pro malé děti a nic velkého v nich napsat nejde. Infikujte a svažte svými typy úplně všechno kolem.

Pište unit testy, zneužívejte je prakticky pro cokoliv a nahraďte jimi ...všechno. Hlavně veškerou dokumentaci.

Unit testy jsou v kombinaci se statickým typováním taky pěkný způsob, jak řešit triviální bugy. Že se dá mnoha bugům předejít použitím neměnných datových struktur, funkcí bez postranních efektů apod.? Blah! Nejsme včerejší!

Nepoužívejte perzistentní a neměnné datové struktury. Ty jsou pro světy, kde se pamět měří v megabytech nebo dokonce gigabytech (to prý existuje!) a HW není drahý. My přece máme jen pár kilobytů a těmi není radno plýtvat! A ty sálové počítače si taky člověk domu nekoupí.

...

Asi chápete :) I kdyby člověk s některými kontroverznějšími tvrzeními nesouhlasil, většina z nich je celkem trefných.

Using Clojure to Serve The Internet of Things

Příběh firmy Xively, jako ze žurnálu. Začli s Ruby on Rails, jakmile získali první zákazníky, šlo to do kolen. Přešli na JVM a Clojure, obrovský nárůst prostupnosti dat. Business téhle firmy je vůbec zajímavý. S rozmachem fenoménu "internetu věcí", bude po podobných konsolidačních platformách hlad a není se čemu divit. Součástí talku byla i ukázka barevného diodového "teploměru", který v reálném čase reagoval na frekvenci výskytu daných hashtagů v tweetech.

Newspaper Massacre

Jeden z nejpůsobivějších příběhů ze zákopů. Daily Mail jsou největší internetové noviny na světě. Původní verze jejich front-endu, který dodává naprosto nezbytné a informačně hodnotné bulvární články čtenářům? 

The mail online legacy code #euroclojure pic.twitter.com/fS21CpNj6x

— Jan Ehrhardt (@derjan)

October 15, 2013

Uspořádali soutěž o to, kdo bude schopen přijít s nejlepším způsobem, jak to celé  dát dokupy (prostě udělalo se pár proof of conceptů, místo aby si manažeři sedli do meetingovky a pak nadiktovali ostatním, jak se to napíše).

The new mail online code base #euroclojure pic.twitter.com/gIw1hQK0MU

— Jan Ehrhardt (@derjan)

October 15, 2013

Kompletní rewrity nefungují? Tak určitě.

(into reduce transient) - Michał Marczyk

Jeden z hlavních přispěvatelů do ClojureScriptu rozebíral teoretické i praktické základy datových struktur v Clojure. Jak je řešena persistentnost (záměrně nepíšu "persistence"; nemá nic společného s databází) a jak na to, chceme-li implementovat vlastní sadu datových struktur, které perfektně zapadnou do stávajících abstrakcí, které Clojure používá. Asi nejvíce computer science talk celé konference, jak radostně podotkla Bodil Stokke ;)

Megarefs - Christophe Grand

Christophe je (mimo jiné) autorem mého nejoblíbenějšího šablonovacího enginu pro Clojure - Enlive. Tato přednáška však byla o něčem zcela jiném. Clojure má softwarovou transakční paměť, díky které je možné měnit hodnoty transakčních referencí a mít garantováno, že se v daném bloku provede buď vše nebo nic (velmi stručně řečeno). V tomto talku byly představeny tzv. megarefs, které umožňují mít v refu jednu velkou datovou strukturu, která uvnitř sebe opět umožňuje za pomoci refů kontrolovat granularitu atomicity změn v celém tom "světě". Rozhodně zajímavá rozcvička a když to Christophe píše, asi pro to má i využití :)

Sada tří Lightning talků

Literate programming - programování s použitím přirozeného jazyka mě nikdy příliš nezajímalo, takže tenhle počin jsem bral vyloženě jako kuriozitu. Osobně si neumím představit, že bych to nějak využil v praxi. Ale takových věcí už bylo...

Lithium - Lisp ve stylu Clojure, který běží přímo na x86 HW. Velká škoda, že Daniel neukázal live demo, ale každopádně klobouk dolů, vyblbnout se musel asi solidně :)

Templatování v Clojure - rychlý přehled templatovacích enginů

Meta-eX: How to live code your own band - Sam Aaron

Další multimediální přednáška od jednoho z tvůrců enginu Overtone. Těžko popisovat slovy Samův enthusiasmus pro experimentování se zvukem a skládání hudby... A už vůbec nemá smysl popisovat, jak hraje kapela, jejímž hlavním hudebním nástrojem je live editování kódu v Emacsu. Bohužel, žádné rozumné video z EC není a tak tu nechám alespoň tohle.   

Poslední dva talky (Enterprise integration with Clojure a A Perfect Storm for Legacy Migration) byly v podstatě příběhy firem, které nasazovaly Clojure a relativně detailní popis toho, jak zapadá do jejich infrastruktury.

Toť vše z mé strany. Pokud jsem k něčemu nenapsal dost, další informace najdete na Lanyrdu.

  [fotku jsem ukradl Kamilu Tomanovi] Nedávno jsme se s @martinhynar vrátili z berlínské konference EuroClojure, kam jsme se podívali díky Vendavu. A tak se sluší a patří, abych si o tom malinko ublognul.

Jde o první větší evropskou konferenci zaměřenou výhradně na programovací jazyk Clojure a filosofii vývoje softwaru, která se kolem něj rodí. První ročník se konal minulý rok v Londýně, letos byl na řadě Berlín a jestli někdy dojde i na Prahu, to těžko odhadnout... :) Vyrazit do Berlína každopádně stálo za to, zvláště když je to z Ostravy pár hodin cesty autem. Akce se konala v areálu bývalého pivovaru, který byl v průběhu času proměněn v kulturní centrum. Není to sice tak impozantní stavba jako podobně využitý Stary Browar v polské Poznańi, ale i tak to je velmi stylový mix moderních technologií a syrové industriální architektury. Obité a hrubé zdi hal v kombinaci s moderním zázemím byly perfektním prostředím pro něco tak živelného a drzého, jako je Clojure. Člověk by měl skoro tendenci si myslet, že tahle platforma je ještě stále ve vývojářském undergroundu... Ovšem již dávno (z pohledu rychlosti vývoje světa IT) tomu tak není a právě i přednášky na téhle konferenci nás v tom utvrdily.

Co se týká organizace, tak ta byla perfektní. Šlo o relativně malou konferenci, takže pokud by člověk čekal, že u vstupu dostane tričko a tašku plnou propisek, bloků a reklamních materiálů, tak by byl zklamán. Naštěstí jsou tohle zcela irelevantní věci a tričko zdarma šlo získat i jinak :) Wifi z počátku haprovala (což bohužel pokazilo jeden kolaborativní talk), ale pak už běžela celkem spolehlivě - samozřejmě s rychlostí v rámci rozumných mezí (cca 200 lidí). Velmi pozitivní bylo jídlo a pití. Budova, kde se vše konalo, měla hned vedle přednáškového sálu plně vybavenou kavárnu s kuchyní (což se např. o polském GeeCONu konaném v kině říci nedá) a tak nebyl vůbec problém pro všechny zajistit stabilní přísun tekutin a dobrého jídla. Během přestávek mezi talky servíroval personál na baru nealko dle přání (typ i množství - káva vzhledem k podmínkám velmi dobrá) a nemálo breaků bylo také oslazeno zákusky, které samozřejmě zmizely velmi rychle. Obědy byly řešeny rautovým stylem a jídlo bylo pestré. V pondělí večer pak byla rezervace v jedné z obřích berlínských pivnic, kde pivo teklo proudem a klobásky se kutálely přímo do pusy (ne, to už v ceně nebylo), hlavně jsme se tam ovšem socializovali a to až tak, že druhý den měli někteří problém mluvit... Inu hromada geeků lačnících po hluboké filosofické konverzaci + vagóny kalících němců + tamní obdoba Evy a Vaška = bengál jak sviňa.

Dost bylo plků, pojďme k tomu, kvůli čemu vlastně vůbec tenhle článek píšu. Pokusím se teď popsat přednášky, které jsme slyšeli.

Keynote: States and Nomads: Handling Software Complexity - Zach Tellman

Zachova keynote byla jednoznačně nejfilosofičtější přednáškou celé konference, takže tenhle popis berte jen jako můj myšlenkový dump - prostě co mi utkvělo v mysli. Jo a není tam překlep. Nemá tam být "monads" :) V zásadě to bylo rozdílu mezi tím, jak k řešení komplexity přistupuje stát (resp. jaká je v tomto mentalita státu) a jak nomadická mysl - a jak to ilustruje chování nás vývojářů. Začal ji perfektní ilustrací principu leaky abstraction: použil dvě rasy z románu Time Machine od H. G. Wellse, Eloi a Morlocky. Eloi si žijí v luxusu na povrchu planety, ten je ovšem udržován při životě morlocky, otroky žijícími pod zemí. Ti každou noc vystupují na povrch a Eloi požírají. Naše leakující abstrakce fungují stejně - máme tendenci se nechat ukolébat tím, jak jsme problém krásně abstrahovali, ale v nestřežené chvíli se abstrakce proskočí skrz mříže a kousne... Realita je rhizoma, propojené kořeny s nuancemi, které nelze při přílišném zjednodušení postihnout. Stát se snaží toto změnit ve strom s jedním kořenem - musí vnucovat svou zjednodušující hierarchizující představu, aby mohl fungovat. Descriptive > Prescriptive. Zach použil několik dalších ilustrací, některé z nich z knihy Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed od farmáře a anarchistického politologa Jamese C. Scotta (viz. také některé texty libertariánského institutu CATO - Scott sám ovšem klasickým libertariánem není). Mezi jinými to byly absurdní pokusy v pruském lesním hospodářství v 50. letech 19. století (devastace půdy sterilizací, geometrizací a homogenizací lesů ve snaze zefektivnit těžbu) nebo budování zcela odosobnělého města Brasília v 60. letech minulého století. Keynote nekončila nějakou ultimátní radou, jak to všecho rozseknout a vyřešit. Bylo to spíše vykopnutí míče na hřiště, snaha nastartovat dlouhodobou diskusi, pokus dostat vývojáře od (možná přespříliš) exaktního techné taky trochu k nomádskému metis (wisdom, skill, craft). Co děláme, je prostě mnohem více fuzzy, než si občas jsme ochotní přiznat a sebevětší hromady computer science paperů nestačí.

Evolving Life In The Browser - Tom Hall

Toto byla ta přednáška, o které jsem již v úvodu zmínil, že jí pokazil haprující internet. Tommy ukazoval několik genetických algoritmů běžících v browseru na ClojureScriptu a po nás chtěl, abychom mu pomohli svými stroji algoritmy rozvíjet. Zajímavý byl např. malý Robbie, který se snaží najít nejlepší způsob, jak uklízet bordel, co se válí kolem. A nebo simulace umělého života s pomocí zipperů.

Build Your Own Lisp for Great Justice - Bodil Stokke

Svéráznou děvčicu Bodil nemusím clojurianům představovat. Na EC přijela ukázat dialekt Clojure / Lispu, na kterém pracuje - BODOL. Nabídla také pár narážek na uživatele jiných editorů než je Emacs a hromadu barevných ponnies ve vymakané Reveal.js prezentaci :) Zmínila ale i praktické věci, jako např. jak implementovala různé aspekty daného jazyka. To je pro lispaře důležité, jelikož implementace vlastního Lispu je smrtelná mozková nemoc, která potká každého lispaře a pokud ne, tak to nebyl lispař :)

Liberator – free your data with RFC 2616 - Philipp Meier

Autor knihovny zmíněné v nadpisu přednášky popisoval svojí cestu nebezpčnou džunglí zvanou HTTP. Dokud člověk nezačne kopat hlouběji, nedochází mu, jak obrovská a komplexní specifikace HTTP je. Liberator není jen o vystavení RESTových endpointů přes HTTP, je skutečně o pokrytí celé cesty tím rozhodovacím stromem, kterým je třeba podle RFC 2616 projít. Liberator umí onu cestu dokonce nakreslit jako SVG obrázek a to pak člověku dochází, kolik věcí většina dnešních knihoven abstrahuje pryč (za cenu nemožnosti do nich zasáhnout). <vtip>Pro mě to bylo opáčko, protože o Liberatoru mluvil na jednom z našich Lambda Meetupů Martin Hynar ;)</vtip>

Creative Machines - Joseph Wilk

Velmi zajímavá přednáška od skromného sympaťáka, upoutaného (snad dočasně?) na invalidní vozík. Joseph byl jedním z lidí, kteří reprezentovali na EuroClojure významné firmy používající Clojure ve velkém - a to přesto, že pokud se dobře pamatuji, vůbec během přednášky nezmínil, že pro tu firmu pracuje. Jde o (původem) berlínskou službu SoundCloud - jeden z nejdůležitějsích internetových hudebních hubů současnosti, který redefinuje způsob, jakým hudebníci a labely komunikují s fanoušky. Data science se tam dělá ve velkém, takže rozsáhlý deployment Clojure nepřekvapí. Není tedy ani  divem, že Josephova přednáška se týkala umění, vizuálního i hudebního. Zamýšlel se nad otázkou, zda stroje dokážou být kreativní... a jak vlastně vůbec pojem "kreativní" definovat. Můžou skládat hudbu? Malovat? Podle toho, co jsme viděli a slyšeli, tak rozhodně můžou - škarohlídi ovšem namítají, že to vždy bude pouze výsledek lidského naprogramování a tedy nelze o kreativitě mluvit. Těžko rozseknout takovou debatu během jednoho talku. A kde tam zapadá Clojure? Overtone - knihovna, která se během EC ještě předvedla (stay tuned) a kterou Joseph použil, aby učil počítač komponovat na motivy naučených útržků hudebních děl. Nakonec hezky ilustroval obrovské kognitivní zkreslení, které tuhle problematiku provází: jakýsi profesor se rozplýval nad hudebním dílem a když ho za rok slyšel znovu a bylo mu řečeno, že ho složil počítač, označil ho za brak...

(assert (= (+ quadrocopter motion-detector core.async) :awesomeness)) - Jarppe Lansio

Jarppe! Legračně nervózní a extrovertní Fin (jo, existujou), který se na stage parádně vyblbnul s quadrocopterem. Řídil ho pohyby ruky nad snímacím zařízením, které předávalo informace Clojure programu používajícímu knihovnu core.async a ten pak ovládal tu bestii. Škoda slov, tady je video.

Functional 3D Game Design - James Reeves

Jméno možná mnoho neřekne, přezdívka @weavejester už by mohla - ano, jde o člověka, díky kterému se dá Clojure pěkně používat na serveru: Ring, Compojure, Hiccup. Jak už ovšem název napovídá, tady o server nešlo - James se rozhodl na chvíli odložit kariéru nezávislého kontraktora a na plný úvazek se věnuje vývoji 3D hry v Clojure. James se soustředil hlavně na to, jak dosáhnout uspokojivého výkonu při zachování důležitého funkcionálního aspektu Clojure - neměnných datových struktur. Herní engine toho ještě mnoho neumí, což me trochu zklamalo - čekal jsem trochu více než rotující kostku na černém pozadí... Ale ani v nejmenším nepochybuju, že to James bude schopen dotáhnout k něčemu efektnímu.

Common Clojure Smells - Jen Smith 

První den zakončila Jen Smith z ThoughtWorks s přednáškou o code smells v Clojure. Ano, i tak übercool jazyk jako Clojure je má, i když se od objektových smellů často dost liší, nebo jsou s nimi přímo v rozporu. Např. Primitive Obsession je jedním z hlavních pilířů Clojure, jakožto data-oriented jazyku. S jednou věcí jsem ovšem nesouhlasil (a už jsem to před časem zmínil i někde na Twitteru): Jen popisovala přílišné zanoření do lispových struktur jako smell. To je samozřejmě OK, nikdo nechce ve svém kódu vidět na konci funkce )))))))))). Jejím řešením ovšem bylo použití threading maker -> a ->> a to je to, co mě nesedí. Threading makro nemá nic společného s vlákny v JVM, ale umožňuje vám obrátit pořadí zápisu lispových funkcí, viz. např. http://clojuredocs.org/clojure_core/clojure.core/-%3E Je to perfektní nástroj pro případy, kdy potřebujete využít z Clojure nějakou javovskou knihovnu a potřebujete volat Java metody postfixovým zápisem. Řešit s ním ale přílišné zanoření mi v mnoha případech přijde jen jako léčení symptomů. Podle mého by první pokus o řešení měla být dekompozice do malých funkcí a přidržení se standardní lispové syntaxe. Samozřejmě netvrdím, že mám patent na pravdu - např. v případě "obalování" middlewarů v Compojure to smysl dává. Jinak ale určitě fajn přednáška - slidy zde.

No a to byl konec prvního dne. V dohledné době očekávejte druhý díl s povídáním o přednáškách z druhého dne.

So I am a raspberrian, too. It's a fascinating toy and I have a few fun projects (and one serious) in my head that I'd like to do with it - starting with obligatory LED experiments, of course! :) Using RPi isn't the only thing that will differentiate this endeavour from my previous hacker projects, though. I've also decided that I want this project to be 100% JVM-free (yes, that means my-beloved-Clojure-free).

I like JVM. It's a fast and ubiquitous platform with myriads of possibilities for whatever project you come up with. But that doesn't mean I need to use it all the time, right? Moreover Java isn't very performant on RPi, for obvious reasons...

What am I going to use then? Well, the title of this post says it all - almost. Apart from Racket I'm planning to use Riak as a database for some of the projects (see https://github.com/dkvasnicka/racket-riak). But even though I've already decided on technologies I wanted to do some performance tests, just out of curiosity.

So I took Racket, Clozure Common Lisp and Clojure and created a primitive program that computes dot product for two lists containing numbers from 0 - 999.999.

https://gist.github.com/dkvasnicka/5939035

As you can see I've forced the evaluation of the Clojure sequence, just to make things a bit more fair. Racket's range function isn't lazy (and the #lazy dialect does not contain it's counterpart, AFAIK) and neither is Common Lisp's for. I know there are other "variables" in this equation. I didn't consider the types of numbers used (bignums?), I don't care about the exact types of collections used... yeah, a bit too simple, you might say. But I believe it's enough for doing just a rough comparison - just to get a glimpse.

My Raspberry Pi is running the latest version of the official Raspbian distribution (which is 2013-05-25 at the time of writing this post). I've also  removed all the X.Org & desktop packages, icons and all that stuff because I'm not going to use GUI on my RPi. And here are the results of my "wannabe benchmark":

Clozure CL 1.9 - 6 secs

Clojure 1.5.1 running on JDK 8 for ARM Early Access (hard-float support) - 21 secs

Racket 5.3.4 - 30 secs

Huh. Something's not right. 30 seconds? A bit too much, I'd say... At this point I was kind of disappointed. I knew CCL (like SBCL) is a wicked fast Common Lisp implementation and I wasn't expecting Racket to outperform it. But getting beaten up by Clojure that much?

So I went to the almighty #racket IRC channel and after a quick discussion I've found out that JIT support for ARM has been included only recently and that it probably isn't in any of the official builds. So I cloned the Racket Git repo and - to be sure I have the latest and greatest - built the master HEAD (it takes ages but that's how we roll on Raspberry).

And guess what! It ran the same program in 12 seconds. Now we're talking! So if you're planning to use Racket on Raspberry Pi be sure to grab the source right from the GitHub oven. You have to build it from sources anyway, so just don't take any of the already-released versions - for now.

And why not Common Lisp, you might ask? I kind of like Scheme and Racket more (not just because of the Lisp-1 vs Lisp-2 dichotomy)... I wrote about it a bit more here (in Czech language). I'd like to do some CL project in the future but now it's just not the right time for me :)

Clojure je parádní jazyk. Znovuzrozený lisp 21. století s obřím ekosystémem Javy na dosah ruky, disciplinovanou a zapálenou komunitou a vizionářem u kormidla.

Bylo by ale nefér upírat veškerou lispovou pozornost k Clojure, i mimo JVM se děje mnoho zajímavého. Common Lisp i Scheme, dva výrazné proudy ve světě závorek, mají oba své aktivní a použitelné zástupce, kolem kterých jsou funkční komunity i ekosystémy knihoven.

Navíc JVM se nehodí úplně všude. Je to platforma relativně rychlá a vyladěná, ale jisté HW limitace má a mít bude. Běžné počítače s ní problém mít nebudou, ale je tu čím dál více se rozmáhající kategorie geeko-hackerských hraček, kterým aktuálně vévodí Raspberry Pi. 512 MB RAM a jednojádrový CPU s výkonem Pentia II není HW pro smysluplné provozování JVM, jakkoliv na tom Java běžet může.

Tyto všechny důvody mě na mých toulkách přivedly mj. i k jazyku Racket - dynamickému a silně typovému lispu z rodiny Scheme. Původně se projekt jmenoval PLT Scheme, ale autoři se pod vlajkou pokroku rozhodli částečně zlomit kompatibilitu se specifikací Scheme a tak pro jistotu zvolili úplně jiné jméno. Jde tedy o lispový jazyk, ovšem s jeho instalací získáváte o mnoho více než jen runtime. Jde o platformu sestávající se z jazyka, relativně pokročilého IDE (DrRacket), balíčkovacího systému pro moduly a základní knihovny obsahující podporu pro tvorbu GUI, vestavěný HTTP server (takže webové frameworky mají na čem stavět), síťařinu (TCP server, UDP), paralelní a distribuované zpracování dat, pattern matching (věc, u které nechápu, proč jí cesta do standardní knihovny Clojure trvá tak dlouho), kontrakty (validační predikáty pro funkce či dat. struktury, zhruba něco jako :pre a :post v Clojure, akorát mnohem mocnější), OOP, psaní testů a samozřejmě makra. Ona makra dělají z Racketu opravdu skutečnou platformu. Lze díky nim totiž tvořit nejen DSL v rámci vašeho programu - jako v každém Lispu, ale celé nové jazyky instalované přímo do runtime Racketu. K výběru dialektu se používá direktiva #lang na začátku souboru, která je se Scheme nekompatibilní. Program, který následuje, pak může být např. psaný ve staticky typovaném Racketu, v (tak trochu) Clojure nebo v nedávno vydaném síťově orientovaném jazyku / frameworku Marketplace.

Co se týká výkonu, porovnání s Clojure je docela výmluvné. Není to samozřejmě výhra na celé čáře, ale ve všech oblastech je na tom Racket (na jednom x86 jádře) v zásadě lépe. Samozřejmě je nutné dodat, že existují lži, velké lži, statistika a pak benchmarky. Ale vypovídací hodnotu to má dostatečnou na to, abych se Racket na Raspberry Pi pokusil nasadit (druhý důvod samozřejmě je, že jsem hračička).

A co Common Lisp!?

Možná si říkáte, proč Racket nebo Scheme, když Clojure je přece Lisp a typickým zástupcem lispové rodiny je přece CL...?

Neznám do detailu všechy rozdíly mezi Clojure, Common Lispem a Scheme, ale přijde mi, že z globálního pohledu má Clojure blíže ke Scheme. Pokusím se rozebrat hlavní znaky a přidat i pár dalších důvodů, proč je Racket dobrým kamarádem do deště.

Scheme, Racket a Clojure jsou Lisp-1, Common Lisp je Lisp-2 - Jazyky z kategorie Lisp-1 mají v paměti jeden společný namespace pro funkce a ostatní hodnoty, CL (Lisp-2) má pro funkce a hodnoty namespacy jiné. Pokud máte dojem, že je to akademické nimrání se v detailech, mýlíte se. Má to docela zásadní vliv na používání anonymních funkcí. Vysvětlíme si to např. na curryingu (neplést s partial application, ať nemáte trapas jako autoři jazyka Groovy...). Co je tedy za problém? Mějme curryovanou funkci + v Clojure

https://gist.github.com/dkvasnicka/5691514

a v Racketu

https://gist.github.com/dkvasnicka/5691519

A tady Common Lisp

https://gist.github.com/dkvasnicka/5692932

Vidíte rozdíl? Ano, tušíte správně, program v Lispu-2 se může jednoduše zvrhnout ve "funcall hell". Jako první člen S-výrazu je totiž očekávána funkce. My jsme si ale z curryované funkce vrátili anonymní funkci, kterou jazyk považuje prostě za hodnotu. Proto ji nelze najít v namespacu funkcí a runtime nás pošle tam, kde slunce nesvítí... V Lispu-1 toto nebezpečí nehrozí. Protiargumentem často bývá, že nemusíte mít strach z překrytí vestavěných funkcí proměnnými. Pro mě tenhle argument na vahách neobstojí.

Neměnné datové struktury - Common Lisp je v tomto velmi liberální jazyk - datové struktury jsou standardně mutable a je na programátorovi, aby psal funkcionálně. Clojure, jak známo, je naopak velmi striktní. Racket je v tomto blíže Clojure - listy jsou immutable, vektory a hashmapy jsou mutable, ovšem součástí standardní knihovny jsou i immutable varianty. Standardně neměnné jsou i strukturální datové typy.

Racket umí být lazy - http://docs.racket-lang.org/lazy/ - opět věc, která je v Clojure standardem, v Common Lispu nikoliv.

Tail-call optimalizace - specifikace Scheme předepisuje, že implementace musí mít optimalizaci pro tail-call rekurzi - funkcionální side-effects-free alternativu imperativnímu for cyklu. Mnoho implementací CL má TCO také, ale je to zcela na benevolenci implementátora. Clojure jí má tak napůl... skutečnou mít nemůže, protože JVM a tak má dvojku loop & recur, kterou je třeba při TC rekurzi explicitně použít a která zaručuje, že vám javovský stack alespoň nepřeroste přes hlavu.

Další lákadla Racketu:

Znáte Grape z Groovy? Umožní vám napsat jednosouborový skript, který závisí na maveních modulech. Grape moduly postahuje a přidá na classpath. Knihovny pro Racket jsou (většinou) v repozitáři zvaném PLaneT, ze kterého se dají buď nainstalovat a nebo je lze použít podobně jako v Groovy, přímo při importu v daném programu. Zde je např. jednoduché REST API postavené na frameworku Spin:

https://gist.github.com/dkvasnicka/5653494

Na druhém řádku je, myslím, hezky pochopitelná ukázka zmíněného zápisu. Díky tomu lze těchto pár řádek prostě spustit a webový server běží. (Nutno dodat, že Quicklisp ze světa Common Lispu funguje velmi podobně)

Racket nemá null / nil ve smyslu absence hodnoty, takže na NullPointerException zapomeňte. null znamená prázdný list (jo, ten název je hrozně debilní).

Zajímavé je, že [], {} a () jsou v Racketu zaměnitelné, pokud samozřejmě dodržíte symetričnost a použijete je v páru. Je tak na vás, kde a jak tyto druhy závorek použijete a jak si jimi zpřehledníte kód.

Fajn, ale kdo tuhle obskurnost vůbec používá? Kromě autora Racketu a lidí kolem něj, kteří tuhle platformu komerčně nasazují, se po krátkém googlení objeví minimálně dvě impozantní nasazení v produkci: Boeing a letectvo Spojených států řídí s Racketem velká pole teleskopů a filmový gigant Universal Studios ho používá na big data analytiku, simulace a strojové učení. Myslím, že zajímavých použití bude určitě více a jak bude Racket získávat na síle, dozvíme se o nich.

Clojure je moc fajn, ale není to jediný Lisp na světě a určitě není jediný, kterému stojí za to věnovat čas... A tak si kromě osvěžování Common Lispu trošku hraju i se Scheme a Racketem (o tom, jaký je rozdíl mezi CL a dialekty Scheme a jestli Racket je nebo není Scheme až někdy příště... a nebo si to vygooglete ;).

Kromě IDE typu IntelliJ IDEA & La Clojure nebo LightTable je pro mě programátorským švýcarákem veleznámý editor Vim. Pro něj existuje moc pěkný plugin zvaný SLIMV, který je obdobou Slime z Emacsu. Jde o plugin, který dodává do Vimu komplexní podporu editace lispů a hlavně možnost programy jednoduše spouštět v REPLu. Důležité je, že podpora je opravdu široká, napříč lispovými dialekty. Clojure (ritz je dobrý SWANK server), Common Lisp (na Macu doporučuju Clozure CL, dříve známý jako MacLisp, nebo SBCL), Scheme, Racket...

V tomto zápisku bych rád sepsal návod, jak takové podpory dosáhnout pro jazyk Chicken (jeden z aktivněji vyvíjených a reálně použitelných dialektů Scheme). Výsledkem by mělo být to, co vidíte na následujícím obrázku (proslýchá se, že to bude umět pustit i komplexnější programy než sečtení třech čísel ;).

V instalaci (Mac)Vimu a SLIMV není žádná potíž, takže budu předpokládat, že to už má ctěný čtenář za sebou. Dále je třeba zchrastit SWANK server pro Chicken. Ten sice existuje, ale veškerý popis k jeho zprovoznění automaticky předpokládá, že vám jde o Emacs. A tak bylo třeba z toho vydestilovat, jak to rozběhat ve Vimu.

Nainstalujte si Chicken. Na Macu doporučuji (a to zdaleka ne jen pro tento případ) balíčkovací systém Homebrew. Pro ty z vás, které MacPorty dohání k šílenství (třeba tím bordelem na disku), to bude vysvobození

brew install chicken

Naklonujte si z GitHubu tento projekt: https://github.com/nickg/swank-chicken

Proveďte první dva kroky v Quickstartu

Pokud byste se nyní pokusili pustit Chicken a loadnout swank-chicken, skončíte na absenci repozitáře dokumentací pro balík chicken-doc, který jste instalovali v rámci Quickstartu. Je proto třeba doinstalovat admin balík

chicken-install chicken-doc-admin

a repozitář inicializovat

/usr/local/Cellar/chicken/4.8.0.1/bin/chicken-doc-admin -i

Nyní z naklonovaného adresáře spusťte

csi swank-chicken.scm

a až vše naběhne a ukáže se příkazová řádka (#;1>), pusťte samotný SWANK server (bacha, nevypíše to naprosto nic)

(swank-server-start)

Ve Vimu otevřete nějaký Scheme zdroják a spusťte ho zkratkou ,b (nesmíte být v INSERT módu, samozřejmě). SLIMV by měl poznat, že již SWANK server běží, neměl by se pokoušet spustit svůj a měl by vám rovnou rozdělit okno na dva buffery - jeden s REPLem a druhý s vaším souborem.

Pevně věřím, že uživatelé jiných unixů si budou umět návod upravit k obrazu svému.

Vždy, když se seběhne nějaká nemilá událost týkající se střelných zbraní, svět hromadně ztratí schopnost racionálně uvažovat a rozhodne se řešit situaci emocionálně. Nejinak tomu bylo i v případě střelby v americkém Newtonu. Tohle médii podporované globální zblbnutí mě vždycky namíchne - snad proto, že v něm nejde jen o zbraně, ale o celkem základní lidské hodnoty a podstatu fungování společnosti vůbec.

K stvoření tohoto malého soupisu mi tedy daly impuls jednak neproduktivní přestřelky na Twitteru a také potřeba si sám pro sebe důležité informace nějak poskládat a zařadit.

Nenechte se zmást - obhájci zákazů často používají data, ale umí je vyzobat tak, aby to na první pohled implikovalo nutnost zakázat i vzduchovky... Jde to až tak daleko, že někteří lidé jsou schopni na jednu osu grafu vynést počet legálně držených střelných zbraní v USA a na druhou počet smrtí způsobených střelbou - z legální zbraně, z nelegální, sebevraždy, sebeobrana(!!!), prostě všecho - a vydávat to zcela vážně za argument. Snad ještě vyšším levelem nechutnosti je cílená démonizace držitelů legálních střelných zbraní, navzdory všem faktům (viz. níže) - http://zpravy.ihned.cz/svet-usa/c1-59024150-kdo-ve-vasem-okoli-muze-mit-zbran.... Jistě, ta data jsou de fakto veřejná, ale všichni víme, že o to tu nejde... Jde tu o "bububu, soused má asi zbraň - je nebezpečný!"  Racionalito, logiko a fakta - z cesty! V páchání dobra nám bránit nebudete! 

Seznam začnu paradoxně článkem, ve kterém o zbraních není ani slovo: The Search for the "Good Society" od Franka Chodorova (výňatek z jeho eseje The Rise and Fall of Society) - nekonzistentní a utopické uvažování kritizované v tomto článku je totiž kořenem problému u mnoha proponentů omezování či zákazů střelných zbraní. Odpůrci zbraní se neustále snaží stavět své argumenty na tom, jak by chtěli, aby společnost vypadala a ne na tom, jak ve skutečnosti vypadá. Není divu, že to pak do sebe nezapadá...

Dále uvedu sérii článků (u D-FENSe jak jinak než) lehce provokativně nazvanou Filosofie ozbrojené společnosti. V druhém dílu zaznívá mj. následující informace:

Co do palných zbraní — v USA mají civilisté zhruba 250 milionů zbraní. Každý rok se takovou zbraní ubrání 2.500.000 obyčejných lidí jako vy nebo já, kteří tak zastaví zločince. A zneužito k vraždění je ročně 9146 zbraní*. Tedy, ještě jednou: 250 milionů zbraní — 2,5 milionu zachráněných životů — 0,009 milionů zmařených životů.

(Viz. také studie Tough Targets: When Criminals Face Armed Resistance from Citizens - pro mě osobně jsou jen tato čísla celkem jasným argumentem). Díl třetí pak za pomoci historických událostí (některých opravdu odporných) a judikátů vysvětluje něco, co možná pro vás bude šokujícím odhalením: Policie tu není (a prakticky ani nemůže být) od toho, aby vás ochránila před agresorem. Policie jedná, až když se zlo uděje. Čtvrtý díl hezky rozebírá nejčastější předsudky vůči ozbrojené společnosti - nesmysly o Divokém západě jakožto jedné velké přestřelce, cílenou manipulaci ze strany médií apod. Rozebírán je také profil legálních držitelů střelných zbraní, což je "hezky" v kontrastu s již zmiňovaným článkem na iHNedu. Pátý díl pak rozebírá, jaké jsou reálné důvody politiků pro prosazování zákazů střelných zbraní. Jedna věc jsou poblouznění majitelé růžových brýli, kteří si myslí, že skutečně zákazy něco zlepší. Jiná liga je ovšem mocenská hra, která se za zbraňovou legislativou skrývá. Škoda, že finální citát Sarah Brady je fake (prakticky nedoložitelné, že to kdy řekla - i když tak ve skutečnosti nejspíše přemýšlí) - hezky ilustruje, o co ve skutečnosti jde. Nejčastější protiargument je samozřejmě posměšné odmítnutí těchto tezí jakožto konspiračních teorií... Je to vzhledem k historii lidstva ubohé, ale poslužte si!

Článek Liberálního institutu Zbraně zmiňuje jednak již zmíněné, pak také nakusuje statistiku z Britálnie (kde stejně jako v Austrálii vyletěl zločin po zákazu zbraní nahoru), ale hlavně popisuje událost, u jejíhož čtení pevně doufám, že budou proponenti takzvaných gun-free zones mít plný žaludek, aby to mělo efekt, až se jim zvedne kufr:

Mimochodem, až do pondělí patřilo smutné prvenství v počtu obětí (23) šíleného střelce incidentu z roku 1991 v Texaském Killeenu. V místní restauraci tehdy seděla i pozdější texaská zákonodárkyně Suzanna Hupp - a sledovala, jak šílenec popravuje její rodiče. Svoji zbraň nechala v autě, protože jí tak přikazoval nový zákon.

Když už jsme u toho nesmyslu s bezzbraňovými zónami, faktem je, že většina masakrů v USA se stala právě v nich (proč, to je snad jasné). Tady si můžete přečíst jejich seznam a pokud vám ani na jeho konci nedojde, že nic jako "zóna bez zbraní" neexistuje, nikdy neexistovalo a nikdy ani existovat nebude, pak už vám nepomůže ani svěcená voda...

Velmi pikantní je článek Two Aurora Shootings: One Widely Known; the Other Ignored. Že jste slyšeli o střílení v kině ve městě Aurora? Asi jste ale neslyšeli o střílení v kostele - v tom samém městě, pár měsíců před tím. Výsledek? Vrah sejmul jednoho člověka a poté byl jedním z účastníků bohoslužby odpraven. Vrah sotva vylezl z vězení, takže jeho zbraň těžko mohla být legální. Média samořejmě tuto událost víceméně ignorovala - přecejen to není moc cool, že... žádné hromady mrtvých, málo krve, těžko se na tom staví obhajoba zákazu zbraní. Popojedem.

Navázat můžeme článkem Auditing Shooting Rampage Statistics. Autor nashromáždil data z jednotlivých střílecích masakrů a vypadlo mu toto: při masakrech, které zarazila až policie (a nebo si to útočník pořešil sám), zemřelo průměrně 14.29 lidí. Při masakrech zastavených majiteli střelných zbraní to bylo 2.33.

Výživné jsou i informace o Washingtonu a Floridě v článku O tom, prečo je vražda zlá, ale zbraň dobrá.

Zmínit je třeba i jeden z hlavních důvodů, které vedly k poslední tragédii v Newtonu - totiž zoufalý stav psychiatrické péče o děti (i dospělé - a nejen v USA). Stručně řečeno - pacienti jsou nacpáváni jedy, aby byl klid a personál si mohl v klidu vypít kafíčko. Občas se ale věci zvrtnou - jako třeba v případě právě A. Lanzy léčeného šílenou substancí, která již jednou byla zakázána, ale pak se na trhu objevila znovu, pod hlavičkou jiné firmy (asi větší úplatek farmaceutickým kontrolorům). Agresivita byla dobře známým nežádoucím efektem téhle zrůdnosti. Článek byl původně na adrese http://www.healthfreedomusa.org/?p=13703, ale web byl hacknut (nejspíše kvůli obsahu, ale taky dost možná kvůli grafickému zpracování). Přikládám PDF vytištěné z Pocketu. Farmaceutická oligarchie asi paní autorku nebude mít příliš ráda... Kdo by měl chuť toto dávat za vinu údajně volnotržnímu zdravotnictví v USA, nechť si nastuduje jeho stručnou historii: Sto let zdravotnického fašismu ve Spojených státech (odvážný titulek, ale článek je velmi slušně a odborně zpracován, jak je na Mises.cz zvykem)

Nakonec přikládám odkaz na masivní kolekci faktů a citovaných zdrojů dostupnou v PDF na http://www.gunfacts.info/ (zdaleka ne jen z USA).