Для тех, кто не смог поприсутствовать на самом докладе:
суббота, 22 октября 2016 г.
вторник, 18 октября 2016 г.
[prog.wow] Самое удивительное для меня в судьбе Erlang-а в Ericsson-е между 1986-ым и 1995-ым
Читаю сейчас урывками историю Erlang-а от Джо Армстронга. Одну вещь ну очень тяжело лично мне осознать, пока не получается и все.
Дело в том, что судя по тому, что рассказывает Армстронг, Erlang в Ericsson-е не выходил за пределы лабораторий до 1995-го года. При том, что собственно над тем, что стало Erlang-ом Армстронг начал работать в 1986 (а вообще к проблематике создания языка для упрощения разработки софта для телефонии он подключился на год раньше, в 1985-ом). В самом конце 80-х были эксперименты по прототипированию на Erlang-е. В начале 90-х группа Армстронга убедила руководство начать раздавать Erlang заинтересовавшимся людям за пределами Ericsson-а. В 1993-ем вышла книга про Erlang. И Ericsson создал дочернее подразделение Erlang Systems AB для коммерциализации Erlang-а. Но в самом Ericsson-е Erlang был востребован в продакшене только в 1995-ом, когда стартовали AXD после неудачи проекта AXE-N.
Т.е. девять лет несколько разработчиков на зарплате Ericsson-а делали что-то, что сам Ericsson не использовал. И, особенно в первые два-три года, никто даже и не знал, во что это в итоге выльется.
Афигеть просто.
В качестве наемного разработчика я проработал почти 20 лет. И не припомню ситуаций, когда можно было уйти в какое-то вольное плавание хотя бы на пару месяцев без предьявления по итогу чего-то, пригодного для использования. Посему и не могу представить себе, какую свободу Ericsson предоставлял сотрудникам своих исследовательских лабораторий, какой огромный кредит доверия там выдавался.
Внушаить.
воскресенье, 16 октября 2016 г.
[prog.memories] Любопытное из воспоминаний Джо Армстронга про историю Erlang
Увидел в статье "A History of Erlang" от 2007-го (бесплатная PDF-ка легко гуглится):
But the Smalltalk was very slow -- so slow that I used to take a coffee break while it was garbage collecting.
Т.е. Smalltalk был настолько тормознутым, что приходилось отвлекаться на чашечку кофе, пока Smalltalk занимался сборкой мусора. Как я понимаю, речь шла о Smalltalk для BSD Unix на Vax 11/750. В 1985-86 годах.
Забавно. Может кто-то из нынешней молодежи лучше поймет, почему в конце 80-х и в девяностых мейнстримом становились языки вроде C++.
четверг, 13 октября 2016 г.
[prog.wow] Новость про новый язык P от Microsoft
Собственно, вот сама новость: Microsoft Open-Sources P Language for Safe Async Event-Driven Programming. Небольшая цитата оттуда:
Microsoft describes P as a domain-specific language to model communication between components of an asynchronous system, such as an embedded, networked, or distributed system. A P program is defined in terms of finite state machines than run concurrently. Each of them has an input queue, states, transitions, a machine-local store, and can send asynchronous messages to the others.
Или, в моем корявеньком переводе на русский язык:
Microsoft описывает P как язык, заточенный под моделирование взаимодействия между компонентами в асинхронной системе, вроде встраиваемой, сетевой и распределенной системы. Программа в P определяется в терминах конечных автоматов, которые работают параллельно. Каждый из них имеет входящую очередь, состояния, переходы, локальное хранилище и может отсылать асинхронные сообщения другим [участникам].
Звучит как-то до боли знакомо...
Ба! Да мы же сделали это в SObjectizer-е фиг знает когда и уже много лет пользуемся полученными плюшками ;)
Правда, в P обещают верификацию. Вот чего у нас нет, того нет...
понедельник, 10 октября 2016 г.
[prog.c++] Статистика по использованию try-catch в исходниках SO-5.5.18
На волне темы про использование исключений подсчитал, как часто в исходниках последней стабильной версии SO-5.5.18 встречаются блоки try-catch. Общий объем ядра SO-5 порядка 25KLOC (не считая пустых строк и комментариев). Всего насчитал 25 блоков try (в двух-трех блоках по 2 секции catch). Из общего числа catch-ей:
- в 10 случаях catch используется для преобразования одного типа исключения в другое. В нескольких из этих случаев перед пробросом нового исключения выполняются действия по очистке/откату операций;
- в 7 случаях в catch-е иницируется вызов std::abort() (перед этом зачастую идет логирование проблемы);
- в 4-х случаях исключение "проглатывается". В двух из них предварительно логируется;
- в 3-х случаях ловятся исключения, выпущенные из обработчиков событий агентов. В этих catch-ах происходит то, что описывалось в свежей статье на Хабре;
- в одном случае ловится исключение, выпущенное из обработчика события агента, для фиксации этого исключения в std::promise. Этот сценарий используется для синхронного взаимодействия агентов;
- в одном случае используется логика на исключениях: с помощью исключения разрывается цикл выборки событий из очереди одного из диспетчеров. Оказалось, что такая реализация цикла самая простая;
- и в одном случае catch используется для эмуляции noexcept для старых VC++ компиляторов.
В общем, получается где-то по одному try-catch на тысячу строк кода.
Отдельно можно сказать про случаи с проглатыванием исключений. В двух из них исключения логируются, но выбрасываются, т.к. исключение вылетает из нотификаторов регистрации и дерегистрации коопераций. Эти нотификаторы вызываются когда основная операция (т.е. либо регистрация, либо дерегистрация) уже завершена, была сделана попытка проинформировать пользователя об этом. Но не получилось. На основную операцию такой сбой повлиять не может, сделать что-то осмысленное с исключением уже нельзя, а прерывать все приложение через std::abort() в данном случае представляется слишком жестоким.
А вот два других случая с игнорированием исключений интереснее. Один из них такой (сорри за качество английского):
|
//! Switching storage from map to vector. void switch_storage_to_vector() { // All exceptions will be ignored. // It is because an exception can be thrown on staged 1-2-3, // but not on stage 4. try { // Stage 1. New containers to swap values with old containers. // An exception could be thrown in the constructors. map_type empty_map; vector_type new_storage; // Stage 2. Preallocate necessary space in the new vector. // An exception can be thrown here. new_storage.reserve( m_map.size() ); // Stage 3. Copy items from old map to the new vector. // We do not expect exceptions here at v.5.5.12, but // the situation can change in the future versions. // Use the fact that items in map is already ordered. std::for_each( m_map.begin(), m_map.end(), [&new_storage]( const map_type::value_type & info ) { new_storage.push_back( info.second ); } ); // Stage 4. Swapping. // No exceptions expected here. m_vector.swap( new_storage ); m_map.swap( empty_map ); m_storage = storage_type::vector; } catch(...) {} } |
Тут в транзакционном стиле делается попытка сменить внутреннее представление одной из структур данных. Если по ходу дела возникают исключения (прежде всего bad_alloc), то операция откатывается и не имеет эффекта. При этом исключение проглатывается, т.к. смысла прокидывать его наверх нет -- ничего же не изменилось.
Какова мораль? Да нет никакой морали. Просто любопытно стало. Думаю, что для библиотек небольшое количество try-catch -- это нормально. В прикладном кода плотность испрользования try-catch наверняка выше.
пятница, 7 октября 2016 г.
[prog.flame] Длина строки кода таки важная штука
В последние дни довелось много покопаться в больших фрагментах чужого кода (часть на C, часть на C++). С разными стилями оформления. Но во всех случаях код вполне нормальный, разобраться не сильно сложно.
Однако, поймал себя на том, что код, в котором длина строки не превышает 80 символов, читается намного легче. Получается, что увеличение количества строк, при их небольшой длине, все-таки лучше, чем меньшее количество длинных строк. Думаю, это потому, что когда доходишь до конца длинной строки и затем переходишь на следующую строку (т.е. возвращаешь взгляд в крайнюю левую позицию), то не сразу понимаешь, откуда именно нужно продолжать чтение. На то, чтобы понять приходится тратить время и внимание несколько рассеивается.
Еще раз убедился в том, что ограничение на 78-80 символов для длины строки кода -- это вполне разумно.
PS. Длинная строка -- это когда 100+ символов.
вторник, 4 октября 2016 г.
[prog.c++] Официальный анонс конференции Corehard C++ Autumn 2016 в Минске
Просто оставлю здесь текст официального анонса конференции, на которой в качестве докладчиков будет выступать мой коллега, Николай Гродзицкий, и я.
| ||
|
Подписаться на:
Сообщения (Atom)