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

M>>>Почему по твоему мнению , серезные приложения которые я перечислял FFMPEG — JASPER написанны без использования FP ? на традиционных C/C++. ?
IT>>Если бы они были написаны с использованием FP, то они были бы ещё серьёзней.

ГВ>Докажи.

Переписать всё на N? Да без проблем. У тебя кошелёк достаточно большого размера?

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

FR>>Оба эмулируются даже на си.

IT>Вот тебе перегрузка:

IT>

IT>void Foo(int i);
IT>void Foo(string s);

IT>Foo(1);
IT>Foo("1");
IT>

void Foo(char *param_format, ...);

Foo("%i", 1);
Foo("%s", "1");

IT>Вот тебе замыкание:

IT>

IT>Func<int,int> Foo(int x)
IT>{
IT>    return y => x + y;
IT>}
IT>

IT>Эмулируй.

typedef struct TFoo
{
    int (*Call)(struct TFoo*, int);
    int x;
} Foo;

int Add(Foo *Self, int y)
{
    return Self->x + y;
}

void Create(Foo *Self, int x)
{
    Self->Call = Add;
    Self->x = x;
}

FR>>И к тому и замыкания и перегрузка методов это не более чем вкусности, они не являются необходимыми чтобы программировать в соответствующем стиле.

IT>А этот топик о чём? Именно о вкусностях. А ты о чём думал?

Ну я то понимаю, но пока не попробуешь объяснять бесполезно

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

ГВ>>Докажи.

IT>Переписать всё на N? Да без проблем. У тебя кошелёк достаточно большого размера?

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

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

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

IT>>>Это не совсем так. Есть вещи, которые невозможно сделать без поддержки компилятора/среды. Например, в ООП это перегрузка методов, в FP замыкания.

IT>Вот тебе перегрузка:

IT>

IT>void Foo(int i);
IT>void Foo(string s);

IT>Foo(1);
IT>Foo("1");
IT>

Т.е. перегрузка функций — это прерогатива ООП
Я лично про виртуальность подумал, тем более раз методы.

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

M>>>>Почему по твоему мнению , серезные приложения которые я перечислял FFMPEG — JASPER написанны без использования FP ? на традиционных C/C++. ?
IT>>>Если бы они были написаны с использованием FP, то они были бы ещё серьёзней.
ГВ>>Докажи.

IT>Переписать всё на N? Да без проблем. У тебя кошелёк достаточно большого размера?

А... То есть, будучи написанными на Немерле они автоматически станут более серьёзными. Ясно.

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

ГВ>>От возможностей компилятора реализация этих подходов до какой-то степени зависит, но только до какой-то.

IT>От компилятора это зависит ровно до той степени будут эти стили использоваться или нет. [...]

Если это было возражение, то из какой-то смежной области.

IT>Ещё пример про стиль? Пожалуйста. Сейчас много говорят о параллельном программировании, о том, что если писать в соответствующем стиле, то компиляторы смогут автоматически распараллеливать выполнение задачи. Я об immutable стиле написания кода. [...]

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

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

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

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

Так что эмулировать конечно можно, а программировать нельзя.

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

FR>Ну я то понимаю, но пока не попробуешь объяснять бесполезно

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

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

VE>Т.е. перегрузка функций — это прерогатива ООП

Точно так же как замыкания — прерогатива платформ с автоматической сборкой мусора. Тот бред, который привёл FR даже комментировать не хочется. У нас тут как-то был большой флейм на тему замыканий в C/C++.

VE>Я лично про виртуальность подумал, тем более раз методы.

Ну вообще-то есть overloading, а есть overriding.

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

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

Конечно, чисто теоретически FP и OOP в C такой же стиль как и в Nemerle. А чисто практически его там нет напрочь и никогда в жизни не будет.

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

IT>>Переписать всё на N? Да без проблем. У тебя кошелёк достаточно большого размера?

ГВ>А... То есть, будучи написанными на Немерле они автоматически станут более серьёзными. Ясно.

Т.е. кошелёк у нас небольшого размера.

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

IT>Точно так же как замыкания — прерогатива платформ с автоматической сборкой мусора. Тот бред, который привёл FR даже комментировать не хочется. У нас тут как-то был большой флейм на тему замыканий в C/C++.

Для замыканий есть объяснение. А что мешает сделать перегрузку в Си?
Т.е. в принципе-то она может там быть вообще без каких-либо изменений, или нет?

IT>Ну вообще-то есть overloading, а есть overriding.

Я в курсе.

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

IT>Здравствуйте, Геннадий Васильев, Вы писали:

IT>>>Переписать всё на N? Да без проблем. У тебя кошелёк достаточно большого размера?

ГВ>>А... То есть, будучи написанными на Немерле они автоматически станут более серьёзными. Ясно.

IT>Т.е. кошелёк у нас небольшого размера.

Можно ещё так сказать:
т.е. переписанными они не будут.
Насколько серьёзен ненаписанный проект (и не собирающийся писаться в виду того, что денег никто выделять не будет) по сравнению с написанным и работающим?
Или так:
Да, небольшого, и что? Ты же утверждение сделал.

А то опять религия начинается:

— Если бы они были написаны с использованием FP, то они были бы ещё серьёзней.
— Докажи
— Ты не можешь доказать, что я неправ!!!!!!! // дай денег, перепишу, убедишься. денег не дашь? ну и всё тогда, я прав

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

Здравствуйте, Воронков Василий, Вы писали:
ВВ>Тем не менее продолжается обсуждение в защиту веб-формс.
Нет нигде обсуждения в защиту веб-формс.

ВВ>А ты под АСП.НЕТ понимаешь все прелести, которые дает стандартная библиотка?
Естественно.
ВВ>Для меня если я разрабатываю приложение используя лишь низкоуровневые надстройки над ИЗАПИ — то не АСП.НЕТ. А АСП.НЕТ для меня эквивалентен веб-формс.
И в третий раз повторяю: очень плохо, что ты не можешь отделить вебФормз от АСП.НЕТ. Тренируйся, иначе так и будешь ключи подавать.

S>>Напомню, что ASP.NET всплыл не потому, что вебФормз. А потому, что Рихтер прикрутил к дотнету Power Threading Library, которая позволяет писать офигенно высокопроизводительный код, не слишком жертвуя читаемостью. И потому, что использование IO Completion Ports, которое Рихтер облегчил, крайне важно как раз в серверах массового обслуживания, в частности в веб серверах. В десктопном приложении лишний десяток потоков — тьфу, семечки. А в сервере каждый поток на счету; неэффективные примитивы синхронизации способны убить производительность куда быстрее, чем проверки выхода за границы массивов.

ВВ>Все это прямого отношения к вебу не имеет. И почему казалось бы тут "всплыл" асп.нет?
Бред какой-то. Мы что, начали с обсуждения веба? Нет, начали с производительности и возможностей по оптимизации. АСП.НЕТ здесь — только пример. Что тут непонятного?

S>>Здесь, конечно, никакого abstraction gain нету.
S>>Аналогичную реализацию теоретически можно получить "на ассемблере". Вот только из местных апологетов микрооптимизаций ни один чего-то не спешит представить доказательство в студию. Всё больше рассуждают о теории. Поэтому я настаиваю на эквивалентной честности к обеим сторонам.
S>>Потому, что теоретически abstraction gain таки не сводится к "голове". Я писал тут неподалеку, каким именно способом абстрактный код может обгонять ассемблер.
ВВ>Это как раз и говорит о том, что в голове. В голове не значит, что его нет. В голове значит, что это "человеческий" фактор.
Еще раз: я писал не про человеческий, а про машинный фактор.

ВВ>Конечно же, если упираться в "крайние" примеры — то тут можно сказать только то, что "на ассемблере" их не только нельзя сделать более эффективно, но вообще чисто физически нельзя сделать.
Ну какие же они крайние. Я привел очень простой пример. Там 30 строчек кода всё демонстрируют.

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

S>>А если мы говорим об этом в том смысле, как имеет в виду Дворкин ("платформа у нас одна — win32"), то это просто ламерство.
ВВ>А если "одна платформа" — это XBox 360?
Во-первых, в предыдущей фразе я об этом упомянул. Во-вторых, где у вас гарантия невыхода XBox370?

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

PD>К сожалению, если поручить это все оптимизатору компилятора, то этот компилятор должен будет быть попросту гениальным, то есть включать в себя знание всех и всяческих техник, трюков и т.п, связанных и с кэшами, и с многопроцессорностью и с характером задачи. Увы, это вряд ли реально. Компилятор будет в лучшем случае оптимизировать "в среднем", то есть в расчете на некую среднюю задачу. И чем выше уровень абстракций, тем хуже он это будет делать. Оптимизировать цикл можно очень хорошо, а оптимизировать задачу "сделай вот это" — можно лишь на бвзе некоторых правил оптимизации общего порядка. Как только попадется нечто, что под эти правила не подходят — результат будет плохим.

Всё обстоит ровно с точностью до наоборот: современные компиляторы включают в себя знание всяческих техник, связанных с кэшами и многпроцессорностью.
Причем эти знания в них имеются по поводу достаточно широкого набора целевых платформ. Этот набор значительно шире, чем кругозор среднестатистического программиста.

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

В итоге, мы имеем относительно небольшой набор техник оптимизации, который применим к достаточно высокоуровневым алгоритмам. Компилятору не нужно быть гениальным. Ему достаточно быть просто очень терпеливым в применении этих техник.
В отличие от навыков программиста, которому проще знать фиксированный набор решений задач типа "сделай вот это", чем в уме перебирать все возможные сочетания различных техник, компилятору проще как раз не затачиваться на высокоуровневые прикладные задачи.
И чем выше уровень абстракции, тем лучше он будет это делать. Потому что нужно меньше правил, и меньше шансов, что "попадется нечто, что под эти правила не подходит".

Вот, в частности, оптимизаторы баз данных начинались именно с эвристических методов — это именно то, о чем ты говоришь как об оптимизации на основе частных правил. Типв, "если идет join, то скорее всего его результат будет непустым". Практика показала, что методы динамического программирования и cost-based optimization дают значительно лучшие результаты.

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

Основные трудности с оптимизацией SQL запросов, требующие ручного вмешательства, относятся к одному из двух случаев:
1. Семантическая оптимизация. Т.е. есть некоторые факты о реальной задаче, которые отсутствуют у оптимизатора, но есть у программиста.
2. Слишком большой объем пространства решений. У СУБД мало времени на то, чтобы заниматься оптимизацией; поэтому она выбирает первое решение, которое кажется ей достаточно приличным. В интегрированной исполняющей среде, где есть информация о частотах встречаемости запросов, можно добиться значительного улучшения.

Аналогичные техники применяются сейчас и для оптимизации классических императивных программ: чтобы получить информацию о "характере задачи", компилятор использует информацию от профайлера. См.тж. "Profile-guided optimization".

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

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

VE>Для замыканий есть объяснение. А что мешает сделать перегрузку в Си?

Кривизна решения, которую нам великолепно продемонстрировал FR.

VE>Т.е. в принципе-то она может там быть вообще без каких-либо изменений, или нет?

Я в его примере заметил некоторые изменения.

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

VE>Больше всего, конечно, меня удивляет, почему надо выставить себя правым любым способом.

Хоть правым, хоть левым, лично мне без разницы. Мой код FP техники делают более серьёзным и мне самому себе доказывать ничего не надо. Если вы хотите, чтобы я это доказывал на ваших задачах, да ещё на достаточно объёмных, и если это вам действительно нужно, то я просто предлагаю заплатить мне за моё потраченное время. Ведь это будет работа не на час и не на два, в возможно на неделю, месяц, год. Я пока без понятия. Требовать от меня переписывания этого кода, конечно же, можно. Но тогда нужно будет подумать о компенсации моего времени. Что в этой логике не так?

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

PD>. Зачеты я только сам ставлю, от других не принимаю

А жаль. Потому как какому числу людей ты будущее загубил только Бог может судить.

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

S>А вот у компании Ericsson был пример другой задачи, когда C++ оказался тупо непригоден потому, что стоимость разработки и отладки софта на нём превысила доступный бюджет. В итоге его выкинули и заменили самым медленным из промышленных ФП-языков; при этом, естественно, микропроизводительность упала со страшной силой. Но свитч заработал, и его надежность компенсирует все претензии к его производительности. Это — правое плечо графика.

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

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

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

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

Далее они подумали, что можно организовать множество параллельно выполняемых процессов общение между которыми производится с помощью сообщений. За чёт того, что ЯП функциональный удалось сократить время переключения контекста и отказаться от синхронизации отличной от очереди сообщений процесса. Это позволило оптимизировать данную очередь.

В итоге в Эриксоне получили решение которое рвет любую реализацию хоть на ассемблере хоть на С++ просто потому, что их модель вычислений позволяет обойтись без накладных расходов которые обязательны для "обычного кода". При этом, если начать считать на Эрланге некий последовательный (когда следующее вычисление зависит от результата предыдущего) алгоритм, то мы получим дикие тормоза, так как "чудес не бывает" и любой интерпретатор минимум в 10 раз медленнее машинного кода. Но если задача хорошо параллелится или просто требует проведения множества (сотен тысяч) параллельных вычислений, то Эрланг начинает рвать обычный код как грелку.

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

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

G>Здравствуйте, Pavel Dvorkin, Вы писали:

G>Это и надо, детали не волнуют.

Если это и надо, то надо именно это и делать, а не нести чушь насчет получения битов с помощью BitBlt.

PD>>Уф! Ну как еще объяснять ? Не знаю. Не хватает моих педагогических способностей. Человеку говоришь — для сравнения двух приближенных чисел, полученных как результаты измерений, необходимо учитывать точность измерений. А он в ответ — да не надо, и так можно. В общем, 8.000001 всегда больше чем 8.00000, даже если точность измерения плюс-минус 0.001
G>Не надо разводить демагогию без конкретных чисел. Какова погрешность измерения Time Stamp Counter?
А самому посмотреть можно ? Для GetTickCount — примерно 15 мсек. Что там в .Net — не знаю, выясни сам. Но при той точности моих данных (15 мсек) — делать какие бы то ни было выводы нельзя, даже если в .Net используется QueryPerfomanceCounter с хорошей точностью. Как минимум в этом случае надо перемерить мои данные с той же точностью.

>Какая разница значений будет на измеряемом коде?

Посмотри свое собственное сообщение, где ты утверждаешь, что тебе удалось на C# сделать лучше, чем мне на С++. Ты там сам эти значения приводишь. Разница измеряется путем вычитания одного из другого, полученное значение сравнивается с 15 мсек

Если немного серьезнее. Как преподаватель уже (не как программист) скажу вот что. Не знать что-то не стыдно. Но вот упорствовать в своем незнании не стоит. В конце концов от этого хуже тебе самому будет, не мне же.