От его ГГ и писанины блевать хочется. Сам ГГ себя считает себя ниже плинтуса. ГГ - инвалид со скверным характером, стонущим и обвиняющий всех по любому поводу, труслив, любит подхалимничать и бить в спину. Его подобрали, привели в стаб и практически был на содержании. При нападений тварей на стаб, стал убивать охранников и знахаря. Оправдывает свои действия запущенным видом других, при этом точно так же не следит за собой и спит на
подробнее ...
тряпках. Все кругом люди примитивные и недалёкие с быдлячами замашками по мнению автора и ГГ, хотя в зеркале можно увидеть ещё худшего типа, оправдывающего свои убийства. При этом идёт трёп, обливающих всех грязью, хотя сам ГГ по уши в говне и просто таким образом оправдывает своё ещё более гнусное поведение. ГГ уже не инвалид в тихушку тренируется и всё равно претворяет инвалидом, пресмыкается и делает подношение, что бы не выходить из стаба. Читать дальше просто противно.
Слог хороший, но действие ГГ на уровне детсада. ГГ -дурак дураком. Его квартиру ограбили, впустил явно преступников, сестру явно украли.
О преступниках явившихся под видом полиции не сообщает. Соглашается с полицией не писать заявление о пропаже сестры. Что есть запрет писать заявление ранее 3 дней? Мало ли, что кто-то не хочет работать, надо входить в их интерес? Есть прокуратура и т.д., что может заставить не желающих работать. Сестра не
подробнее ...
пришла домой и ГГ отправляется в общественную библиотеку, пялясь на баб. Если ГГ и думает, то головкой ниже пояса. Писатель с наслаждением описывает смену реакции на золотую карту аристо. Диалоги туповатые, на уровне ребёнка и аналогичным поведением. История драки в школе с кастетами и войнами не реально глупая. Обычно такие тупые деологи с полицией, когда один сознаётся в навете оканчивается реальным сроком. Когда в руки ГГ попали вымогатели с видео сестры, действия ГГ стали напоминать дешевый спектакль. Мне данный текст не понравился, сказочно глупый.
эффективнее. Допустим, аналитик проекта, хорошо представляющий себе бизнес-логику приложения, теперь сможет самостоятельно описывать на DSL ее отдельные части[В принципе, достаточно лишь понимания аналитиком кода на DSL. При этом он (как правило, все же, она) сможет на словах рассказать разработчикам, что нужно сделать, а затем, просмотрев код на DSL, проконтролировать их работу]. При этом проект избавляется от лишних документов, а разработчики — от их прочтения (на что тоже нужно время) и двусмысленного толкования;
становится возможным повторное использование DSL в схожих проектах. Все разработанные DSL, подобно общим библиотекам компонентов, становятся серьезным активом компании-разработчика, поскольку являются квинтэссенцией опыта компании и допускают повторное использование в будущих проектах.
На мой взгляд, в настоящий момент у языковых инструментариев существует только один серьезный недостаток: риск попадания в зависимость от поставщика программного обеспечения. Дело в том, что сейчас DSL жестко привязан к языковому инструментарию, при помощи которого он был разработан. И если в мире Microsoft этот вопрос отпадает автоматически (ввиду тотального характера зависимости), то для будущих пользователей MPS он вполне актуален, даже несмотря на то, что все файлы проекта MPS хранятся в открытом формате XML. Разумеется, это не является непреодолимым препятствием на пути к использованию языковых инструментариев, тем более что стандартизация в этой области станет возможной лишь с появлением на рынке конкурирующих и несовместимых друг с другом продуктов. Просто к списку технологических рисков проекта добавляется еще один пунктик.
Декларация или империя?
Позволю себе внести предварительное замечание эстетического характера: в свете языковых инструментариев могут возродиться многие давно забытые дискуссии о самих языках программирования, придававшие нашему ремеслу (искусству?) особое, ни с чем не сравнимое обаяние и притягательную силу. Обаяние, которое автор статьи так настойчиво хотел похоронить, публично обличая страстных приверженцев C++, верных любимому языку по сей день[ «Язык мой...», «КТ» #555-556]. Каюсь, грешен: поддался влиянию поголовного обсишарпивания разработчиков. Прошли годы, и хотя в отношении самого C++ автор своих взглядов не изменил, за настойчивость в желании прервать диалог о языках программирования все же досадно.
Итак, переходим к сути. Вообще говоря, при написании программ существуют две стратегии:
записать, что нам нужно сделать (декларативные языки);
записать, как мы собираемся это делать (императивные языки).
Для декларативных языков характерны емкие и компактные конструкции. Достаточно сказать, что исходный текст довольно сложной программы на ПРОЛОГе — ярком представителе всего семейства — вполне может уместиться «на одном экране».
Тем не менее практически весь мэйнстрим современной разработки составляют императивные языки (все те же С++, Java, C#, ...), а чуть ли не единственной серьезной промышленной нишей для декларативных языков являются технологии баз данных, где прочно обосновался SQL вкупе с множеством диалектов. И это не просто «исторически так сложилось». Несмотря на изящество, компактность и концептуальную простоту декларативных языков их применение оправданно только при условии, что предметная область задачи четко определена. Именно этим обстоятельством и объясняется успех SQL, ведь абстракции, на которых построена работа с реляционными данными, давно изучены и хорошо известны.
При проектировании DSL актуален следующий вопрос: нужно ли вносить в него императивные конструкции (условные операторы и циклы)? Не потеряем ли мы в результате то, к чему, собственно, и стремимся: получение простого языка, на котором записана лишь самая суть проекта, без утомительных деталей реализации?
Руководствуясь здравым смыслом, можно сказать, что императивные конструкции целесообразно использовать лишь тогда, когда это продиктовано спецификой предметной области задачи. Например, если в постановке задачи часто употребляется слово «коллекция элементов» и говорится о задачах добавления/удаления/поиска элементов, введение в DSL понятия «цикл для работы с коллекциями» способно существенно упростить решение. Тем не менее предпочтение все же стоит отдавать декларативным конструкциям: их проще моделировать (сокращаются затраты на проектирование DSL), к тому же зачастую они легче воспринимаются и несут больше информации о проекте.
Прекрасное далёко
Для создания DSL «Структура статьи в КТ» автору потребовалось около часа. Разумеется, это не есть адекватный показатель, поскольку мы разработали простой и вдобавок совершенно бесполезный язык, но трудозатраты в один человеко-час все-таки впечатляют. И тем не менее многие почему-то не верят, что разработка в окружении языковых инструментариев будет быстрой, а процесс создания и сопровождения DSL — простым. Мне кажется, здесь вполне уместна
Последние комментарии
6 часов 12 минут назад
10 часов 23 секунд назад
10 часов 18 минут назад
10 часов 24 минут назад
10 часов 39 минут назад
12 часов 13 минут назад