К сожалению, частые разговоры о DSL в Лисп-кругах мало подкрепляется реальными делами. Да, DSL написать можно, но в реальности пишут нечто маловразумительное на уровне все тех же многочисленных скобок. Собственно, с языком Форт подобная ситуация. Декларируется метапрограммирование и создание DSL, но реальных практических примеров подобного очень немного. На мой взгляд, тому в Лиспе есть две причины: 1) слабая существующая поддержка построения внутренних DSL, 2) необходимость для обычного разработчика быть по совместительству еще и неплохим архитектором языков.
Конечно же Лисп имеет смысл применять там, где не хватает готовых решений из традиционных ЯП. Но лично меня удивляет такое внимание именно к неуклюжему Common Lisp. Почему не более изящный Scheme? Добавьте его интерпретатор к тому инструментальному средству, которое востребовано в вашем рабочем проекте (на C/C++, C#, Java или ином «скучном» языке), и у вас будет вполне достойное компромиссное решение.
1. Статья Instruction Selection by Graph Transformation на тему реализации этапа выбора инструкций с помощью системы переписывания (произвольных) графов. Вещь перспективная в том смысле, что даже в LLVM выбор инструкций осуществляется только на уровне DAG.
2. Алгебра программ в DSL-системах SPIRAL и Faust для DSP-программирования.
Спасибо, я эту статью читал. В ней описан консервативный подход к анализу зависимостей для поддержки гнезд нерегулярных циклов, кроме того, вопросы производительности трансформаций остаются открытыми. Поэтому представленный по ссылке подход все равно может быть полезно дополнить динамическим анализом, аннотациями и эвристиками.
Существуют работы по совмещению полиэдрального подхода с классическим динамическим анализом зависимостей inspector/executor. Также представляет интерес, на мой взгляд, техника взаимодействующих полиэдральных процессов — polyhedral process network.
А вот об использовании данного подхода в golang я ничего не слышал. Не поделитесь ссылкой?
Мне представляется, что Вы решаете слишком амбициозную задачу для LLVM. Во многих существующих инструментах от пользователя требуется добавить #pragma или иную аннотацию для соответствующего гнезда циклов. Способы обойтись без таких ручных указаний известны: динамический анализ (JIT, о котором Вы сказали выше) или DSL (ограничивающие программиста конструкции, в том числе сложные системы типов). В случае LLVM и собственного языка/DSL целесообразно, на мой взгляд, сделать собственный backend для LLVM-машины, который будет генерировать IR, прошедший ряд высокоуровневых преобразований.
Что касается, R-Stream, то я сужу о нем по доступным публикациям и патентам. Это, безусловно, полноценный распараллеливающий компилятор, который поддерживает гетерогенные массово-параллельные архитектуры. Просто последняя публикация на их сайте посвящена именно TensorFlow :)
Не стоит идеализировать LLVM, есть ряд полиэдральных оптимизаций которые просто неприменимы из-за недостатков дизайна промежуточных проходов SSA.
А нужно ли вообще иметь дело с Array/Memory SSA там, где мы можем использовать промежуточное представление на основе модели многогранников? Я не очень уловил, как работе на уровне этого промежуточного представления мешают какие-то «недостатки дизайна промежуточных проходов SSA». Ведь в таких коммерческих компиляторах, как R-Stream, а также в расширениях Polly (LLVM) и Graphite (GCC) осуществляется переход из SSA на другой уровень представления для совершения преобразований по векторизации/распараллеливанию/проч., а потом возвращается результат в SSA (или другом виде).
Согласен. Но ведь достойные современные учебники существуют. В этом смысле печально, что до сих пор нет русских переводов Appel (версия для ML, на мой взгляд, до сих пор является одним из лучших примеров такого учебника) и популярного курса от Cooper & Torczon. Я уже не говорю о более узкоспециальной литературе.
Уже в 50-е годы использовались методы экономии регистров, удаления общих подвыражений и базовые варианты анализа потока данных. Первая книга дракона вышла еще в 77 году. Среди впечатляющих проектов по созданию оптимизирующих компиляторов и средств разработки 70-х — компилятор BLISS и инструментарий построения компиляторов PQCC. PQCC, как и система BETA коллектива Ершова, в полном объеме так и не был завершен.
В этой книге работа над компилятором толком не доходит до стадии, когда уже можно использовать что-то в духе LLVM. Для тех времен типичен акцент на лексическом и синтаксическом анализе. Это наиболее проработанная тема, ей с удовольствием занимались исследователи-теоретики. В современном же учебнике практической направленности по компиляторам теме разбора исходного текста должно быть уделено от силы 20-30% содержания. В настоящее время серьезные объемные монографии написаны по таким частным вопросам, как упорядочивание инструкций или выбор инструкций.
Какие же есть альтернативы GCC/LLVM среди компиляторов и соотв. фреймворков общего назначения?
1. CompCert. compcert.inria.fr
Компилятор (подмножества) C99, реализованный на Ocaml, с формально доказанной реализацией. Использует практически все методы улучшения кода из классических учебников.
2. Firm. pp.ipd.kit.edu/firm
Компактная альтернатива LLVM, реализованная на чистом Си. Имеет множество готовых к использованию фаз трансформации кода.
P.S. Скорее всего, разработчики RISC-V приняли правильное решение. Но сама ситуация, когда создатели процессорных архитектур ограничивают себя в выразительных средствах ради совместимости с существующими GCC/LLVM-инструментами допустима не во всех случаях, согласитесь.
Послушайте, я вовсе не против LLVM. И могу сам предложить ссылки на работы по адаптации LLVM для стековой и VLIW-архитектуры. Я с уважением отношусь к Вашему опыту работы с этой системой. Моя основная мысль в том, что LLVM (как и GCC, и большинство других компиляторов) не подходят для разработки compiler-in-loop. Мне показалось, что взглянуть за пределы мира GCC/LLVM будет интересно читателю :)
Требования заказчика, как мне кажется, понятны из статьи. См. цитату:
«They had an existing compiler, but it was very old and porting it to the new generation DSP was not feasible. Embecosm were tasked with providing a LLVM based tool chain capable of compiling their C codecs and delivering high quality code.»
И будьте внимательнее, Synopys ARC не имеет отношения к ASIP Designer.
Бессмысленно меня убеждать в массовой распространенности LLVM. Гораздо интереснее, на мой взгляд, посмотреть на эту систему критически и оценить риски ее использования.
Если мы разрабатываем еще один 32-битный RISC-процессор, то использование LLVM вполне оправдано. Именно на такого вида архитектуры ориентирована эта система. У любого универсального промежуточного представления есть свои границы применимости. Специалисты это знают еще со времен UNCOL.
Задача усложняется, если мы имеем дело с нетрадиционной процессорной архитектурой: стековой, VLIW, CGRA и т.д. Здесь уже необходимо вводить собственные внутренние представления и трансформации. Если Вы не специалист по коду LLVM и не участвуете регулярно в соотв. списках рассылки, но ориентируетесь в методах компиляции, то вопрос уже не стоит так однозначно.
С точки зрения разработчика это вечная дилемма: использовать сторонний фреймворк, который потребует основательной переработки или же создать свое специализированное решение. Нужно учитывать, что сложность изучения самих алгоритмов компиляции значительно ниже, чем сложность реализаций из гигантских систем в духе LLVM. Вам придется читать источники по разработке компиляторов, вместо изучения деталей фреймворка. Но ключевой здесь момент: все это возможно при наличии соответствующего инструментария разработки компиляторов. Если же Вы просто вооружились «книгой Дракона» и решили написать на C/C++ компилятор, то, скорее всего, находитесь на неверном пути.
P.S. И, да, у меня есть свой опыт быстрого прототипирования компиляторов для специализированных процессоров.
К сожалению, практика совместной разработки процессорной архитектуры и компилятора для нее все еще мало распространена. Что странно, ведь данный подход успешно использовался еще Джоном Коком (John Cocke) в разработке первой в мире RISC-архитектуры. Этот подход иногда называют compiler-in-loop и он подразумевает, что прототипы компилятора для оценки вводимых архитектурных решений можно будет создать за считанные недели.
В статье речь идет о портировании LLVM для уже готового специализированного процессора. Конечно же, 120 дней — неприемлемый срок для подхода compiler-in-loop. Понятно, что LLVM был выбран по требованиям заказчика, но можно задаться вопросом: не была бы разработка своего backend для специализированного 16-битного процессора более эффективным (по времени, качеству кода) решением, чем адаптация LLVM?
Разработка компилятора это, разумеется, очень нелегкое занятие. Как и в случае многих других OSS-проектов, в основе «народных» компиляторов лежат идеи и код, разработанный в академической сфере. В частности, без работ Davidson и Fraser не было бы GCC. Но далеко не все «академические» компиляторы попадают в OSS. В таких, например, системах, как Synopys ASIP Designer и Reservoir Labs R-Stream, используются более изощренные методы компиляции, чем в LLVM и GCC. В целом, активность по разработке инструментального ПО за пределами этих двух «народных» компиляторов, безусловно, есть.
Фраза «Никому точно не известно, когда впервые возникли идеи их проектов, каков был путь к созданию реально работающих устройств, и к тому же разница в несколько лет в исторической перспективе ничтожна», пожалуй, более уместна в данном случае.
Да, я надеюсь написать об этом для Хабра в той или иной форме. Спасибо за Вашу заметку!
Особенно интересно анализировать опыт управления сложными проектами с участием «компараторов» и проч. При решении задач, требующих использования большого количества людей-вычислителей, на первый план выходят проблемы управления потоками информации, а также обеспечение корректности результатов. Для современных высокопроизводительных вычислительных систем тут имеются прямые аналогии с работой коммуникационных сетей и обеспечением отказоустойчивости.
Вообще, история осмысления, формализации интеллектуальной, творческой деятельности человека очень интересна. До Бэббиджа был Корсаков с его информационными машинами. В области алгоритмического творчества известна игра Musikalisches Würfelspiel, приписываемая Моцарту. Вопросами формализации и моделирования творческих процессов в СССР много занимался Зарипов.
Здесь можно вспомнить о модели коллектива вычислителей, предложенной Э.В. Евреиновым. Эта модель формализовала действия совокупности людей-вычислителей, работающих над какой-либо общей сложной задачей. Руководитель подобного коллектива должен разбивать задачи на подзадачи, добиваться их распараллеливания и улучшения обменов данными. На основе модели коллектива вычислителей в СССР 50-60-х было создано направление однородных вычислительных систем (поздние примеры: массово-параллельные суперкомпьютеры, кластеры), структур (поздние примеры: систолические массивы, транспьютеры) и сред (поздний пример: ПЛИС).
В этой речи, как и в других своих выступлениях, Алан Кэй повторяет одни и те же идеи. Повторяет, очевидно, потому, что не чувствует, что к нему прислушиваются. Среди таких идей я выделю следующие.
Фильтр нижних частот для идей
Разработчики «оглупляют» свою продукцию, поскольку это приносит больше прибыли. Ни в коем случае не давить на пользователя, не ожидать от него слишком многого, не пытаться его чему-то учить! Иначе пострадают продажи. В этом смысле полезно сравнить современный iPad с проектом Dynabook, о котором Кэй подробно написал в статье Personal Dynamic Media. Там, помимо прочего, речь шла о сравнении таких массовых изделий, как телевизоры, способы применения которых жестко ограничены, с бумагой или глиной, гибких в использовании, но требующих для творческой работы какого-то инструментария. Планшет Dynabook задумывался как объединение среды, столь же поддатливой, как глина или бумага, и инструментария, простого и эффективного, как использование автомобиля или телевизора. В этом смысле постепенное превращение компьютера только лишь в бытовой прибор, а пользователя — лишь в пассивного потребителя «контента» не могло обрадовать Кэя. Было ли когда-то иначе? Как ни странно, в конце 80-х именно компания Apple выпустила на рынок удивительно гибкую среду HyperTalk для Макинтоша. С HyperTalk уже не только программист, а рядовой пользователь мог взять на себя активную, созидающую роль в отношениях с компьютером. Однако, даже HyperTalk требовал освоения, мастерства, а это, зачастую, совершенно запрещенные ожидания для современного маркетинга.
Учет генетики
Кэй часто говорит о том, что люди, и, в первую очередь, дети, генетически наиболее приспособлены к эффективному впитыванию того, что содержится в окружающей среде/культуре. Собственно, Dynabook как раз планировался в качестве подобной плодотворной среды, которая бы эффективно обучала важнейшим современным концепциям (сложные динамические системы и проч.). В реальности же бывает так, что современные медиа просто эффективно эксплуатируют наши генетические инстинкты, беспроигрышно нацеливаясь на «пещерный» уровень аудитории. Здесь Кэй часто ссылается на работы Нила Постмана («Развлекаемся до смерти» и другие).
Долгосрочные прогнозы
Кэй выступает против верхоглядства, против исключительного превознесения узкого отрезка существования цивилизации, называемого «настоящим». Представьте, что для нас 100, 500 лет назад были бы тем же «вчера». В каком широком контексте мы смогли бы мыслить, сколько забытых идей было бы перед глазами! При таком подходе мы бы пришли органично к размышлениям и о будущем на долгосрочных промежутках времени. Мы бы увидели те «невидимые» тенденции, которые проявляются только на более крупных масштабах.
Я не знаю, замечал ли кто-либо еще этот момент, но между Аланом Кэем и писателем Рэем Брэдбери имеется много общего. Оба призывают к ответственному, вдумчивому использованию технологий. Оба любят бумажные книги. «Новости» из выступления выше Брэдбери метко называл «фактоидами». Надо сказать, пути Кэя и Брэдбери неоднократно пересекались. Один раз это произошло в начале 80-х, в компании Атари, где в то время работал Кэй. В стенах лаборатории Атари прорабатывался совершенно удивительный проект дополненной реальности по произведению «Что-то страшное грядет» с привлечением самого автора. В 1988 году Кэй и Брэдбери вместе участвовали в работе над Project 2000, организованном компанией Apple. К сожалению, Брэдбери уже ушел из жизни и его неудобной для многих критики текущего положения дел мы более не услышим. Поэтому давайте с уважением и вниманием отнесемся к еще одному «старому ворчуну» — Алану Кэю.
Как ни странно, на этот вопрос не так уж легко ответить. По крайней мере, ответ с учетом юридических тонкостей вполне заслуживает отдельной заметки на Хабре.
Некоторые известные разработчики, в частности, D. J. Bernstein, считают, что явное указание своей работы, как общественного достояния, вполне достаточно. cr.yp.to/publicdomain.html
Другие указывают, что в некоторых странах понятие «общественное достояние» может трактоваться по-разному.
А я бы хотел напомнить о ПО с «лицензией» public domain (PD, «общественное достояние»). Такого рода ПО всегда находилось вдали от идеологической конфронтации и коммерческой выгоды. Конечный пользователь о нем часто и не слышал. Но именно программы с пометкой PD были двигателем развития информатики. Достаточно вспомнить такие исторические примеры, как SPICE и MACSYMA.
Помните знаменитое письмо Гейтса к членам клуба любителей компьютера по поводу кражи Altair BASIC? Менее известно, что в то же самое время вышел замечательно спроектированный Tiny BASIC (1976), созданный Деннисом Аллисоном из Стэнфордского университета. В коде Tiny BASIC фигурировало «Copyleft; All Wrongs Reserved». Tiny BASIC с различными добавлениями успешно использовался на некоторых микрокомпьютерах.
Мне думается, формат PD для определенного рода программ и сегодня актуален.
Конечно же Лисп имеет смысл применять там, где не хватает готовых решений из традиционных ЯП. Но лично меня удивляет такое внимание именно к неуклюжему Common Lisp. Почему не более изящный Scheme? Добавьте его интерпретатор к тому инструментальному средству, которое востребовано в вашем рабочем проекте (на C/C++, C#, Java или ином «скучном» языке), и у вас будет вполне достойное компромиссное решение.
1. Статья Instruction Selection by Graph Transformation на тему реализации этапа выбора инструкций с помощью системы переписывания (произвольных) графов. Вещь перспективная в том смысле, что даже в LLVM выбор инструкций осуществляется только на уровне DAG.
2. Алгебра программ в DSL-системах SPIRAL и Faust для DSP-программирования.
3. Взгляд на полиэдральный подход со стороны мат. формализма Пресбургера.
Существуют работы по совмещению полиэдрального подхода с классическим динамическим анализом зависимостей inspector/executor. Также представляет интерес, на мой взгляд, техника взаимодействующих полиэдральных процессов — polyhedral process network.
А вот об использовании данного подхода в golang я ничего не слышал. Не поделитесь ссылкой?
Что касается, R-Stream, то я сужу о нем по доступным публикациям и патентам. Это, безусловно, полноценный распараллеливающий компилятор, который поддерживает гетерогенные массово-параллельные архитектуры. Просто последняя публикация на их сайте посвящена именно TensorFlow :)
P.S. Большое спасибо за критику Polly и Graphite!
А нужно ли вообще иметь дело с Array/Memory SSA там, где мы можем использовать промежуточное представление на основе модели многогранников? Я не очень уловил, как работе на уровне этого промежуточного представления мешают какие-то «недостатки дизайна промежуточных проходов SSA». Ведь в таких коммерческих компиляторах, как R-Stream, а также в расширениях Polly (LLVM) и Graphite (GCC) осуществляется переход из SSA на другой уровень представления для совершения преобразований по векторизации/распараллеливанию/проч., а потом возвращается результат в SSA (или другом виде).
ac.els-cdn.com/S1571066111001538/1-s2.0-S1571066111001538-main.pdf?_tid=86c677b1-94c4-4dd7-9b05-07a8149a9fe9&acdnat=1525361214_da2b9d1c18fe5baa768a31e46bbafc90
llvm.org/devmtg/2011-11/Simpson_PortingLLVMToADSP.pdf
Какие же есть альтернативы GCC/LLVM среди компиляторов и соотв. фреймворков общего назначения?
1. CompCert. compcert.inria.fr
Компилятор (подмножества) C99, реализованный на Ocaml, с формально доказанной реализацией. Использует практически все методы улучшения кода из классических учебников.
2. Firm. pp.ipd.kit.edu/firm
Компактная альтернатива LLVM, реализованная на чистом Си. Имеет множество готовых к использованию фаз трансформации кода.
Вариант подхода compiler-in-loop в Synopsys:
www.springer.com/cda/content/document/cda_downloaddocument/9781441911759-c1.pdf?SGWID=0-0-45-813305-p173915907
www.chipex.co.il/_Uploads/dbsAttachedFiles/AddingCProgrammabilitytoDataPathDesign.pdf
Ранние достижения в этой области связаны с работой коллективов из Европы:
www.ace.nl/compiler/cosy.html
pdfs.semanticscholar.org/presentation/3fbe/58c3e1f588aa467f0158a0d47e803ac79149.pdf
P.S. Скорее всего, разработчики RISC-V приняли правильное решение. Но сама ситуация, когда создатели процессорных архитектур ограничивают себя в выразительных средствах ради совместимости с существующими GCC/LLVM-инструментами допустима не во всех случаях, согласитесь.
«They had an existing compiler, but it was very old and porting it to the new generation DSP was not feasible. Embecosm were tasked with providing a LLVM based tool chain capable of compiling their C codecs and delivering high quality code.»
И будьте внимательнее, Synopys ARC не имеет отношения к ASIP Designer.
Бессмысленно меня убеждать в массовой распространенности LLVM. Гораздо интереснее, на мой взгляд, посмотреть на эту систему критически и оценить риски ее использования.
Если мы разрабатываем еще один 32-битный RISC-процессор, то использование LLVM вполне оправдано. Именно на такого вида архитектуры ориентирована эта система. У любого универсального промежуточного представления есть свои границы применимости. Специалисты это знают еще со времен UNCOL.
Задача усложняется, если мы имеем дело с нетрадиционной процессорной архитектурой: стековой, VLIW, CGRA и т.д. Здесь уже необходимо вводить собственные внутренние представления и трансформации. Если Вы не специалист по коду LLVM и не участвуете регулярно в соотв. списках рассылки, но ориентируетесь в методах компиляции, то вопрос уже не стоит так однозначно.
С точки зрения разработчика это вечная дилемма: использовать сторонний фреймворк, который потребует основательной переработки или же создать свое специализированное решение. Нужно учитывать, что сложность изучения самих алгоритмов компиляции значительно ниже, чем сложность реализаций из гигантских систем в духе LLVM. Вам придется читать источники по разработке компиляторов, вместо изучения деталей фреймворка. Но ключевой здесь момент: все это возможно при наличии соответствующего инструментария разработки компиляторов. Если же Вы просто вооружились «книгой Дракона» и решили написать на C/C++ компилятор, то, скорее всего, находитесь на неверном пути.
P.S. И, да, у меня есть свой опыт быстрого прототипирования компиляторов для специализированных процессоров.
В статье речь идет о портировании LLVM для уже готового специализированного процессора. Конечно же, 120 дней — неприемлемый срок для подхода compiler-in-loop. Понятно, что LLVM был выбран по требованиям заказчика, но можно задаться вопросом: не была бы разработка своего backend для специализированного 16-битного процессора более эффективным (по времени, качеству кода) решением, чем адаптация LLVM?
Разработка компилятора это, разумеется, очень нелегкое занятие. Как и в случае многих других OSS-проектов, в основе «народных» компиляторов лежат идеи и код, разработанный в академической сфере. В частности, без работ Davidson и Fraser не было бы GCC. Но далеко не все «академические» компиляторы попадают в OSS. В таких, например, системах, как Synopys ASIP Designer и Reservoir Labs R-Stream, используются более изощренные методы компиляции, чем в LLVM и GCC. В целом, активность по разработке инструментального ПО за пределами этих двух «народных» компиляторов, безусловно, есть.
О нем можно прочесть здесь
Также см. книгу: www.ozon.ru/context/detail/id/140728981
О работах Корсакова кратко говорится тут: www.computer-museum.ru/precomp/korsakov.htm
Фраза «Никому точно не известно, когда впервые возникли идеи их проектов, каков был путь к созданию реально работающих устройств, и к тому же разница в несколько лет в исторической перспективе ничтожна», пожалуй, более уместна в данном случае.
Особенно интересно анализировать опыт управления сложными проектами с участием «компараторов» и проч. При решении задач, требующих использования большого количества людей-вычислителей, на первый план выходят проблемы управления потоками информации, а также обеспечение корректности результатов. Для современных высокопроизводительных вычислительных систем тут имеются прямые аналогии с работой коммуникационных сетей и обеспечением отказоустойчивости.
Вообще, история осмысления, формализации интеллектуальной, творческой деятельности человека очень интересна. До Бэббиджа был Корсаков с его информационными машинами. В области алгоритмического творчества известна игра Musikalisches Würfelspiel, приписываемая Моцарту. Вопросами формализации и моделирования творческих процессов в СССР много занимался Зарипов.
Фильтр нижних частот для идей
Разработчики «оглупляют» свою продукцию, поскольку это приносит больше прибыли. Ни в коем случае не давить на пользователя, не ожидать от него слишком многого, не пытаться его чему-то учить! Иначе пострадают продажи. В этом смысле полезно сравнить современный iPad с проектом Dynabook, о котором Кэй подробно написал в статье Personal Dynamic Media. Там, помимо прочего, речь шла о сравнении таких массовых изделий, как телевизоры, способы применения которых жестко ограничены, с бумагой или глиной, гибких в использовании, но требующих для творческой работы какого-то инструментария. Планшет Dynabook задумывался как объединение среды, столь же поддатливой, как глина или бумага, и инструментария, простого и эффективного, как использование автомобиля или телевизора. В этом смысле постепенное превращение компьютера только лишь в бытовой прибор, а пользователя — лишь в пассивного потребителя «контента» не могло обрадовать Кэя. Было ли когда-то иначе? Как ни странно, в конце 80-х именно компания Apple выпустила на рынок удивительно гибкую среду HyperTalk для Макинтоша. С HyperTalk уже не только программист, а рядовой пользователь мог взять на себя активную, созидающую роль в отношениях с компьютером. Однако, даже HyperTalk требовал освоения, мастерства, а это, зачастую, совершенно запрещенные ожидания для современного маркетинга.
Учет генетики
Кэй часто говорит о том, что люди, и, в первую очередь, дети, генетически наиболее приспособлены к эффективному впитыванию того, что содержится в окружающей среде/культуре. Собственно, Dynabook как раз планировался в качестве подобной плодотворной среды, которая бы эффективно обучала важнейшим современным концепциям (сложные динамические системы и проч.). В реальности же бывает так, что современные медиа просто эффективно эксплуатируют наши генетические инстинкты, беспроигрышно нацеливаясь на «пещерный» уровень аудитории. Здесь Кэй часто ссылается на работы Нила Постмана («Развлекаемся до смерти» и другие).
Долгосрочные прогнозы
Кэй выступает против верхоглядства, против исключительного превознесения узкого отрезка существования цивилизации, называемого «настоящим». Представьте, что для нас 100, 500 лет назад были бы тем же «вчера». В каком широком контексте мы смогли бы мыслить, сколько забытых идей было бы перед глазами! При таком подходе мы бы пришли органично к размышлениям и о будущем на долгосрочных промежутках времени. Мы бы увидели те «невидимые» тенденции, которые проявляются только на более крупных масштабах.
Я не знаю, замечал ли кто-либо еще этот момент, но между Аланом Кэем и писателем Рэем Брэдбери имеется много общего. Оба призывают к ответственному, вдумчивому использованию технологий. Оба любят бумажные книги. «Новости» из выступления выше Брэдбери метко называл «фактоидами». Надо сказать, пути Кэя и Брэдбери неоднократно пересекались. Один раз это произошло в начале 80-х, в компании Атари, где в то время работал Кэй. В стенах лаборатории Атари прорабатывался совершенно удивительный проект дополненной реальности по произведению «Что-то страшное грядет» с привлечением самого автора. В 1988 году Кэй и Брэдбери вместе участвовали в работе над Project 2000, организованном компанией Apple. К сожалению, Брэдбери уже ушел из жизни и его неудобной для многих критики текущего положения дел мы более не услышим. Поэтому давайте с уважением и вниманием отнесемся к еще одному «старому ворчуну» — Алану Кэю.
1. Делия Дербишир.
2. Лори Шпигель.
3. Карла Скалетти.
carlascaletti.com/bio
Некоторые известные разработчики, в частности, D. J. Bernstein, считают, что явное указание своей работы, как общественного достояния, вполне достаточно. cr.yp.to/publicdomain.html
Другие указывают, что в некоторых странах понятие «общественное достояние» может трактоваться по-разному.
Насколько я знаю, в настоящее время наиболее полно соответствует понятию public domain лицензия CC0: creativecommons.org/share-your-work/public-domain/cc0
Помните знаменитое письмо Гейтса к членам клуба любителей компьютера по поводу кражи Altair BASIC? Менее известно, что в то же самое время вышел замечательно спроектированный Tiny BASIC (1976), созданный Деннисом Аллисоном из Стэнфордского университета. В коде Tiny BASIC фигурировало «Copyleft; All Wrongs Reserved». Tiny BASIC с различными добавлениями успешно использовался на некоторых микрокомпьютерах.
Мне думается, формат PD для определенного рода программ и сегодня актуален.