Есть ли вещи, которые вы прницпиально не понимаете... - Философия программирования

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

I>>Можно и без монад — получатся автоматы на коленке с конской вложенностью, простынями из свичей и все это будет размазано по десяткам эвентов.

_>Конечно, но это если писать руками каждый раз. А если ты это всё скроешь в библиотечке за удобным интерфейсом? )

Всё равно два варианта которые я показал.

I>>Все такие возможности очень актуальны, ибо в С++ возможностей для интеграции около нуля. Именно по этой причине для интеграции берут более другой язык — JS, Python, Lua и тд вплоть до С# или Джавы, не гнушаясь даже vbs.

_>Это ты вообще о чём? Что за интеграция? )

Это та самая полезная логика:

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, '127.0.0.1');

На Си написаны сокеты, на JS это интегрируется пятью строчками в http сервер. Можно добавить еще пару строчек и будет простой клиент-серверный чат.

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

I>>js он паттерном идёт, как раз для того, что бы отделить от остального мусора

I>>Очевидно, что в логе не только JS, там результаты функций, снимки состояния и тд и тд.

_>Так я не понял, после "pir:" может идти не js код или нет? Если может, то весьма любопытно взглянуть на твоё решение задачки "выловить среди произвольного текста кусок js кода"...

Не среди произвольного текста, определить, удовлетворяет ли текст внутри блока паттерну или нет. Если да, то взять имя функции

Это не рокет саенс, когда ты проверяешь regex.match("ля ля ля") то делаешь ровно то же. Разница только в том, что
1. у меня язык не является регулярным
2. парсер реактивный

в остальном нет никакой разницы

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

I>>С++ не умеет те операторы, которые нужны для БНФ или РБНФ.
I>>то есть придется эмулировать все подряд, например следование придется пилить явно, скобки и прочую вешь так же придется эмулировать, т.е. пилить явно.

_>Ужас то какой. )))

Да не, просто отстой, ничего серьёзного.

I>>Вот смотри, твой спирит, я даже не знаю, не то смеяться, не то плакать.
I>>...

_>Кстати, вот на таких примерах (когда строим полноценную AST) не видны некоторые удобнейшие (на мой вкус) возможности использования Спирита. Например такая int_[([](const int& n){cout<<n<<endl;})] % ',' штука не просто задаёт список интов разделённых запятой, но и сразу же пишется реакция на распознанное значение. Причём таких реакций может быть сколько угодно — хоть на каждый элемент грамматики или их группу. В итоге получается писать крайне краткие и быстрые парсеры для простых вещей.

Спасибо, капитан, а я то думал спирит просто парсит ради парсинга, а оказывается, он как все парсеры, даёт еще и результат парсинга обработать. Буду знать !

I>>вот BNF:
I>>...
_>А это на каком языке программирования написано?

Я ж сказал — на языке описания грамматик, по русски — БФН, переводится как форма Бэкуса-Наура

I>>А вот фокус — та же грамматика на комбинаторах
I>>...
I>>тут не всё, справа надо добавить .map(AST.ляляля), т.е. трансляцию в АСТ, количество кода не сильно изменится

_>Генерация AST — это ладно, это действительно не надо показывать (т.к. тогда ещё само AST определять надо). А вот где сам парсинг то? )

Там же, где и в спирите — унутре либы.

>В случае Спирита понятно, что парсинг всегда осуществляется ровно одним вызовом глобальной функции, которой передаётся строка и грамматика. А тут у нас что делать с этим списком переменных?

Вот что http://rsdn.ru/forum/philosophy/5416669.1

если это простй парсер, то так

var ast = expr("(-1+2)*8*-(23+2)");

а если реактивный (другая либа с похожим апи)

var stream = ... источник, т.е. эвент, стрим, короутина и тд и тд и тд

stream.parse(expr).on('next', function(ast){
... 
});

_>Т.е. вот предположим нам надо не AST сгенерировать, а напечатать разобранное выражение в консоль (но с другим форматирование естественно). Как будет тогда выглядеть полный код на базе твоего варианта? Кстати, в случае Спирита это одна строчка будет...

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

_>Ну а про разницу в скорости при определение грамматики во время копиляции или во время исполнения я даже особо упоминать не буду — про это по идее и так все помнят.

Когда спирит научится реактивный парсинг делать, тогда и сравним перформанс. А пока что сравнивать не с чем.

_>Хы, в таких задачах (где есть всё работает по определённым законам и можно точно предсказывать "будущее") вообще всё по другому делают. Про фильтр Калмана слышал? ) Кстати, как ты думаешь, там будет фигурировать нормальная скорость или средняя? )))

Ай, не гони. FRP, т.е. Functional Reactive появилось для
1. сложной анимации, которая управляется событиями
2. описания поведения роботов, опять же управление от событий

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

K>Непонятно, как причина претензии лишает претензию смысла. Именно потому, что так происходит претензия и имеет смысл.

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

_>>Совершенно верно. И как раз про это я спрашиваю уже очень давно и так ни разу и не получил ответа. Естественно про какие-то случаи из реальной практики, а не обобщённую теорию..
K>Я же говорю, как только разберем "ужасы" — так сразу.

Вопрос о примере загадочной пользы от особенностей реализации IO/ST Хаскеля прозвучал очень давно, но так и не было ответа, а только отмазки. Такое впечатление, что мы тут слушаем в основном рассуждения теоретика...

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

K>Кроме того, уже известно из опыта, что обсуждать конкретный код и указывать в чем проблемы вы не станете.
K>Понятно, что такое последовательное нежелание переходить от общих заявлений к конкретике скорее всего свидетельствует о том, что никаких подтверждений своим тезисам в конкретных примерах вы даже и не рассчитываете найти, иначе с примеров и начали бы, а не с бла-бла-бла.

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

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

I>Это та самая полезная логика:

I>

I>var http = require('http');
I>http.createServer(function (req, res) {
I>  res.writeHead(200, {'Content-Type': 'text/plain'});
I>  res.end('Hello World\n');
I>}).listen(1337, '127.0.0.1');
I>

I>На Си написаны сокеты, на JS это интегрируется пятью строчками в http сервер. Можно добавить еще пару строчек и будет простой клиент-серверный чат.

Ааа, понял. Сам люблю такое (на Питончике). Но только до тех пор, пока использую готовые чужие C/C++ модули. А если готового модуля нет, то писать свой обычно очень не охота (там всё же надо небольшой слой "лишнего" реализовать) — тогда проще всё приложение на плюсах сделать. Это естественно касается каких-то небольших внутренних задач. С софтом на продажу ситуация совсем другая по ряду причин, и Питончик (или даже Lua) там если и будет, то только как встроенный скриптовой язык в нативное приложение.

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

I>Не среди произвольного текста, определить, удовлетворяет ли текст внутри блока паттерну или нет. Если да, то взять имя функции

Хы, раньше этого условия не было. Но случайно получилось, что тот мой код будет работать правильно и при нём. ))) Ну точнее его конечно можно обмануть подсунув что-то типа "function name(){ляляля не валидный js}", т.к. он не проверяет валидность всего js кода. Но думаю для анализатора логов это вполне подходящий уровень. )))

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

I>>На Си написаны сокеты, на JS это интегрируется пятью строчками в http сервер. Можно добавить еще пару строчек и будет простой клиент-серверный чат.

_>Ааа, понял. Сам люблю такое (на Питончике). Но только до тех пор, пока использую готовые чужие C/C++ модули. А если готового модуля нет, то писать свой обычно очень не охота (там всё же надо небольшой слой "лишнего" реализовать) — тогда проще всё приложение на плюсах сделать. Это естественно касается каких-то небольших внутренних задач. С софтом на продажу ситуация совсем другая по ряду причин, и Питончик (или даже Lua) там если и будет, то только как встроенный скриптовой язык в нативное приложение.

С софтом на продажу все гораздо интереснее, там на таких вещах, как интеграция, вообще всё держится. И её быстрее и надёжнее писать на высокоуровневом языке.
Причина простая — на порядки легче сделать медленное быстрым, нежели некорректное корректным.

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

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

I>>Не среди произвольного текста, определить, удовлетворяет ли текст внутри блока паттерну или нет. Если да, то взять имя функции

_>Хы, раньше этого условия не было.

Не было указания, что блоки могут быть вложенными, все остальное вполне понятно. Это я поторопился.

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

I>Спасибо, капитан, а я то думал спирит просто парсит ради парсинга, а оказывается, он как все парсеры, даёт еще и результат парсинга обработать. Буду знать !

Весь вопрос в том, в какой форме получать эти результаты...

I>Я ж сказал — на языке описания грамматик, по русски — БФН, переводится как форма Бэкуса-Наура

Вообще то принято сокращать как БНФ. Ну так это у нас не язык программирования, правильно? И с чего ты тогда сравниваешь запись грамматики на C++ с этим?

I>Просто что бы распечатать надо добавить функцию, как ты хочешь печатать каждый узел, см мою линку, там именно этот пример

Ага, я про это и спрашиваю... Значит твоя библиотечка выдаёт результат в виде некого дерева, правильно? Соответственно у меня вопросы:

1. Как нам там указывается тип узла (в смысле грамматики)?
2. В переменной какого типа (в смысле C#) хранится распознанное значение в узле?
3. Касательно нашего конкретного примера. У тебя там грамматика задаётся до уровня цифр (а не до уровня int'a как в примере spirit'а) — означает ли это, что конечными узлами дерева будут просто char'ы?

I>Ай, не гони. FRP, т.е. Functional Reactive появилось для
I>1. сложной анимации, которая управляется событиями
I>2. описания поведения роботов, опять же управление от событий

Хыхы, ну расскажи например про управление ADC с помощью FRP, если ты считаешь что оно актуально в этой области.

P.S. Если что, второй пункт (причём не только поведение, а вообще всё) — это как раз моя область. )))

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

I>С софтом на продажу все гораздо интереснее, там на таких вещах, как интеграция, вообще всё держится. И её быстрее и надёжнее писать на высокоуровневом языке.

Надёжнее? ) На языке без статической типизации? ) Нуну... )))

I>Причина простая — на порядки легче сделать медленное быстрым, нежели некорректное корректным.

Как раз на Питончике код скорее будет некорректным. И кстати скорость работы кода (если используем C/C++ модули) будет одинаковая. Главный плюс Питона (и ему подобных) — это скорость разработки/модификации.

Это в случае самого приложения на Питоне. А вот если использовать его в качестве встроенного в нормальное нативное приложение скриптового языка, то возникают уже совсем другие эффекты...

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

I>>С софтом на продажу все гораздо интереснее, там на таких вещах, как интеграция, вообще всё держится. И её быстрее и надёжнее писать на высокоуровневом языке.

_>Надёжнее? ) На языке без статической типизации? ) Нуну... )))

Именно так — надёжнее. Кода меньше и этот аргумент не заборет никакая типизация.

I>>Причина простая — на порядки легче сделать медленное быстрым, нежели некорректное корректным.

_>Как раз на Питончике код скорее будет некорректным.

Надо полагать это у Питона фишка такая — баги в программах имплементить.

>И кстати скорость работы кода (если используем C/C++ модули) будет одинаковая. Главный плюс Питона (и ему подобных) — это скорость разработки/модификации.

И скорость и качество.

_>Это в случае самого приложения на Питоне. А вот если использовать его в качестве встроенного в нормальное нативное приложение скриптового языка, то возникают уже совсем другие эффекты...

А я что, предлагаю Питон во все приложения в качестве скриптинга встраивать ?

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

I>>Я ж сказал — на языке описания грамматик, по русски — БФН, переводится как форма Бэкуса-Наура

_>Вообще то принято сокращать как БНФ. Ну так это у нас не язык программирования, правильно? И с чего ты тогда сравниваешь запись грамматики на C++ с этим?

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

_>1. Как нам там указывается тип узла (в смысле грамматики)?

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

_>2. В переменной какого типа (в смысле C#) хранится распознанное значение в узле?

В переменной типа Result<TValue, TRest>

_>3. Касательно нашего конкретного примера. У тебя там грамматика задаётся до уровня цифр (а не до уровня int'a как в примере spirit'а) — означает ли это, что конечными узлами дерева будут просто char'ы?

Нет, разумеется. Какой смысл делать для символов?

I>>Ай, не гони. FRP, т.е. Functional Reactive появилось для
I>>1. сложной анимации, которая управляется событиями
I>>2. описания поведения роботов, опять же управление от событий

_>Хыхы, ну расскажи например про управление ADC с помощью FRP, если ты считаешь что оно актуально в этой области.

Я не знаю, что такое ADC

_>P.S. Если что, второй пункт (причём не только поведение, а вообще всё) — это как раз моя область. )))

Тем хуже для тебя. Если не помогли ни примерЫ, ни ссылки на работы, то напрашивается один вариант — тебе нравится только императивный код и ничего другого ты видеть не хочешь.

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

_>Потому как сделать компиляцию шаблона в коды процессора невозможно

Ну так надо делать не "шаблоны", а нормальный параметрический полиморфизм.

_>ни в каком языке.

Ну да, языков с "шаблонами", конечно, видимо-невидимо.

_>Максимум что мы можем, это сделать чтобы компилятор проверял корректность всех шаблонов, что встретились в исходниках.

Никакого реалистичного способа исправить "нетипизированность" шаблонов, разумеется, нет. Любое исправление просто сломает существующий код.

_>т.к. дело компилятора контролировать правильность скомпилированного кода, а не исходников.

Отличная шутка. Вообще-то норма, это когда проверяется именно исходники (бывает, что до рассахаривания), а потом уже генерируется код. Что вы в скомпилированном коде напроверяете? Там и типы-то обычно стерты. А для того, чтоб код генерировать их обычно надо знать. Не говоря уже о том, как вы будете восстанавливать положение ошибки типизации в исходниках по "скомпилированному коду".

_>Вопрос о примере загадочной пользы от особенностей реализации IO/ST Хаскеля прозвучал очень давно, но так и не было ответа, а только отмазки.

Просьба прокомментировать заявление про ужасы IO была тоже очень давно. Сами сопоставить примеры вы отказываетесь, от объяснений уклоняетесь, указать что именно не нравится в моем примере вы не хотите. Понятно, что если мы перейдем к следующему пункту, то к этому уже не вернемся, на что вы, похоже, и рассчитываете. У меня же все основания настаивать на подробном обсуждении этого вопроса есть: преимущества контроля за эффектами будут выглядеть как оправдания каким-то невнятным ужасам, которые я вроде-бы автоматически признаю, переходя к следующему вопросу. Такой вариант меня не устраивает. Кроме того, очевидно, что в обсуждении этой темы вы чувствуете себя неуверенно, а значит это направление для меня, как вашего оппонента, перспективно.

_>Такое впечатление, что мы тут слушаем в основном рассуждения теоретика...

Вы мне льстите. Я всего-навсего практик, до теоретика мне пока далеко.

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

_>>Потому как сделать компиляцию шаблона в коды процессора невозможно
K>Ну так надо делать не "шаблоны", а нормальный параметрический полиморфизм.

А как это поможет с компиляцией в коды процессора?
Через type-erasure, а-ля std::function? Не интересно, потому что медленно.

Здравствуйте, alex_public, Вы писали:
_>Так это всё в функциях apply. Они перегружены по типу второго аргумента. Для "голых" значений будет просто применение функции, для монад/функторов применение к внутреннему значению (вот промисы сюда попадают), для коллекций stl поэлементное применение и т.п.
Ну так вот эта функция apply — и есть монада. Точнее, чтобы она была монадой, надо к apply добавить функцию по конверсии "чистого" значения в "монадный" тип, и обеспечить выполнение монадических законов.
Всё. Спор выглядит странным — это всё равно как говорить, что в С++ никакого ООП нет, а есть только данные и методы.

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

регулярных выражениях проще будет. Реактивный естественно. Т.е. что-то вроде:
_>

_>void Analyze(string s)
_>{
_>    static string js;
_>    match what;
_>    if(regex_match(s, what, "/*длинный шаблон фильтрующий js*/")) js+=what[1];
_>    if(regex_match(js, what, "startSync(.+)endSync(.*)")){
_>        string res=what[1];
_>        js=what[2];
_>        if(res.find("pir:")&&regex_match(res.remove("pir:"), what, "function ([^ (]+)")) res=what[1];
_>        cout<<res;
_>    }
_>}
_>

Этот код не работает. Как только в него приедет startSync и endSync по частям, ваш логгер облажается.
Представьте на секунду, что Analyze вызывается на каждый приехавший символ.
Это не говоря о том, что вы опять забыли про возможность параллельной работы нескольких потоков фильтрации.

В этом-то и сложность конверсии активного кода в реактивный — там, где активный код пишет "вынь да полож мне следующие 8 символов" (и встаёт в ожидании завершения IO, если у него исчерпался буфер), реактивный код должен уметь вернуть управление сразу же, как только отпроцессил входные данные.
Поэтому, например, корректных реактивных фильтров контента в ASP.NET приложениях в природе не встречается. Весь Analyze сводится к накапливанию аргументов в буфере, а сам анализ происходит по завершению.

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	09.01.14 20:50
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	09.01.14 20:58
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	09.01.14 21:13
Оценка:

	От:	alex_public
	Дата:	09.01.14 22:17
	Оценка:

	От:	alex_public
	Дата:	09.01.14 22:26
	Оценка:

	От:	Evgeny.Panasyuk
	Дата:	10.01.14 10:14
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	10.01.14 10:59
Оценка: