Re[30]: DSL'и и инструменты для них
От: meadow_meal  
Дата: 08.08.15 08:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

_>>Мне — автору библиотеки? Ниоткуда. Моя задача, чтобы пользователь, которому известно, мог этот метод вызвать без плясок с бубном.

WH>Какой ещё библиотеки?
WH>Я тебя вообще перестал понимать.
WH>Можешь чётко сформулировать задачу?

Библиотека, работающая с rpc-сервисом. Протокол (способ сериализации и передачи данных) известен, схема нет.

_>>Формально не описана = нет. Пока ты заставляешь пользователя что-то формально описывать, мой пользователь уже написал скриптик и пьет чай.

WH>Так откуда он вообще узнает что вызывать?

Это его проблемы. Это что за пример был, база документов? Ну вот, описал скажем пользователь свою коллекцию винила, ни о какой схеме не задумываясь, добавляя к документу поля произвольного типа по мере необходимости. А потом захотел узнать свой личный топ по 1972 году. Приложение ни о виниле ни о годах ничего не знает, его задача — дать пользователю ввести все что он хочет и не грузить типами и схемами, т.к. гуманитарий и ни в чем сейчас не уверен, спросите позже или никогда. Но при этом он четко помнит, что поле год у него называется или "year" или "released", другое дело что там наряду с 1972 или "Feb 1972" может встречаться "I don't know". Описать свой запрос в том или ином виде он в состоянии.

_>>Да и — в случае потока событий — что там насобирали с разных версий приложения, ни в какую схему не загонишь.

WH>Чего?

Чего — чего? Ну вот появилась задача, найди нам самые популярные торговые маршруты в данной игре, т.е. цепочку прохождения ключевых точек между покупкой предмета A и продажей предмета A в рамках одной игровой сессии (пример абсолютно произвольный). Данные о всех этих событиях два года собирали, просто до сих пор не нужны были, а тут дизайнеры заинтересовались, программистам же в свое время (два года назад) поставили задачу эти (и другие) данные сохранять в каком-то виде, они и сохраняли, но за два года много всего поменялось, поля добавлялись, удалялись, меняли тип. Более-менее я знаю что там, да и сэмплы данных за разные периоды посмотреть несложно, но формально описывать схему? Долго и нудно, увольте. А скрипт написать на динамике — запросто.

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

Ну а я задам встречный вопрос, что ты имеешь в виду, говоря что "схема есть". Есть у кого? Откуда? В каком виде? Ты правда в жизни имел дело только с типизированными данными?

_>>Простейший:

_>>
_>>if (accountUpdate.age != undefined)
_>>    account.age = accountUpdate.age;
_>>

WH>На статически типизированном будет примерно так же.

На C# — не будет. Хотя я уже понял тебя, что он плохой.

оффтопик:
Должен сказать, что уважаю твое мнение. В этом ты напоминаешь мне Каспарова (в хорошем и лестном — шахматном — смысле, и надеюсь, что это не будет сочтено переходом на личности). Для него — в шахматах — также всегда должен был существовать ответ, окончательная истина — да или нет, третьего не дано. Именно потребность в истине, сделавшая его величайшим шахматистом века, заставила его биться головой о Берлинскую стену в матче с Крамником, стоившем ему короны — ну не мог этот кривой вариант быть корректным. А C# плохой, потому что есть Nemerle, который объективно лучше. Мне нечего противопоставить этой объективности, я соглашаюсь (но вскоре реальный мир затянет меня обратно).

_>>Поэтому лучший пример — это Service.SomeMethod(...) для которого тебе придется возиться с генерацией кода по схеме, которой у меня нет.

WH>Да как ты вообще про этот метод узнал без схемы то?

В вики прочел. Или коллега по скайпу сообщил.

_>>Прежде чем возражать, уточню: ты действительно утверждаешь, что Эрланг — статически типизированный язык?

WH>Мы говорим про статически типизированный диалект.
WH>В котором типы описаны и проверяются статически.

Сдаюсь.

WH>>>После чего ты будешь ещё несколько месяцев вылавливать все места, где ты забыл изменить код.

WH>>>Короче рефакторинг в статике несравнимо быстрее.
_>>Не вижу смысла продолжать спор по этому пункту. Оба останемся со своим опытом.
WH>Ну так что ты будешь делать в случае с динамикой то?

Ничего не буду. Я уже писал, что этой проблемы не существует. Баги типизации крайне редки.

_>>Я не про качество, а про количество и сложность концепций.

WH>Как думаешь, какое ощущение будет у среднего питониста от этого кода
WH>http://pyparsing.wikispaces.com/file/view/pythonGrammarParser.py/30100174/pythonGrammarParser.py

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

WH>А такого?

WH>
WH>def perm(l):
WH>    sz = len(l)
WH>    print (l)
WH>    if sz <= 1:
WH>        print ('sz <= 1')
WH>        return [l]
WH>    return [p[:i]+[l[0]]+p[i:] for i in range(sz) for p in perm(l[1:])]
WH>


А здесь не понял, что сложного из концепций (языковых)? Слайсы и list comprehension?

_>>В Эрланге нет классов. (Напоминаю, что я говорил о поддержке конкретно Эрланга). Проблемы переименовать функцию, естественно, не возникает.

WH>Только методом глобальной замены имени.
WH>Только это может любой текстовый редактор, который про код вообще ничего не знает.

Чуть сложнее — нужно проверить arity и имя модуля. Но в целом да, это не проблема.

Что еще не работает?

_>>И как это сделать на работающем сервере?

WH>Ещё раз: Мы говорим про возможность.

Меня интересуют практические возможности, а не теоретические.
Re[19]: DSL'и и инструменты для них
От: alex_public  
Дата: 08.08.15 09:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Тут главная идея в иерархии языков.

WH>Те если у нас в стандартной поставке будет
WH>MSIL++ -> MSIL ибо MSIL ужасен. Делать переписывание напрямую в него весьма утомительное занятие.
WH>MSIL -> LLVM
WH>MSIL -> JavaScript

WH>То реализовав C# -> MSIL++ мы автоматом получим компиляцию C# в MSIL, LLVM и JavaScript.


Трансляция — это конечно хорошо, но что делать с рантаймом? Я вот даже не будут предлагать рассматривать такие не тривиальные случае как Пролог. Давай посмотрим на реализацию классического элемента большинства распространённых языков — исключения. Кто будет заниматься реализацией этого под нативный код? )
Re[20]: DSL'и и инструменты для них
От: WolfHound  
Дата: 08.08.15 19:55
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Трансляция — это конечно хорошо, но что делать с рантаймом? Я вот даже не будут предлагать рассматривать такие не тривиальные случае как Пролог. Давай посмотрим на реализацию классического элемента большинства распространённых языков — исключения. Кто будет заниматься реализацией этого под нативный код? )

Язык уровнем чуть выше, чем переносимый ассемблер.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[27]: DSL'и и инструменты для них
От: WolfHound  
Дата: 08.08.15 19:55
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Друг другу? ) Как ты вообще представляешь, чтобы скрипты реакции на ajax взаимодействовали друг с другом? ) Они же живут в полностью отдельных мирах. Естественно они работают с общими данными, но только через БД или клиентский JS.

Вот прямо из этого описания клиентские и серверные скрипты гоняют друг другу json.

_>Какой ещё метод по имени? )

fab смотрит fabfile.py и передает управление в функцию с соответствующем именем.
Больше он ничего не делает.

_>Там эмуляция шелла в языке, причём действующая одинаково и на локальной машине и на удалённой (по ssh). Так что там с одними нюансами ssh и перехвата ввода/вывода повозиться надо. )))

Все равно не вижу, что там больше одного дня писать.

_>Ну это спорный вопрос. Вот скажем какой-нибудь там IDispatch (на котором очень много чего работает) — это динамическая типизация или статическая? )

Динамическая.
Ты считаешь, что он появился от большого ума?

_>Да не о том речь. Ты вот попробуй написать свою функцию, которая скажем будет трансформировать какую-то строку и печатать в консоль результат. И сравни её объявление с аналогом на Питоне. )

Думаю, в большинстве случаев хаскель победит.

_>Да ладно, for'ы в подобных скриптах на каждом шагу.

100% этих for'ов сводится к fold, map или их сочетанию.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[31]: DSL'и и инструменты для них
От: WolfHound  
Дата: 08.08.15 19:55
Оценка:
Здравствуйте, meadow_meal, Вы писали:

_>Библиотека, работающая с rpc-сервисом. Протокол (способ сериализации и передачи данных) известен, схема нет.

Как библиотека может обратиться к серверу, если нет схемы сервера?

_>Описать свой запрос в том или ином виде он в состоянии.

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

_>Чего — чего? Ну вот появилась задача, найди нам самые популярные торговые маршруты в данной игре, т.е. цепочку прохождения ключевых точек между покупкой предмета A и продажей предмета A в рамках одной игровой сессии (пример абсолютно произвольный). Данные о всех этих событиях два года собирали, просто до сих пор не нужны были, а тут дизайнеры заинтересовались, программистам же в свое время (два года назад) поставили задачу эти (и другие) данные сохранять в каком-то виде, они и сохраняли, но за два года много всего поменялось, поля добавлялись, удалялись, меняли тип. Более-менее я знаю что там, да и сэмплы данных за разные периоды посмотреть несложно, но формально описывать схему? Долго и нудно, увольте. А скрипт написать на динамике — запросто.

При написании этого скрипта ты проделаешь всю работу по описанию схемы несколько раз.

_>Ну а я задам встречный вопрос, что ты имеешь в виду, говоря что "схема есть". Есть у кого? Откуда? В каком виде? Ты правда в жизни имел дело только с типизированными данными?

Даже у текстового лога, если на него внимательно посмотреть есть схема.
И если тебе этот лог нужно попарсить более одного раза, то описание схемы уже себя оправдывает.

_>Должен сказать,

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

_>Ничего не буду. Я уже писал, что этой проблемы не существует. Баги типизации крайне редки.

Так типы то не просто так меняются.
Нужно привести структуры данных в соответствие.

_>Безусловно, новичок потребует дополнительных объяснений от куратора.

Вот в случае с немерлом он тоже пойдёт к куратору.

_>А здесь не понял, что сложного из концепций (языковых)? Слайсы и list comprehension?

Тогда что ты сложного нашел в немерле?
Там в обычном коде нет ничего сложнее этого.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[28]: DSL'и и инструменты для них
От: alex_public  
Дата: 09.08.15 11:18
Оценка:
Здравствуйте, WolfHound, Вы писали:

_>>Друг другу? ) Как ты вообще представляешь, чтобы скрипты реакции на ajax взаимодействовали друг с другом? ) Они же живут в полностью отдельных мирах. Естественно они работают с общими данными, но только через БД или клиентский JS.

WH>Вот прямо из этого описания клиентские и серверные скрипты гоняют друг другу json.

JS и Python естественно гоняют друг другу. Но не Python и Python... )

_>>Какой ещё метод по имени? )

WH>fab смотрит fabfile.py и передает управление в функцию с соответствующем именем.
WH>Больше он ничего не делает.

Ааа ты про сам fab.exe? Не, я говорю про весь этот пакет, который включает ещё и соответствующие python библиотеки, реализующие тот самый DSL.

_>>Ну это спорный вопрос. Вот скажем какой-нибудь там IDispatch (на котором очень много чего работает) — это динамическая типизация или статическая? )

WH>Динамическая.
WH>Ты считаешь, что он появился от большого ума?

Можешь предложить более простой способ подключения чужого кода в тот же VisualBasic? )

_>>Да не о том речь. Ты вот попробуй написать свою функцию, которая скажем будет трансформировать какую-то строку и печатать в консоль результат. И сравни её объявление с аналогом на Питоне. )

WH>Думаю, в большинстве случаев хаскель победит.

Дааа? ) Ну так давай сравним. Вот законченное приложение на Питоне:
import time
def Test(data):
    for s in data:
        time.sleep(1)
        print s
Test([u'один', u'два', u'три'])

Я не вижу тут вообще никакого синтаксического шума. Т.е. всё, что написано, является прямым выражением мыслей программиста, а не какими-то обязательными (и нередко бредовыми) требованиями языка.

Покажи как будет выглядеть прямой аналог этого кода на Хаскеле и сравним количество синтаксического шума.

О, кстати, а на Немерле интересно как будет...

_>>Да ладно, for'ы в подобных скриптах на каждом шагу.

WH>100% этих for'ов сводится к fold, map или их сочетанию.

Ага, map по функциям с вводом-выводом — это на Хаскеле особо приятно. )))
Re[21]: DSL'и и инструменты для них
От: alex_public  
Дата: 09.08.15 11:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

_>>Трансляция — это конечно хорошо, но что делать с рантаймом? Я вот даже не будут предлагать рассматривать такие не тривиальные случае как Пролог. Давай посмотрим на реализацию классического элемента большинства распространённых языков — исключения. Кто будет заниматься реализацией этого под нативный код? )

WH>Язык уровнем чуть выше, чем переносимый ассемблер.

Непонятно.

Вот смотри, предположим что ваш проект уже полностью завершён. И я хочу сделать с помощью него свой DSL. Предположим пока, что это будет не какой-то хитрый случай (типа моего, с Прологом), а что-то совсем простенькое, в стиле Basic. Но обязательно с исключениями. Ну и компилироваться оно должно в нативный код (никаких .net'ов и т.п.). Так от вашего инструмента тут будет какая-то помощью (и если да, то какая?) или же мне придётся самому разбираться в существующих реализациях исключений (типа seh, dwarf, sjlj) и как-то встраивать их в свой DSL?
Re[32]: DSL'и и инструменты для них
От: meadow_meal  
Дата: 09.08.15 17:55
Оценка:
Здравствуйте, WolfHound, Вы писали:

_>>Библиотека, работающая с rpc-сервисом. Протокол (способ сериализации и передачи данных) известен, схема нет.

WH>Как библиотека может обратиться к серверу, если нет схемы сервера?

Протокол определяет, как, зная имя метода и задав параметры, можно получить результат. Протокол известен автору библиотеки. Имя метода известно мне — пользователю библиотеки. Его мне прислал коллега из компании, предоставляющей сервис, по скайпу. Никакой формально описанной схемы нет, версия сервиса 0.0.1 преальфа. Я вызвал SomeService.SomeMethod(...) и получил результат.

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

_>>Описать свой запрос в том или ином виде он в состоянии.

WH>У тебя очень странные гуманитарии.
WH>В моей вселенной гуманитарии код писать не могут от слова совсем.

Пользователь неправильный?

_>>Чего — чего? Ну вот появилась задача, найди нам самые популярные торговые маршруты в данной игре, т.е. цепочку прохождения ключевых точек между покупкой предмета A и продажей предмета A в рамках одной игровой сессии (пример абсолютно произвольный). Данные о всех этих событиях два года собирали, просто до сих пор не нужны были, а тут дизайнеры заинтересовались, программистам же в свое время (два года назад) поставили задачу эти (и другие) данные сохранять в каком-то виде, они и сохраняли, но за два года много всего поменялось, поля добавлялись, удалялись, меняли тип. Более-менее я знаю что там, да и сэмплы данных за разные периоды посмотреть несложно, но формально описывать схему? Долго и нудно, увольте. А скрипт написать на динамике — запросто.

WH>При написании этого скрипта ты проделаешь всю работу по описанию схемы несколько раз.

Я — нет, мне схема не нужна. Ты — да, каждый раз, когда незначительная и неважная для задачи часть схемы изменится.

WH>Даже у текстового лога, если на него внимательно посмотреть есть схема.

WH>И если тебе этот лог нужно попарсить более одного раза, то описание схемы уже себя оправдывает.

Конечно, описание схемы текстового лога методом его внимательного рассмотрения — распространенная программистская задача. Или нет?

Проще написать сотню регекспов или sed/awk скриптов, чем описывать схему (задача во многих случаев избыточная), и при каждом обновлении приложения (источника логов) огорчаться, что парсер опять накрылся, и вновь надо что-то внимательно рассматривать.

_>>А здесь не понял, что сложного из концепций (языковых)? Слайсы и list comprehension?

WH>Тогда что ты сложного нашел в немерле?
WH>Там в обычном коде нет ничего сложнее этого.

Программистов в новом языке смущает богатство возможностей. Если есть один прямолинейный способ решить задачу — язык проще, чем когда их два или больше. Цикл и хвостовая рекурсия, match и switch, nullable и option, функциональные списки и SCG, у каждой фичи сестра-близнец, и "в обычном коде" встретишь обе. Ну и метапрограммирование конечно, когда совы не всегда то чем они кажутся.
Re[33]: DSL'и и инструменты для них
От: Mamut Швеция http://dmitriid.com
Дата: 10.08.15 08:36
Оценка:
_>>>Библиотека, работающая с rpc-сервисом. Протокол (способ сериализации и передачи данных) известен, схема нет.
WH>>Как библиотека может обратиться к серверу, если нет схемы сервера?

_>Протокол определяет, как, зная имя метода и задав параметры, можно получить результат. Протокол известен автору библиотеки. Имя метода известно мне — пользователю библиотеки. Его мне прислал коллега из компании, предоставляющей сервис, по скайпу. Никакой формально описанной схемы нет, версия сервиса 0.0.1 преальфа. Я вызвал SomeService.SomeMethod(...) и получил результат.



В идеальном вымышленном сказочнос мире WolfHound'а и клиент и сервер общаются исключительно строготипизированными схемами, на основе которых и генерируются идеально правильные клиент и сервер, которые одновременно обновляются в случае изменения схемы.

Этот разговор просто у меня уже был. Финал тут
Автор: Mamut
Дата: 13.02.15
, но можешь почитать обсуждение выше по ветке.


dmitriid.comGitHubLinkedIn
Re[22]: DSL'и и инструменты для них
От: WolfHound  
Дата: 10.08.15 11:12
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Вот смотри, предположим что ваш проект уже полностью завершён. И я хочу сделать с помощью него свой DSL. Предположим пока, что это будет не какой-то хитрый случай (типа моего, с Прологом), а что-то совсем простенькое, в стиле Basic. Но обязательно с исключениями. Ну и компилироваться оно должно в нативный код (никаких .net'ов и т.п.). Так от вашего инструмента тут будет какая-то помощью (и если да, то какая?) или же мне придётся самому разбираться в существующих реализациях исключений (типа seh, dwarf, sjlj) и как-то встраивать их в свой DSL?

Будет куча языков, которые будет друг в друга переписываться.
ЯВУ -> переносимый ассемблер с исключениями.
переносимый ассемблер с исключениями -> переносимый ассемблер.
много разных
переносимый ассемблер -> конкретный ассемблер.

Разработчику языка нужно будет просто сделать переписывание из своего языка в ЯВУ.
Остальные +90% работы сделает иерархия языков из стандартной поставки.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: DSL'и и инструменты для них
От: WolfHound  
Дата: 10.08.15 11:12
Оценка:
Здравствуйте, meadow_meal, Вы писали:

_>Протокол определяет, как, зная имя метода и задав параметры, можно получить результат. Протокол известен автору библиотеки. Имя метода известно мне — пользователю библиотеки. Его мне прислал коллега из компании, предоставляющей сервис, по скайпу. Никакой формально описанной схемы нет, версия сервиса 0.0.1 преальфа. Я вызвал SomeService.SomeMethod(...) и получил результат.

Нормальные люди при разработке использую что-то из этого списка.
https://en.wikipedia.org/wiki/Interface_description_language
Или мы говорим про случай, когда сервер написали на динамически типизированном языке, изначально создав себе и другим проблемы?

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

Имя метода и его параметры это уже схема.

_>>>Описать свой запрос в том или ином виде он в состоянии.

WH>>У тебя очень странные гуманитарии.
WH>>В моей вселенной гуманитарии код писать не могут от слова совсем.
_>Пользователь неправильный?
Таких пользователей, которых ты описываешь, не существует.
Люди либо способны понять, что такое схема. Либо не способны писать код вообще.

WH>>При написании этого скрипта ты проделаешь всю работу по описанию схемы несколько раз.

_>Я — нет, мне схема не нужна. Ты — да, каждый раз, когда незначительная и неважная для задачи часть схемы изменится.
Если изменилась часть схемы, которую я не использую, я ничего не замечу.
А если изменилась та часть схемы, которая реально используется, ты будешь долго ловить баги.
Например, раньше метод всегда возвращал значение, а теперь стал возвращать опциональное значение.
В моём случае компилятор скажет мне, что нельзя засунуть в коллекцию объектов опциональный объект, а в твоём промолчит. И ты потом будешь долго искать, откуда в коллекции появился null.

_>Конечно, описание схемы текстового лога методом его внимательного рассмотрения — распространенная программистская задача. Или нет?

Когда я парсил логи мне этого очень не хватало.
Приходилось повторять разбор лога в каждом скрипте.

_>Проще написать сотню регекспов или sed/awk скриптов, чем описывать схему (задача во многих случаев избыточная), и при каждом обновлении приложения (источника логов) огорчаться, что парсер опять накрылся, и вновь надо что-то внимательно рассматривать.

Нет. В случае сотен скриптов ты будешь отлаживать их все.
А если у тебя будет описана схема лога, тебе нужно будет только поправить схему лога.
И все сотни скриптов начнут нормально работать.

_>Программистов в новом языке смущает богатство возможностей. Если есть один прямолинейный способ решить задачу — язык проще, чем когда их два или больше. Цикл и хвостовая рекурсия, match и switch, nullable и option, функциональные списки и SCG, у каждой фичи сестра-близнец, и "в обычном коде" встретишь обе. Ну и метапрограммирование конечно, когда совы не всегда то чем они кажутся.

Так в питоне тоже куча всякой фигни.
Не понимаю, почему ты считаешь, что питон проще немерла если по жизни он нифига не проще.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[29]: DSL'и и инструменты для них
От: WolfHound  
Дата: 10.08.15 11:12
Оценка:
Здравствуйте, alex_public, Вы писали:

_>JS и Python естественно гоняют друг другу. Но не Python и Python... )

JS и JS?

_>Ааа ты про сам fab.exe? Не, я говорю про весь этот пакет, который включает ещё и соответствующие python библиотеки, реализующие тот самый DSL.

Какой ДСЛ?
Из описания я вообще ничего кроме запуска методов по имени не заметил.

_>Можешь предложить более простой способ подключения чужого кода в тот же VisualBasic? )

ВБ изначально динамически типизированный.
Что я думаю про динамически типизированные языки и их авторов я думаю, ты уже понял.

_>>>Да не о том речь. Ты вот попробуй написать свою функцию, которая скажем будет трансформировать какую-то строку и печатать в консоль результат. И сравни её объявление с аналогом на Питоне. )

WH>>Думаю, в большинстве случаев хаскель победит.
_>Дааа? ) Ну так давай сравним. Вот законченное приложение на Питоне:
Где здесь трансформация строки?

_>Покажи как будет выглядеть прямой аналог этого кода на Хаскеле и сравним количество синтаксического шума.

Принципиальной разницы не вижу.
import Control.Concurrent;
sleep s = threadDelay  (s * 1000000)

foreach collection fn = mapM_ fn collection

test lines = do
    foreach lines (\x -> do
        sleep 1
        putStrLn x
        )

main = test ["asd", "фвыфыв", "йцууцй", "вапва", "qвапвапzxew"]


_>О, кстати, а на Немерле интересно как будет...

Да вообще то же самое будет.
У него даже синтаксис на отступах есть.

_>Ага, map по функциям с вводом-выводом — это на Хаскеле особо приятно. )))

Какие проблемы?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[29]: DSL'и и инструменты для них
От: DarkEld3r  
Дата: 10.08.15 12:24
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Дааа? ) Ну так давай сравним. Вот законченное приложение на Питоне:

_>
_>import time
_>def Test(data):
_>    for s in data:
_>        time.sleep(1)
_>        print s
_>Test([u'один', u'два', u'три'])
_>

_>Я не вижу тут вообще никакого синтаксического шума. Т.е. всё, что написано, является прямым выражением мыслей программиста, а не какими-то обязательными (и нередко бредовыми) требованиями языка.
А префикс "u" у строк? Разве не мусор?
Re[34]: DSL'и и инструменты для них
От: meadow_meal  
Дата: 11.08.15 07:15
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Нормальные люди при разработке использую что-то из этого списка.

WH>https://en.wikipedia.org/wiki/Interface_description_language
WH>Или мы говорим про случай, когда сервер написали на динамически типизированном языке, изначально создав себе и другим проблемы?

В разработках компании мы используем IDL, парсер/генератор которого написан на Nemerle с использованием Nitra, так что мы люди относительно нормальные. Но на чем пишут люди, предоставляющие нам сервисы, вообще ни разу не наше дело. Проблем они нам не создают и, скорее всего, себе тоже. Проблем, на которые ты намекаешь, не существует.

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

WH>Имя метода и его параметры это уже схема.

Ты не ответил на вопрос (если не считать ответом то, что сервис неправильный). Ну да ладно.

WH>Таких пользователей, которых ты описываешь, не существует.

WH>Люди либо способны понять, что такое схема. Либо не способны писать код вообще.

Люди способны понять, что такое схема. Просто она людям не всегда нужна.

При описании данных есть два способа.
Первый — ты долго думаешь над задачей, набрасываешь схему, вводишь данные, понимаешь, что что-то не предусмотрел, снова думаешь, итерируешь схему.
Второй — ты вводишь данные.

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

WH>>>При написании этого скрипта ты проделаешь всю работу по описанию схемы несколько раз.

_>>Я — нет, мне схема не нужна. Ты — да, каждый раз, когда незначительная и неважная для задачи часть схемы изменится.
WH>Если изменилась часть схемы, которую я не использую, я ничего не замечу.
WH>А если изменилась та часть схемы, которая реально используется, ты будешь долго ловить баги.
WH>Например, раньше метод всегда возвращал значение, а теперь стал возвращать опциональное значение.

Какой еще метод? Ты забыл задачу? У нас поток событий, и т.д.
А как ты будешь парсить данные некорректной схемой, я не понял.

_>>Конечно, описание схемы текстового лога методом его внимательного рассмотрения — распространенная программистская задача. Или нет?

WH>Когда я парсил логи мне этого очень не хватало.
WH>Приходилось повторять разбор лога в каждом скрипте.

Что же ты схему-то не составлял методом пристального взгляда?

_>>Проще написать сотню регекспов или sed/awk скриптов, чем описывать схему (задача во многих случаев избыточная), и при каждом обновлении приложения (источника логов) огорчаться, что парсер опять накрылся, и вновь надо что-то внимательно рассматривать.

WH>Нет. В случае сотен скриптов ты будешь отлаживать их все.
WH>А если у тебя будет описана схема лога, тебе нужно будет только поправить схему лога.
WH>И все сотни скриптов начнут нормально работать.

Да не нужна мне нормальная работа сотен скриптов. Мне нужно гарантированно минимальное время между постановкой задачи и ее решением. sed мне это гарантирует, а устаревшая схема — нет. О какой отладке сотен скриптов идет речь, написать скрипт на sed или аналогичном инструменте — минутное дело.

_>>Программистов в новом языке смущает богатство возможностей. Если есть один прямолинейный способ решить задачу — язык проще, чем когда их два или больше. Цикл и хвостовая рекурсия, match и switch, nullable и option, функциональные списки и SCG, у каждой фичи сестра-близнец, и "в обычном коде" встретишь обе. Ну и метапрограммирование конечно, когда совы не всегда то чем они кажутся.

WH>Так в питоне тоже куча всякой фигни.
WH>Не понимаю, почему ты считаешь, что питон проще немерла если по жизни он нифига не проще.

Потому что в питоне нет кучи всякой фигни. Из предоставленного списка там нет хвостовой рекурсии, pm, двух видов optional и двух видов стандартных списков. В питоне нет двух видов переменных. В питоне нет двух видов синтаксиса — с табуляцией и фигнурными скобками. Питон не пытается мимикрировать под C# и ML одновременно.

Ладно, спасибо за дискуссию, я сворачиваюсь, так как в моем мире кругом "неправильные" сервисы и "неправильные" пользователи, а питон проще, чем немерле, а в твоем все наоборот, и тут уже ничего не поделаешь.
Re[23]: DSL'и и инструменты для них
От: alex_public  
Дата: 11.08.15 11:43
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Будет куча языков, которые будет друг в друга переписываться.

WH>ЯВУ -> переносимый ассемблер с исключениями.
WH>переносимый ассемблер с исключениями -> переносимый ассемблер.
WH>много разных
WH>переносимый ассемблер -> конкретный ассемблер.
WH>Разработчику языка нужно будет просто сделать переписывание из своего языка в ЯВУ.
WH>Остальные +90% работы сделает иерархия языков из стандартной поставки.

Поясни мне пожалуйста, в чём тут будет отличие от следующего сценария:

И так, мне нужен простенький DSL в стиле Basic. Ну там if, for, print, переменные строковые и целочисленные и какие-нибудь доменные функций. Значит я записываю соответствующую грамматику и с помощью bison/flex за пару часов делаю парсер этого языка. Далее, в тот же парсер я добавляю обход по АСТ, который банально выводит в файл соответствующий (if в if, for в for и т.п.) C++ код. Опять же дел на несколько часов. Ну и далее, я просто добавляю в своё приложение clang (он тут лучше gcc и по лицензии и по инфраструктуре), который будет собирать из этого нагенерированного C++ готовое приложение, которое тут же запускается. Кстати, происходить это будет мгновенно, т.к. очевидно, что в данном C++ коде будет ровно один маленький #include (с предметными функциями), а в таком случае C++ компиляторы вообще как молния работают.

Понятно, что такой подход работает только для DSL, хорошо ложащихся на C++. Т.е. с нужным мне для реального проекта Прологом такое не пройдёт. Но, как я понимаю, с Прологом не поможет и ваш продукт (во всяком случае, пока кто-то не добавит в вашу библиотеку полноценную реализацию Пролога, что явно маловероятно). Тогда в чём разница?
Re[30]: DSL'и и инструменты для них
От: alex_public  
Дата: 11.08.15 12:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

_>>JS и Python естественно гоняют друг другу. Но не Python и Python... )

WH>JS и JS?

JS же — это по сути один здоровый скрипт (даже если он и во многих файлах), работающий у клиента. Но причём тут он, если мы говорили про серверный Питон? )

_>>Ааа ты про сам fab.exe? Не, я говорю про весь этот пакет, который включает ещё и соответствующие python библиотеки, реализующие тот самый DSL.

WH>Какой ДСЛ?
WH>Из описания я вообще ничего кроме запуска методов по имени не заметил.

Ха, т.е. ты не увидел основного в этом инструменте? ))) Там же реализован набор команд: local/run/sudo, put/get, reboot, prompt. Плюс набор модификаторов контекста: lcd/cd, prefix, path, shell_env, hide/show. Причём последние идеально ложатся на конструкцию with Питона. Т.е. мы пишем скажем "with cd('/usr/local'):" и далее весь блок будет выполняться в соответствующем каталоге удалённой машины, а после выхода из блока будет возвращён предыдущий каталог. В общем очень удобный DSL вышел, хотя используется язык общего назначения. Ну и да, естественно можно сказать выполнить весь скрипт параллельно на десятках разных серверов.

_>>Можешь предложить более простой способ подключения чужого кода в тот же VisualBasic? )

WH>ВБ изначально динамически типизированный.
WH>Что я думаю про динамически типизированные языки и их авторов я думаю, ты уже понял.

Гм... Вообще то VB статически типизированный язык. Если же ты подразумеваешь под динамикой в нём наличие типа Variant, то он такой и в C++ (ну с Boost'ом) есть... )))

_>>Покажи как будет выглядеть прямой аналог этого кода на Хаскеле и сравним количество синтаксического шума.

WH>Принципиальной разницы не вижу.
WH>
WH>import Control.Concurrent;
WH>sleep s = threadDelay  (s * 1000000)

WH>foreach collection fn = mapM_ fn collection

WH>test lines = do
WH>    foreach lines (\x -> do
WH>        sleep 1
WH>        putStrLn x
WH>        )

WH>main = test ["asd", "фвыфыв", "йцууцй", "вапва", "qвапвапzxew"]
WH>


Не буду цепляться к лишним строкам на переименовывание (кстати не вижу в нём особого смысла — имена то пускай будет родные, главное чтобы смысл не менялся) — тут и без этого большое раздолье... ))) Сразу возникают вопросы: кто такие "do", "\x" и "->"? Причём на оформление функции или цикла их списать нельзя, т.к. при других вариантах (например если без монад) этого всего не будет. Ну и main кстати тоже совершенно не обязательная вещь.

_>>О, кстати, а на Немерле интересно как будет...

WH>Да вообще то же самое будет.
WH>У него даже синтаксис на отступах есть.

Ну так а можно глянуть на пример? ) А то на Питоне или Хаскеле я вообще то и сам могу, а вот на Немерле пока никак. )))

_>>Ага, map по функциям с вводом-выводом — это на Хаскеле особо приятно. )))

WH>Какие проблемы?

Проблема как раз в том, что нужен уже mapM_, а не map. ) С кучей разных последствий из этого.
Re[30]: DSL'и и инструменты для них
От: alex_public  
Дата: 11.08.15 12:44
Оценка:
Здравствуйте, DarkEld3r, Вы писали:

DE>А префикс "u" у строк? Разве не мусор?


А это на самом деле зависит от области разработки. Если подразумевается, что программисту могут понадобиться и юникодные строки и обычные, то очевидно что не мусор, а ясное выражение мысли. Если же программист работает всегда только с одним типом, то да, для него это становится мусором. Кстати, тут ещё существенное значение может иметь значение по умолчанию: в Питоне 3.х (а у меня 2.х стоит и пример написан на нём) дефолтными стали юникодные строк (а префикс соответственно надо указывать для обычных).
Re[35]: DSL'и и инструменты для них
От: WolfHound  
Дата: 11.08.15 16:32
Оценка:
Здравствуйте, meadow_meal, Вы писали:

_>Какой еще метод? Ты забыл задачу? У нас поток событий, и т.д.

_>А как ты будешь парсить данные некорректной схемой, я не понял.
Я буду во время исполнения выдавать корректные сообщения об ошибках.
А что будет делать твоя программа, которая рассчитана на одни данные, а по факту приходят другие загадка.

_>Что же ты схему-то не составлял методом пристального взгляда?

Это было много лет назад.
Я тогда знал намного меньше чем сейчас.

_>Да не нужна мне нормальная работа сотен скриптов. Мне нужно гарантированно минимальное время между постановкой задачи и ее решением. sed мне это гарантирует, а устаревшая схема — нет. О какой отладке сотен скриптов идет речь, написать скрипт на sed или аналогичном инструменте — минутное дело.

У тебя уже написана сотня скриптов на sed'е и прочем ужасе.
Теперь у тебя изменилась схема лога.
И все скрипты перестали работать.
Что делать будешь?

_>Потому что в питоне нет кучи всякой фигни.

Ну как это нет, когда я за 30 секунд гугления её нашел?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[31]: DSL'и и инструменты для них
От: WolfHound  
Дата: 11.08.15 16:32
Оценка:
Здравствуйте, alex_public, Вы писали:

_>JS же — это по сути один здоровый скрипт (даже если он и во многих файлах), работающий у клиента. Но причём тут он, если мы говорили про серверный Питон? )

Мы говорим про всё решение.
Вот и получается что данные из одного питоновского скрипта пройдя через клиенствий ЖС могут попасть в другой питоновский скрипт.

_>Ха, т.е. ты не увидел основного в этом инструменте? ))) Там же реализован набор команд: local/run/sudo, put/get, reboot, prompt. Плюс набор модификаторов контекста: lcd/cd, prefix, path, shell_env, hide/show.

Это всё за час делается.
Короче я так и не понял что ты предлагаешь там неделю писать.

_>Гм... Вообще то VB статически типизированный язык. Если же ты подразумеваешь под динамикой в нём наличие типа Variant, то он такой и в C++ (ну с Boost'ом) есть... )))

Современный ВБ.

_>Не буду цепляться к лишним строкам на переименовывание (кстати не вижу в нём особого смысла — имена то пускай будет родные, главное чтобы смысл не менялся) — тут и без этого большое раздолье... ))) Сразу возникают вопросы: кто такие "do", "\x" и "->"?

А кто такой "s"? А кто такой "in"? А кто такой ":".
Короче я тоже к буквам цепляться умею.

_>Ну так а можно глянуть на пример? ) А то на Питоне или Хаскеле я вообще то и сам могу, а вот на Немерле пока никак. )))

Ох.
#pragma indent
using System.Console

def test(data)
  foreach (s in data)
    System.Threading.Thread.Sleep(1000)
    WriteLine(s)

test(["один", "два", "три"])


_>Проблема как раз в том, что нужен уже mapM_, а не map. ) С кучей разных последствий из этого.

IO нужно только на входе и на выходе.
Так в чём проблема то?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: DSL'и и инструменты для них
От: WolfHound  
Дата: 11.08.15 16:32
Оценка:
Здравствуйте, alex_public, Вы писали:

_>И так, мне нужен простенький DSL в стиле Basic. Ну там if, for, print, переменные строковые и целочисленные и какие-нибудь доменные функций. Значит я записываю соответствующую грамматику и с помощью bison/flex за пару часов делаю парсер этого языка.

При этом будешь долго разбираться с конфликтами shift/reduce.
А потом пользователи будут получать фееричные сообщения об ошибках.

_>Далее, в тот же парсер я добавляю обход по АСТ, который банально выводит в файл соответствующий (if в if, for в for и т.п.) C++ код.

И пользователь будет получать ошибки от компилятора С++.
Это ад.

_>Понятно, что такой подход работает только для DSL, хорошо ложащихся на C++. Т.е. с нужным мне для реального проекта Прологом такое не пройдёт. Но, как я понимаю, с Прологом не поможет и ваш продукт (во всяком случае, пока кто-то не добавит в вашу библиотеку полноценную реализацию Пролога, что явно маловероятно). Тогда в чём разница?

Вероятность того что там будет пролог и все остальные языки которые на слуху равна 100%
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.