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

K>А почему это обязательно list fusion? Есть же прекрасно описаный алгоритм fusion для алгебраических типов. Я его даже применял в своём компиляторе.

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

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

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

Ёшкин кот. Это чьи слова:

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

Гради Буча?

Ты ж, пытаешься свести причины распространение ООП к "индустриальным методам разработки", в которые (в методы, то бишь) ничтоже сумняшеся вписываешь десятки индусов. А я тебе пытаюсь объяснить, что такое почти никому в здравом уме и трезвой памяти в голову прийти не могло. Ну разве что IBM могла какой-нибудь финт отколоть в этом стиле, да и то — маловероятно.

Pzz>Поэтому да, тривиальное знание, типа того, как открыть сокет и как в него писать, в ООП описать относительно удобно. А для нетривиального знания — типа того, что сеть по природе своей штука динамическая — опаньки, никакой готовой методологии и нет.

Блин, ты не можешь чуть послабее шифровать то, что хотел сказать на самом деле? Никто здесь вроде, ООП серебряной пулей не считает. Это был раз.

Два, методология анализа в терминах ООП не просто "слабо развита", она вообще не развита. Нету надёжного метода определения того, что такое "объект". Это тоже ни для кого не новость. И это, тем не менее, никак не противоречит тому, что классы/методы — определённый способ записи знаний. Всего лишь определённый способ, ничего больше. Предоставляет русский язык специальные средства построения анекдотов? ИМХО — нет. Годится он, тем не менее, для выражения анекдотов? ИМХО — вполне. Он богаче наскальной письменности? Вроде как — да. Развивался ли он исключительно для руководства? Вроде как — нет. Вот и с ООП то же самое.

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

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

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

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

Pzz>>>Я имею ввиду, конечно, техническое руководство, а не то, чтобы у всех были исправные стулья и соблюдались сроки
ГВ>>Так ты не путай одно с другим. "Техническое руководство", это такая штука, которая к "менеджменту" вообще никакого отношения не имеет, кроме лексического подобия.
Pzz>Это спор о терминах.

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

Pzz>>>И много программистов с тех пор сократилось? Давайте пропустим маркетинговый буллшит.
ГВ>>Нет, не пропустим. Соображение о повышении индивидуальных способностей программиста было весьма действенным фактором распространения ООП. И кстати, в некоторой части вполне подтвердилось. Естественно, что к рассуждениям о "сокращении количества" относились по большей части скептически, но если бы ООП проталкивалось под флагом вовлечения массы людей — сопротивление было бы сумасшедшим. Да ООП вообще бы из пробирки не вылезло, не смотря на все позывы индустрии.

Pzz>В свободном капиталистическом мире есть только один действенный фактор распостранения чего-бы то ни было: максимизация прибылей.

Где противоречие с:

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

?

Ты прибереги лучше банальности для других слушателей.

Pzz>Не вовлечение массы людей, а линейное увеличение их совокупной производительности по мере увеличения их количества — именно это предлагает ООП.

ГДЕ????? КОГДА???? АВТОРА!!! ШАМПАНСКОГО! Откуда ты взял этот бред?

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

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

Pzz>В современных коммерческих реалиях гораздо важнее успеть быстро, чем ограничиться минимумом сотрудников. Успешная программа может приносить миллион в месяц. Лишний десяток кодеров стоит гораздо дешевле.

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

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

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

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

VD>>Вопрос к головастому товарищу, много ли он на ваяет современных многоэтажных домов если ему дать один топор?
VD>>Как ни одного? А тогда к чему вся эта пышная демагогия?

PD>Вопрос к другому головастому товарищу — сколько комплексов в Кижах ему удастся сделать с помощью крупнопанельных блоков ?

С начало сам на вопрос ответь, а потом свой задавай.

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

WH>Ты хоть один большой сервер вернее кластер хотябы на несколько десятков машин которые стоят в разных дататцентрах и система должна маскировать сбои не только одной машины но и целого датацентра написал?
WH>Вот тебе статистика с одного из серверов такой системы:
WH>

WH>----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- ---load-avg---
WH>usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw | 1m   5m  15m
WH>  0   4  80  11   0   4|  42M  440k|3177k  108M|   0     0 |  14k 2920 | 2.6  3.2  3.1
WH>  1   5  83   7   0   4|  44M    0 |3238k  108M|   0     0 |  14k 3196 | 2.6  3.2  3.1

Гм, а мне расскажите, а как это у Вас так получается, что при avenrun (aka LA) > 2 такой idle? В него в данной системе считается сон над диском? Или там 16 ядер?

Отдача, что ни говори, красивая. Хотя собственно никакой особой кластерности не видно;))

WH>Короче проблемы в таких системах настолько другие что ты себе и представить не можешь.

Да уж...

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

N>Гм, а мне расскажите, а как это у Вас так получается, что при avenrun (aka LA) > 2 такой idle?
Что такое LA я так и не уловил.
Уж очень мутные попугайчики.

N>В него в данной системе считается сон над диском? Или там 16 ядер?
Там 14 винтов по 700гектар каждый, а сколько ядер никогда не интересовался на этих машинах оно до лампочки.
У нас просто старое железо принципиально не закупают, а новые процессоры многоядерные...

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

N>Хотя собственно никакой особой кластерности не видно)
А оно должно быть видно из статистики одной машины?
В любом случае это лишь ответ на "традиционные представления об эффективности"...

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

C>>Справедливости ради, у тебя система заточена на быстрый отклик. Если нужна экономичность без очень быстрого отклика, то энергетически выгоднее загрузить на 100% меньшее число серверов.
ВВ>Вообще согласно всем общепринятым нормам во втором листинге у него как раз практически предельная загрузка для продакшин-серверов, что и есть ~50%.
Эти нормы для интерактивных сервисов (там и 50% может быть многовато). А если делать числодробилки — то нормы совсем уже и другие.

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

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

PD>>Ну уж нет. Читай внимательно. Выделено мной.

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

PD>>Код!

FR>Это

FR>

FR>qsort []     = []
FR>qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)
FR>

FR>по твоему не код?

Задача придолбаться?;)) Проще, понятнее — верю. Эффективнее — сомнительно. Реально, фильтрация на списках будет занимать дохрена копирований, рекурсия может переполнить стек при кривой реализации... в общем, эффективность такого должна быть не выше (а то и ниже) эффективности пузырька, который пишется не менее просто и понятно.:)) Или докажите обратное (желательно на практике;))

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

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

_FR>>>>>и факториал как пример рекурсии
T>>>>Убивать за такие примеры рекурсии.
_FR>>>За что? Только за то, что "навязло" в зубах?
N>>За методическую некорректность. Показывание рекурсии на примере факториала, при том, что рядом он считается просто и тривиально обычным циклом

_FR>Факториал — циклом? Реально считать надо таблицей (массивом), в котором индекс элемента — входное значение, а значение в массиве — результат. Но это так, ремарка, к делу отношения не имеющая.

Вот именно что не имеющая:)) Данные-то откуда-то должны взяться? Или на "Феликсе" считать? ;))

N>>Если бы я показывал рекурсию на каком-то примере, первый пример был бы взят максимально практический, причём такой, чтобы его нельзя было в одной функции свести в цикл. А уже после этого — числа Фибоначчи, а собственно факториал — уже в качестве упражнения (если на лекции — вызвать кого-то к доске и заставить преобразовать).
_FR>Например? Вот я точно знаю, что лично на меня лучше всего подействовал именно факториал, о нём и говорю.

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

_FR> Какой может быть пример? Лучше сказать "такой-то", а я только слышу "какой-то не такой, другой" и т.п. :xz: Покажите, и дискуссия исчерпает себя. но помните, что про рекрсию надо рассказвать ещё школьникам (информатика в 10-11 классе).

Дойдёт до этого — придумаем. Слава богу, есть с кем консультироваться. А что школьникам факториал не интересен — это я по себе ещё помню.

N>>И ещё одно — размахивание факториалом является косвенным указанием на то, что "рекурсия — это очень просто". Когда же выучивший такое сталкивается с реальной жизнью, когда перекладка алгоритма на рекурсивный лад в первую очередь крайне громоздка — следует шок.
_FR>Это уже к вопросу отношения не имеет: просто там вообще или нет. Бывает же по-разному.

Угу, бывает по-разному. (ducks and runs)

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

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

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

А сравнение с C/C++ реализацией на чём-то вроде vector опущено сознательно?

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

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

N>>Гм, а мне расскажите, а как это у Вас так получается, что при avenrun (aka LA) > 2 такой idle?
WH>Что такое LA я так и не уловил.
WH>Уж очень мутные попугайчики.

Среднее за энное время назад (обычно, 1, 5 и 15 минут, некоторым экспоненциально-кумулятивным механизмом) количество готовых к выполнению процессов. В зависимости от системы в это могут включаться или нет процессы, ждущие дискового ввода/вывода.

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

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

В каком смысле "отвисают"?

N>>Хотя собственно никакой особой кластерности не видно;))
WH>А оно должно быть видно из статистики одной машины?

Конечно, нет. Потому и не видно.

WH>В любом случае это лишь ответ на "традиционные представления об эффективности"...

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

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

VD>>Как ни одного? А тогда к чему вся эта пышная демагогия?
Dog>Шикарно. Предлогаю переименовать форум в "Демагагия программирования", как более соответствующее духу дискуссий

Батенька, вы не первый.

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

WH>Ты хоть один большой сервер вернее кластер хотябы на несколько десятков машин которые стоят в разных дататцентрах и система должна маскировать сбои не только одной машины но и целого датацентра написал?

Ну вообще-то, хвастаться надо не количеством затраченных ресурсов ("несколько десятков машин"), а достигнутым результатом — таким, как количество запросов/юзеров/не знаю чего и фотл-толерантностью.

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

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

WH>Короче проблемы в таких системах настолько другие что ты себе и представить не можешь.

Это довольно смелое высказывание о моей способности представлять проблемы

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

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

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

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

DM>Некоторый опыт ФП у меня есть, просто вдруг я что-то важное пропустил, что хорошо заменяет ООП, вот и решил спросить. Пока вижу, что не ничего не пропустил, ответы предсказуемые.

.........

DM>Ручная имитация VMT.

Пока ты будешь думать в таких терминах, (туда же и замыкание как объект) польза от изучения функциональщины для тебя будет близка к нулю.

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

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

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

То есть в 6 раз. А мне в 20.

Успехов!

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

N>Задача придолбаться?) Проще, понятнее — верю. Эффективнее — сомнительно. Реально, фильтрация на списках будет занимать дохрена копирований, рекурсия может переполнить стек при кривой реализации... в общем, эффективность такого должна быть не выше (а то и ниже) эффективности пузырька, который пишется не менее просто и понятно. Или докажите обратное (желательно на практике)

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

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

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

Если на Си реализовать тот же алгоритм, будет сложнее.

N>А сравнение с C/C++ реализацией на чём-то вроде vector опущено сознательно?

Так давай сравнивай никто ни мешает.

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

PD>То есть в 6 раз. А мне в 20.

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

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

WH>При мне про высоконагруженные системы даже не заикайся.
Ик...
WH>Я на них не одну свору собак сожрал.
Говорят очень полезно от туберкулеза, болеете да? Выздоравливайте
WH>Так что порву на тряпки по любому.
Не пойму я вас, то собак жрете, то тряпки рвете...

Здравствуйте, Pzz, Вы писали:
Pzz>Отвечу вопросом на вопрос , а какие вы считаете сводимыми?
Я — все.

Pzz>Угу. И настойчиво продолжают их сравнивать, когда не нужно. Но зато правильно, с учетом пунктуации
Сарказм уловлен, но не понят.

Pzz>Вы говорите ровно то же, что и я: люди, привыкшие изучать интерфейсы без понимания того, что "под капотом" у этих интерфейсов, оказываются в неудобном положении, когда интерфейсы меняются. Через несколько лет string.Compare() будет смотреться столь же ограниченным частным случаем, как сейчас смотрится интерфейс к строке в виде последовательности байт в кодировке ASCII.
Ну, на мой взгляд, всегда нужно смотреть как минимум на +-1 уровень. То есть когда пишешь страничку на ASP.NET, то нужно как минимум
а) знать, для чего эта страничка нужна (а не просто "положи сюда грид, а сюда кнопку в панели")
б) знать, во что превращается разметка, которую ты пишешь (а не просто "упа, я заменил = на # и оно заработало")

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

Но ваши-то утверждения формулируются не в относительных терминах, а в абсолютных. Грубо говоря, та самая страничка находится на 12 уровне абстракции. Я предлагаю смотреть на 11 и 13й, а вы хотите — чтоб прямо от нулевого.

Вот я и говорю про старую гвардию, которая знает ровно два уровня абстракции: язык Си и ассемблер. И им невозможно рассказать даже про 5й уровень, тем более про 13й. Для них это пустой звук.