May 15th, 2010

glider

Краткий саммари движухи за последние два месяца

Всем привет после долгого отсутствия - с февраля валит нескончаемый загруз, поэтому получается постить что-то интересное раз в сто лет, а постить неинтересное какой смысл. За пару месяцев накопилось некоторое количество веселья идей, которые было бы интересно обсудить: 1) насчет веб-девелопмента, 2) насчет Конфлакса, 3) по поводу смены языка программирования для души, 4) по поводу смены энвайронмента на более продуктивный. Теперь немного поподробнее.

---

По поводу первого. В одном из предыдущих постов я писал про внутренний проект, который делал на работе - несложный сайтик из десяти скринов (не включая круд формочки), каждый из которых либо грид с фильтром, либо представляет собой набор из нескольких виджетов. Было интересно затестить концепцию тупого сервера (который всего-то умеет отдавать статический html и "голые" реляционные данные, плюс, конечно, секьюрити, логгирование и т.д., но сейчас это не суть важно) и умного клиента на жабаскрипте. В итоге написал почти весь middle-end руками, по факту, практически переписав asp.net (получилась недопиленная хрень с не самым клевым перфомансом, но в качестве прототипа она мне нравится). Для бакэнда и транспорта данных юзалась связка ADO.NET Data Services + Entity Framework. В целом неплохо, но собрал неслабую пачку граблей.

Выводы обнадеживающие: 1) писать свою инфраструктуру можно и нужно, только надо быть менее самоуверенным, 2) жить без 3rd-party библиотек можно с большим трудом, но это неслабо окупается, 3) в целом, веб-девелопмент оказался проще и интереснее, чем я ожидал по знакомству с ASP.NET (обычным и MVC). В процессе работы я вел лог важных решений и побежденных косяков, поэтому есть желание слабать hands-on описание , но для этого надо отделить зерна от плевел. Кароче, // TODO. to be implemented.

---

Насчет Конфлакса. В этом аспекте занимался тем, что в свободное от вышеописанной активности время лабал декомпилятор шарпа. Кроме, собственно, необходимости для проекта, эта таска мне в свое время представлялась очень романтичной в плане того, что она станет первым шагом для прикручивания какого-никакого метапрограммирования к шарпу. Мечты-мечты. Не учел я одной вещи - декомпилятор это, по сути, рассмотрение чуть более, чем дохера частных случаев. Или, другими словами, кропотливая и нудная работа. Впрочем, может быть, это я что-то делаю не так и, причастившись к работам отцов индустрии, узнаю общий алгоритм для декомпиляции чего угодно. В целом, был сделан вывод о том, что надо юзать нормальные компиляторы, которые отдают AST на этапе компиляции (аля C# expression trees, но только с полной поддержкой семантики языка). В самой ближайшей видимости (ибо дотнет) находятся Boo и Nemerle - интересно будет посмотреть, как там все это сделано.

Моменты, которые бы хотелось здесь обсудить. 1) Дизайн структур данных AST и типичных сценариев работы с ними. Пока что я остановился на мутабельных нодах, которые в своей жизни могут иметь только одного парента (если у нода уже есть парент и он добавляется в чайлды другому ноду, то перед добавлением он клонируется) + клонирующих визиторах. Это наиболее удобное и робастное решение из придуманных ad-hoc, но оно порождает дофига ненужного клонирования. Интересно, как делают такие вещи по науке. 2) Навигацию и декомпозицию. Нашел интересную работу по реализации xpath над s-выражениями, но пока не добрался почитать полностью. Также интересно придумать удобный способ записи следующего запроса, необходимого для peephole-оптимизации mul+add => mad: "найти нод вида foo += bar или foo = foo + bar, где bar суть qux * baz или символ, которому присвоено значение вида qux * baz". Впрочем, может, такого способа и не существует и задача решается тупо в лоб.

---

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

Отсюда получаются два вывода: 1) в принципе, очень много вещей, к которым я привык в сишарпе можно либо написать самому, либо обойтись без них вообще, 2) поэтому, стоит посмотреть в сторону других энвайронментов и языков. Чтобы эти выводы стали чем-то большим, чем просто декларации, я решил набросать список фич, которые мне нужны от языка/ide/энвайронмента на текущем этапе, и посмотреть альтернативы. О первом и будут следующие пару постов (первый, второй, третий), второе еще in progress и по нему мне бы были очень полезны ваши советы (спасибо zamotivator за консультацию на тему разработки без IDE и крутоты линухи).
glider

Wish list возможностей языка и платформы

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

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

Язык
1. Нативное функциональное программирование: функции высшего порядка, выведение типов (хотя бы на уровне шарпа), замыкания, параметрический полиморфизм. Приятны будут нативная поддержка таплов, рекордов, литералов коллекций и мапов.
2. Насчет полной ленивости не уверен, ибо не пробовал никогда, но ленивость сиквенсов нужна обязательно.
3. На тему вопроса типизации тоже не уверен, ибо никогда не пробовал писать что-то большое на динамически типизированном языке.
4. Нативная поддержка объектно-ориентированного программирования некритична. Действительно важна для меня возможность объединить вместе и положить отдельно от остального кода некоторый кусок данных и набор функций, которые с ним работают.
5. Средства структуризации в плане возможности объединить вместе и положить отдельно от остального кода интересные мне фрагменты программы. Очень желательно, чтобы гранулярность была на уровне функций, а не классов.
6. Нативная поддержка исключений: try, catch, finally. Сюда же и стек трейсы (понимаю, коммон сенс, но вдруг где-то этого нет).
7. Средства перегрузки функций по сигнатуре. Сколько я не читал, что это вредная языковая фича, никак не могу придумать, как я бы работал без нее. Возможно, я что-то неправильно понимаю.
8. Паттерн-матчинг, причем желательно работающий с кастомными структурами данных аля актив-паттерны в F#.
9. Поддержка интерфейсов и/или тайпклассов.
10. Желательна возможность вызова функций в ОО-стиле или какого-нибудь другого способа читаемым образом выражать семантику чейнинга вызовов (например, аля |> в F#).
11. Чем больше выразительности, тем лучше. Энумы, кастомные операторы, проперти, индексеры, икстеншн-методы, статик импорты, сиквенс-компрехеншны, итераторы/генераторы, монады - все это только в плюс. Много чего из этого можно достичь жестоким метапрограммированием, но, если можно обходиться без него, то это замечательно.

Компилятор/среда исполнения
1. Горбатый коллектор, крайне желательно иметь над ним контроль как минимум аля KeepAlive и WeakReference.
2. FFI, очень желателен интероп с дотнетом.
3. Очень желательно наличие рефлектора, который является лучшей документацией.
4. Поддержка связывания метаданных с элементами программы.
5. Интроспекция структуры исполняемого модуля и AST отдельных функций.
6. Кодогенерация в рантайме с поддержкой эмита дебажной инфы.
7. Опен-сорс хотя бы компилятора.

Набор библиотек и тулов
1. Библиотека коллекций и ФВП работы с ними.
2. Уникодные строки, к ним прикрученные регексы.
3. Адекватные дата и время.
4. Маппер структур данных на RDBMS или, на худой конец, просто голый ODBC.
5. Средства работы с I/O, плюс важный частный случай, описанный ниже.
6. Веб-сервер, средства работы с HTTP или, на худой конец, сокеты.
7. Сериализация.
8. Желательны стоковые средства RPC.
9. Генератор парсеров.
10. Не помешают уже написанные средства работы с XML и JSON (парсинг, манипуляция, стрингифай).
11. Стримлайновый подход для построения десктопного гуи, желательно с поддержкой MVC. Дизайнер это, конечно, плюс, но он необязателен, ибо на текущий момент я не делаю таски, которым необходим сложный гуи.
12. Удобная система билдов, желательно не требующая программирования на XML.

upd от 23.06.2011. С таким перфекционизмом недолго и с ума сойти. Вот, например, скала. Интересный язык с пачкой эксклюзивных фич (имплициты, система типов), но и тараканов тоже хватает. В данный момент мне кажется, что у языка просто должны быть какие-то совсем базовые вещи (ФВП, коллекции, строки, уникод), а с тараканами просто надо дружить. Сейчас мне более интересно искать фан в энвайронменте разработки.
glider

Wish list возможностей энвайронмента

Недавно я постучался в чят к zamotivator поговорить о моих сомнениях насчет сишарпа и дотнета. В процессе дискашена естественным образом всплыла тема IDE. Так, как с vs 2010 у меня не сложилось взаимопонимание насчет сглаживания текста, этот вопрос для меня тоже стоит весьма остро.

Спасибо Олегу, я получил очень интересное и очень детальное мнение по этому вопросу: 1) ide/debugger не нужны, 2) если они все-таки нужны, то программа написана хреново, 3) юзайте emacs для редактирования, grep для поиска и руки для рефакторинга. Для меня это звучит весьма радикально, но, тем не менее, интригующе. Надо будет при наличии свободного времени разобраться на практике.

Параллельно с вышеописанным революционным бранчем мыслей, существует и бранч эволюционный - составить список того, что мне мило сердцу в текущей связке vs 2008 + r# и оценить альтернативы, имея ввиду то, что кое-что из этого придется дописывать, а от кое-чего, может быть, даже и отказаться. Очень интересно будет мнение со стороны.

Итак, список:
1. Семантическая подсветка: used/unused, locals/fields, props/methods, strings. Лично мне это сильно облегчает парсинг и анализ кода. Может быть, я что-то делаю не так.
2. Поиск банальных синтаксических ошибок на лету. Очень удобно, лишь бы не тормозило так, как решарпер. Впрочем, как верно сказал Олег, REPL в динамических языках является адекватной заменой.
3. Интеллисенс (справка сигнатур и типов параметров, автокомплит), автоимпорт имен, а также вывод типов символов. Ессно, я не ожидаю, что это будет работать в динамических языках.
4. Навигация к определению, инкрементальный поиск классов/методов по имени или вайлдкарду.
5. Поиск: полнотекстовый, поиск использований в проекте, подсветка использований семантического элемента программы в текущем файле аля поиск в современных браузерах, но с учетом семантики (например, оверлоадов).
6. Интегрированный юнит-тест раннер с навигацией по стек-трейсу (аля решарпер).
7. Из рефакторинга, по сути, жить не могу только без переименования (неймспейсов/импортов, классов, функций, локальных переменных и параметров). Еще полезны инлайн переменной и вынос выражения в переменную но без них можно жить.
8. Спрятать/показать фрагменты кода.
9. Кастомизация билда, желательно без XML.
10. Отладка: брейк на упавших исключениях, отладка адвансед конструкций языка (для шарпа это, например, замыкания и итераторы), экстенсибилити дебажного просмотра, поддержка кастомно эмиченной дебажной инфы (для отладки сгенерированного кода).

upd от 28.01.2011. После некоторого отдыха от программирования вернулся обратно и сел кое-что покодярить в линкпаде (типа-репле для сишарпа). В результате получил следующий экспириенс:
1. Пункт 1 предыдущего списка нафиг не упал.
2. Пункт 2 предыдущего списка нафиг не упал.
3. Пункт 3 предыдущего списка в большинстве случаев не нужен. Опыт программирования без интеллисенса показывает, что мозгу так гораздо лучше концентрироваться. НО иногда реально невозможно без виджета, который бы показывал какую функцию/метод можно вызвать в данном контексте, ибо всех имен не упомнишь. Было бы крайне круто, если бы такая штука генерилась в бэкграунде на свободном ядре-двух и мгновенно показывалась по хоткею на втором мониторе.
4. Пункты 4, 5 и 7 я до сих пор считаю очень важными, даже на мелких файлах/проектах.
5. По поводу пункта 10 я серьезно пересмотрел свое мнение, ибо вещи вроде графов, для которых я хотел юзать плагины, гораздо лучше отлаживались трейсами и графвизом.

upd от 23.06.2011. Недавно в журнале у tonsky случился прекрасный дискашен To IDE or not to IDE?. В нем сабжевый топик получил новое развитие, а особенно интересно мне было почитать вот эту ветку обсуждения: http://tonsky.livejournal.com/231610.html?thread=1174714#t1174714. Я для себя оттуда вынес то, что иметь одновременно качественный текстовый редактор (отсутствие тормозов, кастомизация, удобство работы с клавиатуры) и IDE (поддержка семантики языка, интеграция типичных для платформы задач) на текущий момент невозможно. В плане, от чего-то все равно придется отказываться.

upd от 14.08.2011. Недавно я поставил себе емакс и начал подпиливать для поставленной цели: работы с дилайтом в интегрированном стиле. За неделю получилось подогнать сабж к моим привычкам после студии и заинтегрировать основные элементы воркфлова (компиляция при помощи sbt, работа с гитом). Читаем отчет: пост первый, пост второй, пост третий.
glider

Ubuntu + mono

Чтобы расширить сознание, выйдя за рамки привычной экосистемы и централизованно управляемого коммьюнити, я решил попробовать пересесть на убунту + моно (спасибо, zamotivator за просветление =)). В связи с нависающим дедлайном у меня не получится кинуться в пучину прямо сегодня, поэтому есть время морально подготовиться.

Поэтому пару вопросов:
1) Что может быть самое дикое в линухе для человека, который в своей жизни ничего не видел, кроме винды? Чего мне будет заведомо не хватать?
2) Насколько юзаемы моно/монодевелоп после длительного экспириенса общения с дотнетом/студией (учитывая то, что мне ни WPF, ни SL, ни WCF пока что не нужны)? Насколько реально допиливать mono/monodevelop под себя? Насколько монодевелоп соответствует моему виш-листу, опубликованному чуть ранее?

upd от 23.06.2011. Через пару месяцев после написания поста удалось-таки посмотреть Убунту. Это было мое первое знакомство с линуксом, поэтому я был просто заворожен его внутренним устройством и написанием скриптов. Ессно, ни о каком моно речи вообще не шло - не до него было. Серьезное развитие идея миграции получила только через год, когда мне удалось найти побольше свободного времени: пост первый, пост второй, пост третий, пост четвертый.

upd от 09.10.2011. По концовке я все равно вернулся на винду, но с обновленным мировосприятием и багажом хороших привычек: почитать подробнее. Следующий шаг, несомненно - покупка макбука =)