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

Z>Насколько я понял, это не аналог, фишка в том, что функция определяется только в случае когда h(x, y, z) is not null, если это так, то синтаксис вполне нормальный. В вашем же случае функция есть всегда, но иногда возвращает null.

Скажем так, это примерно аналог. Только первый вариант c return зачем-то имитирует императивные языки в отсутствие contol flow, а второй может и был бы нормальным, если бы у нас процентов 80 вычислительной логики не описывалось бы подобными инструкциями, и было бы true/false/null, а не true/null.

Цели сделать синтаксис близким к каким-то распространенным языкам (тем более императивным) не было, потому что платформа в основном предназначена для тех, кто их все равно не знает. Это должен быть примерно уровень 1C/ABAP программистов и толковых бизнес-аналитиков.

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

Z>Да, fluent интерфейс тут мог бы помочь, но его проектирование, разработка и поддержка не легче проектирования, разработки и поддержки отдельного DSL. Ибо это тоже DSL, только с очень ограниченным синтаксисом.

А что с чем сравнивается, современные IDE с мега-супер-шедевром от WH лет через десять ?

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

Z>Да, fluent интерфейс тут мог бы помочь, но его проектирование, разработка и поддержка не легче проектирования, разработки и поддержки отдельного DSL. Ибо это тоже DSL, только с очень ограниченным синтаксисом.

С флюент интерфейсом цикл разработки короче. Берешь любой код любого девелопера, рефакторишь, сообщаешь об изменениях и все готово.

С языком все не так — девелопер должен вкурить сам язык, на это уходит время, просто сообщить об изменениях не получится по твой же причине — все изменения надо долбить и долбить, особенно если изменения нетривиальные вроде замены insert на insert into. Даже если предположить, что инструменты одинаковы по мощности в обоих случаях, изменения в языке гораздо медленнее доходят до людей. Это заметно уже по тому, как медленно люди осваивают новые кейворды скажем в том же C#. Даже свежак в микрософтовском до сих пор бывает идет с самопальными коллекциями, итераторами и прочей ересью. Про await и говорить не приходится.

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

I>А что с чем сравнивается, современные IDE с мега-супер-шедевром от WH лет через десять ?

Я сейчас сравнивал с fluent на C# с DSL на текущей версии Nemerle. С моим небольшим (по сравнению с WH) опытом на этом языке я предпочту написать простенький DSL, чем городить кучу интерфейсов и их реализаций для fluent. У реализации DSL будет прямее логика, проще и легче для поддержки код.

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

Z>Я сейчас сравнивал с fluent на C# с DSL на текущей версии Nemerle. С моим небольшим (по сравнению с WH) опытом на этом языке я предпочту написать простенький DSL, чем городить кучу интерфейсов и их реализаций для fluent. У реализации DSL будет прямее логика, проще и легче для поддержки код.

что, немерл уже научился автоматически макры рефакторить ?

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

Z>>Я сейчас сравнивал с fluent на C# с DSL на текущей версии Nemerle. С моим небольшим (по сравнению с WH) опытом на этом языке я предпочту написать простенький DSL, чем городить кучу интерфейсов и их реализаций для fluent. У реализации DSL будет прямее логика, проще и легче для поддержки код.

I>что, немерл уже научился автоматически макры рефакторить ?

Нет, но для нормального рефакторинга флюента (с изменением синтаксиса) автоматических средств все равно будет недостаточно. А менять синтаксис в DSL будет даже проще.

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

Z>Я сейчас сравнивал с fluent на C# с DSL на текущей версии Nemerle. С моим небольшим (по сравнению с WH) опытом на этом языке я предпочту написать простенький DSL, чем городить кучу интерфейсов и их реализаций для fluent. У реализации DSL будет прямее логика, проще и легче для поддержки код.

С языком получается примерно так — пишешь первую версию, отдаешь разрабам, они быстро плодят в десятки раз больше кода, чем ты этого ожидал. Ты меняешь чтото в языке и тут надо обладать достаточной харизмой что бы убедить разрабов переписать их код.
Вобщем обычно ни у кого не хватает достаточной харизмы уже к третьей итерации + на каждые изменения разрабам нужно долго втыкать в код, поскольку у них нет той степени понимания вычислительной модели и разных требований-ограничений.
В случае с библиотекой можно добиться того, что бы код рефакторился без привлечения самих разрабов, главное что бы они тесты реализовали в самой первой версии.

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

Z>Нет, но для нормального рефакторинга флюента (с изменением синтаксиса) автоматических средств все равно будет недостаточно. А менять синтаксис в DSL будет даже проще.

За счет чего проще ? Изоляция-переколбас-инлайн работает на раз с флюент интерфейсом. А вот непонятно, как это будет работать хотя бы с макросами Ну вот хотя бы изменение сигнатуры макроса, насколько легко это сделать, если скажем 10 разрабов колбасят код на старой версии макров денно и нощно ?

Здравствуйте, AndrewVK, Вы писали:
AVK>Нет, не доказывает. DSL это не весь линк, а конкретно query comprehension. И вот лично я им практически никогда не пользуюсь. Ключевой момент языка, который меняет картину, это прежде всего механизм квазицитирования ака expression tree, и это вполне себе general purpose штука, а никак не DSL.
Не соглашусь. В до-expr-tree-эпоху описывать выражения можно было только чудовищно неудобным образом.
А потом в шарп встроили специальный отдельный язык для описания деревьев выражений.
Он издалека, конечно, похож на "лямбду", но ведь мы хорошо знаем, что это вовсе не она. Далеко не всё то, что позволено в делегате, разрешено и в expression tree.
Так что этот язык вполне себе доменно-специфичный.
То, что его, в свою очередь, используют для других доменно-специфичных вещей — результат природы самого этого языка.
Ну, то есть с высоты птичкиного полёта это примерно то же самое, как и наличие в С++ (в отличие, скажем, от оригинального труъ фортрана) специального DSL для описания "строковых констант", с блэкдэжеком в виде zero-termination. Если выкинуть из плюсов понятие строковых констант, то мы по-прежнему сможем плодить char[] вручную.
Отсутствие строк в фортране явно показывает, что даже такая простая вещь была за пределами его домена (по матмоделированию).
А теперь модные пацаны в дотнете изображают на основе такой высокоуровневой конструкции, как строка, совсем уж запредельный стуфф типа connection strings, URI, и Regular Expressions.

Точно так же и появление в шарпе подъязыка для домена "описание деревьев выражений", который сам по себе мало кому нужен (т.к. люди, пишущие прикладные программы в домене "манипуляции деревьями выражений" встречаются чуть реже, чем никогда), позволяет внезапно построить на его основе DSL для таких мегаполезных доменов, как решение систем уравнений на основе Z3 и порождение статически валидируемого SQL кода.

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

AVK>Осталось заметить, что, в итоге, все выжившие более менее поддерживают единый отраслевой стандарт, а не каждый свой язык изобретает. Надо объяснять почему?

То же самое мы наблюдаем в мире библиотек. Сначала каждый пишет свой личный набор классов-контролов, потом появляются призанные производители, потом постепенно всё, кроме двух-трёх альтернатив вымирает.
Так и тут — будут миллионы недоDSL, будут десятки коммерческие либо опенсорсные DSL в духе рельсов, и будут доминаторы в каждой конкретной области.

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

M>Каким образом SQL обеспечивает ACID, можно узнать?
Очевидно, при помощи ANSI SQL конструкций begin transaction/commit transaction/rollback transaction.
Про set transaction isolation level я уж и не говорю.
M> А то в MySQL есть движок без гарантий ACID, но в нем есть SQL.
Это такой же SQL, как я — Эрик Мейер.

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

AVK>Это я писал, а не Синклер. Что конкретно тебя интересует? Ошибки, собственно, две основных — попытка сделать язык близким к естественному английскому, что привело к тяжеловесному индексу, и крайняя бедность средств декомпозиции, из-за чего копипаста в сиквеле цветет махровым цветом.
Да я тоже это уже писал и неоднократно.
Плюс ещё прочное желание игнорировать сравнительные частоты различных сценариев в угоду "ну у нас же есть многословный и корявый способ сделать то же самое".
Из-за чего скажем джойны очень долго находили себе место в языке, а для star-join, который и нужен в 99% случаев всех джойнов, и до сих пор приемлемо нормального решения нет.

M>>Каким образом SQL обеспечивает ACID, можно узнать?
S>Очевидно, при помощи ANSI SQL конструкций begin transaction/commit transaction/rollback transaction.
S>Про set transaction isolation level я уж и не говорю.
M>> А то в MySQL есть движок без гарантий ACID, но в нем есть SQL.
S>Это такой же SQL, как я — Эрик Мейер.

Пробежался глазами по стандарту SQLя (92, правда, а не более новым). Все нормально READ UNCOMMITED isolation level и вперед.

ЗЫ. И да, судя по стандарту, там взаимное влияние развития движков на SQL и SQLя на движки. То есть да, можно сказать, что SQL гарантирует транзакции.

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

Z>Ты еще конфиг для sendmail вспомни. Вот уж где эпичный фейл DSLстроения, но немногие хорошо освоившие юзают и считают, что без него было бы хуже.

У него вообще-то фейл не в самом языке (он был как раз хорош — ты не хочешь посмотреть, как разбираются адреса вида <@a,@b:c%d!e@f>, а?), а в том, что дальше его начали применять совершенно не к месту.
И вот тут все недостатки подхода вылезли в полный рост.

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

S>А потом в шарп встроили специальный отдельный язык для описания деревьев выражений.

Нет специального отдельного языка. Есть тот же самый шарп, хоть и несколько ограниченный (даже ключевого слова отдельного для ЕТ не вводили). Разница не в языке, разница в том, куда дерево направляется после универсального семантического анализа — на генератор прямого IL или генератор IL генерирующего дерево.

S> Далеко не всё то, что позволено в делегате, разрешено и в expression tree.

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

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

S>То же самое мы наблюдаем в мире библиотек.

Конечно же нет. Аналогом сиквела был бы подход, применявшийся Саном в джаве, когда выпускается стандартный набор контрактов, а потом под него несколько производителей выпускают свои реализации.
А в дотнете мы наблюдаем прямо противоположное — даже сам МС, выпуская две библиотеки, скажем UI, сделал абсолютно непохожие контракты у WPF и WinForms. Аналогом в случае СУБД были бы абсолютно непохожие языки запросов у каждого независимого производителя.

S>Так и тут — будут миллионы недоDSL, будут десятки коммерческие либо опенсорсные DSL в духе рельсов, и будут доминаторы в каждой конкретной области.

Ага, ну то есть все сведется к тому, что DSL будет стандартным для отрасли в целом, типа какого нибудь UBL, и каждый будет свою реализацию при необходимости для него делать. Только что то мне подсказывает, что апологеты DSL в этом топике совсем не это имеют в виду.

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

S>Плюс ещё прочное желание игнорировать сравнительные частоты различных сценариев в угоду "ну у нас же есть многословный и корявый способ сделать то же самое".

Это вообще не лечится. Ну вот есть старая как мир задача — лимитировать выборку. У постгреса и sqlite есть идеальный, на мой вкус, для этого синтаксис — <запрос> LIMIT 123 OFFSET 456. В 2008 комитет разродился поддержкой сего в стандарте. Вот только синтаксис ... Ну я просто пример приведу:

SELECT ROW_NUMBER() OVER(ORDER BY SalesYTD DESC) AS Row, 
    FirstName, LastName, ROUND(SalesYTD,2,1) AS "Sales YTD" 
FROM Sales.vSalesPerson
WHERE TerritoryName IS NOT NULL AND SalesYTD <> 0;

Не, я так подозреваю что этот вариант будет покруче в плане возможностей, так как поддерживает какие нибудь хитро высушенные сценарии, когда ограничивать выборку надо каким нибудь череззаборным способом. Но в 99.99% случаев, когда мне просто страницу надо выдрать отсюда досюда, писать такое угробище ...
Вот и с СТЕ тоже самое — вроде и сделали какой то способ реюза кусков запроса, а результат такой что лучше бы они ничего не делали. Вот что им мешало вместо уродского синтаксиса СТЕ сделать что то похожее на линковский let?

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

AVK>Нет специального отдельного языка. Есть тот же самый шарп, хоть и несколько ограниченный (даже ключевого слова отдельного для ЕТ не вводили).
По факту — есть. То, что он "тот же самый", неверно. Синтаксис — тот же. Семантика — совершенно другая.
Ключевого слова не вводили, а могли бы. Обошлись без него, магией компилятора. С ключевым словом было бы надёжнее, не требовалось бы угадывать, что требуется — делегат или ExprTree.

AVK>Разница не в языке, разница в том, куда дерево направляется после универсального семантического анализа — на генератор прямого IL или генератор IL генерирующего дерево.

AVK>Ну и что? В инициализаторе поля тоже не все позволено, но от этого выражения в этом инициализаторе не становятся другим языком.
Семантика выражений в инициализаторе поля и семантика выражений в expression tree существенно разная.

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

AVK>Конечно же нет. Аналогом сиквела был бы подход, применявшийся Саном в джаве, когда выпускается стандартный набор контрактов, а потом под него несколько производителей выпускают свои реализации.
AVK>А в дотнете мы наблюдаем прямо противоположное — даже сам МС, выпуская две библиотеки, скажем UI, сделал абсолютно непохожие контракты у WPF и WinForms. Аналогом в случае СУБД были бы абсолютно непохожие языки запросов у каждого независимого производителя.
Так и было. Базы данных существуют значительно дольше, чем SQL. Просто за истекшее время он выдавил с рынка почти всех. И несмотря на это, NoSQL сейчас лезут как грибы после дождя.

AVK>Ага, ну то есть все сведется к тому, что DSL будет стандартным для отрасли в целом, типа какого нибудь UBL, и каждый будет свою реализацию при необходимости для него делать. Только что то мне подсказывает, что апологеты DSL в этом топике совсем не это имеют в виду.
Они имеют в виду стандартную закономерность: чтобы ваша сборная выиграла чемпионат, нужно, чтобы десять лет в футбол играли в каждом дворе. Тупо вбухать денег в покупку и тренировку 11 человек даёт не тот же результат.
Так и с DSL — для того, чтобы были единицы мегаудачных языков, должны создаваться (и умирать) тысячи кандидатов.

Здравствуйте, AndrewVK, Вы писали:
AVK>Не, я так подозреваю что этот вариант будет покруче в плане возможностей, так как поддерживает какие нибудь хитро высушенные сценарии, когда ограничивать выборку надо каким нибудь череззаборным способом. Но в 99.99% случаев, когда мне просто страницу надо выдрать отсюда досюда, писать такое угробище ...
AVK>Вот и с СТЕ тоже самое — вроде и сделали какой то способ реюза кусков запроса, а результат такой что лучше бы они ничего не делали. Вот что им мешало вместо уродского синтаксиса СТЕ сделать что то похожее на линковский let?
Тут — понятно что. Они боятся вводить какие-то вещи "в ширину", т.к. это снижает шансы получить распространение реализации стандарта за обозримое время. Фактически, они надеются уговорить вендоров сделать только одну фичу, и хотят засунуть в эту фичу 50 пользовательских сценариев. Типа если бы они сразу предложили 50 фич, по одной на сценарий, то вендоры бы реализовали по 2-3 фичи, причём каждый свои.