Из Лингвы:

Код [программы] — компьютерная программа или часть программы: последовательность команд, данных и описаний данных, из которых она состоит.

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

int Foo()
{
    return 2 * 2;
}

Что же изменилось с тех пор? Давайте посмотрим:

class Bar
{
    int Foo()
    {
        return 2 * 2;
    }
}

За 30 лет развития традиционных языков программирования (Fortran, PL/1, COBOL, Pascal, C/C++, Java, C#) принципиально изменился только мир вокруг метода. Мы получили наследование, инкапсуляцию и полиморфизм, компонентность и контрактность, шаблоны/дженерики и атрибуты, массу паттернов проектирования, подходов и отходов, методологий и прочих вещей, призванных организовать код в нечто более менее управляемое.

Что же изменилось внутри метода? Да почти ничего. Как и 30 лет назад мы имеем if/else/switch, несколько циклов, команды выхода из цикла и метода, операции, присваивание и ещё немного по мелочёвке. Было только одно существенное новшество – замыкания в C# 2.0 в 2005-м году, и те приобрели человеческое лицо только в 2008-м в C# 3.0 с введением лямбд. Может быть ещё с натяжкой вывод типов из инициализации. И это всё! Всё! За 30, блин (в грубой форме), лет!

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

Думаю, именно в этом заключается природа предпочтений многих разработчиков. Все хотят быть архитекторами, никто не хочет быть кодером. Ведь кто такой архитектор? Это стратег, командир космической эскадры, бороздящей просторы вселенной. А кто такой кодер? Пещерный человек с каменным топором в руке, пусть даже его пещера и находится внутри одного из кораблей эскадры. Жуткий дисбаланс. Иметь такой дисбаланс в стратегических и тактических средствах не просто глупо, а уже даже не смешно. Только представьте себе ситуацию – космический десант в виде волосатого безграмотного сброда в шкурах с каменными топорами и костяными ножами. А ведь это и есть истинный портрет современных коммандос от IT. Мы сильно преуспели в стратегии, но при этом являемся абсолютными ламерами в тактике.

В результате часто следствием такого дисбаланса становится смена приоритетов – архитектура всё, код ничто. Много ли у нас обсуждений на тему жизни внутри метода? А чему у нас учат в вузах? Есть ли у нас хотя бы один предмет, рассказывающий как правильно писать код внутри метода? Скорее всего нет. А о чём там рассказывать? Вот и получается на уровне кода бескультурье, самопал и дурь. Но ведь это просто чудовищная несправедливость. Без кода внутри метода, без кодера программа работать не будет, точнее её просто не будет. Без внешней обвязки и архитектора хоть как-то, но можно обойтись.

Но так ли всё плохо? Есть ли надежда на просветление? Конечно, есть. Имя этому просветлению – (кто бы мог подумать) functional programming.

Как это ни странно, но всё это время, в отличии от традиционных языков программирования, развитие на планете FP шло по пути наращивания возможностей внутри функции и манипуляции функциями. В результате было наработано множество техник и паттернов не относящихся напрямую к FP: pattern matching, algebraic types, tuples, type inference, immutability. Всё это спокойно можно использовать вообще без знания, что такое функция высшего порядка. Более того, если попытаться применить FP в традиционном программировании, то окажется, что и ФВП и любые другие возможности FP вообще никак не конфликтуют ни с ООП, ни с АОП, ни с компонентностью, вообще ни с чем. Причина в том, что они применимы и улучшают жизнь внутри метода, практически никак не проявляя себя и не влияя на то, что происходит снаружи, что отлично демонстрируется новыми возможностями C# 3.0.

Казалось бы, причём тут Немерле? А вы думали я о чём? Не дождётесь!

Немерле – это удачная попытка совмещения традиционного программирования и FP. Практически все, что наработано в FP поддерживается в Немерле и уже сейчас готово к использованию. Можно отложить в сторону каменный топор (if/else) и взять в руки охринительной мощности базуку (match). Кривизну out/ref параметров можно заменить на tuples, а зоопарк из приватных методов на удобные локальные функции. Много чего. И главное больше нет необходимости компенсировать скудность тактических средств стратегией.

Это путь в другой мир, в другую жизнь внутри всё того же метода. Примерно как разница между структурным C и современным C# с точки зрения организации архитектуры приложения. Вспомните, как вы изучали ООП или COM/компонентность, точно так же и здесь напрочь рушатся устоявшиеся представления о существующем порядке вещей. Код, получив стероиды от FP, становится мощнее, выразительнее, компактнее, понятнее и интереснее одновременно. Здесь есть куда приложить мозги и есть от чего получить эффект. Кодер здесь уже не троглодит в поеденной молью шкуре, а боец спецназа в нано-костюме из Crysis , способный в одиночку выполнять самые сложные задания.

Впрочем, это всё лирика. На практике получается, что код внутри и снаружи – это два разных кода, два мира, внешний и внутренний. Это хорошо видно при рефакторинге, когда код алгоритма не трогается, но его компоновка полностью меняется. Из этого, кстати, напрашивается ещё один вывод.

Людей принято делить по темпераменту на сангвиников, холериков, флегматиков и меланхоликов. Программистов можно условно поделить на (в примере выше я назвал метод Foo, а класс Bar) фуриков и бариков, на тех, чей код растёт из методов и тех, кто проектирует приложение от иерархий классов. Попробуйте ответить для себя на вопрос кто вы. Представьте, что вы пишите небольшое консольное приложение строчек на 300. Я – однозначно фурик. Я сразу начну писать код прямо в методе Main и только когда почувствую дискомфорт, озабочусь иерархией классов. Делать это сразу я не стану, т.к. считаю это бесполезной тратой времени, потому что не знаю, что меня ждёт впереди. Потом, если понадобится, будет всё, и иерархии, и паттерны, и компоненты. Но это потом, а пока главное – код, главное – функционал.

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

Собственно, всё. Теперь можно и пофлеймить

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

— Я умышленно не стал трогать МП, так эта вещь идёт в параллель с обсуждаемой темой.
— Я знаю про F# и другие функциональные языки. Моё мнение – у них нет будущего в мэйнстриме даже на платформе .NET по причине необходимости переселения на другую планету.
— Все имена и совпадения в тексте случайны.

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

IT>Казалось бы, причём тут Немерле? А вы думали я о чём? Не дождётесь!

Почему то после прочтения первой строчки я уже в этом не сомневался.

IT> Попробуйте ответить для себя на вопрос кто вы. Представьте, что вы пишите небольшое консольное приложение строчек на 300.

Не смог. Ответить, в смысле . Пишу и то и другое одновременно.

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

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

IT>Но так ли всё плохо? Есть ли надежда на просветление? Конечно, есть. Имя этому просветлению – (кто бы мог подумать) functional programming.

Понимаете, есть один очень серьёзный камень преткновения и его имя -- деструктивные присваивания. Не знаю как вам а лично мне очень сложно обойтись без деструктивных присваиваний. Основной рабочий инструмент для меня C, но я много изучал Haskell и много пытался на нём писать. Вы когда-нибудь пробовали написать на этом языке двусвязный список например? А вы попробуйте... А потом слить два отсортированных двусвязных списка с сохранением сортировки... верёвка и мыло в магазине за углом кстати. Диссер Окасаки по чисто функциональным структурам данных на мой взгляд просто хоронит эти структуры с точки зрения практики.
Так вот любая попытка смешать снотворное со слабительным неизбежно заканчивается тем, что обычный человек в своей жизни мыслит императивно, деструктивными ходами. Типа взять ложку положить в ящик. Потом вынуть ложку положить вилку. Вам мама в детстве записки на столе наверняка оставляла. Типа возьми крупу, свари кашу, съешь её и иди в школу. Чисто императивный алгоритм. А функциональные фичи в языке требуют функциональной чистоты и высокой математической культуры (я месяц въезжал в монады и до сих пор не уверен, что въехал). Что до метапрограммирования, то напишите этот марсианский кошмар и вы увидите что его некому поддерживать.
В то же время у меня есть опыт редукции офигительной объектно-ориентированной иерархии на C++ из десятка шаблонных классов и активным использованием STL и Boost на полсотни килобайт кода в одну (!) функцию на C из сорока строчек, *не использующую даже CRT*. И я совершенно уверен из всего своего опыта -- любая "сложность" программирования на простых языках без лишних фич во многом надумана. C is really enough.
Сейчас все эти сишарпы и немерле выплывают только на растущей производительности компов, которая пока растёт быстрее чем все их сборщики мусора тормозят. Надолго ли?

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

Pzz>А вот внутри самих алгоритмов if'ы и while'ы — вполне себе адекватный инструмент. Во всяком случае, все классические алгоритмы описаны в литературе именно в этих терминах.

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

ЗЫ: Удивительно дурацкие флеймы пошли. Как на подбор. Кошмар просто. Казалось бы, причем здесь пропаганда Немерле?

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

IT>Но так ли всё плохо? Есть ли надежда на просветление? Конечно, есть. Имя этому просветлению – (кто бы мог подумать) functional programming.

Ну, ёптыть. Более забористой травы, чем FP в области программирования я пока не встречал. Кто ни попробует -- у всех бошку сносит напрочь.

В целом совсем неплохо, но я не согласен с основным пойнтом того, что нужно скрещивать ООП + ФП и получится всемирное счастье. Попробую пояснить. Раньше я сам тоже был такого же мнения, увидев OCaml и позже Nemerle, думал как же это круто. На первый взгляд все вроде бы отлично, на внешнем более высоком уровне мы используем ООП, а внутри методов ФП. Но чем больше я стал углубляться в ФП, дошел до изучения языка Haskell. Пришел так называемый enlightment! Нет вру, он пришел позже, я все продолжал писать микс ООП и ФП, но уже начали влиять последствия изучения Haskell'а. Внутри методов я все активнее начал применять функциональную декомпозицию, создавать на месте функции, передавать их как аргумент, возвращать их как результат из функции. Таким образом я избавился от многократного дублирования кода (который я хотел кстати убрать макросами), весь объем кода уменьшился в 6-7 раз! Это все я рефакторил одну из моих подсистем. В итоге от ООП остались только описание класса и внешние интерфейсы. Все. Далее, остальные подсистемы подверглись такому же процессу рефакторинга, ну кроме мордочек.

Из всего этого вывод я делаю такой, что ООП в принципе и не нужен, ФП более чем достаточно. Ну разве, что если ООП будет средством модульности. Т.е. от ООП в классическом понимании останется совсем мало.

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

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

Внутри метода — алгоритмы. Те самые сортировки и поиски, о которых книжки пишут. А снаружи — клей и упаковка.

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

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

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

И получается печальная картина: все мечтают наслаивать классы, слой за слоем, а простую сортировку, если что, и написать-то некому.

IT>Думаю, именно в этом заключается природа предпочтений многих разработчиков. Все хотят быть архитекторами, никто не хочет быть кодером. Ведь кто такой архитектор? Это стратег, командир космической эскадры, бороздящей просторы вселенной. А кто такой кодер? Пещерный человек с каменным топором в руке, пусть даже его пещера и

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

IT>- Я знаю про F# и другие функциональные языки. Моё мнение – у них нет будущего в мэйнстриме даже на платформе .NET по причине необходимости переселения на другую планету.

Обратите внимание, что тот дикий язык, на котором в C++ пишут темплейты, тоже является функциональным языком. Причем чисто функциональным, с ленивыми вычислениями и выводом типов.

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

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

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

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

Чуть-чуть вольных рассуждений:

В истории ООП было много всего интересного и неинтересного, но ИМХО, лучше всех подсуетился на ниве популяризации (читай: продажи) принципов ООП небезызвестный Гради Буч сотоварищи. Его RUP (унифицированный процесс фирмы Rational) настолько плотно поселился в индустрии, что сейчас почитается чуть ли не за нечто само собой разумеющееся. На мой взгляд, это связано прежде всего с тем, что RUP очень удачно оседлал терминологию. По-моему, нет такого слова, относящегося к IT-индустрии, которое не встречалось бы в полной спецификации RUP. "Роли", code review, test case, use case, это вот всё как раз было объединено под крылом RUP. Поскольку Буч параллельно проталкивал именно объектно-ориентированное программирование, то вполне естественно и то, что раньше или позже ООП и RUP должны были превратиться в сиамских близнецов в мозгах пресловутого "среднего менеджера". И таки да, так и произошло. Чуть позже начала активной раскрутки ООП его стали повсеместно называть "методом анализа", а потом уже и "способом организации работ". Больше того, даже итеративную разработку (по принципу: сделали-посмотрели-переделали) намертво связали именно с ООП, хотя в сущности, связи тут никакой, кроме того, что RUP определил "итерацию", как шаг развития проекта.

N>>>Фактически, разделение объектов — то, что позднее назвали "контрактным программированием", с ограничением тем, что "контракт" проводится по границе объекта ("пуля вылетает — проблемы не на моей стороне").
ГВ>>Ты путаешь объектную декомпозицию и спецификацию.

N>Я не путаю, я упрощаю до уровня такого менеджера Спецификация взаимодействия (как при выполнении, так и разработке) является следствием декомпозиции. Это в принципе всё, что ему нужно, чтобы подход работал.

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

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

Блин, я вас читал-читал, а как все банально заканчивается

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

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

А теперь представь — вот люди пишут всякие ESB, передают тонны ХМЛя (ХМЛя, понимаешь? ), а ты их пытаешься убедить, что "существуют задачи, для решения которых использование высокоуровневых средств... неэффективно и нецелесообразно". Как на фиг высокоуровневые средства, у нас сплошной ХМЛ, блин

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

И будет еще меньше. Сейчас у банальной игровой приставки — под которую игры выпускают, кстати, в "обрезанном" по сравнению с PC варианте — прозводительность терафлопами мерится. О чем тут можно говорить-то? Какой асм?

Собственно, такова позиция твоих оппонентов, как я ее понимаю. И я с ней согласен. А вот твою позицию я не очень понимаю. Какой смысл все сводить к тому, что "есть задачи для к-х асм подходит"? Ну да, пока еще есть. Но мне действительно кажется, что ты переоцениваешь роль и количество таких задач. Им недолго осталось жить. Через пять-десят лет китайская кофеварка с многоядерным процессором производительностью в несколько терафлоп будет доставать мне из интернета рецепты кофе. Это реальность

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

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

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

ВВ>Может объяснишь в чем принципиальное отличие?

Чего от чего? HTML от XAML? Такое же, как HTML от SOAP, к примеру. XAML сам по себе никакой семантики не содержит, это просто формат сериализации графа компонентов в терминах специальной компонентной модели. HTML же подразумевает вполне конкретную сематику и абсолютно нерасширяем.

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

ВВ>Где именно?

А ты сам не видишь? Во-первых, практически единственный способ расширения функционала контролов — наследование. Почему плохо наследование реализации здесь уже обсуждалось не раз. Кроме того, использование наследования для расширения функционала это нарушение LSP. Использование же, скажем, агрегации практически невозможно ввиду того самого дизайна и подвязки на виндовый хендл.
Во-вторых, взгляни на публичный контракт Control. Он имеет огромный размер и содержит большое количество грубейших нарушений SRP. В WPF он в разы меньше, хотя и там в этом плане косяков предостаточно.
В-третьих, крайне убогие средства реюза готовых кусков UI. UserControl это все, что на эту тебу имеется. Даже нелюбимые тобой вебформсы в этом плане куда богаче.
В-четвертых, убогий, запутанный и крайне плохо расширяемый механизм баиндинга данных.
В-пятых, крайне примитивная компонентная модель, которую правда, в отличие от, по месту подкрутить все таки можно.
В-шестых, большинство контролов имеют неудобный и примитивный API для взаимодействия с состоянием. Виртуальный режим кое где со скрипом появился, но почти всегда с кривизной.
Ну и куча всего по мелочи.
Итого, дизайн винформсов весьма неоднородный и, в среднем, находится на уровне начала 90-х.

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

PD>Ну-ну. Предложи разработчиками Windows заменить потоки в процессе System на файберы. То-то весело будет
Видишь ли Павел... Напомню тебе, что речь у вас шла об эффективности. И здесь Антон абсолютно прав, конкурентная многозадачность показывает существенно большую эффективность, чем вытесняющая.
В Windows планировщик вытесняющий не потому что он производительнее, а потому, что это безопаснее. При вытесняющей многозадачности у неправильно написанного кода меньше шансов уронить все приложение, вместе с OS, и исключительно по этой причине в OS реализована именно она. То есть, производительность приносится в жертву безопастности, как раз тот расклад, который тебе так не нравится.
В тех же случаях, когда безопасность можно обеспечить каким-либо другим способом, например, когда заранее известно все множество возможных операций и можно гарантировать, что никакая комбинация этих операций не приведет к зависаню всего приложения, включая планировщик, кооперативная многозадачность демонстрирует себя во всей красе. Характерные примеры Антон как раз и привел — lightttpd, SQL Server.
MS SQL Server — вообще, классический пример. Там внутри реализована практически полноценная операционка для управления нагрузкой, собственно, эта часть сиквельного движка так и называется — SQL OS, и одна из основных задач этой OS, обеспечивать non-preemptive schedulind. Опять-таки, ты же любишь ссылаться на операционки? Вот тебе пример OS с кооперативной многозадачностью, как раз из тех соображений, чтобы выжать максимум производительности.

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

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

F>>Правда, надо сделать одно важное извиняющее замечание — если человеку так не повезло, что ему не приходилось решать по настоящему сложных (а, значит, интересных) задач, то тогда, действительно, к чему засорять мозг

AVK>О да, без пенисометрии никак. Знаешь только, в чем проблема, особенно в этом форуме? По результатам измерений запросто может оказаться, что у кого то из твоих оппонентов длиннее.

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

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

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

ВВ>>И что мне от этого понимания? C# крут, потому что теоретически возможно написать супер-компилятор? Теоретически много чего возможно.
S>Совершенно верно. Я и говорю — теоретически можно и Http Handler на ассемблере написать.

Мне теоретический "суперкомплятор" неинтересен.

S>Лучший — это по результатам моего личного опыта. Сравнивали с JSP, ASP, PHP, Python. С наколеночными CGI на C и С++. Тесты проводили самые разнообразные. Кроме того, я немножко представляю себе, как все эти фреймворки устроены внутри. А у вас какие основания клеймить ASP.NET?

Опыт использования.
Вернее, давайте я поправлюсь — тот ASP.NET, который начинается и заканчивается на IHttpHandler/IHttpModule — это отличная штука. А вот все что сверху...

Развитие ASP.NETа — причем заметьте в понятие ASP.NET обычно вкладывается не технология "интеграции конвеера с IIS", а собственно web forms — это постепенное превращение его в чистой воды конструктор. Программирование мышкой. В свое время над Дельфи за этой посмеивались. То же самое в ASP.NET — как вы сказали? — высокотехнлогичность или как там? Неувязочка получается, нет?

Во-первых, сама по себе концепция веб-форм ущербна изначально. Это была попытка сделать программирование под веб похожим на windows forms — причем абсолютно непонятно зачем, учитывая принципиально разную модель работы приложений. Они даже св-ва к контролам типа BackColor и проч. поначалу прикрутили — чтобы на вин-формс было похоже. Тоже вот как бы уровень абстракции. А то, что там CSS-ы есть — это до них только потом дошло. В итоге сохраняем "уши" от ASP, aspCompat, мастерскую вставку, гениальный разбор самой ASPX страницы через регулярные выражения — но зато "где-то там" у нас "комплируемый" код. Ну это ладно.

Но что принпиально новое в нес ASP.NET? Чего добились создатели ASP.NET? Разделения логики и представления? Как бы не так. Ничем в сущности ASP.NET приложение не отличается от того же PHP. И там, и там одинаковая по большому счету свалка — только несколько иначе организованная. И там и там можно писать нормально, если уж очень захочется.

Далее. что у нас еще есть? Богатые библиотеки контролов? Берем ГридВью. Нет проблем! Бросили на форму, пару движений мышкой — все работает. Нужна двунаправленная сортировка, чтобы еще и в заголовка направление сортировки показывать? Без проблем, темплейт-column. Нужно чтобы выглядело по-красивее? Без проблем, еще пару движений мышкой. Ох, надо чтобы совсем-совсем по-красивее? Ой, а надо чтобы весь столбец, по к-му происходит сортировка подсвечивался? Ну что ж придется изменить рендеринг HTML — что ж делаем темплейт колонки (количества кода на странице начинает ох как расти). Хотите чтобы работать даже тривиальные функции ГридВью — не вздумайте отключить вью-стейт, ибо ни фига работать не будет. Ну ладно, вроде прикрутили, сделали. Завтра приходит клиент и говорит — о, а давайте это сделаем в виде вложенного грида, который по плюсику будет распахиваться, а эту и и эту колонку будем мержить когда такая-то информация выводится.
И вот смотрим мы — реально на кучу разметки и кода, которую пришлось — смотрим, и выбрасываем на фиг весь это грид, и переписываем все на XSLT. И — о чудо! — на XSLT кода получается даже меньше, а все наши фичи учтены. И выглядит аккуратнее. И работает быстрее.

И таких примеров можно много привести, и не только с контролами. Чуть-чуть сходишь с "рельс" — и все, приехали. Написав приложение на IHttpHandler/IHttpModule + XSLT, ты:
— получишь чистый код с нормальным разделением данных (XML), правил валидации (XSD) и представления (XSLT)
— получишь более производительный код
— и даже потратишь меньше времени (если приложение не хоум-пейдж)
Какой вывод после этого можно сделать о веб-формах? Но зато да, веб-формы это абстракция.

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

S>Неумение с ним работать? Незнание того, как его конвеер проинтегрирован с IIS7? Или просто незнакомство с предметом?

Я так смотрю хамство — это нынче модный тренд на RSDN.

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

Еще раз повторяю — причем здесь вообще ASP.NET? Каким образом ASP.NET вообще возникает при разговоре об ассемблере?

Я в принципе понимаю, в чем ваша проблема. Не "ваша" конкретно, а вообще. Почему в принципе при разговоре об ассемблере возникает предложение написать на нем аналог ASP.NET приложения? Или мы исходим из принципа — все или ничего?
А правда в том, что есть задачи, в к-х abstraction не дает никаких gain-ов, одни penalty. И такие ситуации также реалистичны как и те, где введение уровня абстракции позволяет сделать приложение более производительным.

S>Математика в наши дни встречается редко; большинство десктопного софта в принципе никогда не сталкивается с ситуацией нехватки производительности.

Я этого никогда не отрицал.

S>Как зачем? Чтобы рассуждения "теоретически, самый быстрый код — это написанный вручную на ассемблере" перестали быть голословными.

Большинство рассуждений здесь голословны. Про суперкомпляторы, которые никто не видел в глаза, про производительность кода на C#.
Напишите с 0 на C#, без всяких managed direct x, 3D-движок, полностью дублирующий CryEngine 2 и при этом работающий по крайней мере с такой же скоростью?

S>Пока что никаких доказательств этому в топике не прозвучало. Главный адвокат ручной сборки Дворкин продолжает удивлять примерами на С++.
S>А до тех порк, пока вы настаиваете на присутствии в рассуждениях "теоретического ассемблерщика", я настаиваю на соревновании его с "теоретическим компилятором".

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

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

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

В стародавние времена программы (и задачи) были одноразовыми. Нужно вам, скажем, посчитать число Пи до тысячного знака. Ок, пишем программу, которая считает число Пи; запускаем, дожидаемся результата — ок, задача решена. Очевидно, что второй раз нам считать число Пи уже не надо. (Если, конечно, мы не забыли вывести куда-то результат вычислений ). Опять же очевидно, что при многократном запуске расчета числа Пи эффективнее всех прочих будет программа, которая устроена примерно так (в терминах C++):

сout << "3.1415926...";

(Производители процессоров об этом в курсе; поэтому инструкция fldpi выполняется значительно быстрее, чем самый оптимизированный расчет суммы несложного ряда)

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

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

Теперь так рассуждать нельзя — затраты в тактах и байтах существенным образом зависят от того, какие именно данные мы подали на вход. На пальцах: пузырек, запущенный на отсортированном массиве длины N выполнит N сравнений, 0 обменов и успокоится. На обратно отсортированных данных он выполнит N^2/2 сравнений и обменов.

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

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

Итак, критерий сравнения эффективности программ — это матожидание затрат памяти и тактов на решение одной из задач, заданных некоторым распределением.

Поговорим об идеальной эффективности.

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

В реальном мире такие оценки очень редко можно получить заранее, до запуска программы.

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

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

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

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

_FR>>Вот что ты скажешь о кодере, которому за девять с лишним лет ни разу не пришлось самому писать сортировку Не то, что строить деревья или создавать примитив синхронизации? Что он должен сгореть от горя или позора?

F>Да, однозначно. Ничто не может служить оправданием халтуры. Конечно, на практике нужно использовать оптимизированные и проверенные библиотечные функции. Но это не значит, что нет необходимости знать основные алгоритмы. Пусть пузырьковая сортировка не оптимальна: она дает навык работы с массивами. А быстрая сортировка — навык работы с рекурсией. Или, по вашему, это лишнее ?

Если человеку ни разу не приходилось писать сортировку, это не значит, что он не сможет это сделать, если понадобится. Измерять профессионализм тем, что человеку приходилось или не приходилось делать — это пустое дело. Единственный объективный индикатор профессионализма — это уровень зарплаты.

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

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

IT>>Я сразу начну писать код прямо в методе Main и только когда почувствую дискомфорт, озабочусь иерархией классов.

MS>Слушай, Игорь, но почему именно "озабочусь иерархией классов"? Что, без наследования в современном мире не прожить? Лично я считаю парадигму наследования самым противоестественным самодурством какого-то одного горе-теоретика, типа авторитета, которому удалось запудрить мозги всем и надолго. Я это уже говорил что инкапсуляция и полиморфизм — 256 раз да! Наследованию — отказать. Парадигма наследования в программировании компьютеров — это пожалуй второй по величине фуфлоид.



IT>>Делать это сразу я не стану, т.к. считаю это бесполезной тратой времени, потому что не знаю, что меня ждёт впереди.

MS>Согласен! Лично для меня первична алгортмическая сущность — на уровне получится или нет и что можно выжать из этого именно на алгортмическом уровне. Это для меня — самая сложная и самая интересная часть задачи. А уж обернуть в классы и иерархии, плюс кодовая оптимизация — это рутина, этим пусть мальчики-архитекторы и мальчики-кодеры занимаются. Я всегда готов их проконсультировать и объяснить сущность алгоритма.

самый большой проект, в котором ты когда-либо участвовал?

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

ВВ>"Волновое" телевидение — это такая кочерга на крыше.

Инженеры, блин, обсуждают технический вопрос.

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

S>Только после того, как мне покажут CryEngine на ассемблере.

Вот, кстати, свеженькая информация в тему:
http://tirania.org/blog/archive/2008/Nov-03.html

The Speed Tests

When we were measuring the performance improvement of the SIMD extensions we wrote our own home-grown tests and they showed some nice improvements. But I wanted to implement a real game workload and compare it to the non-accelerated case.

I picked a C++ implementation and did a straight-forward port to Mono.Simd without optimizing anything to compare Simd vs Simd. The result was surprising, as it was even faster than the C++ version:


Based on the C++ code from F# for Game Development

The source code for the above tests is available here.

I use the C++ version just because it peeked my curiosity. If you use compiler-specific features in C++ to use SIMD instructions you will likely improve the C++ performance (please post the updated version and numbers if you do).

I would love to see whether Johann Deneux from the F# for Game Development Blog could evaluate the performance of Mono.Simd in his scenarios.

If you are curious and want to look at the assembly code generated with or without the SIMD optimizations, you want to call Mono's runtime with the -v -v flags (yes, twice) and use -O=simd and -O=-simd to enable or disable it.

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

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

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

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

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

N>Вы ещё ничего не поняли толком про мою точку зрения, но уже успели приравнять её к "одному знакомому" и унизить сравнением.

Думаю что понял. Она примерно следующая: есть те, кому приходилось иметь дело с сортировкой с выкрутасами, и есть клавишное мясо. Ну или мягче — версия с потолком. По части унижения — я унизил только Вас, а Вы — всех тех, кто не писал свою сортировку.
Если я не понял Вашу точку зрения — поправьте.

N>Не думаю, что такой метод дискутирования адекватен теме.
Не думаете — не начинайте.

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

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

Уметь по памяти и суметь на рабочем месте — две разные задачи.

_FR>>В первую очередь из-за того, что редко, очень редко встречаются сейчас такие задачи.
Pzz>Принесут вам код, написанный для UNIX'а и активно использующий read/write lock'и, и попросят запустить его на Windows XP. А в XP нет read/write lock'ов. Ваши дальнейшие действия?

Сяду читать или пойду пить пиво с юниксойдами, или нет, сначала пойду колоть юниксойдов, а потом сяду читать… нет, сначала почитаю, потом пойду пить пиво с юниксойдами Или попросту скажу, что это "не мой профиль" Зачем "это" (read/write lock) знать заранее? Именно: только в силу специфики решаемых задач. Если человеку каждый день надо писать под UNIX с учётом многопоточности, то он, наверное, должен это знать. Если человеку каждый день приходится писать запросы к базе данных, то он должен представлять себе, как работает её оптимизатор. Для "абстрактного" програмиста, для которого не определена специфика решаемых задач эти вопросы безсмысленны.

В том числе и сортировка, потому что (внимание) абстрактному програмисту не придётся её писать самому. Максимум — придётся научиться выбирать между сортировкой А и сортировкой Б, так этому научиваешься быстро, когда решаешь реальные задачи.

Если говорить конкретно о програмисте XYZ, то тогда можно с него потребовать и X, и Y и Z.

Pzz>>>И получается печальная картина: все мечтают наслаивать классы, слой за слоем, а простую сортировку, если что, и написать-то некому.
_FR>>Вот что ты скажешь о кодере, которому за девять с лишним лет ни разу не пришлось самому писать сортировку Не то, что строить деревья или создавать примитив синхронизации? Что он должен сгореть от горя или позора?
Pzz>Ну скорее я посоветую такому кодеру освоить другую профессию. Потому что произойдет очередная "смена технологий", C# заменят на C#$#%, и такой кодер останется без работы: кому нужен в качестве кодера 50-летний дядька, владеющий только устаревшими методами?

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

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

<все skipped>

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

1. Существуют задачи, для решения которых использование низкоуровневых средств, таких как C/C++ или ассемблер, неэффективно и нецелесообразно, а применение высокоуровневых средств, таких как C# (включая LinQ), языки ФП и т.д. — оправданно и наиболее эффективно.
2. Существуют задачи, для решения которых использование высокоуровневых средств, таких как C# (включая LinQ), языки ФП и т.д., неэффективно и нецелесообразно, а применение низкоуровневых средств, таких как C/C++ или ассемблер — оправданно и наиболее эффективно.

Слова "неэффективно и нецелесообразно" и "оправданно и наиболее эффективно" понимаются в некотором общем смысле, без конкретной расшифровки. Просто — стоит такое использовать или же нет в реальной жизни.

Я, Дворкин П.Л., настоящим подписываюсь под этой декларацией и призываю моих оппонентов подписаться под ней.

Подпись под этой декларацией можно осуществить двумя способами. Либо поставьте мне на это сообщение плюс, либо ответьте на это сообщение своим со словом "согласен".

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

Персонально приглашаю AndrewVK и Sinclair подписаться под этой декларацией

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

IT>Этот топик как раз о том, что не у всех и я долго не мог понять почему

Наверное потому-что пару десятков лет "бошку" пытались снести на объектно-ориентированный лад. Хотя классики предупреждали:

"Object-oriented programming is an exceptionally bad idea" (Edsger Dijkstra)

"I find OOP technically unsound" (Alex Stepanov, здесь)

IMHO ФП и ООП несовместимы.

---

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

"В каждой естественной науке заключено столько истины, сколько в ней математики" (Иммануил Кант)

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

Pzz>А много вы знаете граждан, способных написать самостоятельно RB-дерево?

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

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

FR>Угу совместимы тот же Ocaml да и величайший из языков на букву N это демонстрируют. Но совместимы только на том уровне который ты сейчас рекламируешь, а вот если идти выше то уже нет, притом скорее и не отрицают и не дополняют друг — друга а просто совершено различны.

Уровень выше это для тех кто всосал FP с молоком матери, а особо продвинутым оно передалось вообще по трубочке ещё в чреве. Я к ним, к счастью, не отношусь.

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

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

#pragma flame on

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

#pragma flame off

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

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

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

IT>>Это всё будет работать очень и очень медленно. Это просто в принципе не может работать быстро.

LCR>верно

Вот!

LCR>Так что с "в принципе" не согласен.

Ты не понимаешь. Быстро может работать только написанное на ассемблере или его высокоуровневых аналогах вроде C. У тебя же только GC будет отрабатывать столько, сколько нормально написанная программа на ассемблере будет работать всего.

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

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

В итоге, если потратить достаточное время и усилия, то скорее всего получится та самая управляемая среда, jit, hot-spotting, query plan evaluation, и прочие техники, с успехом применяющиеся там, где некоторые упертые программисты до сих пор думают, что ассемблер лучше.

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

Pzz>Я имел ввиду, что поскольку знания, в которые вы вкладываетесь, в основном состоят из перечня интерфейсов той технологии, которую вы сейчас считаете современной, то они по природе своей полностью устаревают за несколько лет, и вам приходится переучиваться. В 50 лет это будет сделать значительно сложнее. В том числе и по организационным причинам: никто не возьмет 50-летнего дядьку "на вырост", лучше возьмут студента.
Очень сильное утверждение. А какие знания вы считаете несводимыми к перечню интерфейсов технологии?
Я вот регулярно спорю в этих же форумах со "старой гвардией", которая делает аналогичные высказывания. А потом выясняется, что для этой гвардии интерфейс строки — это ровно ASCIIZ. И человек, гордящийся умением написать по памяти поиск бойер-мура, совершенно не в состоянии написать эффективный алгоритм конкатенации строк, потому что в его ментальной модели не у всех строк есть длина. Я понятно объясняю?
Или, к примеру, совершенно невозможно объяснить такому человеку, что сравнение двух строк не сводится к сравнению байт, потому что есть суррогаты, есть нормализация, есть case sensitivity, есть accent sensitivity, и что пунктуация должна сравниваться с другим приоритетом, чем alphanumeric.
Тем не менее, такой человек считает себя безмерно круче окружающих и позволяет себе смеяться над людьми, которые выучили только интерфейс к string.Compare().
Тем не менее, с точки зрения, скажем, менеджера, эти наивные молодые люди куда полезнее старой гвардии: они, по крайней мере, могут правильно сравнить строки, когда нужно.

Павел Лазаревич,

PD>Лет так 30 назад была такая система программирования Альфа, сделана была в Новосибирске Ершовым, поттосиным и др. На базе языка Алгол, но с расширениями. Так вот, там сложение матриц делалось еще проще
PD>real array a[1:n][1:m],b[1:n][1:m], c[1:n][1:m];
PD>// инициализация
PD>c := a + b;
PD>Проще некуда.

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

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

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

Несложный анализ показывает, что вышеназванная Альфа никак укладывается в требования выше. Чтобы попытаться накрыть ладонью всё множество алгоритмов, выделения кусочка кода и возможность обозвать его "+" явно недостаточно. Нужна модульность, много модульности, больше чем сейчас. Поясню на примере.

Допустим, вы реализовали умножение матриц, причём учли и кэши, и многопроцессорность, и учли специфику Intel/AMD и ещё много чего. То есть, ваш алгоритм стал очень очень быстрым, так что на любой машине это оказалась самая эффективная реализация.

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

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

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

И, наконец, Алиса, взяв ваш алгоритм в качестве процедуры, вдруг осознала, что он и является главным пожирателем процессорного времени, но специфика задачи позволяет вычислять всё произведение не сразу, а по немножку. И её осенило, что если в вашем алгоритме использовать ленивые for-ы, то всё становится замечательно.

Единственный разумный путь сделать счастливыми всех четырёх человек, как мне видится, это декларативно описать алгоритм и возложить знание об архитектуре и окружение на компилятор (так что компилятор и будет модулем optimize, можно считать что каждая функция описана как f = optimize f_). Такое декларативное описание присутствует в коде на Хаскеле, и в подавляющем большинстве случаев отсутствует в коде на C++, так что бедные Вася, Таня, Алиса и ваш покорный ученик должны заново изобретать свои многоугольные колёса.

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

K>Тут надо не книжки читать. Тут надо прежде всего инструмент соответствующий. А то на while/if реализация даже простых алгритмов превращается в кошмар. А чтение того, что получилось — ещё ужаснее.

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

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

AF>Мне очень интересно послушать, какие в ней есть реальные проблемы.

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

AF>Угм. "Сниму шапку, пусть назло бабушке уши отмерзнут нахрен". Всё таки странно слышать такую аргументацию от взрослого человека.

Это не аргументация. Это констатация факта. Если непонятно — могу проиллюстрировать: когда зовут обедать криком "жрать, суки", у меня почему то аппетит пропадает.
Ну и насчет взрослого человека — давай все таки обходится без хамства.

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

IT>Я сразу начну писать код прямо в методе Main и только когда почувствую дискомфорт, озабочусь иерархией классов.

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

IT>Делать это сразу я не стану, т.к. считаю это бесполезной тратой времени, потому что не знаю, что меня ждёт впереди.

Согласен! Лично для меня первична алгортмическая сущность — на уровне получится или нет и что можно выжать из этого именно на алгортмическом уровне. Это для меня — самая сложная и самая интересная часть задачи. А уж обернуть в классы и иерархии, плюс кодовая оптимизация — это рутина, этим пусть мальчики-архитекторы и мальчики-кодеры занимаются. Я всегда готов их проконсультировать и объяснить сущность алгоритма.

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

N>Единственный объективный индикатор профессионализма — это уровень зарплаты.

Тогда те кто работают в США большие профессионалы чем те кто работает Москве. А те кто работает в Малых Васюках вообще ламеры.

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


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

По моему тут только ты единственный его неправильно понял.

PD>А в смысле работы программиста — вот тебе самое эффективное решение из незабвенного "Hello, World"

Это уже работа непрограммиста

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

PD>В этом смысле — мб, и да, если знать Хаскель, конечно. Но меня вообще-то больше интересует эффективность его выполнения

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

vasja lst = map f lst

Петя взял васин код, и поэлементно применил к возвращаемому этим кодом списку функцию g

petja lst = map g (vasja lst)

Оля взяла петин код, поэлементно применила к возвращаемому этим кодом списку функцию h

olja lst = map h (petja lst)

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

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

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

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

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

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

Pzz>И не забывайте еще одно. Вот выйдет новый процессор Интел, а мелкософт скажет, что ему не интересно. И не будет его специальным образом поддерживать. Дворкин-то выматерится и руками все соптимизирует. А вы куда пойдете?

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

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

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

Ну, тут многие так спорят:

А> ... и буду нем как рыба ...

В> А, рыба? Это та самая, у которой нет шерсти? А, следовательно, блох тоже нет? Так вот, ты нифига не понимаешь в блохах, ведь блохи ...

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

ВВ>>Да я уже, понял. Я сам с собой разговариваю. Зачем мне вообще отвечать? У меня и так прекрасно получается.
S>Совершенно верно. Ну где хоть один аргумент от твоих противников в защиту WebForms?

Лень ветку почитать?

ВВ>>

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

ВВ>>>>ASP.NET — говно.

ВВ>>Это все от ламерства и полного бескультурия! Как ASP.NET может быть говном — ведь он же включает в себя все достоинства .NET, а следовательно и WPF. WPF — это самая мощная технология построения интранет-приложений, которая существует на настоящий момент. И которая как раз и предлагает мощный метаязык для описания представления — XAML. Какой человек в здравом уме скажет после этого, что ASP.NET — говно?
ВВ>>АSP.NET просто невменяемо рулит!

S>Этот понос — он к чему?

Этот "понос" писался не для тебя. Раз уж ты так бестактно влез в мою дискуссию с самим собой, объясни мне в таком случае, где у нас вообще "кончается" ASP.NET? Ты же в достоинства ASP.NET приписываешь все возможности .NET? Даже Рихтеровский power threading тут всуе помянул. Так, извините, почему бы и WPF сюда не засунуть? WPF — часть .NET, позволяет разрабатывать приложения доступные через веб, ну значит часть ASP.NET, очевидно.
Этот "понос" — ваша манера вести дискуссию. Что, пахнет?

ВВ>>А то, может, WindowsForms тоже говно, а я и не заметил.
S>Вообще-то да, говно. У неё тоже модель GUI совершенно не соответствующая современным реалиям. Поэтому нормальный десктопный интерфейс на ней делать весьма и весьма тяжко. Что, собственно, и привело к изобретению WPF. Но это никакого отношения к веб не имеет.

У WindowForms модель полностью отвечает архитектуре Win32 и является прекрасной надстройкой над user32. То, что сама по себе эта модель уже устарела, разумеется, очевидно. Но WPF (в отличие от того разрекламированного тут ASP.NET MVC) представляет собой не другую абстракцию, а принципиально другую технологию.
Если стоит задача разработки именно под Win32, то WindowsForms — пожалуй, одно из лучших решений. Особенно в свете детских болячек WPF.

ВВ>>У месье богатый опыт работы консьержем? Предлагаю на досуге помедитировать над значением аббревиатуры ASP.
S>Аббревиатура совершенно ни при чем. Это становится очевидно, если сравнить архитектуру ASP.NET и ASP, у которых вроде бы она одна и та же.

Само название ASP.NET говорит о то, что это реализация active server pages на .NET. Реализация, active server pages на .NET — это ASPX, класс Page, реализующий IHttpHandler и все, что тянется за ним. И все, что на настоящий момент предлагается в качестве реализации — это WebForms.

ВВ>>кому вообще нужен ассемблер, если на нем нельзя написать эффективное веб-приложение?! Да еще за разумные сроки!
S>Этот понос — он к чему? К тому, что есть какие-то узкоспециальные приложения, где ассемблер всё еще может справиться?
S>Много ли кому интересны эти ниши, кроме ассемблерщиков, неспособных освоить ничего нового?

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

S>Я говорю о сложностях реализации настоящих высоконагруженных систем, где важна производительность. И о том, что она на ассемблере недостижима, что в точности противоположно точке зрения апологетов ассемблера.
S>Вон непдалеку кто-то мне грозил разрывом шаблонов в случае написания высоконагруженного сервера. Павел Дворкин искренне полагает, что microsof.com не может работать на ASP.NET. Твоя точка зрения мне вообще остается непонятной.

ВВ>>Можно было и без "очень простого примера" это сказать. С этим даже Дворкин согласится.
S>Это вряд ли. У него та часть личности, которая отвечает за "ой, извините, это я протупил" отключена за неуплату.

А у меня вот аналогичное впечатление от вашей партии.

ВВ>>И поэтому мы говорим об ASP.NET приложении на ассемблере? Железная логика
ВВ>>Кстати, было бы очень интересно обсудить пример веб-приложения, в котором правильно применяются хорошие фреймворки, разработанного MS.
S>Примером хорошего приложения является сайт microsoft.com и значительная часть msdn.microsoft.com.

Ты знаком с архитектурой этих приложений? Не мог бы рассказать, какие именно хорошие фреймворки там использует и как же именно они правильно применяются.

ВВ>>Предлагаешь производителям ждать XBox370 вместо того, чтобы делать игры? Чур-чур!
S>Предлагаю не делать вид, что инвестиции в ручную оптимизацию под конкретную железку гарантированно не будут выброшены на ветер.

Т.е. компании, вкладывающие десятки миллионов в разработку игр под XBox360, "гарантированно" выбрасывают деньги на ветер?

Pavel Dvorkin,

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

В сортировках, графических фильтрах и сложных файлах на дисках увы дас вайст их нихт.

А вот про матричную алгебру — это пожалуйста:
Скалярное умножение вектора-строки на вектор-столбец:

bra_ket u v =
      sum_product u (map coupled v)

Сложение матриц:

add_matrices :: (Num a) => t -> t1 -> [[a]] -> [[a]] -> [[a]]
add_matrices _ _ = matrix_zipWith (+) where
       matrix_zipWith f a b = [zipWith f ak bk | (ak,bk) <- zip a b]

Транспонирование:

transposed a
    | null (head a) = []
    | otherwise = ([head mi| mi <- a])
                  :transposed ([tail mi| mi <- a])

Умножение матрички на скаляр:

scalar_matrix alpha a =
       [[alpha*aij| aij <- ai] | ai<-a]

Умножение матрички на матричку:

matrix_matrix a b
       | null a = []
       | otherwise = ([sum_product (head a) bi | bi <- b])
                  : matrix_matrix (tail a) b

Умножение матрички на вектор-столбец справа

matrix_ket a v = [sum_product ai v| ai <- a]

Умножение матрички на вектор-строку слева

bra_matrix v a = [bra_ket v ai | ai <- a]

Умножение вектор-строка * матричка * вектор-столбец

bra_matrix_ket u a v = bra_ket u (matrix_ket a v)

Ортогонализация Грамма-Шмидта

orthogonals :: (Scalar a, Fractional a) => [a] -> [[a]]
orthogonals x =
      orth [x] size (next (-1))
      where
          orth a n m
              | n == 1        = drop 1 (reverse a)
              | otherwise     = orth ((gram_schmidt a u ):a) (n-1) (next m)
              where
                  u = unit_vector m size
          size = length x
          next i = if (i+1) == k then (i+2) else (i+1)
          k = length (takeWhile (== 0) x)

gram_schmidt :: (Scalar a, Fractional a) => [[a]] -> [a] -> [a]
gram_schmidt a u =
      gram_schmidt' a u u
      where
          gram_schmidt' [] _ w = w
          gram_schmidt' (b:bs) v w
              | all (== 0) b = gram_schmidt' bs v w
              | otherwise    = gram_schmidt' bs v w'
              where
                  w' = vectorCombination w (-(bra_ket b v)/(bra_ket b b)) b
          vectorCombination x c y
              | null x = []
              | null y = []
              | otherwise = (head x + c * (head y))
                            : (vectorCombination (tail x) c (tail y))

Ну и решение СЛАУ методом выделения треугольной матрицы:

one_ket_triangle a b
    | null a = []
    | otherwise = (p,q):(one_ket_triangle a' b')
    where
        p    = [bra_ket u ak | ak <- a]
        q    = bra_ket u b
        a'   = [[bra_ket ck ai | ck <- orth] | ai <- v]
        b'   = [ bra_ket ck b  | ck <- orth]
        orth = orthogonals u
        u    = head a
        v    = tail a
        
one_ket_solution :: (Fractional a, Scalar a) => [[a]] -> [a] -> [a]
one_ket_solution a b =
    solve' (unzip (reverse (one_ket_triangle a b))) []
    where
        solve' (d, c) xs
            | null d  = xs
            | otherwise = solve' ((tail d), (tail c)) (x:xs)
            where
                x = (head c - (sum_product (tail u) xs))/(head u)
                u = head d

Представьте себе, и это всё, да. В последний раз, когда я видел решение СЛАУ (моё) оно было минимум 5 экранов — и for-ы, for-ы, много for-ов... Выбор несколько других примитивов позволяет, даже в такой "цыкло-насыщенной" задаче, избежать явного применения оператора цикла. Казалось бы, согласно маэстро Дейкстре, основополагающего примитива.

PD>Слишком уж разные у нас с вами задачи, господа...

Из ваших сообщениях в тематических форумах подозреваю что нет. Просто у меня другое отношение к заточке инструмента

Andrei F.,

AVK>>UI то, конечно, делать можно. Проблема в дизайн-тайме, причем не только этого самого UI. Сколько я ни спрашивал, никто не смог мне продемонстрировать чисто функциональную компонентную модель. Что, впрочем, не мешает при этом какими то элементами ФП пользоваться.

AF>Любой интерфейс должен иметь состояние — просто потому, что пользователь так устроен Так что делать его в идеологии ФП — все равно что бегать в ластах.

Нет.

Состояние может существовать просто согласно постановке задачи (например, stateful протокол). Для того, чтобы состояние не рассыпалось, конечно достаточно линеаризации мутаторов и аксессоров, и так делают все императивные языки. Однако, это не необходимое условие. Для корректного сохранения состояния достаточно соблюдать относительный порядок вызовов мутаторов и аксессоров.

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

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

    appWindow :: CompCircuit Window () (() :& QuitReq)
    appWindow = proc () -> do
        () :& Destruction := destruction
            <- unit (ordinaryWindow windowContent) -< () :& Title := constant "Accumulation demo"
        returnA -< () :& QuitReq := destruction

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

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

_FR>>Вот что ты скажешь о кодере, которому за девять с лишним лет ни разу не пришлось самому писать сортировку Не то, что строить деревья или создавать примитив синхронизации? Что он должен сгореть от горя или позора?

F>Да, однозначно. Ничто не может служить оправданием халтуры. Конечно, на практике нужно использовать оптимизированные и проверенные библиотечные функции. Но это не значит, что нет необходимости знать основные алгоритмы. Пусть пузырьковая сортировка не оптимальна: она дает навык работы с массивами. А быстрая сортировка — навык работы с рекурсией. Или, по вашему, это лишнее ?

Т.е. так как я сейчас не могу написать быструю сортировку по памяти — я не умею работать с рекурсией?

Вам не кажется, что вполне возможно оттачивать навыки и на других задачах?

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

E>PS. В начале 90-х в Союзе у многих крышу срывало Прологом. С тех пор я думал, что именно Пролог самая крутая трава. Но, видимо, FP еще круче.

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

Здравствуйте, Воронков Василий, Вы писали:
ВВ>И что мне с ней делать? Молиться на нее?
Ну, например понять, что применение той же техники для C# принципиальных проблем не имеет.

S>>В таком случае, нужно отказаться от муссирования рассуждений типа "теоретически программист может вручную на ассемблере заоптимизировать всё насмерть"
ВВ>Ну правильно, ведь на ассемблере никто ничего не пишет, им пугают детей на ночь, а мы тут уже вовсю дотнет-приложения "суперкомпляторами" компилируем.
Этот понос — он к чему?

ВВ>Да, ослиный ASP.NET — это гениальный пример для сравнения. Ничего лучше чем дебильный конструктор сайтов и подобрать нельзя.
А что в нём ослиного? Это не дебильный конструктор сайтов, а лучший в мире фреймворк для построения высокопроизводительных веб-приложений. Это так, к слову о.

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

ВВ>А может, это — давайте тогда все на свете на АСП-НЕТ писать? Ведь АСП-НЕТ рвет на части асм по своей эффективности. Чет мужики еще не доперли что надо все на АСП-НЕТ переводить.
Еще раз медленно повторяю: пусть твои мужики воспроизведут на асме хотя бы один пример из самплов к Рихтеровской Power Threading Library. И посмотрим, кто кого порвёт по эффективности.
ВВ>Abstraction gain — он в голове. И это хорошо, что он в голове, а не в другом месте. И не надо его из головы куда-то перекладывать.
Еще раз, медленно, поясняю: abstraction gain — вполне конкретная штука, и она существует. В частности специализация абстрактного кода под аппаратную платформу в момент исполнения, она же JIT. В частности, специализация абстрактного кода под реальные данные в момент сборки, она же суперкомпиляция.

Поменьше эмоций, побольше мыслей.

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

AVK>Скептическое отношение у меня как раз таки к МП, а точнее к его реализации в Немерле.

+1, реализация кошмарная, особенно после семейства скобочных в этом плане скобочные превзойти по-моему невозможно в принципе.

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

IT>>Этот топик как раз о том, что не у всех и я долго не мог понять почему
I>Наверное потому-что пару десятков лет "бошку" пытались снести на объектно-ориентированный лад. Хотя классики предупреждали:

За цитаты — респект

А вот как из процетированно следует, что
I>IMHO ФП и ООП несовместимы.

неясно Или это только IMHO?

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

_FR>Вот что ты скажешь о кодере, которому за девять с лишним лет ни разу не пришлось самому писать сортировку Не то, что строить деревья или создавать примитив синхронизации? Что он должен сгореть от горя или позора?

Да, однозначно. Ничто не может служить оправданием халтуры. Конечно, на практике нужно использовать оптимизированные и проверенные библиотечные функции. Но это не значит, что нет необходимости знать основные алгоритмы. Пусть пузырьковая сортировка не оптимальна: она дает навык работы с массивами. А быстрая сортировка — навык работы с рекурсией. Или, по вашему, это лишнее ?

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

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

Приходится задумываться, очень даже. Вот возьмём ту же пресловутую сортировку. Кто из кодеров вообще слышал о каком-то методе кроме "quick sort" (и то — под его маркетинговым названием)? А условия применимости? Вот завтра придут данные с определённым на них частичным порядком вместо линейного, и опаньки — условия применимости не выполняются. А если сравнения очень дорогие и их надо минимизировать? А если данных никогда не больше 8 элементов и quicksort просто дорог в раскачке, простейший метод вставок сработает быстрее? А если надо выполнить сортировку параллельно? А если дали 100 миллиардов элементов и они даже в виртуальную память не влезут (я уж молчу, что сортировать данные толще физической памяти такой сортировкой — самоубийство независимо от того, влезло оно в виртуалку или нет)? Всё, такой кодер сдулся, независимо от того, насколько он хорошо знает STL и может задавать сортировку его средствами.

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

Pzz>>Граждан, способных нагородить иерархую классов, из которой, если ее нарисовать на бумажке разноцветными карандашами, можно обои сделать — пруд пруди. А много вы знаете граждан, способных написать самостоятельно RB-дерево? Или сделать недостающий в системе примитив синхронизации из того, что в системе есть? Много ли вы вообще знаете граждан, которые знают, что в системе может недоставать каких-то примитивов синхронизации? :-)
_FR>В первую очередь из-за того, что редко, очень редко встречаются сейчас такие задачи.

Угу, именно так. Фактически, можно тупо рубить бабло на минимальном базисе. Впрочем, для этого нужно соответствующее усердие, которое тоже нечастый скилл.;(

Pzz>>И получается печальная картина: все мечтают наслаивать классы, слой за слоем, а простую сортировку, если что, и написать-то некому.
_FR>Вот что ты скажешь о кодере, которому за девять с лишним лет ни разу не пришлось самому писать сортировку :???: Не то, что строить деревья или создавать примитив синхронизации? Что он должен сгореть от горя или позора?

Какой ответ на этот вопрос Вы хотите? Можно ответить цинически — мол, есть клавишное мясо:), которое не способно даже осознать, что оно теряет и почему. А можно — что пусть себе и дальше продолжает, но пусть осознаёт, где его потолок. В принципе, оба ответа правильны.

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

N>А описанные Вами знания "есть такое, а есть сякое" без подкрепления забудутся после первого экзамена.
N>Поэтому я с сомнением отношусь к тем архитекторам, которые давно сами не кодируют, и к тем кодерам, которые способны только применить указанное им решение.

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

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

Например, вспоминаю анекдот про то, как старого програмиста спросили, как записать некие данные на диск, а он начал ответ со слов о том, что "перво-наперво нужно спозиционировать головку устройства". И life is good что подобного не требуется знать сейчас.


_FR>>Гхм… попробую так: в каком проценте задач сортировки данных вам не достаточно библиотечных реализаций? Мне кажется, эта цифра вполне подойдёт под описание "очень редкно".
N>У меня лично статистики недостаточно. Но вот случай, когда обычная сортировка крайне невыгодна — каждый рабочий день на глазах, это таймерное дерево в движке событий. Оно сделано на пирамиде.

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

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

Pzz>Да помилте, какой еще нужен струмент для написаныя простых алгоритмов, кроме как раз тех самых if'ов и while'ов? Откройте любую книжку про алгоритмы, обратите внимание, на каком языке в этих книжках алгоритны расписывают.

См. квиксорт на Хаскеле и на С. Классический пример. Или там использование паттерн матчинга для красно-черных деревьев.
Оно реально выглядит красивше и понятнее.

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

AVK>Скептическое отношение у меня как раз таки к МП, а точнее к его реализации в Немерле.

Мне очень интересно послушать, какие в ней есть реальные проблемы.

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

Угм. "Сниму шапку, пусть назло бабушке уши отмерзнут нахрен". Всё таки странно слышать такую аргументацию от взрослого человека.

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

AVK>ФП не отрицает состояния

In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data

AVK>А устроенность мира заменяется в ФП копированием. Это ж, блин, азы.

Я, блин, в курсе, как работает ФП.
"Все вокруг тупицы, один я д'Артаньян" — это ты молодец. Не надо обвинять фанатичных немерлистов, источник флейма явно в тебе.

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

IT>Уровень выше это для тех кто всосал FP с молоком матери, а особо продвинутым оно передалось вообще по трубочке ещё в чреве. Я к ним, к счастью, не отношусь.

Достаточно чтобы ООП не был впитан с молоком матери или еще раньше
Я как раз и отношусь к таким (большое влияние форта на неокрепший еще мозг ).

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

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

DM>>Например, у меня есть несколько алгоритмов компенсации движения, отличающиеся лишь способом поиска похожего блока. Наследование позволило обойтись без дублирования кода, лишних if'ов и указателей на функции (которые, по сути, изоморфны VMT).

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

А на практике окажется, что из ~100 методов отличаются у потомков 20, и этого достаточно, чтобы действие "передать функцию поиска похожего блока" вылилось в извращение типа "передать структуру функций, специфичных именно для этой реализации". И всё это с костылями вроде приведения типов.

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

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

MS>Слушай, Игорь, но почему именно "озабочусь иерархией классов"? Что, без наследования в современном мире не прожить? Лично я считаю парадигму наследования самым противоестественным самодурством какого-то одного горе-теоретика, типа авторитета, которому удалось запудрить мозги всем и надолго.

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

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

N>... "quick sort" ...

Во, IT, ты удивляешься почему не у всех FP крышу сносит? У людей крыша занята. Одни ее занимают мыслями о том как писать quick sort-ты и где их лучше применять. Другие о том как бы не пропустить новые революции от Майкрософ. Третие еще чем-мто...

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

ГВ>>Цирк. Для тех кто в это верит, поясню: привлекать неквалифицированных пользователей к формализации задачи — хорошо, привлекать неквалифицированных программистов (именно их ты имеешь в виду, говоря об индусах, правда?) — очень плохо.

Pzz>Их привлекают не к формализации, а к реализации. Хорошо ли это, плохо ли, но вот привлекают. Наверное потому, что свободных квалифицированных уже почти не осталось.

Это и есть — плохо.

ГВ>>Вообще-то ООП зародилось из фреймов-слотов, это такой ма-а-а-алепусенький кусочек инструментария ИИ по формализации знаний. Менеджеры софтостроения там если и стояли рядом, то только стояли.
Pzz>Вообще-то ООП зародилось из Симулы, языка. предназначенного для компутерного моделирования.

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

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

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

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

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

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

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

Pzz>>>А вот внутри самих алгоритмов if'ы и while'ы — вполне себе адекватный инструмент.
ГВ>>Это не просто "адекватный инструмент", if — это блин, базисная конструкция императивного стиля.
Pzz>Я как-то не уловил, почему базисная конструкция императивного стиля не может быть адекватным инструментом? Какое слово является ругательным, "базисная" или "императивного"?

"адекватный инструмент" Абсурдна сама формулировка. Ну, что-то вроде: "капли — адекватный инструмент дождика". Вот такое же.

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

IT>За 30 лет развития традиционных языков программирования (Fortran, PL/1, COBOL, Pascal, C/C++, Java, C#) принципиально изменился только мир вокруг метода. Мы получили наследование, инкапсуляцию и полиморфизм, компонентность и контрактность, шаблоны/дженерики и атрибуты, массу паттернов проектирования, подходов и отходов, методологий и прочих вещей, призванных организовать код в нечто более менее управляемое.

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

А вот роль организации кода резко повысилась по сравнению с фортрановскими временами, да. Но это не столько с новыми приемами связано, сколько с характером задач. В значительной степени нынешний код — код без алгоритма . Это не реализация какого-то алгоритма, заложенного в задачу, а набор обработчиков разных событий. Программу для обработки битовых карт не превратишь в программу для обработки текста, алгоритмы тут совсем разные. А программа типа — ввести данные с формы — записать в БД практически индифферентна к тому, что вводить с формы и что писать в БД. Отсюда и все эти паттерны, фреймворки, библиотеки и т.д.

IT>Что же изменилось внутри метода? Да почти ничего. Как и 30 лет назад мы имеем if/else/switch, несколько циклов, команды выхода из цикла и метода, операции, присваивание и ещё немного по мелочёвке.

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

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

VD>>Вот если бы я был АВК, то сказал бы "опять С++

AVK>Фи, как грубо и неумело. Не переноси свои фобии на других.

Какие фобии? Как только где-то появляется слово Nemerle, так то час мы видим тебя с громкими воплями "опять этот Nemerle...". Право, реакция совершенно не адекватная. Если в Nemerle ничего нет, то что так на него реагировать то? (вопрос риторический)

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

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

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

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

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

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

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

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

S>Сосал почтовый сервер, весь из себя написанный на плюсах и работавший поверх файлухи. (а то! ведь СУБД — это тормоза, они не дают прямого управления IO).
S>После переписывания на Java, поверх MS SQL, на той же машинке почтовый сервер стал выгребать не 200000 писем в сутки, а 1000000.
S>Второй боттлнек устранить не удалось: это был Interbase, тоже ясное дело, не на сишарпе писанный. Увы, он никак не хотел жрать больше 1 СPU на четырехпроцессорной машине, и кластеризовываться тоже не умел.

Не собираюсь оспаривать твои высказывания, но объясни мне, пожалуйста, почему тогда абсолютное большинство десктопного софта, написанного на яве работает в разы медленее, чем его аналоги на C/C++? Почему mcirosoft-овский MSDN работает быстро, а IBM-овская справка (на Java) — из рук вон медленно? Почему та же история повторяется с парочкой OpenOffice/MS Office? UML-рисовалки, это вообще мрак. Если сравнивать Eclipse и MSVC 6.0 — это попросту не смешно. Если ява с такой уверенностью "рвёт" плюсовый код?

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

S>Сосал почтовый сервер, весь из себя написанный на плюсах и работавший поверх файлухи. (а то! ведь СУБД — это тормоза, они не дают прямого управления IO).
Вот что значат тормозные FS в Винде...

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

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

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

LCR>А вот про матричную алгебру — это пожалуйста:

Вот из-за таких примеров народ и бегает от ФП, как черт от ладана. Классика, блин — специфичные математические задачи, однобуквенные переменные.

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

AVK>>Нет.

PD>Ну что же, все ясно.

Смешно. Потрясающий ты человек, Павел Дворкин.

PD> Ответ свой я дал в ответе IT.

Нет, там ты тоже его не дал. Итого — доказать, что ты в императивном стиле напишешь не хуже функционального ты не смог. Вот и весь итог.

PD>Еще раз (на этот раз тебе) объясняю — требовать от меня чего-либо ни ты, ни он не можешь.

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

AVK>>Я хочу не кашу из звездочек и стрелочек, а вменяемое описание алгоритма.

PD>Ну насчет каши — не нравится язык — дело твое. Я другой язык использовать не буду.

Кто бы сомневался.

PD> А описание — мне казалось , что я его дал.

Вот именно что казалось.

>>поэтому я просто распараллелил вычисление сумм красных компонент по столбцам окна.

Компонент чего, rакого окна? О чем вообще речь? Сравни свое "описание" с описанием IT. Ну хотя бы по объему. А с таким описанием я тебе могу дать точно такой же ответ:

return things.AsParallel().Select(thing => thing.RedComponent).Sum();

Из комментариев еще можно понять, что у тебя там вроде бы есть еще и непараллельный алгоритм, но AsParallel реально параллелит только если есть несколько ядер. Впрочем, явно указать тоже не проблема:

return (isParallel ? things.AsParallel() : things).Select(thing => thing.RedComponent).Sum();

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

PD>Дано окно Windows с неким рисунком в нем. Пройти по всем пиксельным столбцам клиентской области этого окна и найти для каждого столбца сумму R (красных) компонент пикселей , записать результаты в массив columnSum. Две реализации — в лоб без распараллеливания, и с распараллеливанием
PD>Реализация с распараллеливанием — создаются N потоков, где N — число процессоров (возвращает GetSystemInfo). Если процессоров 2, то один поток займется левой половиной окна, а другой правой. Если 3 — левой, средней и правой соответственно. И т.д.

Если это все, тогда в первый вариант вместо things подставляем:

window.Rows.SelectMany(row => row.Values)

Или, если тебе хочется исключительно индексы, то:

Enumerable.Range(0, Width).SelectMany(x => Enumerable.Range(0, Height).Select(y => pixels[x, y]))

Или, используя query comprehension

from x in Enumerable.Range(0, Width)
from y in Enumerable.Range(0, Height)
select pixels[x, y]

Ну и все вместе:

return
    (
        from x in Enumerable.Range(0, Width)
        from y in Enumerable.Range(0, Height)
        select pixels[x, y].Red
    )
    .AsParallel()
    .Sum();

А теперь я поработаю чуток предсказателем — ты все равно не напишешь пример IT в императивной форме.

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

AF>Избавленный от побочных эффектов GUI — это феноменально. Изобретатель обезжиренного сала удавился от зависти. Все корифеи ФП рыдают от тоски, что не додумались до такой простой и гениальной идеи.

GUI даже в чистых ФП языках есть уже ндцать лет. По делу есть что сказать?

AVK>>Рылом не вышел?

AF>Нет, не рылом. Но хотя бы немного думать, прежде чем писать — это очень желательно.

Аналогично. Если ты чего то не понял, это не означает, что оппонент дурак.

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

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

Итак, вернемся к нашим "высокоуровневым конструкциям".
Пока что мы получили интуитивное представление о том, что неплохо бы выбирать решение в зависимости от свойств поступающих задач. Ассемблер достаточно гибок для того, чтобы помочь нам в простых случаях. Под простыми случаями я имею в виду такие, когда количество вариантов решения невелико. Ну вот сколько у нас алгоритмов сортировки для массива? В таком случае, расходы памяти на одновременное хранение всех этих программ не выходят за пределы разумного, а выбор сводится к традиционному conditional statement.

К сожалению, у этого подхода имеются свои ограничения.
Если "размеры" семейства программ-решений выходят за разумные пределы, то их суммарный объем становится препятствием для статической реализации. Это не такая уж редкая ситуация: как правило, некоторая задача делится на более мелкие подзадачи. Если у подзадач A1 и A2 — по четыре решения, то у задачи A, которая является суперпозицией этих двух задач, получается 16 решений.
В более сложных случаях мы можем наблюдать экспоненциальный взрыв пространства возможных решений. Реальный пример желающие могут пронаблюдать здесь.

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

И вот тут-то у нас и возникает спецэффект. Если мы проведем водораздел там, где начинается генерация кода, то как раз и окажется, что она всё-таки помогает сделать код эффективнее.

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

Итак, изначальный вопрос пользовался "высокоуровневыми конструкциями", а не "runtime code generation".
Поясняю логическую взаимосвязь: вот у нас есть та часть программы, которая не меняется в процессе ее работы. И вот есть другая часть программы, которая таки меняется в процессе работы. На чем написана эта вторая часть? Я имею в виду — до того, как мы начали программу выполнять?

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

Вот, собственно, и всё. Sapienti Sat.

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


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

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

LCR>На данный момент необходимо иметь такой базовый набор выразительных средств (нотацию, язык — назовите как угодно), которая
LCR>1. Позволяет реализовать любой алгоритм в принципе

Из кирпичей можно все построить.


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

И будет это здание наиболее эффективным. Некоторые их них уже 2000 лет стоят. И все там учитывают , если надо — от сейсмостойкости до розы ветров.

LCR>Несложный анализ показывает, что вышеназванная Альфа никак укладывается в требования выше.

Коля, вы что говорите! Эта Альфа 1968 г.р.

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

LCR>Допустим, вы реализовали умножение матриц, причём учли и кэши, и многопроцессорность, и учли специфику Intel/AMD и ещё много чего. То есть, ваш алгоритм стал очень очень быстрым, так что на любой машине это оказалась самая эффективная реализация.

LCR>Я делаю преобразование Лапласа, (или решаю нелинейные уравнения, или делаю какой-нибудь комбинаторный алгоритм), и теперь мне тоже надо его сделать как можно быстрее. Я запрограммировал его в виде функции laplas_transform, и теперь как мне выделить из вашего алгоритма отражение знания об архитектуре и использовать с моей функцией? Как вообще сделать так, чтобы это было возможно?

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

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

Что-то я не понял. Вы собрались матрицы в символьном виде перемножать ? Задача достойная, но это не арифметика, а обработка текста в основном. И оптимизация совсем другого, мб, понадобится — рабботы со строками, к примеру.

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


LCR>И, наконец, Алиса, взяв ваш алгоритм в качестве процедуры, вдруг осознала, что он и является главным пожирателем процессорного времени, но специфика задачи позволяет вычислять всё произведение не сразу, а по немножку. И её осенило, что если в вашем алгоритме использовать ленивые for-ы, то всё становится замечательно.

Что-то много у вас знакомых, и все они чего-то хотят


LCR>Единственный разумный путь сделать счастливыми всех четырёх человек, как мне видится, это декларативно описать алгоритм и возложить знание об архитектуре и окружение на компилятор (так что компилятор и будет модулем optimize, можно считать что каждая функция описана как f = optimize f_). Такое декларативное описание присутствует в коде на Хаскеле, и в подавляющем большинстве случаев отсутствует в коде на C++, так что бедные Вася, Таня, Алиса и ваш покорный ученик должны заново изобретать свои многоугольные колёса.


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

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

Оптимизировать задачу "постройте мне автоматически собор святого Петра" — нельзя. Для этого Браманте и Микеланджело нужны. А если эту задачу оптимизировать автоматически, то в итоге получится утепленная собачья будка размером с собор святого Петра.

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

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

Гм... Вообще-то шансы уронить ОС (насчет того, чтобы уронить приложение , промолчу — это не так уж сложно сделать при обоих видах многозадачности определяются не тем, какая многозадачность, а тем, отделен ли код ядра от кода пользователя. В корректно написанной системе шансы нулевые, независимо от того, какая тут многозадачность. Я, признаться, никак не вижу связи между тем, как приложения (потоки и т.д.) уступают друг другу процессор и защищенностью OS. Более того, ИМХО кооперативная модель является более защищенной, так как передача управления происходит в строго фиксированных местах, а не где угодно.

И второй момент. Кооперативная многозадачность в Windows ведь была, 3.1. Но в NT от нее полностью отказались. И дело тут не в Windows. И OS IBM/360-370 всех сортов, и RT-11 — RSX-11, и VAX VMS, и другие OS — используют именно вытесняющую многозадачность. Я вообще до Windows 3.x о кооперативной мультизадачности не слышал, а узнав — был, просто скажу, удивлен. Кто-то, кстати, назвал ее "решением для бедных".


Видишь ли, суть проблемы в том, что мы о разных вещах говорим. Если внутри MS SQL и есть некая псевдо- OS, и если эта псевдо-OS работает именно так, как я сказал — это означает, что для тех задач, которые там решаются, авторы признали кооперативную мультизадачность лучшим решением. Причин для этого может быть много. Но все же это не OS, а лишь приложение, хоть и сколь угодно сложное. В настоящей ОС твое требование "например, когда заранее известно все множество возможных операций и можно гарантировать, что никакая комбинация этих операций не приведет к зависаню всего приложения, включая планировщик" — просто вряд ли выполнимо.

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

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

ВВ>>Хочется узнать, что конкретно делалось.
AVK>Янус устроит? На войну с гридом немало времени убито, а глюков все одно навалом.

Что-то я не увидел там никакого "запаивания".

ВВ>>Я помню, с кем я беседовал. А ты на что возражал?
AVK>На то, что я процитировал.
ВВ>> На заключительную часть предложения? По-моему, это как раз выдергивание слов из контекста.
AVK>А по мне, так совершенно законченная мысль.
ВВ>>Что конкретно не нравится в этой фразе?
AVK>Смысл.

Правда глаза режет?

ВВ>> Дизайн большинства классов дотнета довольно говнистый.
AVK>Нет.

Ага, вин-формс единственная прям ложка говна в огромной бочке меда. Самому-то не смешно?

ВВ>> C# тоже, знаешь, большой внутренней красотой не отличается.
AVK>Нет.

Язык, который лепился в спешке по принципу "с мира по нитке"? В 1.0 я вообще не вижу практически ни одной светлой мысли, многое просто тупо скопировано с J++. И до сих пор нет внятного понимания, в какую сторону он движется.
Да можно даже и не о языке. Наследование всего от System.Object и возникший в результате этого изящнейший боксинг/анбоксинг тоже мега-красивое решение?

ВВ>> Мораль-то какая, запаивать все надо?

AVK>Тоже простой вопрос. Мораль такова:
AVK>1) Дизайн винформсов — унылое гавно
AVK>2) Если не запаивать — в результате получится унылое гавно

ВВ>> Должны быть разумные пределы.

AVK>Конечно. Дизайн винформсов — за рамками этих пределов.

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


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

ВВ>>Ага, бинарный.
ВВ>>Рассказать видимо не получится никак?
AVK>Получится, если я от тебя услышу конкретные вопросы, а не "расскажи, как оно".

А ты ничего конкретного, кроме этого "запаивать" так и не сказал.

ВВ>>- Каким образом ты запаивал вин-формс?
ВВ>>- Не скажу.
AVK>Я этого не говорил. Оно конечно просто — сочинять за собеседника и потом с сочиненным спорить, удобно. Но демагогия есть.

А что ты говорил? Ничего. Вопрос неконкретный — и типа иди на фиг. Я вот не вижу проблемы в описании общего подхода.

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

Да нет, судя по твоим ответам — лучше.

ВВ>>Ну и где я вру?
AVK>А вот прям тут и врешь. Рассказываешь сказки, что не ты про винформсы разговор завел, хотя именно ты этот разговор начал.
ВВ>> Я с самого начала предлагал ее рассматривать как надстройку над юзер32
AVK>Врешь. Ни слова ни про надстройки, ни про user32 в первых сообщениях нету. user32 ты вспомнил, уже отвечая на мое сообщение, а я его в цитатах этих даже не приводил, потому что оно было позже.

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

А без проблем, восстановим беседу:

ВВ->S: (первое упоминание вин-форм в треде )
Интересно, а WindowsForms включает в себя разработку под веб? А то, может, WindowsForms тоже говно, а я и не заметил.

S->ВВ:
Вообще-то да, говно. У неё тоже модель GUI совершенно не соответствующая современным реалиям. Поэтому нормальный десктопный интерфейс на ней делать весьма и весьма тяжко. Что, собственно, и привело к изобретению WPF.

ВВ->S: (второе упоминание)
У WindowForms модель полностью отвечает архитектуре Win32 и является прекрасной надстройкой над user32. То, что сама по себе эта модель уже устарела, разумеется, очевидно. Но WPF (в отличие от того разрекламированного тут ASP.NET MVC) представляет собой не другую абстракцию, а принципиально другую технологию.

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

AVK>Ты про вебформсы? Таки да, тоже гавно. А что, кто то с этим спорит?

Почитай ветку, спорят.

ВВ>>Вообще если уж вспомнить, то речь была о том, что не все абстракции одинаково полезны.
AVK>Не, речь была про то, что не все абстракции одинаково вредны

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

ВВ>> Почему в рамках этой темы надо сравнивать вин-формс с WPF, а не с "низким уровнем" этого самого вин-формс?
AVK>Потому что сравнивать надо с лучшими решениями, а не с худшими. Это так сложно понять?

Так сложно понять, что я не сравниваю ГУИ-фреймворки?

ВВ>> А как же политкорректность?
AVK>Ее кто то обещал?

Правила сайта вообще-то. Но, бесспорно, тебе виднее

ВВ>>>> Мне тоже не очень нравится получать советы в стиле "учись сынок, и ты поймешь, что кривая архитектура это плохо".
AVK>>>Я тебе такие советы давал?
ВВ>>Ну знаешь, многие из твоих реплик звучат именно в таком ключе.
AVK>Ты ошибся. Ни имею никакого желания тебя обучать без твоей воли.

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

ВВ>> Я, конечно, понимаю, что у тебя может быть другой опыт, но это не значит, что он применим везде, и все кто думают иначе... как ты там говорил?
AVK>Золотые слова. Вывод какой?

Да все тот же. Винформс — говно. Какой еще может быть вывод?

AVK>>>В чем? Только надо, чтобы эта тема логически сочеталась с твоими словами.
ВВ>>О том, что вин-формс как надстройка над юзер32 значительно лучше, чем веб-формс как надстройка над прямой работой с HTTP и куда меньше мешает жить.
AVK>Теперь неплохо бы это обосновать.

Я этим вообще-то довольно долго тут занимался, можешь почитать.

ВВ>>Ты же не работал в интеграторе, откуда такие выводы?
AVK>У меня есть несколько хороших знакомых, которые подробно рассказывали.

А мне ты не веришь?

ВВ>>А мы не работаем с клиентами, которые не готовы к серьезным инвестициям
AVK>Видимо, у нас серьезность разная. Под серьезностью я понимаю готовность потратить хотя бы несколько сотен килобаксов (только на разработку, а не на желески и консалтинг) и год работы команды программистов.

Видимо, разная. Никогда не считал несколько сотен килобаксов серьезными инвестициями. "Год работы команды программистов", "ивестиции в несколько сотен" — странная у вас арифметика.
Причем вывод сделан молниеносно — а, да у вас проекты маленькие.

AVK>А если общий бюджет большой, но основаня его масса уходит на железки, коробочное ПО и консалтинг, так это ни о чем не говорит.

Тот же MOSS МС сама хорошо умеет продавать. А внедрение как раз и предполагает разработку да переработку всего что можно под MOSS. И поверь мне, речь там не о сотнях тысяч и не о годе.
Например, один из проектов, на котором я сейчас работаю — и где слава богу нет МОССа — длится уже 6 лет.

AVK>О, о чем я и говорил. Деньги платятся за "внедрение какого-нибудь MOSS или Hummingbird".
А что такое внедрение какого-нибудь "MOSS или Hummingbird" по-твоему? Коробку купил и свободен?

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

Ну да, давай действительно в таком стиле общаться. А я где-то говорил, что ты это говорил?

ВВ>> Но и коробочный софт тоже бывает говном.
AVK>Бывает. Вопрос другой — бывает ли не говном софт, сделаный по принципу "обычно не до "красоты".

Бывает. Особенно когда принцип "обычно не до красоты" понимается именно в том ключе, в котором я его употреблил. А не то, что ты сам там додумал.

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

ГВ>Не собираюсь оспаривать твои высказывания, но объясни мне, пожалуйста, почему тогда абсолютное большинство десктопного софта, написанного на яве работает в разы медленее, чем его аналоги на C/C++?
Вкратце: потому, что десктопный софт работает совершенно по-другому, чем серверный.
Более длинно:
1. в серверном коде важнее не responsiveness, а throughput. Задержка реакции в 500 мс для веб-сервера — норма, благодаря тому, что UI обслуживается отдельным агентом на клиентской стороне. В десктопном приложении задержка реакции в 500мс — это ощутимые тормоза.
2. в десктопном коде важную роль играют операции с графикой, а bit-crunching по историческим причинам в управляемых платформах не слишком-то оптимизирован. Это не то чтобы их неотъемлемая особенность, это скорее вопросы приоритетов, выбранных при разработке платформ.

ГВ>Почему mcirosoft-овский MSDN работает быстро, а IBM-овская справка (на Java) — из рук вон медленно? Почему та же история повторяется с парочкой OpenOffice/MS Office? UML-рисовалки, это вообще мрак. Если сравнивать Eclipse и MSVC 6.0 — это попросту не смешно. Если ява с такой уверенностью "рвёт" плюсовый код?
Однако visual studio, несмотря на значительную долю управляемого кода, работает вполне себе приемлемо. Это, грубо говоря, означает, что дело не столько в языке, сколько в прямизне рук разработчика.
Да, это несколько подтачивает тезис о том, что хороший перформанс на средствах высокого уровня достигается меньшей ценой разработки, чем с низким уровнем, но не опровергает его окончательно.

Просто пока что баланс abstraction penalty / abstraction gain в среднем проходит чуть ниже уровня, доступного прикладным программистам управляемых сред. В стародавние времена и C++ безнадежно сливал C по производительности — однако время прошло, и сейчас редкий ассемблерщик порвет плюсы. Точно так же дело обстоит и в управляемых средах: улучшения Execution Runtime позволяют выигрывать всем программам, даже написанным до этих улучшений, и чем более высокоуровневые средства применяются, тем больше будет этот abstraction gain.

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

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

S>>Вы думаете, что я облажаюсь с пузырьком?

Pzz>А на квиксорте не облажаетесь?
Облажаюсь ли я на квиксорте?
Справлюсь ли я с поиском в ширину
Смогу ли перемножить матрицы

К счастью (моему), у меня и у моих работодателей вопросы интереснее. Чего и Вам желаю.

Не беспокойтесь, пока справляюсь.

З.Ы. Сортировку я возможно писал. Не отложилось в памяти. Не считаю это занимательным фактом, достойным биографии.
BSP дерево — писал. Ток не на интерес, а в рамках курсового. Задача курсового, кстати была не в том, чтобы написать BSP. И это я запомнил вовсе не потому, что написал BSP и офанарел от этого.

Здравствуйте, Воронков Василий, Вы писали:
ВВ>На фига мне "подключать" браузер к БД? Что вообще значит "подключить" браузер к БД? У меня десктоп-приложение, браузер — не более чем контрол для отображения данных. Его использования в данном случае аналогично какому-нибудь текст-боксу. SetText или там SetHtml и все. Работает с базой код на джава.
Ключевой момент — вот этот "SetHtml". Общепринятого стандарта на него нету, в отличие от "NavigateTo".
Поэтому действительно, самый кроссплатформенный способ — это сделать NavigateTo на соответствующий адрес.
В IE применяют специальные трюки для того, чтобы не поднимать честный HTTP-сервер: например, регистрируют свой псевдопротокол.
Или пользуются интерфейсом принудительной загрузки из IStream. Но это не кросс-браузерное решение.

Резюме тут примерно такое: встроить в себя браузер — нетривиальное занятие. А держать локальный HTTP-сервер стоит не слишком дорого.

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

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

За методическую некорректность. Показывание рекурсии на примере факториала, при том, что рядом он считается просто и тривиально обычным циклом — это способ показать "а вот можно ещё через левое ухо, если очень захотеть и совсем нечего делать". Этот способ годится по отношению к тем, кто интересуется математическими диковинками, или к тем, кто заранее _сознательно_ готов принимать все методические принципы преподавателя. И много Вы таких сейчас видели? обычно 1-2 на сотню. остальные — сдадут и забудут.

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

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

Здравствуйте, AndrewVK, Вы писали:
AVK>А какой надо? Все желающие давно уже приобрели себе тарелку с тем самым цифровым телевидением, благо стоит оно сейчас копейки.
Я лично совершенно не верю в отказ от broadcast-модели доставки медиаконтента по двум причинам:
1. Usability.
Далеко не всем хочется заниматься каким-то выбором. Вещание удобно тем, что оно поставляет тебе контент, не требуя вмешательства.
К примеру, вместо имения и поддержки огромного плейлиста в машине, многие до сих пор предпочтут включить радио. Аналогом этого является интернет-радио.
2. Эффективность
Бродкастинг позволяет одним каналом накормить очень много народу. Пока что у нас полоса пропускания не настолько велика, чтобы вещать каждому лично.

3. В итоге, скорее всего останется смешанная модель.
То есть хочешь — включаешь канал "Youtube News 24x7" и сиотришь/слушаешь то, что там тебе течёт в реальном времени.
Не хочешь — каждый раз сам лазишь по каталогу и тыкаешь "watch on demand".
Лень лазить — подписываешься на один или несколько фидов (наприер, на Channel 9, или на "Battlestar Galactica"), телевизор сливает эпизоды асинхронно, ты их высматриваешь как тебе удобно (в отличие от прямого вещания можно ставить на паузу и пересматривать повторно).

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

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

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

Pzz>>В библиотеках содержатся стандартные алгоритмы. Куда вы пойдете, если вам нужна не просто сортировка, а сортировка с преподвывертом? Готовую именно с нужными вам свойствами вы не найдете, свою написать вы не умеете, т.к. всегда использовали готовую.

_FR>Уметь по памяти и суметь на рабочем месте — две разные задачи.

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

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

Вы это либо умеете, либо нет. Если никогда не занимались, то, скорее всего, не умеете. Наверное, потратив время, вы сможете научиться, но у вас никогда не найдется на это времени. Поэтому когда встанет задача, в которой надо не просто скрестить XML с HTML'ем, а изобрести что-нибудь необычное, вас к ней никогда не привлекут. Это и есть тот самый ваш потолок, о котором говорил Валентин Нечаев. Заметьте, это ваш добровольный выбор.

Pzz>>Принесут вам код, написанный для UNIX'а и активно использующий read/write lock'и, и попросят запустить его на Windows XP. А в XP нет read/write lock'ов. Ваши дальнейшие действия?

_FR>Сяду читать или пойду пить пиво с юниксойдами, или нет, сначала пойду колоть юниксойдов, а потом сяду читать… нет, сначала почитаю, потом пойду пить пиво с юниксойдами Или попросту скажу, что это "не мой профиль" Зачем "это" (read/write lock) знать заранее? Именно: только в силу специфики решаемых задач. Если человеку каждый день надо писать под UNIX с учётом многопоточности, то он, наверное, должен это знать. Если человеку каждый день приходится писать запросы к базе данных, то он должен представлять себе, как работает её оптимизатор. Для "абстрактного" програмиста, для которого не определена специфика решаемых задач эти вопросы безсмысленны.

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

Read/write lock — это классический примитив синхронизации, а не что-то UNIX-специфическое. Его нету в API Windows XP по чистому недоразумению (в Висте он уже появился), но аналогичные конструкции попадаются на каждом шагу. Так что я не понимаю, что вы собираетесь обсуждать с юниксоидами, и довольно печально, что вы по этому вопросу вообще собираетесь с ними что-то обсуждать — это свидетельствует о том, что вы не поняли вопрос.

Pzz>>Ну скорее я посоветую такому кодеру освоить другую профессию. Потому что произойдет очередная "смена технологий", C# заменят на C#$#%, и такой кодер останется без работы: кому нужен в качестве кодера 50-летний дядька, владеющий только устаревшими методами?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

F>>Наконец-то — дождались ! Вот оно — ключевое слово: "проще".

AVK>Ключевое слово — "к чему знание деталей реализации"
Ага. Теоретически я знаю, как пилотировать самолет, но практически — предпочту обратиться к тому, кто в деталях знает как это делается. Ну извините — опять "некорректный" прием !

F>> Зачем нам обезболивающие ? Деревянным молотком по голове, как в средние века: пока пациент очухается, мы ему немножко вырежем здесь и подрихтуем там

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

F>>Факториал — это да, это классика. Но именно как пример. Наверное процентов 90 всех книг по программированию объясняют рекурсию на примере именно факториала. Но между теорией и практикой дистанция немалого размера.

AVK>Ну да. И что?
И ничего. Я же написал "именно как пример", поскольку на императивных языках обычный цикл эффективнее.

F>> Интересно, а если надо построить дерево, а потом сделать его обход ? Понятно, что можно и без рекурсии, но вот вопрос — а стоит ли ?

AVK>Иногда очень даже стоит. Только вот, сдается мне, как раз таки нерекурсивный обход дерева может вызвать у новичков затруднение, а не рекурсия.
А что, программист не должен знать (или хотя бы предполагать) где и в чем могут возникнуть затруднения и уметь их либо обходить, либо решать ? Но для этого, думается мне, надо все же знать и детали реализации.

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

F>>А линейный поиск — вообще прелесть. Понятно, что в массиве из 100 записей "при современном развитии печатного дела на Западе" (О.Бендер) — просмотреть их плевое дело. Дураки они, что ли компиляторщики — сортируют таблицу символов, чтобы потом в ней быстро искать ? А то и вообще хэш-функции втыкают

AVK>Только вот, как оказалось, на современных компьютерах линейный поиск на очень коротких списках может оказаться самым быстрым решением. Вот ведь незадача.
Незадача, да только у кого ? Ведь я и привел пример короткого списка 100 элементов в массиве — это разве много ? Для него, действительно, практически никогда не надо осуществлять дополнительных телодвижений.

F>>Правда, надо сделать одно важное извиняющее замечание — если человеку так не повезло, что ему не приходилось решать по настоящему сложных (а, значит, интересных) задач, то тогда, действительно, к чему засорять мозг

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

В общем, я понял — минусов я себе заработал

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

IT>>В плане эффективных оптимизаций я доверяю компиляторам гораздо больше, чем Дворкину.

Pzz>А компиляторы что, какие-то небожители пишут что ли?

Им я тоже доверяю больше, чем Дворкину.

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

T>В то же время у меня есть опыт редукции офигительной объектно-ориентированной иерархии на C++ из десятка шаблонных классов и активным использованием STL и Boost на полсотни килобайт кода в одну (!) функцию на C из сорока строчек, *не использующую даже CRT*.

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

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

КЛ>самый большой проект, в котором ты когда-либо участвовал?

Я не участвую в так называемых "больших проектах", мне это не интересно.

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

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

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

ВВ>Мне вот интересно посмотреть на альтернативу ООП — альтернативу в том плане, что это будет концепция способная полноценно заменить ООП, хотя бы теоретически. Возможно, это ФП. Возможно, это не ФП.
ВВ>Но это точно не должен быть ОО язык, в котором "до кучи" напихивают противоречащих этому самому ОО концепций.

Ну, если считать, что FP, в некотором роде, является базисом ООП, то... Сложный это получается вопрос: кто на ком стоял.

ВВ>>>ФП не в детерминированность ф-ций упирается, а в иной подход к созданию абстракций.
ГВ>>Как это ни удивительно, но именно об этом я с самого начала и говорю.
ВВ>В таком случае "гибридный" стиль и у тебя наверное не должен вызывать особого восторга, нет?

Да нет как раз... Любой стиль, ИМХО, хорош к своему месту. Структурный (процедурный) — в своих случаях, ОО — в своих, FP — в своих.

Если так, немного отвлечённо порассуждать, то мне кажется примерно так:

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

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

FP — очень хорошо, когда нужно решить задачи анализа и разбора чего-то. Ну то есть, когда мы можем естественно выразить задачу в терминах x = f(y) и сопутствующего перебора (привет, pattern matching!). Просто компактно записывается, компактнее, чем в предыдущих случаях. Хотя в распространённых языках, ИМХО, FP на данный момент не лишено недостатков реализации — порой слишком вольно обходится с ресурсами.

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

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

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

I>IMHO ФП и ООП несовместимы.

IMHO, как раз наоборот. Высокий уровень дизайна — ООП (паттерны, классы), низкий (внутри классов) — ФП.

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

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

Pzz>Внутри метода — алгоритмы. Те самые сортировки и поиски, о которых книжки пишут. А снаружи — клей и упаковка.

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

Pzz>Граждан, способных нагородить иерархую классов, из которой, если ее нарисовать на бумажке разноцветными карандашами, можно обои сделать — пруд пруди. А много вы знаете граждан, способных написать самостоятельно RB-дерево? Или сделать недостающий в системе примитив синхронизации из того, что в системе есть? Много ли вы вообще знаете граждан, которые знают, что в системе может недоставать каких-то примитивов синхронизации?

В первую очередь из-за того, что редко, очень редко встречаются сейчас такие задачи.

Pzz>И получается печальная картина: все мечтают наслаивать классы, слой за слоем, а простую сортировку, если что, и написать-то некому.

Вот что ты скажешь о кодере, которому за девять с лишним лет ни разу не пришлось самому писать сортировку Не то, что строить деревья или создавать примитив синхронизации? Что он должен сгореть от горя или позора?

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

_FR>>Мне больше нравится линейный поиск как навык работы с массивами и факториал как пример рекурсии. Они проще И что мы получаем: есть знания и про массивы и про рекурсию, но никакого отношения к сортировке это не имеет.

F>Наконец-то — дождались ! Вот оно — ключевое слово: "проще". Зачем нам обезболивающие ? Деревянным молотком по голове, как в средние века: пока пациент очухается, мы ему немножко вырежем здесь и подрихтуем там

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

F>между теорией и практикой дистанция немалого размера.

Это и есть ответ? Гхм, мне одному кажется это нелогичным? Например, правила сложения гораздо легче объяснять на примере натуральных силел, нежели комплексных (да ещё и в показательном представлении). Так и тут: для объяснения рекурсии — факториал.

F>Интересно, а если надо построить дерево, а потом сделать его обход ? Понятно, что можно и без рекурсии, но вот вопрос — а стоит ли ?

Это большой вопрос. Например, может зависеть от используемого компилятора. Где-то я с удовольствием предпочитаю рекурсии цикл.

F>А линейный поиск — вообще прелесть. Понятно, что в массиве из 100 записей "при современном развитии печатного дела на Западе" (О.Бендер) — просмотреть их плевое дело.

А если в массиве всего четыре элемента?

F>Дураки они, что ли компиляторщики — сортируют таблицу символов, чтобы потом в ней быстро искать ? А то и вообще хэш-функции втыкают

Если поиск в большом массиве делается один раз, то зачем его перед этим сортировать?

F>Правда, надо сделать одно важное извиняющее замечание — если человеку так не повезло, что ему не приходилось решать по настоящему сложных (а, значит, интересных) задач, то тогда, действительно, к чему засорять мозг

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

Y>Из всего этого вывод я делаю такой, что ООП в принципе и не нужен, ФП более чем достаточно. Ну разве, что если ООП будет средством модульности. Т.е. от ООП в классическом понимании останется совсем мало.

Смотря, что считать классическим понимание ООП Если "черные ящики, обменивающиеся сообщениями"(с)Алан Кей, то ООП остается

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

AVK>О да, без пенисометрии никак. Знаешь только, в чем проблема, особенно в этом форуме? По результатам измерений запросто может оказаться, что у кого то из твоих оппонентов длиннее.

Эххх, ну когда же все поймете, важна ведь не длина, а диаметр!

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

КЛ>со всем более-менее согласен кроме
IT>>…а зоопарк из приватных методов на удобные локальные функции.…

КЛ>локальная функция, если она не захватывает контекст, ничем не лучше private static, а может быть и хуже, тк захламляет код оснофной функции. Если же захватывает, то надо быть очень осторожным. Тут по работе пришлось насмотреться на локальные функции в delphi.net — ппц.

Ага, уж лучше замусорить тело класса пачкой функций-хелперов, чем тело одной единственной функции

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

AVK>>ФП не отрицает состояния

AF>

In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data

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

AF>"Все вокруг тупицы, один я д'Артаньян" — это ты молодец. Не надо обвинять фанатичных немерлистов, источник флейма явно в тебе.

А может в тебе?

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

Pzz>А вообще да, ФП предоставляет очень гибкий набор средств для выражения сложных структур данных и итераторов по ним. Но не более того. Те вещи, которые не сводятся к хитроунмой итерации сложной структуры данных, на ФП и на Фортране будут выглядеть совершенно одинаково

ФП предоставляет расширяемый набор средств. Не на столько хорошо расширяемый, как в случае с метапрограммированием, но всё же. Взять хотя бы тот же Parsec. Он же не использует сторонних утилит. И не пользуется средствами метапрограммирования. Он целиком сделан поверх языка. А вот если бы в Хаскелле были средства расширения синтаксиса, Parsec выглядел бы красиво.

Даже какая-нибудь троица map/filter/reduce в "традиционном" ИЯ тянула бы на полноценную конструкцию языка. А дальше — больше. Таких "конструкций" я могу понаделать вдоволь. Жаль только, что синтаксис не всегда будет замечательным. Вообще, тот факт, что функция является первоклассным объектом в языке и что эти самые функции удобно описывать, есть большое подспорье в смысле увеличения выразительности языка на порядки.

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

_FR>Точно! Но с каикх это пор область прогармирования ограничивается "изобретением что-нибудь необычного"? Если хотя бы каждый сотый програмист на Земле начнёт этим "изобретением" заниматься, во что превратится мир [програмирования]?

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

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

Pzz>>Есть знание специфическое, и есть знание фундаментальное.

_FR>Я по-прежнему не понимаю (из Ваших слов), для чего веб-програмисту обладать фундоментальными знаниями о примитивах синхронизации? Давайте тогда определим, что для "тех-то" нужно "то-то", а для "этих" "вон то". Только ограничить уж очень не просто получится, вплоть до того, что обоснованная работа на эту тему сможет стоитьь дисера.

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

Pzz>>Я имел ввиду, что поскольку знания, в которые вы вкладываетесь, в основном состоят из перечня интерфейсов той технологии, которую вы сейчас считаете современной, то они по природе своей полностью устаревают за несколько лет,

_FR>С чего Вы это взяли? Это как-то следует из того, что я не могу написать сортировку?

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

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

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

_DA>>Есть такие программисты вроде меня, которые просто не могут понять, ну как можно "не вспомнить", как реализовывать бинарный поиск.

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

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

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

IT>>Так и для организации кода достаточно одних структур и методов. Зачем ООП придумали и кучу других паттернов? Непонятно

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

Цирк. Для тех кто в это верит, поясню: привлекать неквалифицированных пользователей к формализации задачи — хорошо, привлекать неквалифицированных программистов (именно их ты имеешь в виду, говоря об индусах, правда?) — очень плохо.

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

Вообще-то ООП зародилось из фреймов-слотов, это такой ма-а-а-алепусенький кусочек инструментария ИИ по формализации знаний. Менеджеры софтостроения там если и стояли рядом, то только стояли.

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

Свежо предание... Только паттерн, это не "готовое решение", а некое собирательное название разных по существу решений. Хотя примеры могут быть и вполне определёнными. А каким же им ещё быть?!

Pzz>А вот внутри самих алгоритмов if'ы и while'ы — вполне себе адекватный инструмент. Во всяком случае, все классические алгоритмы описаны в литературе именно в этих терминах.

Это не просто "адекватный инструмент", if — это блин, базисная конструкция императивного стиля. Ну, вернее, не if, а goto. if — это уже структурный подход. Уж куда "адекватнее"!

P.S.: Не ставьте лошадь позади телеги, коллеги. Совсем уже свихнулись на "инструментах", "адекватности" и прочих "проблемах". Хех, ООП — инструмент менеджеров. Насмешил, спасибо.

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

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

Вот если бы я был АВК, то сказал бы "опять С++ ". А так...

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

КЛ>Это сарказм? Если удается сделать правильную пачку хэлперов, то это повышает читабельность основного метода,

Дык, так оно и есть. Только если эти хэлперы локальны специфичны для конкретного метода, то лучше калькулироваться их в этом самом методе, а уж если они универсальны, то мм самое место в отдельном классе/модуле.

КЛ>плюс от к захвату контекста все-же лучше прибегать с осторожностью.

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

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

IT>Знаешь что ты только что сказал? Примерно следующее:

IT>(я) — я думаю, что 2 * 2 = 4
IT>(ты) — нифига ты, мужик, не понимаешь. 2 * 2 — ЭТО ЧЕТЫРЕ!!!!! Запомни, будешь знать!

Что-то чересчур много экспрессии и мало смысла.

IT>Даже не хочется на это отвечать. Знаешь, если всё же открыть дверь, то мир может оказаться совсем не таким, каким он видится через замочную скважину.

Ну и не отвечал бы.

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

IT>1. http://www.rsdn.ru/forum/message/2102148.aspx

Автор: IT
Дата: 10.09.06

IT>2. http://www.rsdn.ru/forum/message/3112438.aspx

Автор: IT
Дата: 22.09.08

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

Слишком уж разные у нас с вами задачи, господа...

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

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

PD>>Все же, если не сложно, сделай, пожалуйста, в разы проще, понятнее и эффективнее сортировку — любую.

FR>http://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell
и
http://www.haskell.org/haskellwiki/Introduction#Ease_of_understanding
на всякий случай

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

PD>>Все же, если не сложно, сделай, пожалуйста, в разы проще, понятнее и эффективнее сортировку — любую.

FR>http://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell

Фишка в том, что этот Quicksort совcем не quick.

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

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

КЛ>>может быть после того, как поучаствуешь, будешь говорить про мальчиков-архитекторов?

[]

от твоей манеры общения пропадает все желание тебе отвечать

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

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

DM>А вот тут подробнее, пожалуйста. Как упомянутые фишки изменят дело, кроме более удобного синтаксиса?
DM>Вот задачка: есть семейство алгоритмов (та же компенсация, допустим), которые теперь отличаются не одной функцией, а пятью (при этом имеют по 10 общих). В случае ООП и наследования все просто — общие функции в базовый класс, различные — в наследников.

Вот эти "если" — это все выдумки. На практике если для алгоритма требуется передавать более трех функций, то что-то не так в самой функции. Когда код исходно пишется в функциональном стиле, то функция пишется не как монолит с "настройками", а собирается из других более общих функций. При этом происходит нечто вроде IoC (разворот управления). Вместо того чтобы создавать функцию-монстра и потом передавать ей тонну детализирующих функций, нужная функция собирается из кусков. Примером тут может служить LINQ. В нем нет одной супер-функции типа Query, а есть несколько функций: Where, OrderBy, ThenBy, Join, Group, Select и т.п. Каждая из них принимает одну-две лямбды и возвращает некий обект-контекст к которому можно применять другие функции из приведённого списка.

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

DM>А что в этом случае делают в Хаскеле и Лиспе?

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

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

Есть разные пути. В конце концов не трудно функции поместить в кортеж. Но на самом деле сама постановка задачи — это выдумка.

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

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

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

Здравствуйте, 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.

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

Pzz>Угу. И получишь программу, которая на вид как живая, все вроде работает, только данные никуда не ходят. Потому что сети нет. Перманентные сокеты — это то, что Джоел называет Leaky Abstractions.

Скажи пожалуйста, а что, введение абстракций является прерогативой исключительно ООП?

Pzz> А методология ООП подразумевает

Методология ООП ничего не подразумевает, потому что нет в природе никакой методологии ООП. Есть RUP, есть agile семейство, есть MSF, а методологии ООП нет.

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

Какая то каша у тебя выходит. Сокеты, методологии, динамические сети — все в одном горшке. Ни черта не понятно.

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

Хм. Модульность и ООП ортогональны. Вот, к примеру, С++ ООПнутый, но, обычно, нифига не модульный, а Виртовский Оберон модульный, но нифига не ООПнутый, в джаве модуль действительно совпадает с классом, а в дотнете классы и модули (ака сборки) друг другу ортогональны (за одним маленьким исключением).

Здравствуйте, 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>по твоему не код?

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

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

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

.........

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

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

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

Pzz>#pragma flame on

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

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

Разрыв шаблонов, действительно, произошел. Оказалось, что узкими местами в системе были вовсе не JSP странички. Они-то как раз летали, как трофейный мессершмит.
Сосал почтовый сервер, весь из себя написанный на плюсах и работавший поверх файлухи. (а то! ведь СУБД — это тормоза, они не дают прямого управления IO).
После переписывания на Java, поверх MS SQL, на той же машинке почтовый сервер стал выгребать не 200000 писем в сутки, а 1000000.
Второй боттлнек устранить не удалось: это был Interbase, тоже ясное дело, не на сишарпе писанный. Увы, он никак не хотел жрать больше 1 СPU на четырехпроцессорной машине, и кластеризовываться тоже не умел.

До того проекта я придерживался ровно таких же взглядов, как и Павел Дворкин сейчас. Стандартный набор шаблонов: "Ассемблер порвать невозможно; плюсы — единственный приемлемый язык" и так далее. Разрыв был таким, что я днями смотрел в профайлер и не верил себе.
Ничего, потом всё зажило. Павлу повезло — ему не удалось столкнуться с человеком, который бы столь же наглядно продемонстрировал ему ущербность его взглядов.

Вот, он рядом пишет про сайт microsoft.сom. Ну это же просто праздник какой-то!

Pzz>#pragma flame off

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

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

G>Расширяемые записи есть -- вот и основа для ООП. Ну а то, что методы нужно вручную прописывать в процедурные переменные (поля этих записей) -- ну так на то он и "ассемблер ООП"...

Ну тогда и в Си есть ООП

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

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

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

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

Более того, во многих задачах невозможно заранее предложить оптимальное решение в терминах mov, add, jmp и т.д. Просто потому, что еще нет информации о том, в каких условиях будет алгоритм выполняться. Потому, что, к примеру, параллелить на 1 ядре — это гарантированная потеря производительности. И непараллелить при 4 ядрах — тоже гарантированная потеря. А никакого способа автоматически трансформировать mov/add/jmp так, чтобы они были оптимальны для 1/2/4 ядер наука не знает. Зато знает способы делать это в том случае, если программа написана в декларативном стиле.
Ты в курсе, как работают оптимизаторы в современных компиляторах? Именно так и делают: переписывают Control Flow Graph в виде SSA/SSI, то есть практически в функциональном, а потом уже применяют всякие трансформации, учитывая дополнительную информацию.

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

C>>Вот что значат тормозные FS в Винде...
S>А, ну да, конечно. А сиквел сервер, значит, не поверх них работает, а божьей милостью впятеро быстрее шарашит.
S>Дело не в FS, а в правильности подхода. Смею полагать, что мы с тем же успехом могли бы поднять тот сервер и поверх Оракла на линухе, и всё равно джава порвала бы нативную реализацию поверх файлухи.

Обычно "взрослые" SQL-сервера стараются общаться с диском напрямую, насколько это возможно. Вплоть до использования своей собственной партиции, на которой нет никакой файловой системы.

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

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

Совершенно аналогично, есть код, которому поможет рантаймовая оптимизация, встроенная в дотнет, а есть, которому только помешает.

P.S. Что до самой идеи держать почту в файлах, а не в SQL-базе, в ней есть свои преимущества. Такая конструкция значительно проще и прозрачнее, и если в ней что-то сломается, проще починить, что немаловажно для администрирования. К тому же, юниксовские файловые системы довольно быстрые при таком паттерне использования, в отличии от.

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

PD>Вообще-то такое называется провокацией . Ладно. Будем считать, что провокация твоя удалась

Это не провокация и уж тем более не удавшаяся. С заданием ты не справился, а подменил его своим, подогнанными под себя.

PD>Но процентами и провайдерами я все же заниматься не буду.

И совершенно напрасно. Эта примитивная задачка достаточно сложна для того, чтобы на распаралеливание её в императивном стиле на неё потратить не 20 минут, а несколько больше. При этом мы бы увидели как 80 строк императивного кода лекго превращаются в 150-200. И ещё бы мы увидели, что задеревьями лес потерялся бы окончательно. В примере с Linq 90% кода — это алгоритм. В императивном от алгоритма примерно процентов 20%. Оптимизации уменьшают эту долю ещё в разы. А теперь предположим, что такого кода как 25 строк на linq у меня 2000 строк. Императив + оптимизации увеличат этот код минимум раз в 5, если не больше. Итого 10000+ строк. Full time job по поддержке такого кода для какого-нибудь индуса — это обычное дело. Ещё на забудем про QA team и тогда уж точно манагеров. Куча народа, на внесение изменений тикет за пол года вперёд и поехали.

PD>Насколько я понимаю, AsParallel — это из .Net 4.0, так ?

Это PLinq, CTP доступен здесь.

PD>Ray Tracer мне изучать недосуг, поэтому я просто распараллелил вычисление сумм красных компонент по столбцам окна. Зачем там эти суммы — а просто, чтобы было что делать .

Ну и зачем это надо? Тебя же просили распаралелить конкретный код, чтобы потом сравнить с существующим. А с чем мы теперь будем сравнивать? Опять с твоими домыслами?

PD>Вот код

Свят, свят, свят. Давненько я не видел C. Жуть. От звёздочек и кучи конвенций аж в глазах рябит.

PD>А теперь вопросы к тебе.

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