Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, WolfHound, Вы писали:
AVK>>>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL? WH>>Это не серьезно.
AVK>Как раз это — серьезно, коль уж вы претендуете на практическую ценность концепции. А общие слова не стоят ничего. Show me your code, как IT любит говорить.
Ну ты тогда ты без сомнения на примере _этого_ кода покажешь преимущества ООП над процедурным программированием, не так ли??
Здравствуйте, Sinclair, Вы писали:
V>>А я не про DSL, а про то, что при наличии такой возможности многие DSL вполне могут служить языками общего назначения. Даже случайно. S>Вы так говорите, как будто это плохо.
Если я доверяю кусок кода непрофессионалу-бухгалтеру, то плохо, ес-но, т.к. он может банально всё уронить.
V>>С тобой не согласен синтаксис объявления функций без определения в С и ключевое слово extern для переменных. S>И тем не менее, никакого способа сообщить в языке "мне нужна эта библиотека" нету.
Вообще-то есть. Как прямо, так и косвенно.
V>>В общем, никогда в плюсах линкер не был отдельно, это часть языка. Хотя бы потому, что без знания ABI конкретного компилятора линковка невозможна. S>Простите, это чушь. Линкер всего лишь разрешает символьные имена. Никакой информации об ABI в нём нету.
ABI — это еще форматы объектных файлов и способов кодирования информации в них. Чтобы связать имена, надо знать как их искать.
S>И линкер не является частью языка C.
Сорри, за ликбез, но является обширной частью спецификации. В стандарте прямо упоминается внешнее и внутреннее связывание. Упоминается термин "единица компиляции".
Вот примеры конструкций из стандарта, которые управляют линковкой:
namespace/* anonimous */ {
int someInternalSymbol = 42; // можно включить по include, и у каждой единицы компиляции будет свой экземпляр
}
extern const int x = 42; // заметь, ключевое слово extern и инициализация одновременно, почему?static void foo() {} // что значит static для свободной ф-ии?static int y = 42; // что значит static для глобальной переменной?
Про платформенно зависимые pragma даже говорить неохота. Но справедливости ради pragma упоминается именно в исходном коде программы, а не аргументах командной строки линкера.
S>Вы правильно помните. Итак, стал ли Лого GPPL после добавления возможности импорта библиотек на том же Лого?
Т.е. если расширить спецификацию языка до вызова произвольных внешних ф-ий? На нем станет возможным писать код общего назначения, т.е. не только той направленности, под которую разработали язык.
V>>Тем, что в С можно подключать любые нейтивные библиотеки. Похоже, ты путаешь синтаксис языка и его полную спецификацию. Для того, о чем ты говоришь, есть скриптовые языки с практически полной иммитацией синтаксиса С за исключением вот этого extern и предварительного объявления ф-ий. Их как раз для своих DSL в "любимом синтаксисе" и разработали. S>Я как раз ничего не путаю. В JS я тоже могу подключать любые "нейтивные" библиотеки. Если хост будет столь добр, что разрешит CreateObject(), то я могу делать всё, что угодно.
Ну так хост не дается кем-то сверху, это именно ты хостишь JS, и ты можешь дать только то, что считаешь нужным. Я потому и использую для JS для своих инструментов в кач-ве DSL, что в нем изкаробки нет ничего, кроме голого синтаксиса, т.е. весь нужный функционал подается извне. Именно поэтому он БЕЗОПАСЕН для браузеров. Вернее, ровно наоборот — он был разработан таким, чтобы быть безопасным, поэтому такие ограничения.
S>В С роль хоста играет линкер.
Опять сорри за ликбез, но нет. CRT является частью языка и стандарта, позволяя писать практически что угодно без линкера. Т.е. реализация CRT не обязана поступать из неких внешних либ, компилятор может ее эммитить как угодно в конечный бинарник на своё усмотрение. Поэтому компиляторы автоматически линкуют программы к CRT, бо это требуется для обеспечения работы ф-ий из стандарта. Да, есть возможность управлять этой линковкой (напр. запретить линковать CRT, идущую по-умолчанию, или можно выбрать вид CRT), но вот это как раз эти моменты и есть подробности/частности реализаций, лишь подтверждающие правило.
Насчет твоих inp/outp. Если интересовался, то в защищенном режиме x86 порты отображены на карту виртуальной памяти. Во многих embedded-архитектрах, например PIC — точно так же без всякого защищенного режима — порты ввода-вывода лежат по специальным адресам. Но это фигня, дело-то не в порта, так? А в выполнении произвольной инструкции процессора, правильно? С/С++ чуть ли не единственные языки, где можно записать данные в некоторую область памяти (в сегмент данных, например) и передать туда управление. Так работают всякие нейтивные вирусы, писанные на С. Именно поэтому на DSL никак не тянут, т.к. подобное бывает случайно происходит даже у профессиональных программистов. И опция защиты исполнения данных тоже не глобальная ни разу, какими-нить настройками совместимости отключается аж бегом.
V>>А для какого-нить скриптового, со встроенным типом SomeType — вовсе не факт. Потому что помимо синтаксиса важна еще семантика происходящего. И эта семантика таки входит в спецификацию языка. S>Ок, тогда давайте вернёмся к вопросу определений. Как мы убедились, возможность подключать библиотеки сама по себе никак не влияет на DSLность языка.
В каком месте мы в этом убедились? На примере С/С++ никак не убедились, т.к. совокупность всех возможностей языка позволяет ему ставить раком произвольную аппаратную платформу.
В общем, своё видение DSL я уже описывал, могу повториться. В плане императивного DSL — для меня это любой язык, который "ничего не умеет сам", т.е. "замкнут сам в себе" в своих там арифметических выражениях, типах данных, пользовательских ф-ий и т.д. Я думал, что приведенные примеры JS и LUA должны уже были полностью пояснить точку зрения. Далее. Чтобы такой ограниченный язык сделать DSL, мы подаем в процессе хостинга некую внешнюю функциональность, которая позволяет решать задачи лишь из некоей узкой области. Зачем именно так? В этом случае вероятность "всё завалить" непрофессиональным программистом прикладной логики многократно меньше, чем если дать ему куда разбежаться. Даже если речь о самом себе, когда я хочу сосредоточиться на конкретной задаче, я сам себя считаю потенциальной "обезъяной с гранатой" и хочу себя ограничить, чтобы не забивать лишний раз голову. ИМХО, вполне нормальный подход.
Да и взять сами термины: на мой взгляд specific area отличается от general area границами и более ничем. Поэтому для меня императивный DSL — это в первую очередь ограничение области приложения, а затем уже хелперы и прочие плюшки. Например, с точностью до тонкостей синтаксиса можно этот HTML-DOM обрабатывать из какого-нить C# или С++ при подключенной соответствующей библиотеке.
Если же DSL декларативный, то есть ничего сам не делает by-design, а только описывает данные для интерпретатора этих данных, то тут ровно наоборот: степень его безопасности никак не изменится, даже если реализовать его в виде eDSL даже внутри исходников С++ программы. Поэтому подход декларатиного DSL я спокойно использую прямо в коде С++. В этом случае DSL — это лишь подход к решению задачи, через описание условий и применения некоего "решателя" для конкретной области. Соответствующее замечание на счет ссылки, приведенной в начале ветки, уже делал:
... по твоей исходной ссылке непонятно, зачем там была DSL? Замени :- на какой-нить << и будет тебе щастье прямо из твоего языка программирования, будь то C# или C++. Там же просто декларация правил для решателя,
Здравствуйте, vdimas, Вы писали:
V>Грамматика SQL проста до безобразия
Я бы так не сказал. Там местами даже в LL(k) не укладывается, LL(*) нужен.
V> и в сети лежит множество готовых парсеров, которые расширить на свои потребности можно с пол-пинка.
Парсер это примерно 5% потребной работы, если не меньше.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, Jack128, Вы писали:
J>Ну ты тогда ты без сомнения на примере _этого_ кода покажешь преимущества ООП над процедурным программированием, не так ли??
Зачем?
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Как раз это — серьезно, коль уж вы претендуете на практическую ценность концепции. А общие слова не стоят ничего. Show me your code, как IT любит говорить.
Покажи, как создать архитектуру вот по этому коду. Тот, что под cat. Re[12]: Языки общего назначения не имеют смысла!
Ты не сможешь.
ДСЛ тоже не сможешь. Ибо там уже потерялось куча информации о том, что же там происходит.
Да ты и сам по своему куску кода никогда в жизни ничего не спроектируешь.
Повторю еще раз: Для того чтобы сделать ДСЛ нужно проанализировать задачу. Проанализировать задачу на основе нескольких десятков строк кода невозможно.
И ты сам это знаешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Tanker, Вы писали:
T>даже в менеджед приходится спускаться на il.
IL приходится писать, потому что до 4 версии в фреймворке не было других способов динамической кодогенерации. В 3.5 появился ExpressionTree.Compile(), а в 4 ET дополнили стейтментами.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, WolfHound, Вы писали:
WH>Покажи, как создать архитектуру вот по этому коду. Тот, что под cat.
Ты что то перепутал. Я как раз таки не утверждаю, что спроектировать DSL легко.
WH>ДСЛ тоже не сможешь. Ибо там уже потерялось куча информации о том, что же там происходит.
Мне кажется, приведенный кусок значительно понятнее и очевиднее. Ну и я всегда готов ответить на дополнительные вопросы.
WH>Повторю еще раз: Для того чтобы сделать ДСЛ нужно проанализировать задачу.
Я с этим и не спорил. Я просто продемонстрировал, цитирую:
1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации.
2) Современные ЯОН совсем не так уж и ужасны при умелом использовании.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Jack128, Вы писали:
J>>Ну ты тогда ты без сомнения на примере _этого_ кода покажешь преимущества ООП над процедурным программированием, не так ли??
AVK>Зачем?
ну как. Ты взял произвольный кусок кода и предложил на этом примере доказать преимущество одной парадигмы программирования(не уверен, что правильно выбрал термин, не силен в теории) над другой. Я предложил сделать тоже самое.
Здравствуйте, oldjackal, Вы писали:
O>Вы очень неудачно пример выбрали. В любой CAS эта задача решается именно через правила переписывания, причем крайне простые: факторизация выражения ( раскрытие скобок) и подстановка коэффициентов в готовую формулу.
Ты про ресолвинг имен и вывод типов не забыл? Даже такая простая вещь, как свертывание константных выражений "подстановками коэффициентов в простую формулу" никак не решается.
Ты, случаем, семантический анализ с кодогенерацией не спутал?
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, Jack128, Вы писали:
AVK>>Зачем? J>ну как. Ты взял произвольный кусок кода и предложил на этом примере доказать преимущество одной парадигмы программирования
Тебе показалось. Я всего лишь предложил показать, как мог бы выглядеть DSL.
J>Я предложил сделать тоже самое.
В контексте топика твое предложение абсолютно бессмысленно.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
WH>>Покажи, как создать архитектуру вот по этому коду. Тот, что под cat. AVK>Ты что то перепутал. Я как раз таки не утверждаю, что спроектировать DSL легко.
Ты утверждаешь, что это сложнее чем делать архитектуру на обычных языках.
Но это не так.
Обрати внимание я тебе не ДСЛ предложил делать.
WH>>ДСЛ тоже не сможешь. Ибо там уже потерялось куча информации о том, что же там происходит. AVK>Мне кажется, приведенный кусок значительно понятнее и очевиднее. Ну и я всегда готов ответить на дополнительные вопросы.
Это он тебе кажется понятным и очевидным. Ибо ты его написал. А до этого проанализировал предметную область и сочинил архитектуру.
А для меня очевидна та гора кода. Ибо я сделал генератор, который ее генерирует.
WH>>Повторю еще раз: Для того чтобы сделать ДСЛ нужно проанализировать задачу. AVK>Я с этим и не спорил. Я просто продемонстрировал, цитирую: AVK>
AVK>1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации.
AVK>2) Современные ЯОН совсем не так уж и ужасны при умелом использовании.
Да ты что издеваешься что ли?
Я тебе про то, что задачу нужно проанализировать ты мне про квалификацию.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Jack128, Вы писали:
AVK>>>Зачем? J>>ну как. Ты взял произвольный кусок кода и предложил на этом примере доказать преимущество одной парадигмы программирования
AVK>Тебе показалось. Я всего лишь предложил показать, как мог бы выглядеть DSL.
на примере кода в 50 строк?? смеёшься?? Это тоже самое что предложить спроектировать иерархию классов на этих 50ти строках.
Здравствуйте, alex_public, Вы писали:
_>Ну так я про то и говорю, что кругом просто "размётка". И в этом случае я невижу никакого смысла для отдельного языка под это — проще сразу генерировать в редакторе готовый код на системном языке.
Генерировать то может и проще, а вот десериализовать его потом ...
_>А вот если бы у нас в gui dsl можно было бы задавать хотя бы минимальные действия...
Есть и такое. Например, WPF/XAML. Отработка на самого себя и другие контролы, а так же несложная анимация задаются декларативно прямо внутри XAML.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, WolfHound, Вы писали:
WH>>>Покажи, как создать архитектуру вот по этому коду. Тот, что под cat. AVK>>Ты что то перепутал. Я как раз таки не утверждаю, что спроектировать DSL легко. WH>Ты утверждаешь, что это сложнее чем делать архитектуру на обычных языках.
Из этого никак не следует, что архитектуру сделать просто.
AVK>>Мне кажется, приведенный кусок значительно понятнее и очевиднее. Ну и я всегда готов ответить на дополнительные вопросы. WH>Это он тебе кажется понятным и очевидным. Ибо ты его написал.
Не угадал. Я его не писал. Я его даже не видел до того как в форум воткнуть.
WH>Я тебе про то, что задачу нужно проанализировать ты мне про квалификацию.
А вроде бы не тебе отвечал. И нигде не утверждал, что задачу анализировать не нужно.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>А вроде бы не тебе отвечал. И нигде не утверждал, что задачу анализировать не нужно.
Ох. Ты сам-то веришь, что задачу по этому куску можно проанализировать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Топик не об этом. Но расскажи.
Типичный пример лапша-кода.
код очень трудно читаем. что он делает и зачем он нужен понять трудно.
кучи даункастов
кучи null'ей, которые в разных случаях имеют неявный смысл
видно, что по коду проводились спонтанные рефакторинги, в результате остались намешаны разные уровни абстракции. В частности одну ветку "if (invAfter != null)" вынесли в подпрограмму, а во второй оставили низкоуровневый лапшу-код
напрашивается вынос из метода 3-х 4-х подпрограмм
Если перед выполнением "Manager.DeleteObjects(cardsDeleteSet)" надо сделать проверку "if (cardsDeleteSet.Count > 0)", значит внутри Manager.DeleteObjects определенно говнокод.
Использование бессмысленных идентификаторов
Метод с 6-ю параметрами, большую часть которых клиенты прилежно забивают нулями — говнокод.
Использование бессмысленных комментариев:
// удалить операции
DeleteInventoryOperation(relatedOperation);
Попытки с помощью комментариев прикрыть непонятный код:
// Найти все связанные операции по видам учета
IInventoryOperation[] operations = inv.GetInventoryOperations(
null, InventoryOperationKindEnum.InternalDisplacement, (IDocument)doc, null, null, null);
Есть подозрение на использование синглтонов: Manager, LinkManager
Можно было бы обойтись без модификаций локальной переменной (cardsDeleteSet)
Здравствуйте, Sinclair, Вы писали:
S>>>И чем сложнее эти операции, тем сильнее рулит SQL. V>>Ну так в этом и дело, вы пытаетесь рассматривать только запросы в отрыве от всего остального куда входят сами базы данных, управление правами, пользователями, связи и отношения в таблицах, триггеры, процедуры и т.д. Сами запросы это вершина айсберга. S>Нет. Запросы — это всё-таки ядро. Управление правами и пользователями — это администрирование серверов баз данных. S>Но вы по-прежнему не понимаете одну главную вещь: скрипты SQL гораздо проще для управления БД, чем любые библиотеки на С++.
Как я сказал уже это от базы данных зависит. Как вы к примеру собираетесь через SQL управлять реестром винды? Или файловой системой? А это ведь тоже база данных. S>Совершенно неважно то, что сами базы данных — это большая и сложная область. Мы сейчас не сравниваем объём предметных областей. Мы сравниваем удобство и простоту различных языков для работы в этих областях.
Попу с пальцем сранивать бесполезно.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
ИМХО, вполне нормальный подход.
