Натолкнулся на сборник цитат Алана Перлиса Epigrams in Programming. Ну очень понравились. Не смотря на то, что написаны они были еще в 1982-м году, почти все они актуальны и сегодня. Всячески рекомендую для прочтения программистам.
Сбылась мечта идиота ;) Наконец-то приобрел эту потрясающую книгу.
Для тех кто не в курсе: „Структура и интерпретация компьютерных программ“ вышла в июле этого года на русском языке. К сожалению, тиражом всего в 1000 экземпляров и во всех магазинах она уже давно раскуплена. Однако не стоит отчаиваться, можно попробовать сделать где-нибудь заказ и подождать следующего завоза. По крайней мере у меня получилось.
Для тех, кто совсем не в курсе: SICP — одна из лучших книг по программированию из когда либо изданных. Прочесть ее от корки до корки — абсолютный MUST для любого уважающего себя программера.
Потрясает то, что эта книга — изначально всего лишь вводный курс по информатике в MIT. Метода для первокурсника, так сказать. Однако материал, который она охватывает, далеко не всегда вообще преподается в ВУЗе. Книга начинается с описания абстракции процедур и данных (рассматриваются функции высших порядков и даже символьная алгебра), плавно переходит к рассмотрению модульности, объектов и состояния (в частности: параллелизм, имитация цифровых схем, распространение ограничений). Затем начинается описание металингвистических абстракций (например, строится интерпретатор пролога, имитация ленивых вычислений, недетерминистское вычисление). А заканчивается книга вообще чудесно — строится эмулятор регистровой машины и пишется компилятор под нее.
Вот так надо учить программированию!
Безумно жалко, что 12 лет назад, когда я только начинал изучать программирование, я тратил время на всякую ерунду и на горьком опыте или путем долгих ковыряний в инете находил то, что в этой книге описывается „на пальцах“.
Не менее жалко, что во многих учебных заведениях также зачастую учат ерунде. На сколько бы увеличилось качество выпускников ВУЗов, если бы их на первом курсе учили по этой книге...
PS: также доступны видеозаписи лекций.
PPS: после того как прочту книгу для первокурсников, закажу себе книгу для второкурсников :)
UPD: можно попробовать купить SICP в издательстве.
Заметил интересную вешь. Практически вокруг любого языка программирования имеется свой культ. "С++ rulezzz", "LISP rulezz", "Haskell rulezzz", и т.д. Однако после продолжительного использования любого из "культовых" языков ощущение его культовости у меня проходит.
Каждый раз, сталкиваясь с культом, я вижу как люди торчат от того, что на некоем языке можно делать что-то, что было невозможно раньше. Я сам торчал от плюсовых темплейтов, лисповских макросов, хаскельной красоты (а также ассемблерной крутизны, окемловских first class functions, питоновского форматирования кода, Tk-ного описания интерфейсов, erlang-овского межпроцессного взаимодействия и много от чего еще).
Но со временем понимаешь, что бесплатного сыра не бывает. За любые фичи приходиться платить: остутствие типизации в лиспе, низкая производительность хаскела, связывание с legacy кодом, и т.д. Тут-то культ и торч проходит, а взамен ему приходит здравое понимание того, что для каждой задачи нужен свой инструмент (причем выбирать его надо в контексте проекта, а не одной задачи).
Интересно только, почему у многих людей культ и торч не проходят? Смотришь на некоторые посты и думаешь... пока еще думаю... :)
Почитал тут мега пафосный пост про то, что Хаскел - это Роллс-Ройс языков программирования.
Красиво, конечно. Хаскел - аристократический язык. Он не будет опускаться до серых нужд обычных людей :) Пока серые люди возятся со своими серыми языками, хаскел третий раз подряд выигрывает самое сложное соревнование в мире.
Смех сквозь слезы. Ведь действительно хороший язык. Только вот беда в том, что его действительно используют "аристократы" программирования. И мало что делается, чтобы превратить его в мейнстрим.
Для окемла есть потрясающая книжка Developing Applications With Objective Caml. А где такая книжка для хаскела? Куча введений в ФП c примерами a-la сферический конь в вакууме, описаний монад с очень "нужными" обычному программеру monad laws, куча разрозненных статей для Ph.D. people. А вот конкретного тьюториала для среднего программиста, с описанием разработки реальных приложений нет.
В итоге мы знаем, что хаскел крут, но не знаем как на нем сделать что-нибудь настоящее. С такими понтами хаскел рискует навсегда остаться уделом "аристократов". А ведь хочется применения его в мейнстриме.
Про окемл я могу сказать человеку, чем он крут и знаю, куда отослать человека для дальнейшего изучения. А как внедрять в массы хаскел? Как его самому-то изучать в конце концов :)
Возможно, многие уже видели и знают. Но приведу пару ссылок:
Записи докладов на КРИ - огромная куча очень интересных докладов.
Семинары на Chaos Constructions'2006 - кучка заметно меньше, но не менее интересна.
Наткнулся тут на очень интересный рассказ человека, ушедшего из MMORPG World of Warcraft.
Пара выдержек:
...Why did I leave? Simple: Blizzard has created an alternate universe where we don't have to be ourselves when we don't want to be. From my vantage point as a guild decision maker, I've seen it destroy more families and friendships and take a huge toll on individuals than any drug on the market today, and that means a lot coming from an ex-club DJ...
...Blizzard created a game that you simply can not win. Not only that, the only way to "get better" is to play more and more. In order to progress, you have to farm your little heart out in one way or another: either weeks at a time PvPing to make your rank or weeks at a time getting materials for and "conquering" raid instances, or dungeons where you get "epic loot" (pixilated things that increase your abilities, therefore making you "better"). And what do you do after these mighty dungeons fall before you and your friend's wrath? Go back the next week (not sooner, Blizzard made sure you can only raid the best instances once a week) and do it again (imagine if Alexander the Great had to push across the Middle East every damn week)...
Мне и до этого особенно не нравились все эти MMORPG. Теперь я понимаю, что производство таких игр имеет очень много общего с производством наркотиков.
Любая интересная игра захватывает и отнимает кучу времени. Но стоит задуматься: может ли человек выиграть, играя в твою игру? Получит ли он удовольствие или красные глаза?
Позиция Blizzard понятна - им невыгодно, чтобы человек прошел игру. Только вот человечно ли это?
На работе пришел к немного странному, на первый взгляд, решению: из окемловского приложения вызываю питовский код, который, в свою очередь, вызывает плюсовый. Казалось бы - что за изврат? Ан нет.
Логика игры, которую мы сейчас делаем (равно как и предыдущей игры) пишется на ocaml. Низкоуровневая работа с OSG, OpenGL, OpenAL и пр., ведется на С++. Окемловских байндиногв для OSG нет, есть питоновские. А писать окемловкие байндинги для С++ гимор тот еще.
В итоге, все плюсовые дела через boost::python (очень удобная библиотека, кстати) выводятся в питон. В питоне пишется тонкий слой, переводящий работу с объектами в примитивные функции. А в кемле написан небольшой код на полстранички, который позволяет легко и type-safe-но вытаскивать функцию из питона. Например:
let fun1 = f "module" "fun1"благодаря написанному ручками оператору
(type1 **-> type2 **-> ret_type)
(**->)определяет функцию
(f : type1 -> type2 -> ret_type)Ну где вы еще такое напишите, кроме окемла или хаскела :)
За счет этого, я с минимальными усилиями получаю из ocaml доступ к плюсовому коду.
Так что не бойтесь применения разных языков программирования в одном проекте. Это не так уж сложно и впридачу вы имеете возможность писать то, что надо, на том, на чем надо.
Маленький совет для тех, кто пишет окемловкие байндинги к плюсовым библиотекам.
Никогда! Запомните! Никогда не мешайте окемловские эксепшны с плюсовыми объектами. Из-за longjmp(), который вызывается внутри caml_failwith, caml_invalid_argument или caml_raise*, ни один деструктор плюсового объекта не будет вызван и вы получите memory leak.
Также не мешайте обработку плюсовых эксепшнов и вызов окемловских эксепшнов, т.к. плюсовые эксепшны - это те же классы с деструкторами. Т.е. в данном коде
try
{
bla-bla;
throw std::runtime_error( "oh, shit!" );
}
catch ( std::runtime_error& e )
{
caml_failwith( e.what() );
}
деструктор std::runtime_error не будет вызван и строчка "oh, shit!" навсегда останется в памяти. gcc пофиг на __attribute__ ((noreturn)).
Объекты отдельно, failwith отдельно. Запомните это, пожалуйста, и тогда вам не придется две недели анализировать логи mtrace или valgrind. Спасибо.
Все ненавидят рекламу. Залез в инет что-то найти - а там куча говна и ничего нужного. Как бороться с мигающей помойкой и "релевантной" гуглевской рекламой?
А очень просто. Есть две программы:
1. Ad Muncher - фильтрует рекламу в любой программе (т.к. перехватывает все обращения в инет и отрубает то, что попадает под рекламный фильтр, а фильтров у Muncher-a очень много). Программа платная, но кряк найти не проблема (хотя ЭТУ программу стОит купить).
2. CustomizeGoogle - дополнение к Mozilla Firefox, которое убирает ВСЮ текстовую рекламу из гугля, гмайла и прочих гуглевых служб. Программа бесплатная.
Даю гарантию, через пару дней Вы будете в ужасе от вида браузера других людей. А через полгода будете с удивлением говорить: "Фига, оказывается на этом сайте столько рекламы".
Короче, хватит читать - бегите скорее, устанавливайте себе и другим это чудо. И да будет с вами чистый инет.
Залез тут на Blogger и увидел, что гугль предлагает переключиться на обновленный вариант Blogger Beta - вроде как теги появились и прочие вкусности.
Переключился. И не смутился, что переключение безвозвратное. И не смутился, что Beta (Gmail ведь тоже Beta, однако работает). Только вот настолько все это сырое и глюкавое, что аж жуть берет. Теже функции, что и в обычном блоггере, почему-то работают через раз. Новые функции вообще через два. С горем пополам подправил темплейт, но сколько сил и времени на это ушло.
Короче, уважаемый Гугль - тестируйте, пожалуйста, свои альфы сами, а не силами ни в чем не повинных юзеров. Это свинство: заманивая пользователей новыми возможностями, заставлять их обкатывать свое сырое говно.
Нанять тестеров, вовсе не так уж сложно и дорого. Доверие пользователей, которое получает любая компания, производящая качественный продукт, стоит гораздо больше.
Делаю сейчас на работе новую игру (я для игровых автоматов пишу, если кто не в курсе). И вот думаю, как бы поудобнее логику сделать.
Предыдущую игру я сделал на основе Functional Reactive Programming (FRP от Conal Elliot). Оказалось очень даже ничего, только вот всплыли пара проблем: малая производительность (вся игра - один большой continuation, который каждый фрейм пересоздается заново, спасает только то, что игра не особо большая), и не совсем удобное описание логики в некоторых местах (причем, как грамотно описывать, сам пока не знаю).
Так вот - полез я посмотреть: какие-же продвижения в области FRP произошли за последнее время? И нашел я очень интересную статью, про Functional Hybrid Modelling. Моих вопросов оно не решает (хотя и дает некоторые направления). Но, в целом, крайне рекомендую для прочтения тем, кто хочет узнать, как надо делать симуляции физических и игровых систем.
Основная фича, которые придумали авторы - неявная связь между сигналами (signal relation), как основной строительный кирпичик. Т.е. мы больше не описываем, что из чего следует, а только описываем взаимосвязи. Из этих хреней можно автоматически выводить систему диффференциальных алгебраических уравнений (DAE), что является гораздо более мощным средством описания физических задач, нежели относительно низкоуровневые ODE.
Также эта хрень показывает верность моего старого предположения, что на ограничениях (constraints) можно строить практически любые системы. Ведь отношение (relation) - есть частный случай ограничения.
Конечно реализация всего этого пока что не просто хромает, а вообще отсутствует. Почитал отчет их студента о языке Hydra - пробной реализации задуманных фич и не увидел там ничего нового, кроме описания семантики и примера перевода этой семантики в тупое FRP на continuation-ах.
Короче, идея интересная. Буду думать, как реализовать ее подмножество для своих задач. Решать DAE я не буду, т.к. физики у меня в игре не будет. А вот описывать задачу не иерархической комбинацией, а системой взаимосвязей может оказаться очень даже удобно. Буду продолжать думать: как совместить описание взаимосвязей задачи и динамическую симуляцию, да еще и сделать все это работающим с нормальной скоростью.
Ох, и давненько же я сюда ничего не писал. Спрашивается - зачем блог создавал?
Хотел мега мысли писать: как надо CAD-системы делать, как сам их делаю. А в итоге - как сессию сдал, так и забил и на работу научную и на SpindleCAD. И вроде блог есть, а писать нечего. Ведь на CAD-ы-то я малость подзабил. А блог изначально вроде как для них делался.
И решил я теперь, что буду я писать сюда все, что в голову взбредет. И не важно - интересно это Вам или нет. Относится ли это к CAD или нет. Пофиг. Мой блог - что хочу, то и ворочу.
На моем сайте появился черновик статьи Ограничения как база CAD системы, в которой рассказывается о том, как ограничения могут решить проблему отсутствия интеграции в CAD системах.
Отрывок статьи:
"Современные CAD системы страдают от недостатка интеграции – мы чертим в одном месте, считаем в другом, оформляем документацю в третьем. Если в одном месте что-то изменилось, то в других местах все приходится менять вручную. Данный недостаток вызван тем, что CAD/CAM/CAE/PDM системы не имеют общей базы, которая могла бы их связать. В роли такой базы может выступать система ограничений, описывающих инженерную задачу и различные взаимосвязи, существующие в задаче."
Полный текст >>
Если у Вас есть какое-либо мнение по поводу этой статьи, пожалуйста оставьте здесь свой комментарий или напишите мне письмо.
До встречи...
Здравствуйте. Как можно уже догадаться, меня зовут Владимир и я хочу рассказать вам кое-что обо мне и об этом блоге.
Обо мне
На данный момент я являюсь студентом 5-го курса МГТУ им. Н.Э. Баумана. Кафедра МТ1 «Металлорежущие станки».
Параллельно с этим я работаю программистом - разработчиком игр. Если очень интересно и не лень читать по-английски, можете посмотреть краткое резюме здесь.
Мои интересы
Интересов много. Расскажу о некоторых.
Разработка игр является моим профеcсиональными интересом, т.к. последние пару лет именно этим зарабатываю на жизнь.
Как любого ленивого программиста, интересуют "продвинутые" языки программирования и технологии разработки ПО, которые помогают мне сберечь время и нервы.
Еще в последнее время меня заинтересовала разработка CAD систем - это то, чем я не собираюсь заниматься профессионально, т.к. разработка игр пока привлекает меня гораздо больше. Тем не менее в институте я веду научную работу по расчету и проектированию шпиндельных узлов и, в рамках этой работы, создаю программу SpindleCAD.
О блоге
По-сути, этот блог создается мною как место, где я рассказываю какие-либо новости из моей же собственной жизни. Также я буду сообщать здесь о различных мыслях, которые, как я считаю, могут оказаться полезными не только мне, но и Вам.
До встречи...
