Именно в этот день, 8 июня 1995 года, Расмус Лердорф открыл исходный код PHP Tools общественности.

Созданное в 1994 году Расмусом Лердорфом, самое первое воплощение PHP было простым набором CGI-скриптов, написанных на языке программирования Си.

Первой версией PHP, напоминающей тот язык, каким мы знаем его сегодня, была версия 3.0. Примерно после девяти месяцев публичного тестирования, при объявлении официального выпуска PHP 3.0, он уже был установлен на более чем 70000 доменах по всему миру. На пике своего развития PHP 3.0 был установлен приблизительно на 10% веб-серверов в Интернете.

PHP 4.0, основанный на новом движке «Zend Engine», официально вышел в мае 2000 года. Кроме значительного улучшения производительности, PHP 4.0 получил ещё несколько ключевых нововведений, таких как поддержка намного большего числа веб-серверов, поддержка HTTP сессий, буферизация вывода, более безопасные способы обработки вводимой пользователем информации и несколько новых языковых конструкций.

В июле 2004 был выпущен PHP 5 с обновлённым движком «Zend Engine 2.0», новой объектной моделью и множеством других нововведений. Версия 5.3 порадовала пользователей пространствами имён, поздним статическим связыванием и замыканиями.

В 2009 году появилась группа совместимости фреймворков (PHP-FIG), которая начала благородную миссию по стандартизации совместимости PHP-проектов. Большинство PHP-библиотек и фреймворков начали адаптацию под рекомендации, предложенные или одобренные группой совместимости фреймворков (PSR).

В апреле 2011 началась работа над менеджером зависимостей Composer, который должен прийти на замену устаревшему PEAR.

Новая значительная версия PHP 5.4 была выпущена в марте 2012. С выпуском этой версии PHP получил заметные улучшения производительности, новые функции включают трейты, короткий синтаксис массивов, встроенный веб-сервер для тестирования и многое другое.

С приходом версии 5.5 в PHP появились генераторы и сопрограммы, ключевое слово finally, упрощенное API для хеширования паролей и множество других новых функций.

Несмотря на наличие обширной документации, первоначальный черновик спецификации был анонсирован только в 2014 году.

А в августе этого же года вышла стабильная значительная версия PHP 5.6. Новые функции включают скалярные выражения в константах, функции с переменным числом аргументов при помощи оператора ..., оператор возведения в степень **, импорт функций и констант при помощи ключевого слова use и многое другое.

Уже осенью этого года состоится выпуск PHP 7, который включит революционные для этого языка изменения.

>>> Подробности

Подскажите, пожалуйста, где мощнее метапрограммирование в Clojure или D? Есть ли в D макросы? я так не понял миксины это макросы или нет, чем они отличаются от макросов Clojure?

Можно ли расширять компилятор и насколько легко?

15 мая 2015 года, в соответствии с планом, вышел публичный релиз Rust 1.0 - языка программирования общего назначения, разрабатываемого Mozilla совместно с сообществом. Язык ориентирован на разработку безопасных и эффективных приложений, имеет развитую систему типов, оптимизирующий кодогенератор на основе llvm и предоставляет расширенные гарантии потокобезопасности и безопасного доступа к памяти без использования сборщика мусора. В частности, Mozilla использует Rust для разработки браузерного движка следующего поколения servo.

( читать дальше... )

>>> Подробности

Edi Weitz, широко известный лиспер, автор известной библиотеки cl-ppcre и многих других, начал работу над своей книгой: «Common LISP Recipes: A Problem-Solution Approach» для издательства Apress.

Эта книга будет наподобие книги рецептов (cookbook-style). Часть книги будет посвещена библиотекам с открытым исходным кодом, работой с ASDF и Quicklisp.

По линкам ниже можно посмотреть предварительные страницы заказа книги:

• Springer
• Amazon

1-го апреля 2015 года стала доступна новая версия нереляционной СУБД Redis. Основной отличительной особенностью данного релиза является то, что это первая стабильная версия Redis со встроенной поддержкой кластеризации*).

Redis - это нереляционная СУБД типа ключ-значение (key-value) с открытым исходным кодом.

Поддерживает следующие структуры данных:

• строка (string);
• хэш (hash);
• список (list);
• множество (set);
• сортированное множество (sorted set);
• битовый массив (bitmap);
• HyperLogLog (структура данных для реализации алгоритма рандомизированного вероятностного подсчета количества уникальных значений).

Для всех этих типов поддерживаются атомарные операции (например вставка в список или пересечение множеств). База данных Redis хранится в основной памяти, а для обеспечения долговременного хранения используется синхронизация на диск.

Основные изменения:

• встроенная поддержка кластеризации;
• улучшен аппроксимационный алгоритм вытеснения ключей для LRU**)-кешей;
• добавлена команда CLIENT PAUSE: остановка обработки всех запросов клиента на определенное время;
• переработан механизм обеспечения долговременного хранения даных AOF***) с целью уменьшения задержек при сбросе буфера на медленных дисках;

*) Redis Cluster Specification
**) least recently used
***) append only file

>>> Подробности

Sophia это встраиваемая СУБД, работающая по принципу «ключ - значение» и имеющая уникальную архитектуру, разработанную в результате попытки избавления от основных алгоритмических недостатков LSM-деревьев.

Sophia рассчитана на быструю запись в режиме постоянного пополнения (append-only) и не менее быстрое чтение данных и диапазонов значений.

Особенности:

• Полное соответствие требованиям ACID.
• Движок MVCC (Multi-Version Concurrency Control) для мультидоступа к БД.
• Чистый режим постоянной дозаписи (append-only).
• Поддержка множественных БД.
• Многопоточность в движке и клиентском доступе.
• Мультиоперационные транзакции.
• Поддержка сериализованных представлений.
• Асинхронное горячее резервирование.
• Консистентные указатели.
• Снапшоты.
• Простой и лёгкий API со стабильным форматом.
• Прост в интеграции (требуется только два файла на С).
• Легко расширяется посредством FFI.
• Распространяется под лицензией BSD в виде небольшой блибиотеки на языке С без каких-либо зависимостей.

>>> Подробности

Мужики, поясните за eval-when. В целом, эмпирически, я представляю как работает eval-when в разрезе compile-file, (load .lisp) и (load .fasl), но таблички в HyperSpec-е и CLtL2 вообще никак соотнести со своими представлениями не могу. В частности, не могу понять что из-себя compile-time-too и non-compile-time режимы представляют и когда они наступают. В описании какие-то мутные, если можно так сказать, определения.

Для удобства, приведу таблички здесь: http://www.lispworks.com/documentation/HyperSpec/Body/03_bca.htm

| CT  | LT  | E   | Mode | Action   | New Mode         |
|-----+-----+-----+------+----------+------------------|
| Yes | Yes | -   | -    | Process  | compile-time-too |
| No  | Yes | Yes | CTT  | Process  | compile-time-too |
| No  | Yes | Yes | NCT  | Process  | non-compile-time |
| No  | Yes | No  | -    | Process  | non-compile-time |
| Yes | No  | -   | -    | Evaluate | -                |
| No  | No  | Yes | CTT  | Evaluate | -                |
| No  | No  | Yes | NCT  | Discard  | -                |
| No  | No  | No  | -    | Discard  | -                |

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node68.html#SECTION00933000000...

| LT  | CT  | EX  | CTTM | Action                                |
|-----+-----+-----+------+---------------------------------------|
| yes | yes | -   | -    | process body in compile-time-too mode |
| yes | no  | yes | yes  | process body in compile-time-too mode |
| yes | no  | -   | no   | process body in non-compile-time mode |
| yes | no  | no  | -    | process body in non-compile-time mode |
| no  | yes | -   | -    | evaluate body                         |
| no  | no  | yes | yes  | evaluate body                         |
| no  | no  | -   | no   | do nothing                            |
| no  | no  | no  | -    | do nothing                            |

Статью (на русском) Fare про eval-when знаю, но считаю её ещё более запутанной, чем описания в первоисточниках.

P.S. У меня вот такие таблички получились:

| :compile-toplevel | :load-toplevel | compile-file   | load .fasl |
|-------------------+----------------+----------------+------------|
| -                 | -              | -              | -          |
| +                 | -              | eval           | -          |
| -                 | +              | compile        | eval       |
| +                 | +              | eval & compile | eval       |

| :execute | load .lisp     |
|----------+----------------|
| -        | -              |
| +        | eval           |

Common Lisp разрабатывался и используется в предположении, что пользователь программы — программист. Поэтому из языка намеренно исключены сложные для понимания конструкции (пользователь не обязательно квалифицированный программист), поэтому в языке мощнейший отладчик, позволяющий без остановки программы переопределять функции и вообще делать что угодно. Но из-за этого документация по большей части библиотек Common Lisp существует только в виде docstring и комментариев в коде (некоторые вообще считают, что код сам себе документация). Из-за этого обработка ошибок почти всегда оставляется на отладчик (главное сделать рестарт «перезапустить с последней итерации», а там пользователь сам разберётся). Из-за этого в программе проверяется только happy path (пользователь ведь «тоже программист»).

Racket разрабатывался и используется в предположении, что пользователь программы не программист, а задача разработчика написать программу так, чтобы она корректно работала при любых входных данных (если данные некорректны, то сообщала об этом в том месте, где данные были введены). Поэтому в языке эффективная библиотека для написания тестов, система контрактов на уровне модулей, макимально широкий спектр инструментов программирования (разработчик должен быть профессионалом!). Также реализована идея инкапсуляции: считается, что пользователь модуля не должен знать особенности реализации и, более того, не может в своём коде изменить функцию чужого модуля если это явно не разрешено разработчиком того модуля. Исходный код разумеется доступен, но его не требуется смотреть, чтобы использовать модуль. Достаточно документации. Поэтому реализована мощнейшая система документировния Scribble, а при реализации макроса есть возможность обеспечить указание на ошибки в коде, предоставленном макросу пользователем, не показывая потроха макроса.

И поэтому в Racket нет CLOS (есть как минимум две реализации, но не используются) - провоцирует заплаточное программирование (monkey patching), поэтому отладчик намеренно ограничен (если ты отлаживаешь программу, значит ты не знаешь как она должна работать!), поэтому нет разработки в образе (image based) - она провоцирует разработку через отладку (а значит непонимание программы и проверку только happy path).

Таким образом, Racket и Common Lisp несмотря на внешнее сходство являются очень разными языками. И я рекомендую писать на Racket, если только конечными пользователями программы не являются исключительно программисты на Common Lisp.

Взято с http://racket-lang.blog.ru/#post214726099

Хотелось бы знать, что по этому поводу думают пользователи ЛОРа. А также, мне кажется, что для Java и C++ будет где-то такая же разница.

Учитывая весь шум, который поднимается вокруг лисповских макросов, вокруг их необычайной мощности и выразительности, я был несколько удивлен довольно уничижительным высказыванием в их адрес, подкрепленным примером:

Yes, there is a macro mechanism in PicoLisp, to build and immediately execute a list of expressions. But it is seldom used. Macros are a kludge. Most things where you need macros in other Lisps are directly expressible as functions in PicoLisp, which (as opposed to macros) can be applied, passed around, and debugged. For example, Common Lisp's DO* macro, written as a function:

(de do* "Args"
   (bind (mapcar car (car "Args"))
      (for "A" (car "Args")
         (set (car "A") (eval (cadr "A"))) )
      (until (eval (caadr "Args"))
         (run (cddr "Args"))
         (for "A" (car "Args")
            (and (cddr "A") (set (car "A") (run @))) ) )
      (run (cdadr "Args")) ) )

Есть в сети и еще примеры, довольно много, где макросы откровенно отсасывают. Их часто сравнивают с фэкспрами, причем, оказывается, в лисп среде, до появления компиляторов, лисперы действительно считали макросы достаточно слабым и редкоиспользуемым инструментом. Насколько я понимаю, основная претензия к ним, не столько в том, что они громоздки, многословны и невыразительны, хотя это тоже, сколько в том, что они не first-class.

Так может быть легенды о мощности лисповских макросов сильно преувеличены? Может быть, их использование — это, всего лишь, дань моде и вынужденный компромисс между выразительностью языка и возможностью компиляции?

Возникло желание «потыкать в скобочки», посоветуйте какой-нибудь «диалект» или там «наследника», чтобы было много достаточно литературы и библиотек, чтобы можно было хоть что-нибудь полезное (для себя) сделать

ЗЫ Капелька бояна http://imgs.xkcd.com/comics/lisp.jpg

Перемещено mono из talks

Ещё 10 февраля вышла новая версия языка Mercury — 14.01. Мажорные релизы называются по номеру года и месяца запланированного выпуска, предыдущий был 13.05.

Mercury — это логический и функциональный язык программирования, похожий на Prolog, но с поддержкой компиляции в машинный код, чистыми предикатами, со строгой статической типизацией, явным объявлением детерминизма предикатов, с функциями (а не только предикатами), встроенным каррированием и другими новшествами.

В новой версии:

• Могут повторяться переменные типов в объявлении экземпляров классов типов (type class instances). Например:

  instance foo(list(T), map(T, T)).

• Ряд улучшений в стандартной библиотеке, особенно связанных с функциями свёртки списков (см. полный список).
• Исправлены проблемы совместимости с GCC 4.8 (а также с Visual Studio 2013 и Mac OS X 10.9).

Сайт Mercury

Скачать

>>> Примечания к выпуску 14.01

Собственно меня интересуют батарейки и возможность компиляции в нативный код (последнее в меньшей степени). Как я понял, серьезно следует рассматривать только различные реализации CL и Scheme (Racket).

Если вы предлагаете Clojure, хотелось бы услышать обоснование (кококо-интероперабельность-с-жабой и кококо-ынтырпрайз - не аргументы).

С недавних пор взялся за изучение лиспа и никак не могу нигде найти инфу, зачем нужны точечные пары. Я знаю, что любой список является в Лиспе точечной парой, прошу не объяснять, об этом везде пишется. Но неясно, почему нельзя, как бы, выпилить вообще эти точки, на мой взгляд, нет такой ситуации, где нельзя было бы обойтись просто списками. Собственно, в Newlisp, ЕМНИП, так оно и сделано. Единственным мыслимым применением точечных пар, мне представляется ситуация, когда из точечной пары достается хвост, который не является списком, например, (cdr (1 . 2)), но очевидно, что здесь мы могли бы тоже обойтись списком и доставать 2 значение с помощью cadr. Создается такое ощущение, что эта структура имела какое то особенное значение в старых лиспах, а сейчас осталась как атавизм.

Какой же настоящий смысл данной структуры?

Осмысливая итоги своей прошлой попытки понять LC, пришла мысль, довольно очевидная, которая почему-то не приходила раньше.

LC - это метапрограммирование в чистейшем виде. Любая апликация возвращает либо другую аппликацию, либо абстракцию, которая «ждет» аргумента, чтобы вновь применить и абстрагировать. Иными словами, любое выражение LC - это диспетчер, который принимает на вход другого диспетчера, и возвращает его же. Выражение в LC не может манипулировать реальными программами, оно манипулирует только метапрограммами!

Отсюда возникает интересное следствие. LC имеет своего рода «утечку абстракции», только в прпотивоположном направлении. Когда мы пишем «обычную» программу, мы «спускаемся вниз» по абстракции. Например, если мы пишем:

(lambda(x y) (x y))

(define tst
  (((lambda(x) (lambda(y) (x y))) (lambda(x) x)) (lambda(x) (lambda(y) (x y)))))

(write ((tst (lambda(x) x)) 'b)) ; --> b

Сегодня, 20 января 2014, согласно расписанию разработки, вышел FreeBSD 10. Этот релиз можно назвать самым громким среди остальных - произведена миграция некоторых ключевых компонентов/механизмов системы. А среди них:

1) Замена основного способа компиляции программ и исходных кодов. Теперь для установки портов вместо компилятора GCC будет использоваться clang, распространяющийся по BSD-подобной лицензии. Если необходимо использовать GCC - его можно скачать из системы портов.
2) Распространяющийся в базовой поставке DNS-сервер BIND (named) был заменен на Unbound. Если нужен BIND - его тоже всё еще можно скачать из портов.
3) Произведен переход на следующее поколение менеджера пакетов - средства установки скомпилированных программ, удаления, также разрешения зависимостей: утилиты с префиксом pkg_, а именно pkg_add, pkg_create, pkg_delete, pkg_info, pkg_updating, pkg_version были заменены на pkg/pkgng

( читать дальше... )

Оригинальный список изменений

Выбор и скачивание образа

>>> Подробности

Если вы желаете помочь open-source проекту, вы все еще можете перечислить некоторую сумму FreeBSD Foundation.

На данный момент, январь 2014 года, собрана сумма в размере $710408 долларов.

FreeBSD Foundation занимается развитием и популяризацией проекта FreeBSD. В том числе выделением грантов на разработку необходимых проекту драйверов и систем.

>>> Подробности

Это достаточно известная книга Кристиана Кеннека, рассматривающая семантику Лиспа и основы его реализации на примере диалекта Scheme. В процессе повествования разбирается множество аспектов семантики языка, начиная разнообразными вариантами окружений, проходя через продолжения и исключения, заканчивая рефлексией, сутью макросов, компилятором в Си и объектной системой.

Книга содержит 11 интерпретаторов, 2 компилятора, стопку упражнений в каждой главе, уйму интересного материала об истории Лиспа и причинах принятия тех или иных решений в дизайне языка, некоторое количество аллюзий на современные языки программирования, а также небольшой вагончик литературы впридачу.

Здесь нет откровений, невероятно эффективных оптимизаций, мощных систем типов и прочих атрибутов современной computer science (книге 20 лет всё же), но есть отличное твёрдое введение в реализацию языков программирования, призванное заинтересовать новичков, познакомить их с основными понятиями и приёмами этого дела, построив таким образом фундамент для дальнейшего развития.

( Исходники и прочие детали )

>>> Скачать PDF

Уже много всякого прочитал про лисп(в том числе Practical Common Lisp и уже даже освоился с Clojure), но никак не могу понять, чем же на самом деле являются макросы в этом языке. И этот вопрос не дает мне покоя т.к. лисп сильно повлиял на мое мышление и я вижу, что лисп (а особенно, common lisp для своего времени), действительно, лучше и удобней других языков (ну, за исключением странного скобочного синтаксиса ^^) ... Если бы его преимущества заключались в динамической типизации, сборке мусора и интерактивном цикле разработки, то их в полной мере имели бы питон, javascript и даже php.

Обычно пишут, что макросы - сильная сторона лиспа, которая отличает его от других языков и в качестве аргументов приводят неудачные примеры, которые довольно просто реализовать в других языках. Может кто-нибудь объяснить более-менее формально, что такое макросы? В чем их преимущества?

Для себя мне удалось выделить лишь два свойства макроса, отличающих его от функции:

макрос выполняется до исполнения кода; вычислением аргументов макроса управляет программист.

Первое мне видится ограничением, которое приводит к целому ряду неудобств, как, например, невозможность применить apply к макросу(особено часто хочится сделать (apply and ...) или (reduce and ...)).

А второе может быть легко реализовано посредством функций высшего порядка хоть в C и C++. Для примера, в весьма популярной книге «Приемы объектно-ориентированного проектирования. Паттерны проектирования» Э. Гамма, Р. Хелм, Р. Джонсон, Д.Влиссидес описываются пaттерны Command и Interpreter - в комбинации это в точности макросы времени выполнения...