[life.cinema] Ролик фильма 2012

Внушаить!

Нужно будет сходить в кинотеатр, чтобы посмотреть все это действо на большом экране.

[comp; life] Оказывается, Андрей Александреску работает в Facebook

Всегда было любопытно, где работают разработчики каких-нибудь технологий или авторы нашумевших книг о программировании. Не буду скрывать, любопытство это с некоторым оттенком зависти – надо же, люди имеют возможность заниматься своим детищем, и им за это еще и платят! :) Правда, врожденная лень не позволяла даже заглянуть в Wikipedia, поэтому довольствуюсь лишь случайной информацией, которая временами мелькает в каких-нибудь новостях.

Так, известно, что Линус Торвальдс некоторое время работал в компании Transmeta (помнится, был какой-то слух о том, что он по контракту имел возможность тратить до 50% рабочего времени для работы над ядром Linux). Теперь он трудится в Open Source Development Labs и имеет возможность целиком посвящать время Linux-у (что не помешало ему между делом создать Git).

Гвидо ван Россум (Python) сейчас работает в Google, где не только допиливает Python, но еще и занимался какой-то системой на базе Python-а (вроде бы связанной с безопасностью).

Бьярн Страуструп (C++) до недавнего времени работал в Bell Labs. Теперь он профессор в Texas A&M University. Полагаю, в Bell Labs он занимался не только C++, но не думаю, что ему чинили препятствия в развитии C++.

Якихиро Матцумото (Ruby) сейчас возглавляет подразделение Research & Development в Network Applied Communication Laboratory (Япония). Так же я читал когда-то, что когда Ruby стал набирать популярность в Японии в конце 90-х, кто-то предоставил Матцумото, фактически, фиксивное место работы, на котором он смог 100% времени уделять разработке Ruby. Может эта как раз и была та компания, в которой он сейчас и работает.

Герб Саттер (автор отличных книг по C++) сейчас трудится в Microsoft, в команде C++ного компилятора.

Вальтер Брайт (разработчик Digital Mars C++ и Digital Mars D), похоже, живет за счет своей компании Digital Mars (которая продает не только C++ компилятор, но и DMDScript). Ранее он работал в Zortech и Symantec (как я понимаю, именно он и был автором Zortech C++ и Symantec C++, а так же имел отношение к разработке компилятора Java в Symantec).

Ганс Рейзер (автор файловых систем ReiserFS) владел компанией Namesys, которая на деньги инвесторов и разрабатывала ReiserFS. Сейчас он отбывает срок в тюрьме за убийство своей жены.

Ну с Джеймсом Гослингом (Java) и Андерсом Хейлсбергом (Turbo Pascal, Delphi, C#) все понятно – первый трудится в Sun (теперь уже Oracle), второй в Microsoft.

А вот вчера узнал, где работает Андрей Александреску (автор нашумевшей книги “Modern C++ Design” и соавтор отличной книги “C++ Coding Standards”). Что и подтолкнуло меня к написанию этого поста. Поскольку уже давно меня мучает вопрос – а что такого сделал Александреску? Не, ну книги – это понятно. А вот что он сделал как программист, кроме библиотеки Loki? Вопрос, однако :)

Так вот, Александреску работает как ученый-исследователь в Facebook. Учитывая, что он стал играть активную роль в разработке языка D (в частности, с его подачи в язык была добавлена вирусная константность и иммутабельность; им же переписана часть стандартной библиотеки D) и пишет книгу “The D Programming Language”, то его работа в Facebook может стать трамплином для старта D, как языка для серьезной разработки. А может и не стать… ;)

PS. Ну и не могу удержаться о того, чтобы вписать свое имя в один ряд с великими :) Я работаю главным программистом в отличной компании Интервэйл. Моя главная задача – поддержка и развитие реализованных на C++, что называется mission critical, сервисов. Попутно развивая и SObjectizer (выкраивая время на его доработку в паузах между фич-реквестами в “денежных” проектах, а пауз этих с каждым годом становится все меньше и меньше). Так и живем – в работе по уши. Чего и вам желаю!

[comp.prog.thoughts] Языки для быстрого и медленного программирования

Хочу развить комментарий тов.Skynin к заметке “Споры о языках программирования – не могу смолчать”:

...а я тут недавно сел, понадобилась утилитка работающая под "чистой" виндой, от вынь2к и выше, и что-то Си мне разонравился. Такие были хорошие воспоминания, и оказывается, на нем "крупу перебирать" хорошо, а не написать что-то непритязательное и быстро.
Тогда открыл VC++ - и вообще не понял ничего. Пока вывел строку wchar_t на экран...

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

На вершине холма стоят два быка – старый и молодой. Под холмом пасется стадо коров. Молодой бык говорит старому: “Давай мы быстренько-быстренько спустимся и вы*бем вон ту телочку!” Старый ему: “Нет…” Молодой опять: “Ну давай тогда мы быстренько-быстренько спустимся и вы*бем вон ту телочку!” Старый ему: “Нет…” Молодой снова: “Ну тогда давай мы быстренько…” Старый его прерывает: “Нет, мы сейчас спокойно, не торопять, спустимся, и вы*бем все стадо!”

Все молодые программисты, которых я видел, грешат одним и тем же: бросаются махать шашкой писать код не подумав толком что, как и зачем. Я и сам таким был. Это, наверное, нормальное явление – в молодости сил много, опыта мало, гормоны голос разума заглушают. У многих с возрастом и с проведенными в отладке и переделке ночами набитыми шишками это проходит. И это хорошо. Но сейчас я не об этом.

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

Первая группа не то, чтобы провоцирует быстрое программирование, но очень лояльно к нему относится. Это такие языки, как Pascal, Visual Basic, Java, Ruby, Python, D, Scala (наверное, в эту же категорию попадают и OCaml с F#, но не буду настаивать). Их характерными чертами являются:

• отсутствие серьезных требований к знаниям языка программирования и его особенностей со стороны разработчика для получения работающего варианта программы;
• отсутствие серьезных трудностей в поиске причин возникновения ошибок. Т.е., если программа, скажем, обратилась по нулевому указателю или вышла за пределы какого-то массива, то программист сразу об этом узнает – или в виде подробного стек-трейса, или в виде точного адреса, по которому элементарно определяется место возникновения ошибки. Т.е. эти языки бьют по рукам сразу и не больно;
• многие из них предоставляют программисту возможность писать мало кода за счет различных видов “синтаксического” (и не только) сахара: автоматический вывод типов или динамическая типизация, foreach вместо циклов, лямбда-функции и пр.;
• практически все они освобождают программиста от целого ряда проблем, как то: ручное управлению памятью, несовместимые компиляторы, разные системные API на разных платформах и т.п.;
• для ряда из этих языков доступно большое количество уже готовых библиотек хорошего (на первый взгляд) качества на все случаи жизни. Иногда прямо в комплекте стандартной поставки.

Все это ведет к тому, что ужаленный в жопу загоревшийся идеей программист может сходу налабать что-нибудь работающее на Java/Scala/Ruby/Python, потратив 15 минут на изучение синтаксиса языка + 20 минут на чтение краткого описания библиотеки + 30 минут на набор текста и исправление нескольких ошибок (утрирую, но смысл точен). И, что характерно, решение получится действительно работающее. И не суть важно, что работающее медленно, отжирающее всю память, и с кучей постоянно возникающих ошибок. Важно, что результат есть.

Вторая группа языков (C и C++ в первую очередь) не препятствует ковбойскому быстрому программированию, но очень сильно и больно мстит программисту за это. Написали быстро программу с проходом по повисшему указателю или с выходом за пределы массива – получили периодические непредсказуемые падения и недели (в лучшем случае) увлекательной и изматывающей охоты за такими ошибками. Быстренько навставляли в программу классов из STL (стали возвращать std::string/std::vector и Co из функций по значению или передавать в параметрах по значению) – получился тормознутый и прожорливый монстр, много хуже, чем слепленный на Java аналог.

С языками из второй группы нужно быть очень осмотрительными. По минному полю болоту быстро бегать не принято. Зато если спокойно сесть, прикинуть маршрут, провести небольшую разведку – то все можно сделать красиво и аккуратно. С минимумом жертв и максимумом результата.

Ну и третья группа – это языки, которые не позволяют писать быстро. Они расчитаны на медленное, очень спокойное и вдумчивое программирование. В первую очередь, это язык Eiffel (а так же Ada, но на Ada я не программировал). Удивительно, но на Eiffel не получиться писать быстро (и мало) даже при очень большом желании. Тотальная объектная ориентированность + Design By Contract + принцип разделения command и query + особенности синтаксиса = мы сейчас спокойно, не торопясь, спустимся и…

Не знаю, будет ли это сюрпризом для читателя или нет, но при работе на Eiffel можно получать такие же минималистичные и эффективные решения, как на C++. При этом программист находится в твердой уверенности, что в его программе очень мало ошибок. Но кода будет написано на Eiffel-е, как минимум, в два раза больше, чем на C++.

Чтобы проиллюстрировать свою мысль о быстром и медленном программировании, покажу несколько примеров кода для решения одной несложной задачи. Вот ее решение на языке D 1.0 и на языке Nice (симпатичный язык для платформы JVM, по почивший к сожалению). Для людей, знакомых с C-подобными объектно-ориентированными языками в них не будет ничего особо сложного для восприятия. Обычный код. А вот, для сравнения, та же самая задача, но уже решенная на языке Eiffel.

Объем кода на Eiffel, как минимум, в два раза больше объема кода на других языках. Соответственно, и писал я его гораздо дольше (правда, нужно отметить, что большого опыта в Eiffel у меня не было и библиотеки у Eiffel-я специфические).

Такие вот три группы языков. Наверное, еще нужно сказать, что если язык допускает быстрое программирование, то при работе с ним возникает некий драйв/фан – ты спешишь переложить в код свои сумбурные мысли, код быстро пишется, программа быстро начинает дышать, ты чувствуешь ее пульс, ты видишь, как она отзывается на твои действия, это заводит тебя, ты распаляешься все больше… Ничего подобного нет в медленном программировании – там есть только скучное продумывание разных вариантов, учет всевозможных граничных условий, размеренное и неспешное кодирование с документированием… Рутина! Ну да, заработало с первого раза, ну да, делает то, что задумано, ну да, ошибки находятся раз в полгода… Но кайф-то где? ;)

Что еще характерно: по мере перехода из стадии “водка, лодка и молодка” в стадию “кино, вино и домино” мои языковые предпочтения серьезно меняются. Если еще лет пять назад я на Eiffel смотрел с ужасом, то сейчас думаю, что лучше было бы спокойно и не торопясь писать на Eiffel-е надежный код, чем пытаться бежать по минному полю делать это же, но на C++…

PS. Я не упоминал в тексте такие языки, как PHP, Perl, C# и Haskell, поскольку никакого опыта работы с ними у меня нет. Подозреваю, что PHP и C# точно попадают в первую группу. Perl, наверное, во вторую. Куда отнести Haskell – я даже не знаю.

[life.photo] Отлично пойманный момент: белка и коты

Найдена в блоге “Обратная сторона реальности”.

[comp.prog] Керниган об отладке

Отличная цитата из Брайана Кернигана об отладке программ к моей предыдущей заметке (я цитировал флейм на RSDN в котором обсуждалась нужность IDE и сторонники функционального программирования говорили, что они не пользуются отладчиками):

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

-Brian Kernighan,
The Elements of Programming Style

Или в моем переводе:

Каждый знает, что отладка в два раза тяжелее, чем написание программы в первый раз. Но если при ее написании вы были настолько искусны, насколько вы только способны, то как вы вообще сможете отлаживать ее?

Ну ёптыть, что тут скажешь? Керниган – он ведь не зря Керниган.

[comp.prog.flame] Не могу не процитировать

На RSDN ведутся две дискуссии, на мой взгляд, очень сильно оторванные от проблем производства ПО. Не могу отказать себе в удовольствии процитировать пару высказываний оттуда.

Первый флейм посвящен проблеме разработки ПО без использования IDE: Жизнь без IDE. В нескольких сообщениях там сквозит мысль, что если задача сложная (а не какой-нибудь monkey coding) и если инструмент подходящий (никак не меньше OCaml, в идеале Haskel), то IDE и не нужна вовсе. На что последовал совершенно замечательный ответ:

Ой вей, я вас прОсю.
Представь себе что Хаскел двинул в массы. Ну лет через 15 к примеру. Народ к тому времени будет учить его по книгам Хаскел за 24 часа для чайников.
А где мозгов и книги для чайников не хватит будут юзать performUnsafeIO или как его там. И будут либы написанные такими программистами. Бангалорскими. И во всем этом придется кому-то разбираться. К примеру юноше со взором горящим. Который еще молод и ему не дадут написать свою версию бангалорской библиотеки с гейшами и го. А гуры будут все говорить что ИДЕ оно ненужно. А молодежь будет охреневать. И невдомек ей будет что задачи стоящие перед ними и перед гурами разные. Кому-то писать прототип сложноалгоритмичной мегафичи. А кому-то поддерживать код в который превратилась мегфича после реализации доблестными бангалорцами. И молодешь будет плакать и жрать кактус, а гуры вести просранные разговоры о теплом ламповом звуке(С) аскетичных редакторов. И то что современные ИДЕ высокие частоты не тянут. Иващеблин.

Я вообще к чему. Микросхемки можно паять и на коленках, чего уж там. Но в промышеллном производстве пользуются немного другими технологиями.

Отлично сказано, респект автору. Очень по делу.

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

Второй флейм под названием “Noop – новый язык для JVM” вообще затронул много разных вопросов, но сейчас в нем очень активно доказывают, что Оберон – это отстой и каменный век. Что студентов обязательно нужно учить самым-самым передовым технологиям – функциональному программированию и, особенно, метапрограммированию. В рамках этой агитации прозвучала фраза (выделение мое):

Мне кажется твоей главное проблемой является научить студентов программированию. Причем научить так, чтобы они выйдя со студенческой скомьи могли бы быстро начать разрабатывать сложный, современный софт. А для этого они должны быть теоретически и практически освоить все современные парадигмы программирования.

Бред. Нельзя студента обучить программированию так, чтобы после окончания он мог быстро начать разрабатывать сложный, современный софт. (Если только речь не будет идти о корифеях типа Кнута и Вирта). И уж тем более в разработке сложного софта не обязательно знать все современные парадигмы программирования.

Плохо то, что подобный бред читают начинающие программисты, которые могут воспринять его за чистую монету. Да и какие-нибудь не сильно искушенные в программировании преподаватели тоже – почитают корифея от программирования VladD2 и решат давать студентам всего и понемногу.

PS. Кстати, еще об IDE и маразмах. В Dr.Dobb недавно была серия статей про внедрение в Nokia инструмента Tasktop. В одной из них, Integrating ALM: Lessons Learned Deploying Tasktop at Nokia, коротко освещается основная задача этого дела: сократить для разработчика время на переключения между задачами. Т.е. сидит человек в IDE, связанной с Tasktop-ом, работает над какой-то задачей (task-ом). Тут ему бах! и приходит распоряжение заняться правкой какого-то важного бага (новый task). Разработчик выполняет этот новый task, после чего хочет вернуться к предыдущему. И тут (фанфары!) Tasktop возвращает его IDE к тому виду, который был при работе над предыдущей задачей. Она какой подход у серьезных шараг – экономия на каждой секунде времени разработчика! :-/

[comp.prog.cpp.book] Книга “Скользкие места C++”

Общая информация:

Стефан К. Дьюхерст. Скользкие места C++. Как избежать проблем при проектировании и компиляции ваших программ. – М.: ДМК Пресс, 2006. – 264 с.: ил.

Английское название:

Stephen C. Dewhurst. C++ Gotchas. Awoiding Common Problems in Coding and Design, 2003.

Официальная аннотация:

Вы держите в руках руководство по тому, как не допускать и исправлять 99% типичных, разрушительных и просто любопытных ошибок при проектировании и реализации программ на языке C++. Эту книгу можно рассматривать также, как взгляд посвященного на нетривиальные особенности и приемы программирования на C++.

Обсуждаются как наиболее распространенные “ляпы”, имеющиеся почти в любой программе на C++, так и сложные ошибки в использовании синтаксиса, препроцессора, преобразований типов, инициализации, управления памятью и ресурсами, полиморфизма, а также при проектировании классов и иерархий. Все ошибки и их последствия обсуждаются в контексте. Подробно описываются способы разрешения указанных проблем.

Автор знакомит читателей с идиомами и паттернами проектирования, с помощью которых можно решать типовые задачи. Читатель так же узнает много нового о плохо понимаемых возможностях C++, которые применяются в продвинутых программах и проектах. На сайте http://www.semantics.org можно найти полный код примеров из книги.

В книге рассказывается, как миновать наиболее серьезные опасности, подстерегающие программиста на C++. Программисты найдут в ней практические рекомендации, которые позволят им стать настоящими экспертами.

Издание предназначено для всех программистов, желающих научиться писать правильные и корректно работающие программы на языке C++.

Что из себя представляет книга:

Книга является сборником из 99 советов, разбитых на 9 глав:

• Глава 1. Основы (такие советы, как “Избыточное комментирование”, “Магические числа”, “Глобальные переменные” и т.д.)
• Глава 2. Синтаксис (например, “Не путайте массивы с инициализаторами”, “Неопределенный порядок вычислений”, “Помните о предшествовании”,…)
• Глава 3. Препроцессор (“Определение литералов с помощью #define” и др.)
• Глава 4. Преобразования (“Преобразование посредством void*”, “Срезка” и др.)
• Глава 5. Инициализация (“Не путайте инициализацию и присваивание”, “Правильно выбирайте область видимости переменной” и др.)
• Глава 6. Управление памятью и ресурсами (“Различайте выделение и освобождение памяти для скаляров и для массивов”, “Контроль ошибок при выделении памяти” и др.)
• Глава 7. Полиморфизм (“Кодирование типов”, “Невиртуальный деструктор базового класса” и др.)
• Глава 8. Проектирование классов (“Интерфейсы get/set”, “Константные и ссылочные данные-члены” и др.)
• Глава 9. Проектирование иерархий (“Массивы объектов классов”, “Не всегда один контейнер можно подставить вместо другого” и др.)

В каждом совете рассматривается конкретная проблема – формы ее проявления и последствия, даются рекомендацию по ее обходу и/или устранению.

Коротко об авторе книги:

Стефан К. Дьюхэрст был одним из первых пользователей языка C++ в компании Bell Labs. За его плечами более 18 лет опыта применения C++ к таким задачам, как проектирование компиляторов, торговля производными ценными бумагами, электронная коммерция и встраиваемые телекоммуникационные устройства. Он соавтор книги “Programming in C++” (Prentice Hall, 1995), автор-редактор в журнале “C/C++ Users Journal”. В прошлом он так же вел колонку в журнале “C++ Report”. Кроме того, Стив разработал два компилятора для языка C++ и написал многочисленные статьи о проектировании компиляторов и технике программирования на C++.

Мое впечатление:

Отличная книга. Точно из разряда must read для C++ программистов. В особенности, для начинающих программистов. Поскольку начинающие С++ники регулярно и неизбежно умудряются опробовать большинство этих проблем на собственном печальном опыте. Но и для опытных программистов в книге, я уверен, найдется достаточно нового.

Книга хороша именно тем, что в ней в одной собрано столько подводных камней C++. Пожалуй их все можно найти и в книгах других авторов (Страуструпа, Саттера, Александреску, Мейрса), но по всего по несколько штук у каждого из авторов, а здесь они сконцентрированы в одном месте.

Что не понравилось, так это отвратительное качество именно русского издания. Множество опечаток и ошибок в тексте. Даже на задней обложке написано: “Стефен К.Дьюхэрст были одним” – т.е. Стефен вместо Стефан и ‘были’ вместо ‘был’. Не удивительно, что в тексте ситуация не многим лучше.

[comp] Ноутбук с четырьмя(!) экранами

Да, вот такая вот концептуальная хреновина от Intel:

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

[comp.prog] Fossil – минималистичная распределенная система контроля версия + bug tracking + wiki

Никогда раньше о ней не слышал, но оказалось, что SQLite использует Fossil для хранения своих исходников. Тогда как Fossil использует SQLite для хранения своей информации :)

Подробно не разбирался с Fossil, т.к. не являюсь поклонником распределенных систем контроля версий. Но вот что поразило – это всего один исполняемый файл (под Windows порядка 800Kb). Инсталляции не требует. Достаточно просто поместить его в PATH.

Кроме системы контроля версий в этот исполняемый файл входит так же и HTTP сервер, который обеспечивает и управление репозиторием через Web-интерфейс, и bug tracking, и wiki. И все это в 800Kb! Внушаить!

В общем, если кто-то ищет простую систему для ведения своего проекта, то имеет смысл плотно посмотреть на Fossil. Тем более, что Fossil работает и под Windows, и под Linux, и под MacOS.