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

_>>С каких это пор Эрланг стал языком чистого ФП? )
F>он не менее чист, чем прочие.

В Эрланге даже с просто понятием чистоты хуже чем в некоторых императивных языках. К примеру в императивном D имеется полноценное (проверяемое компилятором) понятие чистоты. Да даже в C++ есть отдалённое подобие (правда только времени компиляции). А чем у нас тут может похвастаться Эрланг?

А у нас был разговор вообще о языке чистого ФП, где чистота не просто имеется, а ещё и является обязательной.

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

__>Инженер, разрабатывающий прошивку для устройства; разработчик компьютерной игры; разработчик информационного портала — все трое программируют, но каждый решает свою задачу при помощи соответствующих, подходящих для данной задачи инструментов, абстрагируясь от тех уровней системы, за которые ответственны люди отличного от их профиля. В пределах конкретной специальности невозможно одинаково подробно раскрыть все уровни сложных технических систем. Может быть, это можно было сделать в те времена, "когда пользователи были настоящими мужчинами, и сами писали драйверы для своих компьютеров", но не сейчас. На бакалавриате ещё можно изучать максимальное кол-во тем для роста "в ширь", но на магистре приходится выбирать определённую область, в которой двигаться "в глубь".

Ты похоже не понимаешь. Никто не предлагает иметь навыки работы на всех уровнях. А вот понимание на всех уровнях должно быть. Т.е. тот самый "разработчик информационного портала" должен хорошо себе представлять особенности работы кэша современного процессора. Если он конечно хороший специалист. Однако при этом от него никто не требует навыков проектирования процессоров.

Конечно на рынке имеются и специалисты без нормального набора знаний (выпускники всяких там ПТУ и колледжей), но по нормальному они не должны подниматься выше уровня рядовых кодеров. Иначе будет очень печально.

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

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

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

_>>>С каких это пор Эрланг стал языком чистого ФП? )
F>>он не менее чист, чем прочие.

_>В Эрланге даже с просто понятием чистоты хуже чем в некоторых императивных языках. К примеру в императивном D имеется полноценное (проверяемое компилятором) понятие чистоты. Да даже в C++ есть отдалённое подобие (правда только времени компиляции). А чем у нас тут может похвастаться Эрланг?

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



Начнем с определений:

define следующее:
— чистота
— понятие чистоты
— проверяемое компилятором понятие чистоты

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

V>>>Еще раз, мои воспоминания довольно свежи и я ими делюсь. Я писал много на Бейсике, но больше на
I>>Ощущение что ты до сих пор на нём пишешь всё свободное от работы время.

V>Глупости какие, в свободное время в тексте что-то писать как в рабочее. В свободное от работы время я пишу на самописном графическом DSL. А текст за меня кодогенератор пишет. Бо чем старше, тем ленивее.

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

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

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

>Т.е. тот самый "разработчик информационного портала" должен хорошо себе представлять особенности работы кэша современного процессора. Если он конечно хороший специалист. Однако при этом от него никто не требует навыков проектирования процессоров.

Зачем ему _особенности_ работы кэша? Достаточно знать его размер, остальное сообщит профайлер. И это только в том случае, если вообще дело дойдёт до профилирования. Если есть несогласные, пусть покажут конкретный пример, когда знания деталей работы кэша необходимо разработчику информационного портала.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Это зависит от количества диапазонов в конкретном переходе. Для какого то быстрее обычный if, для какого то — лукап.

Лукап плох из-за промахов кеша данных, т.е. когда этих лукап-таблиц много. Когда она одна, то все работает неплохо.


НС>Для лукапа иногда быстрее отсечь сперва if'ами границы суммарного диапазона. Кроме того, таблица лукапа может быть большой, для таких случаев выгоднее лукап делать только частично или в два этапа.

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


НС>Это резко сокращает размеры словарей при мизерном ухудшении перфоманса.

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


НС>Иногда вместо лукапа быстрее будет поиск по сортированному списку.

Иногда даже не по сортированному, а линейному списку. Я делал такое сравнение. Для дотнета это порядка 8 элементов, для нейтива — порядка 16-32-х. Но это для различных таблиц на каждом шаге. Если же в цикле используется одна и та же таблица, ссылку на которую взяли в переменную, объявленную в том же scope, да еще умудрились избежать встроенной дотнетной проверки на длину массива (проверив всего один раз, в начале цикла парсинга, что charTable.Length==65536, а индексация затем идет по char), то стоимость обращения к этой таблице в "разогретом" варианте приближается к стоимости линейного поиска по 4-м значениям.

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


НС>Иногда имеет смысл учитывать неравномерность вероятности появления различных значений во входных данных

Эта статистика даёт профит при линейном поиске, когда наиболее вероятные значения идут первыми.

========
Насчет двух этапов — как раз мой случай. Первая lookup-таблица идет для кодов символов (одна и та же на каждой итерации), вторая — для следующего состояния (каждый раз разная, если текущее состояние изменилось). После первой таблицы вторая получается оч маленькая.

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

_>>А у нас был разговор вообще о языке чистого ФП, где чистота не просто имеется, а ещё и является обязательной.
F>не думал, что вы про бесполезные языки.

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

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

F>>не думал, что вы про бесполезные языки.
_>Ну так если глянуть на заголовок темы, то можно увидеть, что здесь дискуссия как раз об одном из самых бесполезных. ))) И как раз его предлагают в качестве первого языка для студентов. )))

нет, после того, как х-ь смог в побочные эффекты, он уже не абсолютно бесполезен.
даже один из его авторов это признаёт.

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

V>Так и есть, только в этом случае надо ветвится по признаку способа кодирования переходов для данного случая

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

НС>>Это резко сокращает размеры словарей при мизерном ухудшении перфоманса.
V>Словарь у меня один — это отображение входного символа на его код. После минимизации алфавита, кодов-терминалов очень мало

Ну это у тебя. А на моих данных их может быть много, несколько сотен легко.

НС>>Иногда имеет смысл учитывать неравномерность вероятности появления различных значений во входных данных
V>Эта статистика даёт профит при линейном поиске, когда наиболее вероятные значения идут первыми.

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

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

M>Начнем с определений:

M>define следующее:
M>- чистота
M>- понятие чистоты
M>- проверяемое компилятором понятие чистоты

Под чистотой естественно подразумеваются чистые функции — не имеющие побочных эффектов. Само собой такие функции можно создавать хоть на ассемблере, но это не имеет особого смысла, если компилятор не может гарантировать их чистоту. В этом смысле какой-нибудь C# (или упоминаемый Эрланг) ничем не отличаются от ассемблера. Если же компилятор умеет гарантировать чистоту функций (как скажем в D), то тогда от таких функций можно получить два известных полезных бонуса: кэширование результатов и произвольный порядок выполнения (та самая ленивость). Кроме того, мы можем потребовать обязательную чистоту функций в языке — тогда мы получим так называемый чистый ФП язык (типа Хаскеля). В нём указанные выше бонусы распространяются на весь язык, правда это совсем не окупается, т.к. без возможности удобного написания не чистых функций практическое программирование крайне неудобно.

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

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

Ну это у кого как. ))) На данном форуме присутствует не мало специалистов, имеющих хорошее понимание на всех уровнях. )

__>Зачем ему _особенности_ работы кэша? Достаточно знать его размер, остальное сообщит профайлер. И это только в том случае, если вообще дело дойдёт до профилирования. Если есть несогласные, пусть покажут конкретный пример, когда знания деталей работы кэша необходимо разработчику информационного портала.

Отлаживать профайлером что? ) Nginx или PostgreSQL? )

Ну и необходимы подобные знания естественно в случае системы с большой нагрузкой. В случае сайта компании "рога и копыта" такое само собой не требуется. )))

_>Под чистотой естественно подразумеваются чистые функции — не имеющие побочных эффектов... Если же компилятор умеет гарантировать чистоту функций (как скажем в D)

Что-то ты очень плохо, имхо, понимаешь, как компилятор в D "гарантирует" чистоту. Он «гарантирует» только то, что программист прописал ручками pure, const, immutable где надо. Плюс в «чистых» функциях можно прекрасно создавать нечистые функции, и никто и глазом не моргнет. Плюс «чистые» функции прекрасно могут модифицировать то, что передается им в аргументах.

Ну и вообще http://dlang.org/faq.html#pure


Глядя на эту «чистоту» понимаешь, что Erlang намного более чистый язык

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

M>Что-то ты очень плохо, имхо, понимаешь, как компилятор в D "гарантирует" чистоту. Он «гарантирует» только то, что программист прописал ручками pure, const, immutable где надо. Плюс в «чистых» функциях можно прекрасно создавать нечистые функции, и никто и глазом не моргнет. Плюс «чистые» функции прекрасно могут модифицировать то, что передается им в аргументах.
M>Ну и вообще http://dlang.org/faq.html#pure

А что тебе собственно не нравится? ) Компилятор гарантирует определённое поведение у функций, помеченных как pure. Соответственно в дальнейшем при работе с этими функциями можно использовать техники, дающие нам два неплохих бонуса, известных из чистого ФП. Причём благодаря статической типизации компилятор не позволит нам передать не pure функцию в такие места.

M>Глядя на эту «чистоту» понимаешь, что Erlang намного более чистый язык

В Эрланге то даже такого понятия нет на уровне языка. )))

_>А что тебе собственно не нравится? ) Компилятор гарантирует определённое поведение у функций, помеченных как pure. Соответственно в дальнейшем при работе с этими функциями можно использовать техники, дающие нам два неплохих бонуса, известных из чистого ФП. Причём благодаря статической типизации компилятор не позволит нам передать не pure функцию в такие места.

Давай посмотрим на твои прекрасные чистые функции с гарантированным поведением

Сначала определения:

a function may be described as a pure function if both these statements about the function hold:

— The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state

— Evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices

Ой, а что это у нас в D творится? http://klickverbot.at/blog/2012/05/purity-in-d/

int readAndIncrement(ref int x) pure {
  return x++;
}

For example, this piece of code

int val = 1;
auto result = readAndIncrement(val) * readAndIncrement(val);
// assert(val == 3 && result == 2);

clearly does not give the same result if readAndIncrement is only evaluated once instead:

int val = 1;
auto tmp = readAndIncrement(val);
auto result = tmp * tmp;
// assert(val == 2 && result == 1);

Ахаха мяу.

Нет, конечно можно в определении функции указать, что нам требуется immutable или const x, но это уже ручная работа, и в итоге все равно никто ничему не гарантирует (потому что в итоге все равно все упирается в человека, который может расставить эти указания, а может убрать в очередном коммите).

И чистоты там не было, так и нет.

M>>Глядя на эту «чистоту» понимаешь, что Erlang намного более чистый язык

_>В Эрланге то даже такого понятия нет на уровне языка. )))

Какого понятия? Твоей уверенности, что в D — чистые функции? Бггг.

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

M>Нет, конечно можно в определении функции указать, что нам требуется immutable или const x, но это уже ручная работа, и в итоге все равно никто ничему не гарантирует (потому что в итоге все равно все упирается в человека, который может расставить эти указания, а может убрать в очередном коммите).

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

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

M>Ой, а что это у нас в D творится? http://klickverbot.at/blog/2012/05/purity-in-d/
M>...

Ты думаешь, что сообщил тут что-то новое? ) Данные вопросы (то, что определение чистоты в D расширено относительно определения чистоты в Хаскеле) обсуждались на этом форуме ещё несколько лет назад. )))

M>Нет, конечно можно в определении функции указать, что нам требуется immutable или const x, но это уже ручная работа, и в итоге все равно никто ничему не гарантирует (потому что в итоге все равно все упирается в человека, который может расставить эти указания, а может убрать в очередном коммите).

Вот ты и сам написал ответ. Да, а если не проставить нужные модификаторы (pure, immutable и т.п.), то приложение просто не скомпилируется, т.к. в коде ожидают функцию с вполне определённым прототипом. Хотя это же всё вопросы статической типизации и тебе слабо знакомо...

M>И чистоты там не было, так и нет.

Ну раз великий эксперт так сказал, то тогда конечно. )))