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

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

Чего воду в ступе толочь? Реализуй описанный алгоритмв императивном стиле, и чтобы распараллеливался, вот мы и посмотрим.

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

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

Слушай, а не хватит ? Так ведь ничего не докажешь!

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

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

IT>Что касается первого примера с pattern matching, то для леквидации своей безграмотности

Опять! Ну пойми же наконец — так ничего не докажешь.


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

Он на P4 выполняется или нет ? Если да — берем ассемблерный код, который в конце концов получился хоть от Немерле, хоть от духа святого. Вот тебе эти самые if'ы и т.д.

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

>Refletor в большинстве случаев такой код не восстанавливает, пишет что метод обфусцирован.

И что? какое это отношение к делу имеет ? В EXE с С++ все "обсфуцировано" и без всяких усилий с моей стороны

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

Если я в своей задаче сделаю код слабочитаемым (о задаче я писал в ответе VladD2) — мне это простят. Если там будет нечто вроде блюда спагетти (не будет , конечно, но допустим) — простят. Ассемблер — не обсуждал с заказчиком, но , думаю, простят. Все простят, кроме одного — если я не уложусь в эти 200 мсек. И на фоне этого все прочие рассуждения меня интересуют, как прошлогодний снег. Потому что тут действительно сложная задача(и как ее решить — я пока не знаю), а не оптимизация вычисления процентов


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

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

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

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

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

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

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

А ты попробуй. Возьми код, который я привёл (там же простенький алгоритм) и распаралель его на несколько ядер, а мы посмотрим. Ну давай, ради забавы. Там делов то.

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

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

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

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

AVK>Чего воду в ступе толочь? Реализуй описанный алгоритмв императивном стиле, и чтобы распараллеливался, вот мы и посмотрим.

Думаю, мы сейчас будет свидетелями очередного слива

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

PD>Он на P4 выполняется или нет ? Если да — берем ассемблерный код, который в конце концов получился хоть от Немерле, хоть от духа святого. Вот тебе эти самые if'ы и т.д.

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

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

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

Можно, PGO (http://msdn.microsoft.com/en-us/library/e7k32f4k(VS.80).aspx) не зря придумали

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

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

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

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

КЛ>Я тебя спросил, я ты мне тут же "не участвовал, стремно; используй моск, приходится разжевывать".

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

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

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

КЛ>>Я тебя спросил, я ты мне тут же "не участвовал, стремно; используй моск, приходится разжевывать".

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

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

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

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

Понятно. То же замыкание, только создающееся в несколько шагов.

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

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

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

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

VD>Есть разные пути. В конце концов не трудно функции поместить в кортеж.

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

VD>Но на самом деле сама постановка задачи — это выдумка.

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

Если что: я не защищаю ООП и не против ФП, только за. Просто хочу узнать получше.

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

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

Наскока я понимаю, мелкософт.ком примерно так и спроектирован. Но с двумя оговорками: 1) у мелкософта бабла немеряно, поэтому они могут себе позволить поставить неограниченное количество серверов 2) перед мордой у мелкософтовского сайта висит акамаевский акселератор. Благодаря сочетанию этих двух факторов мелкософтовский сайт хоть как-то ворочается. А без них — получится как раз RSDN.ru

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

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

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- ---load-avg---
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw | 1m   5m  15m
  0   4  80  11   0   4|  42M  440k|3177k  108M|   0     0 |  14k 2920 | 2.6  3.2  3.1
  1   5  83   7   0   4|  44M    0 |3238k  108M|   0     0 |  14k 3196 | 2.6  3.2  3.1
  0   4  83   9   0   4|  46M    0 |5719k  102M|   0     0 |  14k 3336 | 2.6  3.2  3.1
  1   3  74  17   0   5|  42M 3380k|2982k  106M|   0     0 |  14k 2990 | 2.6  3.2  3.1
  0   3  80  13   0   4|  52M 1560k|2993k  109M|   0     0 |  13k 3393 | 2.6  3.2  3.1
  0   5  83   9   0   4|  42M  196k|3365k  108M|   0     0 |  13k 3269 | 2.6  3.1  3.1
  0   5  82   8   0   5|  46M    0 |3487k  111M|   0     0 |  14k 3373 | 2.6  3.1  3.1
  0   4  84   8   0   3|  52M    0 |3596k  112M|   0     0 |  13k 2901 | 2.6  3.1  3.1
  0   4  84   6   0   4|  47M 1180k|3141k  113M|   0     0 |  14k 3060 | 2.6  3.1  3.1
  0   4  80  11   0   4|  49M 2584k|3297k  112M|   0     0 |  14k 2844 | 2.6  3.1  3.1

Особо интересны колонки usr (загрузка CPU пользовательскими процессами) и idl (простой процессора).

Вот статистика с сервера который много чисилок молотит (процессинг изображений):

----total-cpu-usage---- -disk/total -net/total- ---paging-- ---system-- ---load-avg---
usr sys idl wai hiq siq|_read write|_recv _send|__in_ _out_|_int_ _csw_|_1m_ _5m_ 15m_
 29  12  50   8   0   1| 704k 2732k|5639k 5003k|   0     0 |9321  39.3k|7.95 5.56 4.15
 16   6  75   2   0   1| 568k    0 |4179k 7573k|   0     0 |8297  20.5k|7.95 5.56 4.15
 11   4  81   2   0   1| 708k    0 |4546k 5800k|   0     0 |9092  18.1k|7.95 5.56 4.15
 16   5  75   3   0   1| 556k    0 |5344k 5335k|   0     0 |7562  18.1k|7.95 5.56 4.15
 12   4  55  28   0   1| 216k 4620k|3846k 5698k|   0     0 |7679  20.4k|7.95 5.60 4.17
 16  14  61   8   0   2| 896k 3440k|5169k 7656k|   0     0 |10.2k 35.5k|7.95 5.60 4.17
 28   7  60   2   0   2| 576k    0 |7049k 7740k|   0     0 |8587  20.5k|7.95 5.60 4.17
 27   9  61   3   0   1| 616k    0 |4732k 5278k|   0     0 |7812  15.8k|7.95 5.60 4.17
 16   8  73   2   0   1| 456k    0 |3576k 14.9M|   0     0 |10.1k 22.9k|7.95 5.60 4.17
  8   4  80   6   0   1| 712k 5044k|5638k 6572k|   0     0 |9047  16.7k|7.32 5.51 4.15
  6   4  86   4   0   1| 544k   24k|3742k 5101k|   0     0 |8058  21.5k|7.32 5.51 4.15
  7   4  86   2   0   1| 396k    0 |3209k 4688k|   0     0 |7691  14.0k|7.32 5.51 4.15

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

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

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

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

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

Отвечу вопросом на вопрос , а какие вы считаете сводимыми?

S>Тем не менее, такой человек считает себя безмерно круче окружающих и позволяет себе смеяться над людьми, которые выучили только интерфейс к string.Compare().
S>Тем не менее, с точки зрения, скажем, менеджера, эти наивные молодые люди куда полезнее старой гвардии: они, по крайней мере, могут правильно сравнить строки, когда нужно.

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

Вы говорите ровно то же, что и я: люди, привыкшие изучать интерфейсы без понимания того, что "под капотом" у этих интерфейсов, оказываются в неудобном положении, когда интерфейсы меняются. Через несколько лет string.Compare() будет смотреться столь же ограниченным частным случаем, как сейчас смотрится интерфейс к строке в виде последовательности байт в кодировке ASCII.

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

WH>Ты хоть один большой сервер вернее кластер хотябы на несколько десятков машин которые стоят в разных дататцентрах и система должна маскировать сбои не только одной машины но и целого датацентра написал?
WH>Вот тебе статистика с одного из серверов такой системы:
Справедливости ради, у тебя система заточена на быстрый отклик. Если нужна экономичность без очень быстрого отклика, то энергетически выгоднее загрузить на 100% меньшее число серверов.

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

C>Справедливости ради, у тебя система заточена на быстрый отклик. Если нужна экономичность без очень быстрого отклика, то энергетически выгоднее загрузить на 100% меньшее число серверов.

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

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

ВВ>Вообще согласно всем общепринятым нормам во втором листинге у него как раз практически предельная загрузка для продакшин-серверов, что и есть ~50%.
А в первом типа не придельная? Ты на колонки с IO посмотри...
А во втором случае реально система может сожрать еще раза в 2-3 больше запросов на обработку картинок (так я ее не в пике и сфотографировал). Правда она там еще всякой ерундой занимается чтобы IO не простаивало.

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

C>Справедливости ради, у тебя система заточена на быстрый отклик. Если нужна экономичность без очень быстрого отклика, то энергетически выгоднее загрузить на 100% меньшее число серверов.
Это совсем другая задача с совсем другими решениями.

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

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

Я не предлагаю на нее ориентироваться, я лишь описываю сложившуюся реальность.

ГВ>То есть? (Просьба: обращайся ко мне на "ты", пожалуйста.)

ОК, но могу забыть

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

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

Управляющие сигналы ты можешь описать и перечислить, хоть все сто тыщ. Беда лишь в том, что эти сто тысяч в совокупности — некоторый "алфавит", множество "символов". А программа твоя работает не с символами, а с "фразами" на этом языке. И за этим есть свои знания — например то, что disconnect приходит после connect'а, или то, что между disconnect'ом и следующим connect'ом никак не может прийти file_transmission_completed, потому что если сети нет, то какой уж тут completed. Теперь вопрос, где эти знания кодифицизованы в твоей программе? В лучшем случае — в конструкторской документации, в типичном — в голове у тех 2-3-х человек, которые на самом деле понимают, как оно работает.

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

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

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

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

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

Это спор о терминах.

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

Pzz>>И много программистов с тех пор сократилось? Давайте пропустим маркетинговый буллшит.

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

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

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

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

См. выше — сам же предложил перманантный сокет

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

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

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

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

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

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

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

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

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