December 16, 2010

Лисп как клей

Перебежчик с Common Lispа на Clojure zahardzhan (Роман Захаров) публиковал отчёт о своей первой коммерческой программе в Clojure. Его тезис: "реальные программы — это комья грязи; липкая гадость которая склеивает энное количество технологий, семантик и языков."

Понятие "glue language" - "язык-клей" началось с Tcl и Perl тк они обычно использовались для обработки и послания данных между разными, уже существующими системами ("cклеивая" их вместе). В принципе Лисп полностью годен как клей, но мешало плохая интеграция с операционной системой, неполноценные FFI, и отсутствие библиотек для парсинга разных форматов и интерфейсинга с базами данных и сетевых сервисов. Сейчас первые две проблемы во многих своих образах устранены, и количество библиотек для интерфейсинга все растет. Главные задачи что бы сделать Common Lisp годным как клей, это разработка новых библиотек для интерфэйсинга, и обновление и пиар существующих.

December 15, 2010

Understanding Web in the context of the medium/message dichotomy

Web is not a medium. Web is a space of possible combinations of medium, message, and method. The medium and the message are familiar, but what exactly is a method? Methods are algorithms and effects. Previous media had no algorithmic component, no way to conditionalize or effect outcome (choose-your-own-adventure books came closest).

Web IS NOT interactive. It is a two-way audience: every viewer is a publisher. But the websites themselves aren't publishers, they're the medium. Every website is a new medium.

December 11, 2010

Programming language evolution

Programming language evolution is sometimes claimed to be a search for greater abstraction.

This is wrong, and mirrors the misunderstanding of biological evolution. There is no end-goal, no such thing as progress or improvement. It's about adaptation.

There are different kinds of models and different kinds of environmental factors, such as machine constraints, and how ignorant of mathematics and past programming languages the designers of a programming language are.

A good example of this is MapReduce. The programming paradigm goes back to APL. Limited support for parallelism was added in the form of vector co-processors on IBM mainframes. The first "massively" parallel implementation of the idea was StarLisp.

Another example is Objective C. Brad Cox claims that the only reason he developed Objective C was because at the time Xerox wouldn't sell Smalltalk (Masterminds of Programming, p. 258).

In terms of parameters like dynamism and introspection, Lisp already had all the necessary features in 1958. From there the same basic idea of lambda abstraction has been applied to Actors and prototype-based languages like Self and JavaScript, but in terms of other "dynamic" programming languages, almost all of them are a step backward from 1958 Lisp.

The same thing can be said about C and Algol 68.

December 1, 2010

Gaming academia, or why style is more important than substance

I started with failure. I submitted a couple of papers to conferences and then waited on pins and needles for months, only to be rejected. It was disappointing and motivating at the same time. I realized there was something fundamentally wrong in my writing strategy. At the same time, some of my counterparts at Microsoft were publishing prolifically, and I asked myself, "What is it about their papers that gets them accepted so regularly?" I printed several of their papers looking for a pattern, and I found it. Every one of their papers used the same template and certain stylistic elements. I started using a similar formula and found my papers getting accepted almost immediately. My team submitted papers to some important venues - SIGMOD, VLDB, ICDE, and others - and had 90% of everything we submitted accepted, even in venues in which the acceptance rates were 1 in 6 or 1 in 9. Between 2001 and 2007, my team published more than 35 papers. We became incredibly efficient at it, authoring professional papers in just a few days, almost always using ideas and experimental results we had on hand from our regular line item development work.

--Sam Lightstone, Making it Big in Software