Re[16]: Языки общего назначения не имеют смысла! - Философия программирования

Здравствуйте, oldjackal, Вы писали:

O>>> Сформулированная задача — это уже формализованная задача. По определению. А если задачу даже сформулировать не осилили, то уж и закодировать решение в лоб никто не сможет.

T>>Я сколько ни работаю, все время все приходится формулировать и формализовывать самому

O> Что, и задачи себе самому придумывать приходится? Сам пошутил, сам посмеялся?

"иди туда не знаю куда и принеси то не знаю что" @

T>>>> Например потому, что придется вводить десяток другой дсл для частных задач и организовывать взаимодействие этих дсл.
O>>> И именно такой подход к быстрому прототипированию и работает быстрее и надежнее всех прочих. Вы не знали?

T>>Покажи пример.

O> Ну вот, например: http://ahefner.livejournal.com/20528.html
O> Или вот: http://homepage.mac.com/digego/study_in_keith.mov

Где там "десяток другой дсл для частных задач и организовывать взаимодействие этих дсл" ?

T>>Еще раз — на проект затрачена определенная сумма, которая кроме зп всех вовлеченных (разрабы, тестеры, маркетинг, менеджмент и тд) включает в себя и аренду, и железо и командировки и все возможные налоги и вызов девок для празднования майлстонов.
T>>ЗП(гросс) всех разрабов вместе с тестерами это 10% от всей суммы.

O> Да кого это колышет-то? Вы-то сначала про время чего-то там говорили.

Это волнует мендеджмент который в бизнесе

T>>Вроде умные люди, а азы экономики понять не могут

С т.з. бизнеса нужно или урезать затраты наибольшей части, 90% или же делать так, что бы общий расклад приносил денег больше. Второй вариант это норма для софтверной индустрии.

O> Вот не надо мне про экономику заливать. Не интересно мне выслушивать про экономику от человека, не понимающего смысла "time to market".

Вот благодаря этому time to market и появляются решение string.split вместо CSV-парсера. Пока один пилит dsl и покрывает тестами, другой без тестов и вливает string.split в продакшн и получает профит.
В долгосрочной перспективе нужен дсл. В краткосрочной, например что бы тупо вырвать тендер, в ход идут любые средства, что бы продемонстрировать первый результат. Кто показал первый результат, тот и получает основные деньги.

T>>Ну то есть, для распознавания aaa ты используешь регулярные выражения, а для ббб тебе вдруг понадобится другой мощный механизм ? Я даже не знаю, что и сказать.

O> Как-то так. Для распознавания регулярной грамматики я буду использовать один DSL (регулярные выражения), для распознавания контекстно-свободной грамматики — совсем другой (например, PEG). Вся идея DSL в том, что надо решать конкретные частные задачи, а не искать ненужные в данный момент обобщения.

Правильно. Почему ты решил что UI это разные случаи не совсем ясно.

T>>Не я преувеличиваю, а ты сам только что плакался, что не можешь найти толкового студента-выпускника.

O> Я где-то говорил, что они глупые и "не толковые"? Я говорил, что они не умеют программировать, и что ничему хорошему их преподаватели не научили. Но это не беда, дурное дело не хитрое, быстро научить можно. Программирование вообще тривиально, если не переусложнять его искусственно всякими там ООПами да паттернами.

"в геометрии достаточно трёх аксиом"

T>> Но почему то простую истину про корреляцию разницы в квалификации с доступностью на рынке труда доказываю тебе именно я, хотя плачешься именно ты.
O> Я не спорю, что есть корреляция. Разница в том, что я устанавливаю планку намного ниже. Как по мне, если человек fizz-buzz смог закодить, то он уже адекватный программист. И компиляторы писать научится без проблем. Вы же утверждаете, что это только редкие высокооплачиваемые ковбои могут, что есть чушь и бред, и опровергается практикой.

То есть, готов брать людей на работу по одному только тесту fizz-buzz ?

T>>Не далее чем пару сообщений назад ты назвал людей из конторы-гиганта идиотами.
O> Это софтовая контора? Не верю. В софтовой конторе такого быть не может. Не представляю себе Microsoft или Google, где парсили бы CSV сплитом. А в не-софтовых, конечно же, любой дряни хватает.

Софтовее некуда. А в Микрософте и не такое случается

Я чет смотрю, чем больше гигант, более гигантские глупости случаются и это как то слабо коррелирует с доходностью бизнеса.

Здравствуйте, Sinclair, Вы писали:

M>>Чем не DSL?

S>Всё зависит от того, что нужно делать дальше. Возможно, захочется обращаться к колонкам типизированно; возможно, захочется обращаться по именам, а не номерам; возможно, захочется понимать написанные там формулы Excel.

Тут самое интересное начинается. Есть ДСЛ для организации всяких импортов ?

Здравствуйте, Sinclair, Вы писали:

V>>После этого подставляешь имеющиеся алгоритмы, реализующие примитивы РА над нужными структурами, в которых хранятся данные сущностей Manager, City и прочих. Сами алгоритмы могут быть как энергичными, так и ленивыми на итераторах...
S>Ничего не понимаю. Мы всё ещё говорим о попытке заменить DSL библиотекой, да?
S>Ну вот я и прошу вас показать мне, как будет выглядеть прикладной код, когда библиотека будет написана.

Ну, во-первых запрос мне кажется некорректным, т.к. не выведет менеджеров, у которых не было продаж вообще.

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

Для первого уровня как-то так:
АПИ библиотеки (const и & везде опускаю для краткости):

template<typename Enitity, typename Predicate, typename Transform>
Iterator<typename Transform::ResultType> select(Iterator<Entity> i, Predicate p);

template<typename Enitity, typename Transform>
Iterator<typename Transform::ResultType> transform(Iterator<Entity> i, Tranform t);

template<typename Enitity, typename GroupBy>
Iterator< pair<typename GroupBy::KeyType, Iterator<Entity> > > group(Iterator<Entity> i, GroupBy groupBy);

template<typename Value>
struct BetweenPredicate { 
  Value v1, v2; 
  bool operator()(const Value & v) { return  v>=v1 && v<=v2; } 
};

template<typename Entity, typename Value>
struct MemberBetweenPredicate { 
  Value Entity::* member;
  BetweenPredicate<Value> between;
  bool operator(Entity e) { return between(e.*member); } 
};

Прикладной вызов либы как-то так:

struct OrderTotal { ManagerID managerId; double amount; }

auto annual = select(from(orders), between(cdate("20100101", &Order::orderDate, cdate("20101231")))
auto byManager = group(annualOrders, groupBy(&Order::managerId));
auto orderTotals = transform(byManager, transformWrap<OrderTotal>((_1.managerId=_2.first, _1.amount=sum(_2.second, &Order::amount)) ));

Дальше лень расписывать, пока было расписано подвыражение:
select ManagerID, sum(Orders.Amount) from Orders where Orders.OrderDate between '20100101' and '20101231' group by ManagerID;

Типы результатов продукций/пересечений вводить так же, как было показано для transform.

Можно спросить, что ты хотел узнать? На Клиппере пожестче было в свое время — никто не жаловался. И рвали по быстродействию любые базы, бо скомпилированный код многократно быстрее интерпретируемого работает.

V>>Если же ты о перезаписи операций и прочей оптимизации — то это совсем отдельные операции, которые тоже, впрочем, достаточно формализованы.
S>Хотелось бы, чтобы перезапись операций и прочая оптимизация были не хуже, чем в SQL.

Это нужен подход №2, когда выражение дается в виде декларации и доступно затем для аналитических вычислений. Тогда точно так же как показано выше в синтаксисе, но пусть select, from, transform и т.д. являюся не вызовами на обработку коллекций, а конструкторами узлов графа операций (аналог AST). Добавится лишь еще одна команда, нечто типа:

auto resultingCollection = execute(result);

Аналогичное я делал для описания грамматики прямо в С++ и затем генерации/минимизации по описанию лексера и LR(1)-парсера. Оба табличные, ес-но.

V>>Таким макаром можно далеко пойти, называя матаном любую формальную модель... даже если это модель табурета.

S>Прочитайте по ссылке. В интернетах матаном называют любую формальную модель.

Даже на этом сайте "профессионалов"? Не замечал.

В любом случае, прикладные модели, которыми будет оперировать прикладной специалист (не программист) тоже могут быть формальными. Опять получается бессмыслица в аппелировании к такому толкованию "матана".

Здравствуйте, WolfHound, Вы писали:

G>>Не уходи от ответа.
G>>1) Что за проект?
WH>Обработка изображений.

А можешь ответить на такой вопрос. На каком языке надо писать бинаризацию изображения? Дано greyscaled (8bpp) изображение, сделать черно-белое.

Условия :

Картинка размером от 3000*5000 до 5000*6000 пикселей, размер файла 15-30 Мб.
Время на обработку — 200-300 мсек на современном процессоре. Не уложишься — считай, что задача не решена.

Я ее писал на С. Наверное, неправильно делал. Расскажи, на чем надо было бы писать.

Здравствуйте, Sinclair, Вы писали:

V>>Но вообще, если программа, порождаемая языком, работает сверху ОС, то языку необходимо только умение подключать библиотеки и больше ничего, чтобы превратиться в язык общего назначения.
S>Мне не нравится этот критерий. Потому что он слишком сильно противоречит бытовому понятию DSL.

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

S>Скажем, Clipper, который, в отличие от VBA, явно заточен на конкретный домен, получается GPPL, т.к. в нём можно подключать библиотеки.

Дык, я и видел на Клиппере "просто программы" в своё время.

Потому что в нем была библиотека GUI для DOS и у него был компилятор.

V>>Поэтому строгий DSL никак не сделаешь на основе языков, которые умеют это изкаробки.
S>Вот это опять непонятно. Что именно называется "это"? Наличие встроенных в языке средств импорта библиотек?

Да, так считаю. Потому что внешние DSL для того и нужны, что eDSL — это дыра в безопасности "скрипта". DSL — это всегда ограничение. Это ограничение, с одной стороны позволяет минимизировать синтаксис, с другой — повысить безопасность, как в плане случайных ошибок, так и в плане специальных.

S>Да ну! Вот, скажем, в языке C нет никаких возможностей импорта библиотек. Там всё, что есть — это текст одной программы.
S>Библиотеки в него потом запихивает линкер, который отдельный от языка.

С тобой не согласен синтаксис объявления функций без определения в С и ключевое слово extern для переменных. В общем, никогда в плюсах линкер не был отдельно, это часть языка. Хотя бы потому, что без знания ABI конкретного компилятора линковка невозможна. Поэтому нужен не просто линкер, а конкретный линкер для конкретного компилятора.

S>Давайте теперь я напишу версию лого, в синтаксис (и семантику) которого я добавлю IMPORT MODULE XXX. Он что, от этого внезапно станет GPPL?

Если в этих модулях будут ср-ва "общего назначения", типа ввода/вывода в файлы, сеть и т.д., то ес-но станет. Но, насколько я помню, в Лого таких ср-в быть не может, все его операторы — это оператор рекурсии и команд над черепашкой.

V>>Но на JS или LUA прекрасно сделаешь.
S>Объясните мне ещё раз, чем С в этом смысле хуже JS.

Тем, что в С можно подключать любые нейтивные библиотеки. Похоже, ты путаешь синтаксис языка и его полную спецификацию. Для того, о чем ты говоришь, есть скриптовые языки с практически полной иммитацией синтаксиса С за исключением вот этого extern и предварительного объявления ф-ий. Их как раз для своих DSL в "любимом синтаксисе" и разработали.

Т.е. я считаю, что по одному только синтаксису нельзя отличить DSL от не-DSL. Например, в C такая запись означает операцию копирования по-значению:

SomeType someVar = getValue();

А для какого-нить скриптового, со встроенным типом SomeType — вовсе не факт. Потому что помимо синтаксиса важна еще семантика происходящего. И эта семантика таки входит в спецификацию языка.

Здравствуйте, netch80, Вы писали:

O>> Неверно. DSL нужны там, где решение с DSL будет проще, понятее не поддерживаемее. Никаких таких "общих случаев" не надо, это совершенно нерелевантная тема.

N>Вы не противоречите друг другу. Но Tanker говорит о том, что разработка DSL полезна не для однократного случая, а для систематического решения задач какого-то специализированного типа.

Вот, такие простые слова но мне в голову не пришли

ДСЛ это долгосрочная перспектива и многократное решение схожих задач.

N>Наоборот, это разработка и реализация языков — сложная тема на всех уровнях.
N>А UI в своей базе примитивен до ужаса. Сложность там в основном в оптимизации юзкейсов.

+2

Здравствуйте, Sinclair, Вы писали:

VD>>Ничем. Но ДСЛ для фильров не должен позволять написать ДСЛ для фильтров, а только фильтры.
S>Ну, а язык для компиляторов не обязан позволять написать фильтр.

Не. Не так... "язык для компиляторов обязан НЕ позволять написать фильтр"

Если он это позволяет, то мы имеем овердизайн. В лучшем случае инструментом будет сложно пользоваться.

S> Или, по крайней мере, написать его удобно (понятно, что любой тьюринг-полный язык сразу даст написать и фильтр, и компилятор с DSL).

Вот именно. Вот только удобнее получается только, если язык ограничен и специализирован.

VD>>Это бессмысленная философия. Должно быть различие между двумя совершенно разными вещами.
S>Развернём утверждение: если чёткого различия нет, то две вещи не являются совершенно разными. Не так ли?

Если, то нет. Но четкая разница есть.

Почитал книгу Фаулера Предметно-ориентированные языки программирования.

В случае внешнего DSL имеется четкая граница между предметноориентированным языком и языком программирования общего назначения. Языки могут быть ориентированы на предметную область и при этом оставаться языками общего назначения. Хорошим примером в данном случае является R, язык и платформа для статистики; он имеет ярко выраженную направленность на работу со статистикой, но при этом имеет выразительные возможности универсального языка программирования. Таким образом, не смотря на его ориентированность на предметную область, я бы не назвал его предметноориентированным языком.

Более очевидным DSL являются регулярные выражения. Здесь ориентированность на предметную область (соответствие текста шаблону) сочетается с ограниченными возможностями, достаточными только для проверки соответствия текста. Одним из общих показателей DSL является то, что это не полный по Тьюрингу язык. Предметноориентированные языки обычно избегают обычных императивных структур управления (условия и циклы), не имеют переменных и не могут определять подпрограммы.

Многие могут не согласиться со мной и, используя буквальное определение DSL, будут утверждать, что такие языки, как R, должны рассматриваться как предметноориентированные. Поэтому я сделал сильный акцент на ограниченности выразительных возможностей как на важном отличии между DSL и языками общего назначения. Ограниченность выразительных возможностей придает DSL иные характеристики как в плане их использования, так и в плане реализации. Это приводит к отличию представлений о DSL по сравнению с языками общего назначения.

Давайте рассмотрим XSLT. Предфметной областью XSLT является преобразование XML-документов, но у него имеются все возможности, которых можно было бы ожидать от обычного языка программирования. Я думаю, что в этом случае способ применения языка важнее, чем сам язык. Если XSLT используется для преобразования XML, то это DSL. Однако если он используется для решения задачи о восьми ферзях, то это язык общего назначения. Конкретное применение языка может разместить его по обе стороны границы.

Другими словами — поддерживает мою точку зрения

.

S>Мне кажется, ты сравниваешь полноту по тьюрингу с проблемно-ориенированностью.

Я не сравниваю. Я считаю, что полнота по Тьюрингу — это признак ЯОН, но при некоторых оговорках. Скажем хотя SQL с CTE теоретически и стал полон по Тьюрингу, но написать на нем парсер будет крайне сложно. А вот на ВБА или 1Эс вполне.

S>На мой взгляд, они не являются взаимоисключающими.

Взаимоисключаемы ДСЛ-и и ЯОН-ы. Понятно, что полнота по тьюрингу не четкий критерий, но наличие процедур, циклов, условных операторов и прочего барахла, как бы говорит нам, что это 100% ЯОН. И не фига тут философствовать.

Говоря о чем-то нужно пнимать о чем идет речь. При очень вольной трактовке понятния ДСЛ его просто нельзя использовать, так как одним и тем же термином описываются принципиально разные вещи.

ЯОН со встроенным ДСЛ-ем не превращается в ДСЛ. ЯОН прикрученный к Ворду или броузеру не становится ДСЛ.

И все это потому, что ДСЛ — это не о том, что язык для чего-то заточен, а о том, что язык предназначен только для чего-то.

Еще одним показателем ЯОН-а является то можно ли на нем (без использования других языков) написать целую систему. Если можно — это почти наверняка не ДСЛ. Вот на 1Эс можно. А на SQL — нет.

Если для написания системы использует ДСЛ, то система уже обязана быть написана более чем на одном языке. Если это не так, то вас обманули.

VD>>Уж слишком разные требования и свойства у этих вещей.
S>Не вижу особенных различий в требованиях.

Это то и печально.

S> Вот, скажем, два языка — Паскаль и C++. Оба — GPPL ("можно написать все, что угодно"). Но в Паскале есть встроенная механика по работе с файлами фиксированной структуры (FILE OF TYPE), а С++ — механика перегрузки операторов. Почему? Надо полагать, у них отличаются домены.

Это не имеет отношение к делу. Ты как и многие не верно (прямолинейно) толкуешь термин ДСЛ. Кстати, у Фаулера об этом хорошо сказано:

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

Но буквальные определения часто неправильны: мы не называем монеты компактдисками, хотя это типичные диски, которые, конечно, более компактны, чем те, к которым мы применяем данный термин.

VD>>Кроме того тогда встает вопрс о том, что вместо ДСЛ можно использовать термин "язык". Ведь если мы дофилософствовались до того, что любой язык являетс ДС, то нафиг тогда нужна эта приставка?
S>Влад, с какого момента можно называть человека толстым? Где граница между "полным", "полноватым", и "склонным к полноте"?

Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем. А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.

Здравствуйте, PSV100, Вы писали:

PSV>А лично я от программирования в GUI-дизайнере как-то уже отошёл в сторону. Всё-таки неудобно, когда ты не видишь в виде удобного (!) кода то, чего создаешь, что изменяешь (дельфовские DFM-файлы — они не для этого), есть неудобное разделение — что-то нужно делать в дизайнере (в которых ковыряться мало удовольствия), а что-то нужно в коде ваять. К тому же дизайнерство ограничивает тебя в функционале, потенциале, несмотря на то, что например, в Delphi вполне мощная техника наследования форм. Кроме того, направленность на GUI-дизайнер влияет на архитектуру визуальной библиотеки, в результате, хоть в своём программном коде можно делать абсолютно всё (дизайнерство никак не ограничивает в коде), но работать с GUI в коде неудобно, громоздко (если с нуля что-то создавать).

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

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

PSV>Delphi повлиял на Net, там тоже любят дизайнеров. А вот в жабе как-то дизайнеры особо не востребованы. Там научились программировать, хотя джава как язык не фонтан для этого. Для расположения контролов используют выравниватели — layout manager.

Да, да, у нас тоже только на них всё. Никаких абсолютных координат (хотя возможность и для этого есть) и т.п. Иначе сделать автоматический перевод интерфейса очень напряжно. ) А так он работает из коробки. )))

PSV>Ну, прежде всего, нужно ориентироваться на конкретные задачи, конкретные потребности. А в таком, глобальном, масштабе я с тобой не соглашусь. Вот тот же HTMLLayout специально создавался с целью позволить разделить дизайнерчество от программирования, ну кроме того, чтобы дать возможность делать любой интерфейс и как-то упростить программирование.

HTMLayout — специфическое решение, которое приносит web-технологии в нативные приложения. Поэтому не очень укладывается в то разделение, про которое я писал. И таких решений много довольно. Тот же XULRunner. У меня пока смешанное отношения к ним и неясное видение их будущего...

PSV>

декларативное описание GUI. В рамках вэба стандарт является HTML, он же повлиял и на десктоп. Его недостаток в том, что он труден для восприятия и для прямой работы с ним. Также он затрудняет задачи локализации (разные варианты языков), если убрать из него содержательный текст, останутся только одни тэги, причём в этом случае они неудобны, ведь HTML — это язык для разметки элементов внутри текстового документа (для чего он и предназначался), а теперь текста и нет, сплошные неудобные угловые скобки. Но он стандарт, поэтому востребован.
HTML в чистом виде использует только подмножество нормального набора нативных контролов. В вебе это обычно расширяется вручную. Но мы же хотим использовать html как язык размётки...

PSV>Второй вариант, это DSL по мотивам JavaFX-скрипта, пример которого я приводил раньше. Он оперирует не текстом, а GUI-элементами: сценами и объектами внутри них. В принципе, тут даже и спецы-дизайнеры также смогут работать, ибо, как я понимаю, это уже тоже некий типовой промстандарт. Конкретно JavaFX-скрипт позволяет ещё и включать сразу в себя и программный код, внутри описаний, но этот вопрос решаем (в этом и плюс тоже, тут и дизайнерам может даже что-то пригодиться, но как-то это нужно ограничить, но не ликвидировать полностью).

Да, интересное решение.

PSV>А этот микрософтский XAML — в какой-то степени JavaFX-скрипт, но в XML-формате. Спецы по нему вроде только в рамках около WPF. Имхо, для ручной работы неприятен, несмотря на чудеса от IDE. Такой XML, как и в JavaFX, имхо, лучше применять в рамках кодогенерации, в т.ч. и при работе GUI-дизайнеров, для чего, в первую очередь, их и придумывают. Я же пытаюсь нащупать способ для простой жизни, без дизайнеров.

Ага. Хотя мне кажется что визуальные редакторы всё же удобны в определённых рамках.

PSV>

Нужно и удобное прямое алгоритмическое программирование GUI. Какое бы не было крутое декларативное описание, но всех потребностей оно никогда не покроет. Здесь какой-нибудь miglayout очень кстати (соответственно и декларативный DSL должен иметь как бы прямую связь с API языка программирования, т.е. в DSL задаются те же элементы, что и в этом miglayout).

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

Здравствуйте, Sinclair, Вы писали:

S>>>Складывается ощущение, что вы мне пытаетесь доказать, что можно заменить запрос на SQL процедурой на C++, причём последняя будет иметь сопоставимую с запросом сложность. Но этого не может быть, так как это, очевидно, неверно.
V>>Не так, в sql много чего кроме самих запросов. На самом деле сами запросы это вершина айсберга. Можно взять любой учебник по SQL и поисследовать на тему что ещё входит в "знания по SQL".
S>Ещё раз спрошу: какой тезис вы пытаетесь доказать или оспорить? Вам что, кто-то тут написал, что SQL — проще, чем С++?
А это что?

SQL является удобным и несложным средством описания сложных операций с данными.

По вашему получается что с++ по сложности вообще для первоклашек, раз так.

Здравствуйте, WolfHound, Вы писали:

V>>Не так, в sql много чего кроме самих запросов. На самом деле сами запросы это вершина айсберга. Можно взять любой учебник по SQL и поисследовать на тему что ещё входит в "знания по SQL".
WH>Только в этой теме говорится о том что аналогичный запрос на С++ будет на порядки сложнее.
Это вообще-то зависит от базы данных.
WH>Так что совершенно не ясно к чему ты это сказал.
Вот и мне не ясно почему вы приводите SQL как классический пример DSL, когда он вообще сам по себе и не доказывает что DSL может заменить языки общего уровня.

Здравствуйте, Tanker, Вы писали:

T>Поэтому, когда ты говоришь что преподают плохо, это значит, что в голове у преподавателей все еще земля на трёх китах. А это значит, что даже преподаватели еще не доросли до внятного понимания компиляторов.

Это потому что в этом мире рулят не правильные теории или красивые идеи, а реклама и пиар.

Вот в Америке сложилась традиционная школа основанная на BNF и LR-автоматных парсерах, и хрен ты им что объяснишь.

Берем книгу дракона, глядим... Ба да там ни TDOP Пратта, ни PEG Форда нет. Ну, с PEG еще можно понять. Ему не так много лет (хотя базе уже лет 40, не меньше). Но TDOP — это 1974 год.

А где доценты материал для курсов берут? Да из кнжек, что купили на Озоне, и из того пиара, что валит из-за всех дыр.

Здравствуйте, Sinclair, Вы писали:

S>Скажите мне Киса, как художник художнику, вот Аппель — он по делу пишет, или только теоретик? Я имею в виду http://www.cs.princeton.edu/~appel/modern/

Где берут сабж?

Здравствуйте, koodeer, Вы писали:

K>Скорее так: годами и десятками лет пытаются выразить специфику неудобными конструкциями языков общего назначения. Колются, плачут, но продолжают мучиться.

Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?

// откатить отработку документов в ХО
UncarryDocuments(objectsIds);
var cardsDeleteSet = new HashSet<IInventoryCardBase>();
var documents = Manager.Get(objectsIds);
foreach (IInternalDisplacementDocument doc in documents)
    foreach (IInventoryInternalDisplacementOperation obj in doc.GetObjects())
    {
        IInventory inv = obj.GetInventory();
        // Найти все связанные операции по видам учета
        IInventoryOperation[] operations = inv.GetInventoryOperations(
            null, InventoryOperationKindEnum.InternalDisplacement, (IDocument)doc, null, null, null);
        foreach (IInventoryOperation operation in operations)
        {
            IInventoryOperation relatedOperation = operation;
            // не должно быть более поздних операций
            if (inv.GetInventoryOperations(relatedOperation.AccountingKind, null, null, null, null, null)
                    .Any(op => op.Order > relatedOperation.Order))
                throw new BusinessException("После внутреннего перемещения не должно быть операций.");
            if (!Equals(relatedOperation.InventoryCardBefore, relatedOperation.InventoryCardAfter)
                    && !(relatedOperation.InventoryCardAfter is IAccrualAccountingInventoryCard))
                cardsDeleteSet.Add(relatedOperation.InventoryCardAfter);
            // удалить операции
            DeleteInventoryOperation(relatedOperation);
        }
        IInventory invAfter = inv.ChangesHistory;
        if (invAfter != null)
        {
            IInventoryCardObject invCardObj = invAfter.GetInventoryCardObject();
            if (invCardObj != null)
            {
                var card = ((IPersistedObject)invCardObj).Master as IInventoryCardBase;
                if (card is IAccrualAccountingInventoryCard)
                    Manager.DeleteObject((IPersistedObject)invCardObj);
                else if (!cardsDeleteSet.Contains(card))
                    invCardObj.Inventory = inv;
            }
            inv.ChangesHistory = null;
            ChangeInventoryActualStateInDocuments(invAfter, inv);
            ILinkManager linkManager = LinkManager;
            foreach (IObjectLink link in linkManager.GetAllInLinks(((IIdentifiableObject)invAfter).Id))
            {
                var linkDoc = link.Source as IDocument;
                if (linkDoc != null)
                    throw new BusinessException(InventoryIncludedErrorTemp, linkDoc.DisplayName);
            }
            Manager.DeleteObject((IPersistedObject)invAfter);
        }
        else
            ChangeInventoryActualStateInDocuments(inv, inv);
        // изменить ИО
        inv.MateriallyResponsiblePerson = doc.GetDelivererMateriallyResponsiblePerson();
        inv.StructuralSubdivision = doc.GetDelivererSubdivision();
    }
// удалить созданные при отработке инвентарные карточки
if (cardsDeleteSet.Count > 0)
    Manager.DeleteObjects(cardsDeleteSet);

... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>

Здравствуйте, VladD2, Вы писали:

VD>Где берут сабж?

Я года четыре назад его находил выложенным где-то.

Здравствуйте, Vain, Вы писали:

V>А это что?
V>

V> SQL является удобным и несложным средством описания сложных операций с данными.

V>По вашему получается что с++ по сложности вообще для первоклашек, раз так.
Ваша ошибка — в попытке оценивать сложность в отрыве от задачи. Для описания операций с данными SQL значительно проще, чем любой GPPL, будь то си, паскаль, или жава.
И чем сложнее эти операции, тем сильнее рулит SQL.

Здравствуйте, VladD2, Вы писали:

VD>Взаимоисключаемы ДСЛ-и и ЯОН-ы. Понятно, что полнота по тьюрингу не четкий критерий, но наличие процедур, циклов, условных операторов и прочего барахла, как бы говорит нам, что это 100% ЯОН. И не фига тут философствовать.

VD>Говоря о чем-то нужно пнимать о чем идет речь. При очень вольной трактовке понятния ДСЛ его просто нельзя использовать, так как одним и тем же термином описываются принципиально разные вещи.
И ты в поддержку этой точки зрения цитируешь Фаулера, для которого XSTL одновременно является и GPPL и DSL — в зависимости от задачи.

VD>И все это потому, что ДСЛ — это не о том, что язык для чего-то заточен, а о том, что язык предназначен только для чего-то.
Ок, так тоже можно. Но даже если мы будем судить о DSL-ности по тому, чего именно нельзя на этом языке, всё равно у нас будет континуум таких языков.

VD>Еще одним показателем ЯОН-а является то можно ли на нем (без использования других языков) написать целую систему.
Я уже в этой ветке писал, что это — не критерий. На языке C без использования других языков ничего полезного не напишешь, тупо потому, что в него кроме управляющих конструкций ничего не встроено. А библиотеки для него, обеспечивающие ему возможности для написания систем, написаны, очевидно, с использованием других языков.

VD>Это не имеет отношение к делу. Ты как и многие не верно (прямолинейно) толкуешь термин ДСЛ. Кстати, у Фаулера об этом хорошо сказано:
Прости, но Фаулер для меня не авторитет. Для тебя, кстати, тоже — см. противоречие выше.

VD>Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем.
Практика показывает, что толстость человека напрямую зависит от его окружения. В компании дистрофиков типа меня или Мерля любой покажется толстоватым.

А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.
ВБА — не DSL. В нём нет никакой доменной специфики. Про 1С ничего не скажу, в связи с некомпетентностью в нём.

От:	Sinclair	https://github.com/evilguest/
Дата:	13.04.12 15:18
Оценка:	+1

От:	Sinclair	https://github.com/evilguest/
Дата:	13.04.12 15:56
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	13.04.12 16:34
Оценка:

	От:	Tanker
	Дата:	13.04.12 17:10
	Оценка:

	От:	Tanker
	Дата:	13.04.12 17:13
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	13.04.12 21:29
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	14.04.12 04:01
Оценка:	+1