Здравствуйте, vdimas, Вы писали:
V>Неинтересная. Обычно менюхе назначается код команды (или его аналог — объект Command), затем эта команда роутится на активный элемент. Команда может поступить как из менюхи, так и из тулбара или из кнопки на форме или еще откуда-нить, например, через системное сообщение. Команда может быть контекстно-зависима, поэтому и нужен роутинг, начиная от активного элемента и вверх по иерархии.
Вот и я о том же. Если отвлечься от вопросов дизайна интерфейса (который может и вообще не на компьютере продумывается), то сама реализация обычно является достаточно простой и шаблонной работой. Все решения давно известны. И соответственно возникается желание максимально автоматизировать этот процесс.
V>На DSL тут не императивщину писать надо, а связывать элементы управления и команды. Но вроде в дизайнере это и так несложно делается визуально.
Смотря что подразумевать под командами. Если функции из системного кода, то да — так и работают сейчас большинство редакторов. Но как показывает практика, большое количество этих команд сводятся к 1-2 вызовам функций других элементов интерфейса и всё. Соответственно подобная привязка прямо в визуальном редакторе (или же в текстовом gui dsl — кому что больше нравится), без создания обработчиков в системном коде (руками — как оно там внутри реализуется не важно) существенно повысила бы эффективность разработки. И кстати в таком случае например дизайнер мог бы тестировать логику работы интерфейса в режиме WYSIWYG, а не ждать пока программисты её реализуют.
<оффтопик> K>Но с точки зрения физики массу и температуру складывать нет смысла: какая величина должна получиться?
В одной известной физической системе единиц как раз можно и даже возможно будет некий смысл. )))
</оффтопик>
А вообще я согласен. Именно в этом смысл DSL — ограничение возможностей.
K>Именно эту ситуацию способен разрулить DSL.
Только на самом деле действительно качественных dsl не так уж много. Мне с ходу sql, regexp, xslt, make в голову приходят — то, с чем часто имеем дело. Но это же капля в море. И инструментов для их проектирования в промышленных масштабах не видно.
Да наши позиции действительно схожи, но твой тон прямо провоцировал написать опровержение.
Мне вот вообще интересно, те люди которые придумывают очередную фиговину на которой смогут писать кухарки и матросы, они вообще с пользователями когда-нибудь общались? Или хотя бы с коллегами — хреновыми программистами? На что они после такого общения вообще рассчитывают?
Здравствуйте, AndrewVK, Вы писали:
K>>1. Я не явлюясь специалистом в данной предметной области. K>>2.1. Я не являюсь специалистом в создании DSL.
AVK>А таких людей вообще — просто считанное количество. That's the problem.
Таких людей — очень много! Каждый бизнесмен — специалист в своей области. (Пояснения дальше.)
K>>Пока что я пишу примерно такой же код.
AVK>Ну так покажи — какой код ты хотел бы писать.
AVK>Я не прошу тебя написать парсер и анализатор DSL, я прошу показать, как DSL будет выглядеть.
Это не я должен показывать. Это должны показывать бизнесмены. Оно уже есть: предметная область. Берём стандарт, ГОСТ, спецификацию этой области, и механически переносим в наш DSL.
K>>2.2. У меня нет удобных средств написания DSL.
AVK>Причем тут средства?
Всё-таки от средств зависит многое.
Я понимаю, что слишком многого хочу. Но в мечтах вижу создание DSL именно так: манипулирует предметная область текстами — наше средство создания DSL должно легко позволять это; бизнес манипулирует чертежами — DSL должен уметь делать это, а фреймворк по созданию DSL должен легко поддерживать это; и т. п.
AVK>1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации.
Как я уже сказал, сочинять ничего не нужно: оно уже всё есть. Сочинено самими спецами в данной области.
AVK>2) Современные ЯОН совсем не так уж и ужасны при умелом использовании.
Здравствуйте, koodeer, Вы писали:
K>Таких людей — очень много! Каждый бизнесмен — специалист в своей области. (Пояснения дальше.)
Это даже не смешно. При чем тут бизнесмен? Речь о специалисте по созданию DSL.
AVK>>Я не прошу тебя написать парсер и анализатор DSL, я прошу показать, как DSL будет выглядеть. K>Это не я должен показывать. Это должны показывать бизнесмены.
Забудь, это фантастика. Заказчики не способны даже логически непротиворечиво изложить требования.
K> Оно уже есть: предметная область. Берём стандарт, ГОСТ, спецификацию этой области, и механически переносим в наш DSL.
Продемонстрируй.
K>>>2.2. У меня нет удобных средств написания DSL. AVK>>Причем тут средства?
K>Всё-таки от средств зависит многое.
Да пофик. Я тебя спрашиваю про то, как будет выглядеть DSL.
AVK>>1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации. K>Как я уже сказал, сочинять ничего не нужно: оно уже всё есть.
Ну вот покажи мне это есть для приведенного примера. И область то — одна из самых в этом плане востребованных. Т.е. если в ней не будет, то можно считать, что готовых DSL почти нигде нет.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Картинка размером от 3000*5000 до 5000*6000 пикселей, размер файла 15-30 Мб. PD>Время на обработку — 200-300 мсек на современном процессоре. Не уложишься — считай, что задача не решена.
Может я чего не понял в твоей задаче, но лобовое решение без всяких SSE и CUDA, типа такого:
for (var y = 0; y < _height; y++)
{
var line = data[y];
for (var x = 0; x < _width; x++)
line[x] = line[x] < 128 ? (byte) 0 : (byte) 1;
}
На моем процессоре (мейнстрим годовалой давности) для картинки 6000х5000 дает 260мс.
А чуть-чуть более умный:
Parallel.For(
0,
_height,
y =>
{
var line = data[y];
for (var x = 0; x < _width; x++)
line[x] = line[x] < 128 ? (byte) 0 : (byte) 1;
});
65 мс.
Получается, уложился почти с 5-тикратным запасом.
Только DSL на таких примитивных задачах, разумеется, мало что даст.
А вот если SSE и CUDA понадобится, то там уже DSL заработает в полный рост.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, WolfHound, Вы писали:
T>>2. компиляторы хорошо идут только у тех кто хорошо знает математику WH>Для того чтобы писать компиляторы матан знать не нужно.
Матан не нужно. А вот CS (ну или ПМ в отечественной терминологии) было бы мягко говоря, неплохо.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, oldjackal, Вы писали:
O> Из жизни, из практики. А преподаватели — это недоумки-теоретики, в основном. Много вы видели в ВУЗах преподавателей с реальным опытом в индустрии?
Я себя в КубГУ в прошлом году видел. ABBYY вот на физтехе тоже силами своих спецов лекции читает.
O> Они не только компиляторов не понимают, они вообще-то ничего не понимают.
А ты какой ВУЗ по какой специальности закончил, если не секрет?
O>Посмотрите на выпускников ВУЗов — они ни черта вообще не умеют
Выпускники, они разные бывают. Несколько человек на поток обычно вполне вменяемые. А остальные просто для корочки 5-6 лет отсидели, что то по ним мерять неинтересно.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, koodeer, Вы писали:
K>Поясню. Например, в обычном коде имеются две переменные типа double — масса и температура. Простой язык программирования никак не запретит допустим сложить две эти переменные: с точки зрения компилятор типы double можно складывать. Но с точки зрения физики массу и температуру складывать нет смысла: какая величина должна получиться?
На шаблонах С++ эту задачу можно решить довольно просто.
Показать, как или сам хочешь подумать?
K>Конечно, нечто подобное можно реализовать в ООП: создать классы Масса и Температура, переопределить операции сложения для них. Но очевиден оверхед: для простых типов данных будет использоваться класс, что и быстродействие снизит, и память жрать будет. В случае обработки миллионов значений это критично.
В случае с С++ это не проблема. Если в класс засунуть один double то там ничего кроме него не будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?
Это не серьезно.
Для того чтобы создать ДСЛ нужно садиться и анализировать предметную область.
Ибо создание ДСЛ == создание архитектуры.
Это один процесс.
Создание архитектуры даже сложнее, ибо кроме создания ДСЛ происходит еще и натягивание этого ДСЛ на ЯОН таким образом, чтобы код не превращался в говно. В случае с ДСЛ это не проблема. Ибо код на ЯОН генерируется.
Так что любой адекватный архитектор может спокойно создавать ДСЛи.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Лично для меня очевидно, что ДСЛ дающий делать больше чем нужно для решения задачи предметной области — это как минимум плохой ДСЛ.
О как долго я пытался тебе это лет несколько назад объяснить. Извини, не удержался.
VD> А скорее всего не ДСЛ.
VD>Польза ДСЛ в декларативности описания. Меньше кода, меньше ошибок, больше метаинформации.
И в идентичности его терминологии терминологии домена. Т.е. сущности в предметной области в соответствующем DSL часто являются first class citizen, в отличие от ЯОН.
Для примера (не для тебя лично, для тех кто топик читает), тот же язык запросов Паруса. Есть там такая штука — enum. По сути, в БД, это просто гуид из предопределенного набора значений. Если я хочу поработать с ним из голого SQL, то мне придется писать что то такое:
WHERE tbl.Attr = '67579290-3712-4b03-9C1F-06BA6FD97A2F'
или, если дописать udf, такое:
WHERE tbl.Attr = ENUM_VALUE('MyEnum', 'Value1')
И никакого контроля, кроме check constraint в рантайме.
В тоже время в DSL можно написать просто:
WHERE tbl.Attr = MyEnum.Value1
И компилятор статически ругнется, если попытаешься подсунуть не тот enum или не то значение.
VD>Если библиотека решает задачу на достойном уровне, то ДСЛ — оверкил.
+1
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, WolfHound, Вы писали:
WH>У тебя получается, что полные по Тьюрингу языки все ЯОН. Но по некоторым мутным причинам ты некоторые полные по Тьюрингу языки записываешь в ДСЛ.
Ограничения DSL заключаются не в ограничении Тьюринг-полноты, а в ограничении внешних возможностей. Например конструировании собственных типов определенного вида, использовании внешних библиотек и т.п.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, oldjackal, Вы писали:
O> Решение любой задачи вообще всегда сводится к созданию языка. Всегда. Достаточно заметить этот факт, и дальше все становится просто.
O> Посмотрите на историю развития науки. Каждая новая теория это язык. Каждая хоть немного новая и сложная задача решается через введение нового языка. Вся математика это не более чем коллекция разнообразных языков, созданных в разное время для решения возникающих в науке задач.
Влад верно сказал — практическая полезность всей этой философии тождественно равна 0. Под языком в DSL понимают вполне конкретный инструментарий, и не надо тут доказательствами по аналогии заниматься.
O>если узко мыслить в терминах существующих языков то можно не заметиь, что родился новый язык.
А зачем мыслить "широко"? Практический выхлоп из такого мышления какой?
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, WolfHound, Вы писали:
AVK>>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL? WH>Это не серьезно.
Как раз это — серьезно, коль уж вы претендуете на практическую ценность концепции. А общие слова не стоят ничего. Show me your code, как IT любит говорить.
WH>Для того чтобы создать ДСЛ нужно садиться и анализировать предметную область. WH>Ибо создание ДСЛ == создание архитектуры. WH>Это один процесс. WH>Создание архитектуры даже сложнее, ибо кроме создания ДСЛ происходит еще и натягивание этого ДСЛ на ЯОН таким образом, чтобы код не превращался в говно.
Ты мне хочешь расказать, что такое создание архитектуры и создание DSL? Спасибо, не надо. Show me your code.
WH>Так что любой адекватный архитектор может спокойно создавать ДСЛи.
Попробуй доказать.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, WolfHound, Вы писали:
AVK>>>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL? WH>>Это не серьезно.
AVK>Как раз это — серьезно, коль уж вы претендуете на практическую ценность концепции. А общие слова не стоят ничего. Show me your code, как IT любит говорить.
Здравствуйте, netch80, Вы писали:
N>Я поставил ему плюс именно за грамотные и интересные комментарии о DSL для пользователей — я раньше как-то не задумывался о том, почему большинство успешных из них так похоже на Basic.
SQL похож на бейсик? Всевозможные внутренние list comprehension или query comprehension? UML? HTML? XAML? Может XSLT?
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, Sinclair, Вы писали:
S>Во-вторых, всё же всё не настолько плохо, как вы говорите. В новом SQL
Я бы сказал, в "новом". SQL'99, однако, 13 лет уже тому.
S> есть with как способ введения "табличной переменной".
Он уродский. Ввиду старых заскоков они затолкали все это в одно выражение с мутноватыми правилами видимости внутренних имен реляций, что на читабельности сказалось далеко не лучшим образом. Куда проще было ввести, наконец, многострочность на уровне стандарта и сделать как то так:
PARAM @Org AS CHAR(3);
DEFINE
SELECT * FROM Users WHERE UserClass='A'
AS Admins;
DEFINE
CASE
WHEN @Org IS NOT NULL THEN
SELECT * FROM Users WHERE Origin=@Org
ELSE
SELECT * FROM Admins;
END
AS OrgAdmins;
SELECT * FROM OrgAdmins;
А так CTE на практике просто на редкость извратный способ получить в запросе ограниченную рекурсию.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
