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

VD>На что? Можно конкретнее?

Для того, чтобы определиться "на что", надо в первую очередь понять "что" конкретно не устраивает. В интерпретации ИТ ситуация выглядит так:

"Снаружи" методов у нас все шоколадно. Иерархии классов, сплошное ООП, полиморфизм и прочие извращения. "Внутри" методов — пещерный век.

Мне вот это как раз и непонятно. Я об этом тут уже писал да потерли.
А "что" происходит внутри методов-то? Что за таинственная "жизнь" такая? Может сложиться впечатление, что "жизнь внутри методов" происходит как бы отдельно и сугубо автономно от всех этих внешних иерархий.
А фактически внутри методов и пишется как раз код, который использует все эти "иерархии". И если наши красивые объектно-ориентированные классы предполагают по своему дизайну, что работать с ними приходится пещерными методами — то чему тут можно удивляться?

Касательно Немерле. Вопроса метапрограммирования я нарочно не касаюсь — возьмем только сочетание ФП и ООП. Почему мне не нравится это? Потому что ФП в данном случае это не что иное как попытка облечь "пещерные методы" в более красивую форму. И все. Я тут не вижу никаких "кардинальных" изменений по сравнению с тем что раньше было. Да, раньше кололи дрова топором, теперь лесопилка — но "двора"-то по-прежнему нужны, мы от этого не ушли никуда.
Ну по-моему реально странно все это. Мы, к примеру, создаем коллекции, скажем так, "векторного" типа, которые предполагают, что для осуществления групповых операций придется пользоваться банальным перебором — а потом начинаем придумывать наиболее "красивые" формы этого перебора.

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

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

AVK>Здравствуйте, Константин Л., Вы писали:

КЛ>>Ну что за тон, право?

КЛ>>Понимаешь, обычно уменьшительно-ласкательные приставки это способ выразить насмешку, презрение.

AVK>ИМХО, вполне естественная, хоть и некорректная, реакция на попытку пенисометрии.

Да никто с ним ничем меряться не собирается. Чем он занимается и насколько у него больше/меньше все прекрасно знают. Просто мимо его заявления про мальчиков-архитекторов и рутину я не смог пройти мимо. Вот и решил поинтересоваться, в каких проектах он участвовал, кроме своего AGG.

КЛ>>1. Обосрал процесс создания архитектуры
КЛ>>2. Обосрал пару профессий вместе с ихними представителями

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

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

V>Возможно, отличия в скорости работы?

А причем тут скорость работы? Для жабо-скрипта кстати никто не мешает сделать Джит — причем даже примеры реализации уже есть в количестве.

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

Реплика в зал: не, ну что за мода пошла — понапридумывать аналогий, и потом считать, что это выглядит хоть в малейшей степени убедительным обоснованием собственной точки зрения?

Здравствуйте, Константин Л., Вы писали:

КЛ>Да никто с ним ничем меряться не собирается.

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

КЛ> Чем он занимается и насколько у него больше/меньше все прекрасно знают.

Ну так и не надо тут заниматься флеймогенераторством.

КЛ> Просто мимо его заявления про мальчиков-архитекторов и рутину я не смог пройти мимо.

Это не повод поступать точно так же.

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

AVK>Реплика в зал: не, ну что за мода пошла — понапридумывать аналогий, и потом считать, что это выглядит хоть в малейшей степени убедительным обоснованием собственной точки зрения?

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

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

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

qsort [] = []
qsort h:t = qsort [e | e <- t, e < h] ++ [h] ++ qsort [e | e <- t, e >= h]

Предлагаю повторить то же самое на "базовых" if-ах и while-ах. Кстати, хочу заметить, что истинно базовыми являются jz, jnz, jc, jnc и т.п. Ну а вообще труъ — это когда таблица переходов для машины Тьюринга.

PD>А не возникала ли у тебя мысль — а может, ничего и не надо ? Базовые конструкции потому и называются базовыми, что они , во-первых, не упрощаются, а во-вторых, их набор минимален и не всякое туда пустят, просто для того, чтобы не нарушать стройность и логику — иными словами, по принципу бритвы Оккама. Это как аксиомы Евклида — за 2000 лет никаких новых аксиом туда не добавили и не добавят . И три классические формы — следование, выбор, повторение — так и остались, и четвертому Риму похоже, не бывать

Гм, ну вообще-то повторение тоже разное бывает. Я вот уже давно for-ом в C# не пользуюсь. А в Питоне, например, for вообще имеет семантику C#-ского foreach, и ничего. Во-вторых, про труъ базовые конструкции я уже писал. В-третьих, туда не только не добавили аксиомы, но и изъяли одну, и получили теории, гораздо более мощные. Ну и наконец, никто не заставляет строить геометрию аки Евклид. Можно выбрать и другой набор аксиом, правда он будет не столь удобен. Так вот в случае с программированием мне известны три такие альтернативные системы аксиом. И не факт, что они чем-то уступают машине Тьюринга.

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

PD>>Да. Но не более эффективно, чем собственно ассемблер. В лучшем случае (см. выделенное мной) — не хуже. А ведь обещали на порядок — вот я и смеюсь.
S>Неочевидно, кто будет смеяться последним. Представления вашего поколения об эффективности программ оказались плохо совместимыми с реальностью.

#pragma flame on

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

#pragma flame off

S>Помимо abstraction penalty есть еще и abstraction gain.
S>В реальной жизни вручную оптимизировать мало-мальски сложный алгоритм на ассемблере не получится — слишком мала емкость головы. И это даже если задаться конкретным целевым процессором и параметрами окружения.

У вас на слово "ассемблер" невротическая реакция. Павел не предлагал все писать на ассемблере, или даже что-либо писать на ассемблере, он произнес слово "ассемблер", чтобы очертить некоторый теоретический предел эффективности, достижимой на данном железе.

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

K> Я вот уже давно for-ом в C# не пользуюсь.

А если надо пройтись по индексированному списку и индекс использовать внутри — руками заводишь счетчик или делаешь foreach по Enumerable.Range()?

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

FR>Программа на хаскеле конечно эффективнее, в смысле производительности пишущего (и читающего) код программиста.
FR>В смысле производительности работы готового она малоэффективна. Но можно оптимизировать http://en.literateprograms.org/Quicksort_(Haskell) и все равно код будет проще сишного в разы а по производительности вполне к нему приблизится.

Кстати, для отдельно взятой функции сортировки Haskell может и проиграет в скорости. Но для реально больших программ компилятор делает такие оптимизации, что ручками то же делать на C — равносильно самоубийству.

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

D>Ключевым моментом, которого пока не касались в этой дискуссии, является высокоуровневая оптимизация, про которую никакой ассемблер не знает. Например, в Хаскелле есть дефорестация (list fusion). Вася взял список, применил к его элементам функцию f, получив другой список:

А почему это обязательно list fusion? Есть же прекрасно описаный алгоритм fusion для алгебраических типов. Я его даже применял в своём компиляторе. Каково же было моё изумление, когда я до этого недели две убил на оптимизацию редуктора графов и сумел ускорить его всего в 2.5 раза, а потом добавил fusion и на исполнение тестового примера понадобилось в 30 раз меньше редукций (соответственно, и времени). Надо сказать, что код задачек для бенчмарка был крайне простеньким и запросто оптимизировался в случае с C. Но это же простой случай. Я по сей день когда пишу на С#, со страхом представляю, каких оптимизаций компилятор не будет делать. А в ручную сделать не возможно by design.

Кстати, слышал что то же fusion реализуется на хиломорфизмах. Но пока до этого не дорос.

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

VD>Дворкин, а что ты тогда делаешь в форуме по дотнету, да и здесь? Ты же должен писать софт на асме. И по сему, времени у тебя свободного остаться не должно. Вот у меня и возникает вопрос, ты просто: ты нас обманываешь или заказчиков?

Вообще-то на вопросы, заданные в таком тоне, лучше не отвечать, но так и быть, отвечу.

1. В форуме по дотнету я задаю вопросы, связанные с небольшой утилиткой, которую я написал. А мне на эти вопросы вместо ответов по существу дают советы, как правильно делать и учат уму-разуму.
2. На асме мне писать, возможно, придется. Очередная задача — есть некий код автора алгоритма, работает 5 сек, коммерческий софт на эту тему работает тоже примерно 5 сек, а заказчик хочет, чтобы уложилось в 200 мсек. Как ускорить быстродействие раза в 3-4 — понимаю, а вот в 20 — нет. Хотя предпочел бы обойтись без асма, но, возможно, придется. И не так уж это сложно, поверь.
3.И поскольку я это не понимаю пока, и заказчик тоже понимает, что я это за мгновение не сделаю, то мне надо думать, и заказчик меня не торопит. Думать надо, понимаешь ? Не оптимизировать вычисление процентов и не искать синтаксический сахар или аттическую соль, а думать, что с алгоритмом сделать. И думать я могу в самых разных местах, например, в маршрутке по дороге из дома/домой (почти час в один конец, увы). И я не знаю, сколько времени мне понадобится на то, чтобы что-то радикальное придумать. Был случай — две недели думал, ни одной строчки не написал, потом придумал и за пару дней реализовал.
Вот поэтому мне и забавно, когда серьезные вроде бы люди на полном серьезе обсуждают, как оптимизировать вычисление процентов или как контрол должен с родителем общаться. Мне бы ваши проблемы, господа.
4. А сегодня у меня университетский день был, между прочим. И писалось все это в основном в двухчасовом перерыве, а немного рано утром, пока студенты меня еще в оборот не взяли.
5. А обманывать тебя или других — в чем, собственно, этот обман мог бы заключаться ?


Надеюсь, я удовлетворил твое любопытство ?

А теперь позволь вопрос к тебе. Я не буду указывать, на чем ты должен писать софт, а вопрос такой — ты его вообще пишешь или только рассуждаешь здесь о преимуществах того или иного языка/среды/сахара/соли ? Дело в том, что у меня довольно давно сложилось устойчивое впечатление — те, кто очень любят обсуждать синтаксические конструкции и т.п. — люди, которые сами уже ничего серьезного не пишут.

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

Pzz>#pragma flame on

Pzz>Напротив. Просто потребность в эффективности программ стала не общепринятой, а нишевой. Когда возникает необходимость спроектировать сервер, обслуживающий большое количество клиентов, или коробочку, выдающую осмысленную производительность на слабом железе, то тут некуда деваться от традиционных представлений о производительности (разве что tradeoff между процессором и памятью заметно сместился в сторону памяти). Ваше поколение оказывается довольно беспомощным при решении такого рода задач, и плохо обучаемым, потому как у вас происходит разрыв шаблона при соприкосновении с реальностью

Pzz>#pragma flame off

Я вот об одном думаю иногда. Взять бы этих специалистов по паттернам, фреймворкам и интерфейсам, назначить им хорошую зарплату, да только поручить им спроектировать и написать www.microsoft.com , с тем количеством запросов, которое он реально обслуживает. А потом, когда время ответа будет порядка десятков секунд, уволить всех с распубликованием их имен

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

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

AVK>А если надо пройтись по индексированному списку и индекс использовать внутри — руками заводишь счетчик или делаешь foreach по Enumerable.Range()?

Правильнее было сказать, "уже давно for-ом практически не пользуюсь". Правда, чаще выбираю второй подход, нежели for. Потому что у меня есть свой индексированный список. И для работы с ним у меня есть Range. Я как правило не имею дело с парами индексов или длиной списка. У меня на это есть Range, который ещё реализует IEnumerable (например, пройтись по списку foreach (var i in list.All) { }. Разумеется, всё это только в тех проектах, где мне можно использовать свои библиотеки, и не надо взаимодейтстовать с кодом, который уже написан под List<T> или массивы.

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

PD>А это не обсуждалось. Вот что писал IT

IT>>Вот здесь два примера того, как правильные высокоуровневые конструкции могут сделать код в разы проще, понятнее и эффективнее

А почему "могут" не выделил? Я же знал с кем имею дело и специально так сформулировал

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

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

K>Гм, ну вообще-то повторение тоже разное бывает. Я вот уже давно for-ом в C# не пользуюсь. А в Питоне, например, for вообще имеет семантику C#-ского foreach, и ничего. Во-вторых, про труъ базовые конструкции я уже писал. В-третьих, туда не только не добавили аксиомы, но и изъяли одну, и получили теории, гораздо более мощные. Ну и наконец, никто не заставляет строить геометрию аки Евклид. Можно выбрать и другой набор аксиом, правда он будет не столь удобен. Так вот в случае с программированием мне известны три такие альтернативные системы аксиом. И не факт, что они чем-то уступают машине Тьюринга.

Со всем этим можно было бы согласиться, если бы процессор мог непосредственно выполнять код на Хаскеле/C#... Тогда я бы снял свои возражения. А пока что, что там не делай, а закончится все mov, add, jmp и т.д. И вот это есть абсолютный теоретический предел при данном алгоритме, если его идеально эффективно запрограммировать. Улучшить можно, только если алгоритм поменять (или доступ к данным ускорить или распараллелить и т.д.).

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

D>Компилятор Хаскеля взял эту конструкцию с кучей промежуточных списков и оптимизировал в
D>

D>olja_oplimized lst = map (h . g. f) lst
D>

D>Без единого промежуточного списка.

Ты пойми, люди вроде Дворкина мыслят не так. Они когда пишут код, то представляют его в уже оптимизированном виде. У него не то что списка не будет (это же непроизводительные расходы памяти!). У него и функций в коде не будет. Он просто напишет один огромный "for" в тело которого он зафигачит все свои вычисления. В другом месте он зафигачит другой цикл, который будет похож на этот, но немножко другой. А для себя и окружающих от скажет (подумает), что дублирование кода неизбежно и определяется оно алгоритмами. В лучшем случае часть кода в цикле он вынесет в отдельные процедуры.

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

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

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

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

Что касается первого примера с pattern matching, то для леквидации своей безграмотности можешь полистать на досуге вот этот документик. Это алгоритм компиляции pattern matching, который используется в Nemerle. Код, который получается в результате, не просто полностью отжат и максимально эффективен, он ещё и генерируется так, что повторить его столько же эффективно на if-ах просто невозможно. Refletor в большинстве случаев такой код не восстанавливает, пишет что метод обфусцирован.

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

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

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

PD>>А это не обсуждалось. Вот что писал IT

IT>>>Вот здесь два примера того, как правильные высокоуровневые конструкции могут сделать код в разы проще, понятнее и эффективнее

IT>А почему "могут" не выделил?

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


>Я же знал с кем имею дело и специально так сформулировал

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

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

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


>Распаралеливание императивного алгоритма потребует больше времени, чем написание самого алгоритма и сделает его в конце концов окончательно безнадёжным.

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

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

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

PD>Я вот об одном думаю иногда. Взять бы этих специалистов по паттернам, фреймворкам и интерфейсам, назначить им хорошую зарплату, да только поручить им спроектировать и написать www.microsoft.com , с тем количеством запросов, которое он реально обслуживает. А потом, когда время ответа будет порядка десятков секунд, уволить всех с распубликованием их имен

ASP.NET, который оно использует, спроектировали как раз таки "специалисты по паттернам, фреймворкам и интерфейсам".

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