to post messages and comments.

← All posts tagged dev

Из programmers.stackexchange.com

Let's take JavaScript for example. (I worked on the original versions of JScript at Microsoft from 1996 through 2001.) The by-design purpose of JavaScript was to make the monkey dance when you moused over it. Scripts were often a single line. We considered ten line scripts to be pretty normal, hundred line scripts to be huge, and thousand line scripts were unheard of. The language was absolutely not designed for programming in the large, and our implementation decisions, performance targets, and so on, were based on that assumption.
Хороший ответ на тему почему языки со статической типизацией обычно лучше языков с динамической типизацией на больших объёмах кода.

Знаете, почему и через 10 лет мы будем писать на С++, а не на каком-нибудь другом языке? Потому что современные компиляторы С++ оптимизируют так, что диву даёшься. Например, bit.ly
Я пытался обмануть компилятор так, чтобы он не оптимизировал пробрасывание временного значения в функцию bar. Что из этого вышло — сами видите.

Ну, и раз зашёл разговор про чтиво, вот вам великолепное и очень смешное эссе про системных программистов: research.microsoft.com
Например, цитата оттуда: "I had the modest goal of translating a file read into a network operation, and now my machines have tuberculosis and orifice containment issues. Do you see the difference between our lives? When you asked a girl to the prom, you discovered that her father was a cop. When I asked a girl to the prom, I DISCOVERED THAT HER FATHER WAS STALIN.”

В #2599052 велось здоровое обсуждение того, как технологии создания программных продуктов не прогрессируют с 60-х. @dk назвал это "алгеброй", которая плохо справляется с современными задачами.
Оставим обсуждение алгебры этому прекрасному треду и поговорим о философии программирования, которая тоже не меняется с середины прошлого века. Программированием правит утилитаризм. "Premature optimization is a root of all evil" — говорит нам старина Кнут, и мы вспоминаем о производительности только тогда, когда уже поздно. 50-кратное падение производительности? Да пофиг, будем писать на Python в 3 строки! 4 гига оперативы ушло в никуда? Да пофиг, зато мой pure functional язык позволяет мне выражать мысли монадами!
Здесь же недавно обсуждались невероятные тормоза LibreOffice при прокрутке документа с SVG. На персональных компьютерах 2013-го года. Мне особенно больно это слышать, потому что я почти 4 года проработал над офисным продуктом, который изначально затачивался под мобильные устройства. Excel, который работает на мобильном 20 мегагерцовом процессоре. Word, который в памяти занимает меньше, чем документ, который вы открываете. Но пришло время айфонов и ипадов, и я лично наблюдал, как деградировал продукт, когда снимались определенные ограничения. На первом iPad можно было легко откушать до 64 метров памяти без риска быть убитым, это было роскошью, приложение летало. К появлению iPad Retina приложение уже хотело под 300 метров в определенных случаях, а на первом iPad тормозило. Аналогичная деградация наблюдалась в Android версии. Изначальный лимит в 16 мб для поддержки слабых андроидофонов был вскоре забыт, основная разработка велась под Android-планшеты, которые могли поспорить в производительности со слабенькими персоналками. К чему это привело вы все сможете посмотреть в Android 4.4 KitKat, в ванильной поставке должен быть тот самый офис.
Виновата философия программирования, которая сделала создание программных продуктов чисто утилитарным действием. Программирование сегодня — это как написание картин для того, чтобы дырку в стене закрыть. Модернизация "алгебры" этого процесса приведёт лишь к тому, что качество картины будет выше с точки зрения ее возможностей висеть на стене и прикрывать дырку. А вот что делать, чтобы программирование стало искусством, а не ремеслом? Или такая возможность безнадёжно утеряна?

dev

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

Похоже, я не писал в жуйк о чудесном эксперименте с сортировкой флоатов, который я когда-то проводил. Предлагаю провести его и вам(@SannySanoff, например, тебе). Итак, основа для эксперимента — задачка с Ponder This: domino.research.ibm.com
Если очень кратко: представьте, что вы стоите в саду на плоскости, в точке 0,0. В каждой точке с целыми координатами растёт дерево определенного радиуса. Сам сад тоже имеет радиус — 9801, за пределами сада деревья не растут. Начиная с определенного радиуса деревьев вы не сможете увидеть край сада. Нужно определить радиус, начиная с которого это произойдёт.
Но я хотел рассказать о подзадаче, которая может возникнуть при решении в лоб. Для определённого радиуса деревьев для каждого дерева(если забить на остальные деревья) у вас есть угол, начиная с которого дерево блокирует зрение, и угол, начиная с которого дерево больше ничего не блокирует. Подзадача: для каждого дерева в первой кварте (половина первой четверти) построить пары таких флоатов и затем лексикографически эти пары отсортировать. Пар должно быть около 40 миллионов.
Интересны результаты для разных языков, если писать в лоб и использовать стандартные фичи. С++ очень шустр, требует мало памяти (около 300мб, ЕМНИП). СPython помедленней, но ест тоже совсем чуть-чуть, 500-600мб. PyPy намного быстрее CPython, но и памяти съедает больше гига. OCaml съедал два гига. Другая OCaml версия с чьей-то помощью приближалась к Python по потреблению памяти, обгоняя его по скорости. Java версия сжирала 4 гига, работала очень медленно. А если VM ограничить по памяти, то вообще ооочень медленно. Благодаря помощи джавистов удалось загнать Java в рамки 2-х гигов, но качество кода пострадало. Haskell версию заставить нормально работать я не смог, падала по памяти. JS версия тоже не пережила такие запросы по памяти.
Теперь дополнительно, по выразительности по версиям, которые показывали максимальную производительность при минимальном потреблении памяти:
1 место — Python. Никаких оптимизаций проводить не понадобилось. Сортируем стандартные таплы, получаем малое потребление.
2 место — С++. Никаких оптимизаций проводить не понадобилось. Сортируем пары, получаем скорость и малое потребление.
5 место — Java. Пришлось отказаться от использования стандартных средств языка для работы с парами как с объектами.
8 место — OCaml. После оптимизаций код на OCaml стал больше походить на С, чем на функциональщину.
Обратите внимание на отсутствие 3,4,6 и 7 места. Это из-за разрыва в читабельности. Вывод: Python и C++ — офигенные языки, в которых выразительность не принесена в жертву memory footprint, а в случае с С++ — и скорости. Функциональные языки очень расстроили своим непредсказуемым потреблением памяти. Java удивила тем, насколько простая задача может требовать ручных оптимизаций.
Если кто считает, что я не прав — пишите программы, сравнивайте. Буду рад почитать.

Наконец-то заопенсорсил свою прекрасную утилиту для мержа Xcode проектов: github.com
Кто хоть раз пытался замержить Xcode проект тулзами для мержа текстовых файлов знает, насколько это неприятная вещь. Эта утилита мержит Xcode проекты по возможности автоматически, без участия пользователя. Год назад, когда писалась тулза, аналогов не было. Важные моменты:
* Кроссплатформенная. А не только под макосью.
* Читает и пишет Xcode проекты в OpenStep plist формате. CocoaPods, это плевок в вашу сторону. Брать пользовательский файл в OpenStep формате и пересохранять его потом в XML? Вы представляете, как это потом мержить, если вдруг?
* Чтение и запись файла без его изменения должны давать в результате тот же самый файл. Побайтово. Т.е., прогон через тулзу не добавит никаких лишних пробелов, не потеряет комментарии. Тулза старается редактировать файлы так, как их редактирует Xcode.
* У Xcode иногда бывают тяжелые дни и он меняет Xcode проект просто так. Тулза достаточно умная, чтобы распознавать такие ситуации. Это значит, что вам не нужно будет мержить проекты из разных веток, когда вы ничего не меняли, а Xcode все же решил что-то поменять.
* Тулза тестировалась на очень сложных и развесистых проектах. Но она всё еще бета. Используйте на свой страх и риск :)

После того, как поменял место проживание в LinkedIn на Bay Area, стали сыпаться предложения от кучи разных местных компаний. И что я вам скажу — украинские рекрутёры в подметки не годятся западным, нашим расти и расти еще. Все сообщения чёткие, направленные, бывают даже интересные.
Поток сообщений от украинских компаний почти иссяк. Но всё равно порою предлагают поработать Lead Python Developer где-нибудь в Одессе. Наивные :)

Занятная статья по С++: bartoszmilewski.com
Очень понравилось сравнение c Эдвардом-Руки-Ножницы — Edward-C++-Hands. Программисты на С++ справляются с большими количеством задач легко и непринуждённо. Но некоторые вещи делать опасно, как, например, Эдварду-Руки-Ножницы опасно обнимать девушек.

Чтобы успеть к дедлайну PA6 пришлось сразу после яхты, перелётов и поездов устроить себе нон-стоп кодинг марафон на 16 часов. В результате было дописано 2500 строк довольно сжатого кода.
Парсер будущего компилера занимает 3100 строк, переписан на функциях, биндах и лямбдах, минимизировано количество исключений. Почти до самого конца удавалось держать функции pure, но из-за особенностей стандарта в условиях ограничений времени пришлось этим пока поступиться.
Вывод: я всё больше и больше люблю С++11. Но он всё больше и больше меня пугает.

В продолжение темы #2432930 . Наткнулся на старое: alarmingdevelopment.org
Цитата оттуда:
"A lesson I have learned the hard way is that we aren’t smart enough. Even the most brilliant programmers routinely make stupid mistakes. Not just typos, but basic design errors that back the code into a corner, and in retrospect should have been obvious. The human mind can not grasp the complexity of a moderately sized program, much less the monster systems we build today"
Истинная правда. Сколько бы не было у меня опыта разработки и дизайна ПО, я продолжаю ошибаться. Ну, что ж, ошибками выстелена дорога к мудрости

Добил всё же PA4. Давно я так много не думал и не тратил столько времени на простые с виду задачи. В голове шумно, новые знания интенсивно пробиваются в мозг. Вывод: это один из лучших программерских курсов что я пробовал. Будет жаль, если я не успею по дедлайнам(например, PA5 нужно сделать до 14-го) и не смогу продолжать.
Еще один вывод: здесь лучше переписать всё с нуля, а не пытаться починить мёртвое. 1500 строк кода я писал неделю. Если бы начал заново, когда их было только 700, закончил бы раньше, а код был бы в 10 раз лучше.

Человеки, которые писали emscripten, большие молодцы. Умудрился часа за 4-5 портировать часть большого С++ проекта в JS. Даже под Android с его Native Development Kit я провозился несколько дней (хотя в итоге у меня и работал там весь UI, а не только proof of concept как в вебе). Все тулзы работают неплохо, хоть и приходится порою юзать Google дабы обойти ту или иную ошибку.
Из минусов — я так и не научился генерить производительный код. Генерация в asm.js и -O2 помогают, но не кардинально
Вердикт: можно юзать уже сейчас и даже стартовать проекты. К моменту релиза браузеры подтянутся и наконец смогут это относительно быстро запускать. Но работать так же быстро, как и нативный код, вряд ли будет. Так что от standalone никуда не деться. И это хорошо!

Перед тем, как уехать в кругосветку, я настроил хук в Mercurial, который делал снимок веб-камерой на каждый коммит в репозиторий. После полугода путешествий вы можете наблюдать результат. Не забудьте включить звук, там прекрасная песня на фоне.
Как видите, ответ на вопрос "Откуда я беру деньги на путешествия?" довольно прост — я работаю в дороге, в любом состоянии и в любое время.
i.juick.com

"Любую ценность контролирует лишь тот, кто в состоянии её уничтожить"(Фрэнк Герберт, Дюна). Эту цитату нужно вытатуировывать начинающим Object-Oriented программистам на каком-нибудь хорошо заметном месте