[comp.prog.thoughts] Цитаты из интервью Брайана Кернигана

Брайан Керниган недавно дал интервью в серии “A-Z of programming languages”. Позволю себе перевести несколько цитат оттуда.

Типичный программист сегодня тратит много времени просто пытаясь выяснить, какие методы следует вызвать из некоторого огромного пакета и, вероятно, нуждается в какой-то IDE вроде Eclipse или XCode, чтобы справиться с этим. Сейчас используется больше языков и программы зачатую содержат комбинации из нескольких языков. Все это усложняет жизнь, но несмотря это сейчас возможно быстро создать весьма впечатляющие системы, если все идет нормально.

Вот это -- “если все идет нормально” мне очень понравилось. Очень точно подмечено. Сейчас столько симпатичных и привлекательных готовых компонентов. Кажется, что просто возьмешь, поставишь к себе и все заработает. И ведь работает! До тех пор, пока не натыкаешься на какую-нибудь нештатную ситуацию или на тебя не падает какое-то неожиданное требование. Тут-то случается приплыздец. Хорошо, если сторонний компонент с исходниками и лицензия позволяет его модифицировать…

В ответе на вопрос, что он может посоветовать начинающим программистам, Керниган сказал:

…способ научиться программировать – это написать код, переписать его, посмотреть, используется ли он, и переписать опять. Чтение чужого кода так же бесценно. Конечно, это подразумевает, что код хорош; я не вижу много пользы от чтения больших объемов плохого кода, разве что научиться не писать так. И никто, разумеется, не должен писать плохой код сам. Это легче сказать, чем сделать, вот почему я так подчеркиваю переписывание кода.

Здорово. Чем-то напоминает “совершенство – это не когда нечего добавить, а когда нечего отнять”.

Спасибо ув.тов.googledictionary за найденую в первом варианте перевода ошибку.

[comp.prog] Небольшой рассказ об опыте применения Scala в реальной жизни

На сайте языка Scala появилась информация о презентации некого Lee Momtahan про опыт использования Scala в Électricité de France Trading. Там же даны ссылки на слайды доклада, и на видеозапись доклада. Желающие могут ознакомиться с этими материалами самостоятельно, для остальных я расскажу вкратце своими словами.

Итак, Lee Momtahan со товарищи занимается разработкой приложения для моделирования методом Монте-Карло различных трейдинговых ситуаций. Оно производит вычисления на гриде из нескольких сотен компьютеров, плюс содержит GUI и специализированный внешний DSL для того, чтобы эксперты могли задавать различные условия моделирования.

Приложение разрабатывается в течении семи лет, командой из шести человек. Объем приложения – более 300K строк. До декабря 2008 года приложение разрабатывалось на Java, но затем команда решила попробовать Scala. И ей это понравилось. В основном за счет компактного синтаксиса, инфиксных операторов, паттерн-матчинга и замыканий. Все это позволяло разработчикам записывать сложные математические конструкции гораздо проще, чем на Java.

Очень важным, по словам Lee Momtahan, фактором является работа на платформе JVM и отличная интероперабельность с уже существующими Java-библиотеками. Он даже подчеркнул, что использование Java библиотек из Scala оказывается гораздо более простым делом, чем использование Java библиотек из Java.

Похоже, что транслятор их собственного DSL написан полностью на Scala, т.к. подчеркивается что с помощью отличной библиотеки комбинаторных парсеров (parser combinator library) в Scala исходный текст парсера был очень похож на BNF-грамматику. Часть транслятора была сделана в чисто функциональном стиле, но при добавлении поддержки макросов использовался императивный стиль (т.к. с его помощью получалось более простое решение).

Скорость работы всего приложения их устраивает. Мол, благодаря библиотеке Colt из CERN, они достигли производительности, сравнимой с C++.

В общем, им понравилось. И они считают Scala вполне пригодным языком для создания приложений, от которых зависят серьезные суммы денег (ну а чего не сказать, они же не самим трейдингом занимаются, а его моделированием – прим.eao197).

Добавлю так же, что по словам докладчика часть людей из проектной команды ранее уже была знакома с функциональным программированием. Сам докладчик сказал, что его производительность на Scala составила порядка 2KLoC за 6 месяцев. И что Scala позволяет писать в несколько раз меньше кода, чем Java.

Теперь пару слов без протокола :) Во-первых, эта история мне понравилась тем, что по-моему внедрение Scala сейчас именно так и должно происходить – был старый Java проект, который изрядно задолбал разработчиков. Захотелось более современного инструмента и пожалуйста – берется Scala. И старый код переиспользуется, и новый удобно писать.

Во-вторых, что-то я в последнее время фигею от производительсности западных программистов. То на SPARK-е за 9 месяцев работы написали 10KLoC, теперь вот здесь 2KLoC за 6 месяцев, а до этого 300KLoC за 7-мь лет вшестером. Я тут с мая месяца уже почти 30KLoC C++ кода наклепал… Может я что-то не так делаю? ;)

[life] Фотография напомнила фильм “Район №9”

Глядя на эту фотографию:

в очередной раз убеждаешься в том, что фильм “Район №9” документальный, а фантастические персонажи были добавлены туда только для облегчения прохождения цензуры.

[life] Любая деятельность интересна в течении примерно пяти лет?

Из ответов Дмитрия “Гоблина” Пучкова читателям газеты “АиФ”:

Вопрос: Дмитрий Юрьевич каковы Ваши творческие планы на длительную перспективу?
Нравится ли Вам самому то чем занимаетесь, я имею ввиду переводы фильмов и игр?

Ответ: В настоящее время занят переводами фильмов для проката и переводом мультфильмов для ТВ. Заметил, что любая деятельность интересна в течение примерно пяти лет – далее достигаешь предела своих способностей на данном участке, а затем интересы переключаются на что-то другое. Сейчас мне интересно переводить, растёт уровень знаний и умений, переключаться на что-то другое явных позывов не ощущаю. Ну а что будет дальше – будет понятно дальше.

(выделение мое)

Наверное, это сильно индивидуально. Может быть Дмитрий Пучков по жизни человек такой, чем ему однообразие надоедает (еще одна цитата оттуда: “Прежде чем стать переводчиком, Дмитрий Пучков успел сменить профессии таксиста, шлифовщика, кузнеца, слесаря, сантехника, электрика, кинолога, библиотекаря, помощника бурильщика, инженера-гидрогеолога и даже старшего оперуполномоченного уголовного розыска.”)

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

В конце-концов пишут же художники картины до глубокой старости. И вовсе не от того, что вынуждены это делать.

[comp.prog] Интересная фича новой версии DMD – вывод информации о программе в формате JSON

Свежая версия компилятора DMD, 1.050 и 2.035, содержит ключ –X – генерация JSON-файла вместе с компиляцией объектного кода.

Допустим, у нас есть простая программка:

module hello_world;

import std.c.stdio;

class HelloWorld {
  public void sayHello() {
    printf( "Hello, World!\n" );
  }
}

int main() {
  auto greeter = new HelloWorld();
  greeter.sayHello();
  return 0;
}

Запускаем dmd с ключиком –X и получаем JSON-файл следующего содержания:

{
  "name" : "hello_world",
  "kind" : "module",
  "file" : "my_hello_world.d",
  "members" :
  [
    {
      "name" : "HelloWorld",
      "kind" : "class",
      "line" : 5,
      "base" : "Object",
      "members" :
      [
        {
          "name" : "sayHello",
          "kind" : "function",
          "type" : "void()",
          "line" : 6
        }
      ]
    },
    {
      "name" : "main",
      "kind" : "function",
      "type" : "int()",
      "line" : 11
    }
  ]
}

(форматирование я чуть подправил, чтобы лучше воспринималось).

Имхо, очень полезная штука для разных инструментов – начиная от IDE и заканчивая всякими анализаторами и генераторами кода (например, для сериализации/десериализации). Штука эта пока не законченная, сам Брайт признается, что пока не знает точно, что именно нужно помещать в JSON описание. Плюс есть маленький баг – компилятор с ключом –X падает, если в файле нет директивы module. Но это явно временные недостатки.

В общем, в очередной раз возникает вопрос – неужели из D так ничего хорошего и не получится?

[comp.prog] Продолжается серия интервью “The A-Z of Programming Languages”

В журнале http://www.computerworld.com.au продолжается публикация интервью в серии “The A-Z of Programming Languages”. Сейчас эта серия включает в себя:

Larry Wall: Perl
Don Syme: F#
Simon Peyton-Jones: Haskell
Alfred v. Aho: AWK
S. Tucker Taft: Ada 1995 and 2005
Microsoft: ASP
Chet Ramey: Bash
Bjarne Stroustrup: C++
Charles H. Moore: Forth
Don Woods: INTERCAL
Stephen C. Johnson: YACC
Steve Bourne: Bourne shell
John Ousterhout: Tcl
Giancarlo Niccolai: Falcon
Luca Cardelli: Modula-3
Walter Bright: D
Brendan Eich: JavaScript
Anders Hejlsberg: C#
Guido van Rossum: Python
Prof. Roberto Ierusalimschy: Lua
Joe Armstrong: Erlang
Rich Hickey: Clojure
Martin Odersky: Scala
Guillaume Laforge: Groovy
Новая публикация --> Brian Kernighan: AWK and AMPL
Новая публикация --> Tom Igoe: Arduino

По мере обнаружения новых интервью, ссылки на них я буду добавлять в данный пост.

[life] Маразм крепчал: поленились прочесть инструкцию – разбили самолет

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

Хотя, по большому счету, пофигу, кто именно разбил самолет -- покупатели или инженер Airbus-а. То, что это произошло по вине инженера Airbus-а придает истории даже больший трагизм. Уж если производитель самолета не может с ним управиться...

Оригинальная цитата:

Арабская команда оттаксировала самолёт к площадке, где проводятся испытания турбин, и... при совершенно пустом самолёте врубили все четыре турбины на полную мощность в режиме взлёта. Поленившись ознакомиться с Инструкциями по пользованию, абу-дабцы понятия не имели, насколько лёгок А340-600, почти не загруженный топливом, без пассажиров и багажа.

Когда турбины были разогнаны на всю катушку, в пилотской кабине со страшной силой взревела сирена, предупреждающая об ошибочно выбранном режиме: бортовые компьютеры решили, что пилоты пытаются совершить взлёт в то время, как параметры самолёта не сконфигурированы по топливу и нагрузке, а закрылки, элероны, хвост и проч. не приведены в положение, требуемое для взлёта. Чтобы избавиться от назойливого рёва сирены, один из пилотов потянул рычаг выключения размыкателя, ответственного за Ground Proximity Sensor (устройство, распознающее наземные препятствия, мешающие взлёту).

После этого самолётные компьютеры окончательно решили, что самолёт идёт на взлёт — пилоты понятия не имели, что они отключили устройство безопасности, не позволяющее взлетать/приземляться с включёнными тормозами.

Здесь вся история целиком и с картинками.

А вот и прояснение ситуации:

Да, именно инженер Airbus и дёргал ручки. Представители заказчика только наблюдали за процессом. Было проведено расследование и опубликован отчёт: http://www.bea.aero/docspa/2007/f-cj071115/pdf/f-cj071115.pdf В пункте 1.5.1 указаны люди, находившиеся в кабине в момент инцидента. В правом кресле сидел инженер Airbus. При этом только он по регламенту мог управлять самолётом (см. пункт 1.5). Представители заказчика (Abu Dhabi Aircraft Technologies) могли только наблюдать за происходящим. В 15:58 начали проводить тесты двигателей. При этом инженер Airbus поставил тягу на все четыре двигателя, хотя обычно они тестируются парами по очереди. В то же время, наземный персонал забыл поставить башмаки под колёса (и дальнейшее расследование показало, что это случалось и до этого). В 16:02 представитель ADAT в левом кресле заметил движение самолёта. Инженер Airbus вместо того, чтобы сбросить тягу, начал оттормаживать и выкручивать переднее колесо. Самолёт врезался в стену. Всё это время представитель ADAT не вмешивался в ситуацию (см. пункт 2.2) как ему и полагалось (см. пункт 2.3). В заключениях вина представителя заказчика (ADAT) никак не указана. Виновны наземные инженеры, забывшие про башмаки, и инженер Airbus, управлявший авиалайнером в правом кресле. Причём тут арабы? Всё, что написано выше, - просто фантазия на тему произошедшего.

PS. Найдено в Тупичке Гоблина.

PPS. Почему-то вспоминается афоризм: можно написать программу, которой сможет пользоваться даже дурак, но только дураки станут ей пользоваться. Видимо, создатели Airbus-а достигли больших успехов в создании систем, которыми смогут пользоваться даже дураки.

[comp.prog.thoughts] Причины шума вокруг функционального программирования

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

По поводу шума вокруг ФП у меня в последнее время вот какая теория.

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

Ура! Все толпой в ООП!

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

Однако время шло. Выросло новое поколение программистов, которое начинало учиться сразу на ООП. Что такое структурное программирование и функциональная декомпозиция сейчас мало кто знает и/или помнит. Везде ООП – и где нужно, и где не нужно. Как обойтись без ООП знают не многие. Даже на C программируют с использованием ОО идей о полиморфизме и инкапсуляции (сам видел примеры такого кода в OpenSSL и gSOAP).

Соответственно, писать в ОО стиле некоторые задачи сложно, трудоемкость решений зашкаливает. А тут подворачивается что-то “новое и неизведанное” под названием ФП. Которое наглядно демонстрирует, что вот это и вот это в ФП решается гораздо проще и быстрее, чем в ООП. Ну и плюс шумиха вокруг multi-/manycores и concurrency: “Как! Вы все еще кипятите выискиваете баги в shared memory из-за side effects?! Тогда мы идем к вам!”

Ура! Все толпой в ФП!

---

Естественно, что все это утрирование и передергивание. Современное ФП – это далеко не структурное программирование середины 80-х годов. Но в плане декомпозиции задачи я честно не вижу принципиальной разницы между ФП и структурным программированием. А различия между декомпозицией в функциональном и объектном программировании были хорошо описаны в книге Бертрана Мейера “Объектно-ориентированное конструирование программных систем”.

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

Цитата из обсуждения на RSDN:

Всё, что ты делаешь (и я делаю, и кто-либо ещё делает в районе проектирования любых ЯП), направлено на уменьшение количества ошибок, допускаемых программистами.

Это единственная разумная точка зрения. "Мы все уменьшаем количество ошибок наших пользователей".

Не могу согласиться. Думаю, что основная цель разработчиков языков программирование – уменьшение количества работы программиста. Количество ошибок – это уже побочный эффект.

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

[life] Пара впечатлений после прогулок дождливым днем

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

Вот например, замечали ли вы, что если на тротуаре есть две большие лужи и узкая полоска суши между ними, то с большой долей вероятности в самом узком месте этой полоски остановятся две необъятных размеров тетки для того, чтобы поболтать? Справедливости ради скажу, что раньше я такое поведение замечал только за женщинами (вне зависимости от возраста). Но в последние годы и молодые ребята стали перенимать эту привычку – видимо, мода на unisex не прошла даром.

Вчера, покупая мед, видел еще одно проявление этого феномена – палатка продавцов меда, в ней прилавок, у прилавка стали две тетки с открытыми зонтиками. Зонтики они держат не над головой, а почти за спиной, как панцири у черепах. И все. Ни войти в палатку, ни посмотреть, что стоит на прилавке. Зато им хорошо – над ними зонтики и палатка, ничего не капает, можно спокойно постоять и потрындеть… Жалко, не догадался заснять эту мини-крепость на мобильник.

По пути с работы на остановку попал под сильный заряд дождя. И понял, что беда на Руси всего одна – дураки. А дороги – это уже следствие первой беды. Дороги такие, потому, что дураки их строят.

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

А вот в бывшей Восточной Пруссии, где мне доводилось когда-то бывать, в старых районах Калининграда (бывшего Кенигсберга), все дороги (что проезжая часть, что тротуары) выпуклые. Т.е. в центре дорога выше, чем по краям. В результате, вода естественным образом стекает к краям, там образуются хорошие ручейки, стекающие в дренажную систему. Такая форма дорог в купе с основательной дренажной системой приводит к тому, что даже в самый сильный дождь в старых немецких кварталах нет ни грязи, ни луж.

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

[life] Нужно ли так любить деньги, чтобы нырять за ними в дерьмо?

Для начала старый анекдот:

Мужик лет пятидесяти стоит перед зеркалом и разглядывает себя: маленький, с большим животом, с волосатыми кривыми ногами, с тоненькими ручками, с проплешиной на голове…  Там же, в отражении, видна кровать, на кровати молодая, стройная, с шикарными формами блондинка. Мужик еще раз смотрит на себя, потом на нее, и задумчиво произносит: “Это же нужно так любить деньги…”

А теперь суть. Сегодня в передаче про разные чрезвычайные проишествия по НТВ показали сюжет на тему большой любви к деньгам: в Чернигове, в общественном туалете на вокзале, мужик уронил в унитаз крупную денежную купюру. И захотел достать. Засунул руку в дырку по плечо. Даже купюру нащупал. А вот извлечь руку уже не смог. Пришлось вызывать спасателей.

Для полноты картины: унитаз был примерно вот такой:

Все-таки выражение “Что упало, то пропало” вовсе не лишено здравого смысла.