stdray: (Default)
В комментариях к энторпрайз БАЙСИКУ proofit404 дал линк на свой пост, где рассказывает, про негативный опыт со средами разработки для Haskell, ну и предлагает выпилить люк, создав хитрющую прослойку между редакторами и конпелятором.

Я так полагаю, дело вовсе и не в редакторе и не в способах хранения цветов и автокомлитов каких. Если говорить о компилируемых языках программирования, то никто не может знать о программе больше чем сам компилятор. И вопрос упирается в то, проектировался ли компилятор с учетом работы в режиме IDE или нет. Если да, то написание качественной интеграции большая, но понятная задача. Надо лишь выбрать IDE, изучить документацию и нарисовать плагин, который просто будет заниматься вызовами API компилятора и среды разработки.

При этом "проектировался" означает не только умение принимать / возвращать какие-то данные, но и работать в разных режимах. Потому как шевелиться все это должно достаточно быстро, а если какой-нибудь компилятор Haskell сначала начнет типизировать 100500 файлов проекта, потом займется оптимизацией, позвав на помощь LLVM-бекенд, то ничего хорошего из этого точно не получиться. Выходит, что в режиме IDE ему нужно лишь распарсить и типизировать AST, опуская непосредственную компиляцию, или компилируя без оптимизаций, если редактируемый проект у кого-то в зависимостях и есть потребность в метаинформации сборки (для языков по типу C#). Если язык имеет макроподсистему, то информацию о режиме работы компилятора надо пихать и туда. Также не считаю, что возможно реализовать какой-то stateless протокол обмена между компилятором и IDE, сделав компилятор сервисом или вроде того, поскольку работы у него действительно много. И если при каждом изменение текста гнать ему все файлы проекта для обработки - все будет весьма печально. Потому компилятору нужен стейт, чтобы иметь возможность кешировать результаты своей работы.
Read more... )
stdray: (Default)
Пока в сети продолжаются споры от том нужны DSL или не очень, я решил разобраться, как на макросах Nemerle реализуются встраиваемые языки. Потребность такая может возникнуть, даже при наличии макросов, расширяющих синтаксис языка. Дело в том, что менять правила лексера и препарсера нельзя, а значит определенные последовательности символов будут невалидными, например непарные скобки, хотя я подозреваю, что ими ограничения не исчерпываются. Для выхода из ситуации используются рекурсивные строки, внутри которых пишется код на интересующем языке, а потом транслируется в AST Nemerle. Подобным образом реализованы xml-литералы и linq query syntax.

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


Реализация МИКРОБЕЙСИКА )
stdray: (Default)
Декларативность – стиль оформления устных или письменных текстов, при котором заявленные цели и ценности не соответствуют реальным действиям и реальным возможностям автора этих текстов.

src
stdray: (Default)
Бывает, ради эксперимента пишу какие-то макросы, чтобы разобраться что позволяет макро-подсистема Nemerle, а что - нет. Если будет получаться что-то забавное, стану выкладывать это сюда.


Расширяемые анонимные типы

По мотивам хотелок [personal profile] metaclass. На сколько я понял, ему нужны анонимные типы, которые можно расширять, добавляя новые элементы, а также передавать за пределы той области видимости, в которой они были объявлены. В языке Nemerle нет анонимных типов, однако ими все пользуются, поскольку они реализованы через макросы.

def obj = new(name = "anon", age = 10, created = DateTime.Now);


В общий чертах, работает это так: макрос new по переданным параметрам генерирует генерик-класс с макро-атрибутом [Record] вида

[Record] class AnonType[name, age, created] {

public name : name;

public age : age;

public created : created;

}


Макрос [Record] создает конструктор с аргументами для всех полей, а потом вызов макроса переписывается в конструктор только что созданного класса.
После раскрытия макроса new
Read more... )
stdray: (Default)
боль и унижение )

Твиттерочек фп-блогов приносит иногда феерические откровения. Золотой в жж, мудризм... Один тут недавно MVC разгадал, другой гвозди в "крышку их устоев непоколебимости ООП" забивает. Атаковали бойцы невидимого фронта некошерную парадигму. Урон "врага" пока оценить трудно, но вот атакующая сторона уже несет серьезные имиджевые потери. Надеюсь, планета ФП и дальше будет держать нас в курсе событий.
stdray: (Default)
Проблемы описание маршрутов в ASP.NET MVC известны:
- это слишком многословное описание
- это строки и отсутствие проверки в compile-time корректности маршрута
- это отсутствие хелперов для генерации ссылок

Есть, правда, шаблоны T4MVC, предоставляющие статические хелперы для генерации url'ов по action'ам и доступа к разнообразным view. Однако, проблема со строками в маршрутах остается, проблема проверки соответствия параметров описанных в маршруте и параметров обработчика тоже.

Хотелось бы сделать нормально, чтобы было кратко, интуитивно понятно, с проверками в compile time. Я достаточно давно в фоновом потоке размышляю на этим вопросом. И пока у меня сформировался такой краткий список требований к DSL описания маршрутов:
- внутри строки маршрута должно происходить связывание имен
- необходимо иметь возможность указать слово ХТТП
- необходимы ограничения на связываемые имена (прямо внутри маршрута? отдельно?)
- необходим вывод маршрутов по контроллеру
- возможно, необходима группировка маршрутов по общей части пути
- необходимы параметры по умолчанию
- необходимы имена для маршрутов (опционально?)

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

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

Глядел на описание в Play Framework. Описание достаточно краткое и лаконичное, но нельзя сказать, что богатое возможностями.

И, конечно, я смотрел, как сделано в Ruby on rails. Это, пожалуй, самая продвинутая система описания маршрутизации веб-приложения. Там есть все из моего списка и даже больше. Сложно сказать, насколько удобно оно на практике, но читать такие декларации маршрутов, мне не очень приятно (видимо, из-за непривычности синтаксиса Ruby).

Смотрел какие-то другие поделия, регулярно натыкаясь на описание маршрута, приклеенное к обработчику. Такого счастья точно не надо.

Самая большая проблема, пожалуй, RESTful routes. Идея, лежащая в основе, достаточно проста - есть некоторый набор HTTP Verbs и с их помощью можно отобразить один путь на разные методы контроллера, имитируя действия (CRUD) над объектом (ресурсом). При этом, сразу возникает желание иметь вложенные объекты. И для этого, требуются какие-то специфичные средства описания. Для ASP.NET MVC уже достаточно давно была сделана библиотека, позволяющая несколько сумрачным синтаксисом на лямбдах описывать подобные иерархии. Потом, c выходом четвертой версии фреймворка, оно вроде стало не нужно, поскольку WebApi сам генерирует маршруты. Правда, это не касается вложенных ресурсов. При этом видно, что в дочернем ресурсе происходит накопление параметров от всех родителей. В Ruby, как я понял, принято забирать параметры из словаря, для целей реализации проверок в compile time это подходит мало. Не знаю, существуют ли красивые решения.

По сути, хотел просто сформулировать свои мысли по этому поводу. Но, заодно, пожалуй, спрошу у читающих меня:
- есть ли фреймоворк, где описание маршрутов сделано идеально, который можно взять как пример?
- какие задачи должен решать dsl описания маршрутов, то есть чем вы пользуетесь часто, чем редко, чем хотели бы пользоваться, но не имеете средств?
stdray: (Default)
Решил посмотреть, чем ребята из соседнего комьюнити F# в плане unit-тестов промышляют. И нашел вот такой шаблон проекта. Скачал, установил, стал смотреть, чего там в файле проекта такого особенного. А ничего! То есть вообще самый обычный проект библиотеки классов!

Ну ок, качаю сборку Nemerle для 2012 студии. Это кстати оказалось труднее, чем я думал. Самое новьё сейчас доступно по ссылке http://tc.rsdn.ru/, там надо выбрать интересующую платформу и версию студии, потом выбрать последний удачный билд и на вкладке Artifacts уже можно забрать желанный msi. Я какбэ с TeamCity никогда не сталкивался, потому достаточно долго разбирался что и где.

Ладно, поставил Nemerle и интеграцию с 2012 студией. Создал проект библиотеки, добавил в зависимости уже поднадоевшую VisualStudio.QualityTools.UnitTestFramework.dll, написал два теста, собрал и... ВСЕ ТЕСТЫ ПОЯВИЛИСЬ САМИ. И даже отладка доступна и вообще все робит из коробки. То есть, я там вытанцовываю с бубном вокруг студии в стиле прыщавого админа, а прогресс рядом. MS, видать, переработали систему, избавившись от тех невменяемых ограничений и теперь все хорошо.

Правда, сама интеграция Nemerle с 2012 студий пока нестабильна, хотя большую часть времени работает весьма сносно. И я как-то побаивался переходить, но, думаю, безгеморройные тесты являются весомым аргументом.
stdray: (Default)
Написал про вуду-тесты для Nemerle в студии и уже хотел смотреть зомбоящик, как внезапно в голову пришла мысль, что возможно студия фильтрует проекты с тестами банально по расширению файла проекта. А ради совместимости с сишарповским тулзами Nemerle умеет компилировать достаточно большое подмножество C# и, соответственно, работать с проектами csproj.

Отлично, как и в прошлый раз создаю немерлевую библиотеку, добавляю Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll, пишу тесты. Компилирую - все собирается. Теперь удаляю проект из решения. Меняю ему расширение с .nproj на .csproj. Открываю файл проекта в текстовом редакторе и в самую первую секцию PropertyGroup копирую:

<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>


Пулучился .csproj следующего содержания: пример. Добавляю проект обратно в решение, компилирую и, вуаля, тесты доступны без всяких лишних проектов.

Отличия от предыдущего метода:
1) Там есть лишний проект, тут - нет
2) Там нельзя дебагером отлаживать тесты, тут - можно.
3) Там работал немерлевый автокомлит, тут - нет.

Я думаю, что так-то поудобней будет. Даже с учетом того, что автокомплит поломался. Но может и этот вопрос решаемый.
stdray: (Default)
Для написания unit-тестов я пользуюсь стандартными студийными возможностями - "Создать тестовый проект Visual C#" и пихаю туда тесты (суть классы и методы помеченные специальный атрибутами). Я не то чтобы фанат тестирования, просто писать тесты быстрее и проще, чем каким либо иным способом проверять написанную функциональность. И хотя я понимаю, что надо бы прочитать что-то про разработку через тестирование, про лучшие средства для него и тд, текущее положение дел меня вполне устраивает.

Однако, этот подход перестает работать, если пишешь код на чем-то отличном от C#/VB.NET/C++.NET, поскольку то ли в студию, то ли в mstest зашито данное ограничение. И хоть писать тесты на C# вполне приемлемо, это сильно раздражает. Как вообщем-то и ставить какие-то сторонние тулзы вроде NUnit большого желания нет, поскольку, во-первых, я уже привык к студийным возможностям вроде ведения списков тестов, ко всяким связанным с ними окошкам, а, во-вторых, предпочитаю по мере возможности пользоваться средствами из коробки.

Вообщем, мне надоело писать тесты к Nemerle на C# и я решил разобраться в проблеме. И хочу рассказать про вуду-решение, подходящее не только для Nemerle, но и для любых других языков .Net, не заапрувленных MS, вроде того же F#.

Первое, надо добавить в решение проект библиотеки на Nemerle (в моем случае это Nemerle.Mixins.Tests). К ней в зависимости добавить Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll, открыть соответствующее пространство имен и написать пару тестов. Что-то вроде такого:

using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]

public class SimpleTest {

[TestMethod] public Fail() : void { Assert.IsTrue(1 == 2); }

[TestMethod] public Win() : void { Assert.IsTrue(1 == 1); }

}


Read more... )
stdray: (Default)
В вики Nemerle существует вот такая страничка, на которой рассказывается, как могли бы вести себя трейты, будь они реализованы в языке. Но пока что "not yet done", хотя тема неоднократно поднималась на форуме. Как я полагаю, это все следствие размышлений на тему "Как бы нам вернуть обратно множественное наследование". То есть сейчас в дотнетах оно есть, но в значительно урезанном виде: интерфейсы позволяют наследовать только требования к объектам, а уж реализацию приходится пилить вручную, что конечно же раздражает.

Мне в этом описание понравилась идея выставлять требования для объектов, к которым возможно "подселять" трейты. Однако, мне не очень нравится идея реализовывать это дело внутри интерфейсов, поскольку такой объект будет некорректным с точки зрения, допустим, C#. К тому же такие трейты не смогут иметь собственное состояние, что очень сильно ограничивает варианты их использования.

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

Для описания примеси я использую модуль, помеченный атрибутом [DefMixin], внутри которого описывается интерфейс (он представляет собой требования) и класс (он представляет реализацию). Простейшее описание примеси может выглядеть так:

[DefMixin]

public module Foo {

public interface Require {

getX() : int;

setX(v: int) : void;

}

public class Provide[T] where T: Require {

public inc() : void { self.setX(self.getX() + 1); }

}

}


Узнать больше про примеси в Nemerle )
stdray: (Default)
Когда читаешь в интернете разные программистские дискуссии, постоянно натыкаешься на некоторые шаблонные суждения. Например,
- когда говорят про high load, ведут речь за хорошую горизонтальную масштабируемость;
- когда говорят про embedded, обсуждают, как станцевать вальс на площадке размером с пятирублевую монету;
- когда говорят про enterprise, имеют в виду либо оскорбление, либо CRUD.

Хотя в последнем случае разница довольно условна. То есть «энторпрайз» - это такие сферические неудобные медленные приложения в вакууме, а круды — это продукт деятельности макак, школьников и индусов. Это значит, например, что индийцы не индуисты круды писать не могут. То есть круды — это что-то плохое и простое.

Хотя, конечно, только от того, что какую-то деятельность заклеймили как простую и бесполезную, проще от этого она точно становится. Чем дальше, тем важнее становится информация. И все, кому не лень (и кому лень тоже) занимаются её накоплением, структурированием и анализом. При этом мой опыт таков, что данные — вещь удивительно не гибкая. Поскольку есть информация сама по себе, а есть ее представление, выбранное для решения конкретной задачи. Эти представления являются первой сложностью. Первой, в том смысле, что все начинается c выбора представления: как данные разделить на маленькие кусочки, как выразить эти кусочки в терминах своего инструментария (модель данных приложения, модель постоянного хранилища), как обеспечить их согласованность и определенную сложность доступа к ним. Хотя по этому поводу написано достаточно много, от нормальных форм реляционной базы данных до паттернов Фаулера, эта задача все же не является тривиальной. Слепое следование рекомендациям ни к чему хорошему не приводит, потому приходится постоянно оценивать свои решения, насколько они кажутся удачными, начиная с момента разработки и заканчивая текущим моментом (если апликуха до него дожила). И тут большую роль играет опыт, поскольку он позволяет учесть значительно больше вариантов использования и сложных граничных случаев.
Read more... )
stdray: (Default)
Ломающие новости! Срочно в номер первой полосой! В Москве выпал снег! И продолжает падать! Москвичи все в снегу! На крышах домов снег тоже!

Сейчас прямое включение нашего корреспондента!
- Борис!
- Да, спасибо! Вот я стою, вот падает снег, вот москвичи, вот снегоуборочная техника, вот машины под снегом! Константин!
- Борис, какие прогнозы?
- Спасибо! Снег пока продолжает падать, вот москвичи идут по снегу, вот снег падает на москвичей...
- Спасибо, Борис! Это было прямое включение нашего корреспондента.


Снег. Ну ахуеть теперь. Время идет, а некоторые вещи все не меняются. Я почему-то раньше думал, что если живешь в Москве, то подобные репортажи не выглядят столь тупо, ан нет - тупо. Ещё как тупо. Летом возвращался домой, откуда уже не помню, а тут дождь внезапный, ну я встал у подъезда ближайшего дома. Дождь сильный и очень косой идет, что планшет не достанешь - долетают капли, а телефон норм. Так и стою читают твиттерок и срачи срачелятора и тут ВНЕЗАПНО звонок от матери, мол как ты там, в новостях передали, что в Москве дождь с ураганом, что москвичи опасаются повторения трагедии Крымска в столице. Ну, конечно, в Москве же дождь, почему бы чему-нибудь не повториться. Ну или те же пожары десятого года, ну как вопили то. "В Москве дым, вот москвич в марлевой повязке, вот еще в марлевой повязке, вот в шлеме стоит москвич" и так далее. А ко мне на прошлой неделе знакомый мой из Хабаровска заезжал чаю попить, так говорит, пожары как горели каждое лето в бытность мою хабаровчанином, так горят. Ну а кому какое дело? Вот и я о том же. Вспоминаю, как где-то на рубеже тысячелетий нас травили шок-контентом в телевизоре: "В Москве холодно! Вот ваш корреспондент! Вот москвичи, вот мороз, вот даже в валенках стоят москвичи, да чего дошло! Вот из-за угла выглядывает ОБМОРОЖЕНИЕ, вот Дед Мороз зубоскалит". Ну такое веселье, в самом деле. Потеха на всю страну. Хотя про страну тоже все понятно. Я же почему пишу такое? Потому что городок Б и все такое, потому что ближайший подмосквич.
stdray: (Default)
[personal profile] xeno_by написал, что макры для скалы почти вот-вот будут готовы. А люди как-то не очень радуются. Я почитал комментарии, мне что-то не понравилось такое обсуждение.


Макросы - это признание поражения. "Наш язык оказался недостаточно хорошо, нам придется генерировать программы на нём, чтобы продолжать притворяться, что мы пишем на нём".

Во-первых, тут явно подразумевается, что кодогенерация является чем-то плохим и доказывает несостоятельность языка, как средства для написания программ. Из моего ежедневного: редактировать форму мне удобней в графическом дизайнере, просматривать схему базы данных и редактировать связи между таблицами опять же удобней в графическом представлении. По-моему, очевидно, что если существуют разные способы выполнить одну работу, то надо выбирать самый удобный. И либо у нас есть серебряная пуля, либо для каждой задачи существует свой самый удобный инструмент. А чтобы это все как-то между собой взаимодействовало о совмещалось, надо приводить к одному знаменателю. Например, к текстовому представлению в виде кода на определенном языке программирования. Этот способ не единственный, но, на мой взгляд, достаточно практичный и удобный.
Read more... )
stdray: (Default)
Я про себя не могу сказать, что разбираюсь, но могу рассказать, что мне нравится. В основном я пью китайские чаи и больше всего в них меня привлекает разнообразие вкусов. При этом, иногда бывает так, что определенный чай ничем не впечатляет и вообще кажется никаким, а потом в нем различаются нотки, которых нет больше нигде и он становится одним из любимых. Потому первое время стоит покупать разный чай. И, если есть какие-то предубеждения вроде нелюбви к зеленому или там черному чаю, то лучше о них забыть. Те же зеленые чаи очень сильно между собой разнятся.

Лунцзин - зеленый чай с бодрым не приедающимся вкусом. Его я пью больше всего, потому считаю, что с ним обязательно стоит познакомится. чай-чай-чай )

дыбр

Oct. 21st, 2012 07:34 pm
stdray: (Default)
Что касается чая. Если продавец не импортирует чай оптом сам, а закупает у русской чайной компаний или там у dammann freres, то переплата будет примерно 300-600 (10-20 баксов) тупо за железную банку, при том объем там всегда меньше. То есть не 100 грамм, а 85 например и меньше. А качество чая не лучше. Поразительно, бл. Потом мне говноилита рассказывает, что нормальный чай стоит по 600 рублей за 100 грамм. То есть с вероятностью в 98% это недорогие сорта в дорогой баночке. А без баночки, они думают, идет наебалово. Такой каргокульт, лол. То есть взять 100грамм в банке и 100грамм в развес в магазине с прямым импортом, а потом сравнить, люди просто не осиливают. А потом, заваривая железную банку, такие: "тебе продали сушеную свеклу, а не тегуаньинь".
stdray: (Default)


Какая феерия. У майкрософт додиез, заборы, коровники старообрядцы, хипстеры. Не иначе как по мотивам басни Крылова подбирали. Читал кто ту басенку в переводе на английский (если ее, конечно, переводили)? Что там сказано, забись у той троицы воз с поклажей везти получается?
stdray: (Default)
про мифический хаскель (линк).

Блин, аж до тошноты. Атд есть динамическая типизация. Типы нужны, чтобы узнать какое количество памяти надо выделить. Метки типов. Типов пустых туплов. Классы типов — это АлгТД. Классы типов - недокостыль. Система типов — это лишь инструмент для разметки памяти под данные и связи кода с данными. Статическая типизация: это когда в исходнике if есть (в том или ином виде: ПМ, overloading и т.д.), а в генеренном коде if-а нет? Боксирование...

Как всякие морготные фильмы ужасов. Когда кровь, кишки, слизь какая-то, глаз выпал, и кто-то постоянно нападает из-за угла. Смотреть противно, но все равно смотришь. Даже не уверен, что мне интересен конец истории. Смотришь и плющит. Эмоции как-никак, хоть и негативные.

August 2017

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
27282930 31  

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags