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

D> В связи с чем возникает вопрос, а может все эти принципы программирования
D>(KISS, поддерживаемость, инкапсуляция и т.п.) я понимаю неправильно? И надо брать с индусов пример?
я за KISS принцип. и мой шеф тоже за него. так что мы нашли друг друга. вообще, сравните апи никсов с виндами. вы действительно считаете, что в CreateFile должно быть столько параметров? и что у нее должно быть такое удачное название? и что нам позарез нужны все аргументы CreateProcess. и что нам нужно 100500 API функций?

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

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

Здравствуйте, мыщъх, Вы писали:


М>но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.

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

int _write(
   int fd,
   const void *buffer,
   unsigned int count 
);

Отдельная функция получения списка процессов дает пользователю возможность получить снимок системы. С файлами такое поведение получить невозможно.

У файлов вообще мало общего с процессами: файл можно переименовывать, файл можно удалить, после чего он не удалится, а перейдет в специальное состояние, различное под NT и posix. Можно отменить его удаление. У него нет "кода выхода".
</режим КЭП'а>
Ну вобщем, я бы не стал смешивать эти две абстракции при проектировании.

Здравствуйте, мыщъх, Вы писали:

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

BBI>>Здравствуйте, мыщъх, Вы писали:

М>>>вы действительно считаете, что в CreateFile должно быть столько параметров?
BBI>>Да, я ими пользуюсь.
М>интересно как юниксоидам хватает open?
Не хватает.
int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);
int creat(const char *pathname, mode_t mode);

М> или поставим вопрос иначе: чего не хватает системным вызовам никсов в работе с файлами, что если в win api.
Это неблагодарное занятие — сравнивать их.
Да и флейму разведём.

М>>> и что у нее должно быть такое удачное название?
BBI>>Ну, название не особо удачное. Предложи лучше.
М>см. posix open. уже давно предложили.
три функции там где в WinAPI одна. Да ещё одна с ошибкой в написании.

М>>> и что нам позарез нужны все аргументы CreateProcess.
BBI>>Да, я ими пользуюсь.
М>всемя? сразу? в каждой программе? ой. а если в первый аргумент кинуть нуль, то одного второго не хватит?
Они децл разное делают.

М>кстати, при всем этом изобилии нету форка.
Архитектурно.

М>>> и что нам нужно 100500 API функций?
BBI>>Ты предлагаешь оставить одну: void SdelatsZaippis (void); ?
М>я не предлагаю. я api вообще использую только специфическое (последний раз считывал показания счетчиков производительности и реализовано все это через одно место, можно было бы и через псевдофайловую систему реализовать). а так мне хватает libc.
Мне его никогда не хватало. Более того, я практически ничем оттуда не пользуюсь дальше базового функционала уровня memcpy, который практически весь давно уже intrinsic в компиляторах.

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

М>>если писать через API, то это делать программу намертво привязанную к платформе.
BBI>И пофиг. Зато оптимально юзаем возможности платформы.
и чем же вызов CreateFile отпимальнее fopen? хотя, вероятно, у нас с вами разные задачи. я вообще не касаюсь гуи и интерфейса. у меня только ввод и вывод. аллокатор памяти свой, заточенный под конкретные нужны (освобождение памяти в определенные моменты времени).

BBI>Я когда то писал кроссплатформ. Причём платформы отличались сильнее чем win vs lin.
ну а я пишу под линух на ms vc 6. конечно, окончательно собирается оно gcc. но окончательная сборка она только перед релизом, что происходит не часто.

Здравствуйте, мыщъх, Вы писали:

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

D>> В связи с чем возникает вопрос, а может все эти принципы программирования
D>>(KISS, поддерживаемость, инкапсуляция и т.п.) я понимаю неправильно? И надо брать с индусов пример?
М>я за KISS принцип. и мой шеф тоже за него. так что мы нашли друг друга. вообще, сравните апи никсов с виндами. вы действительно считаете, что в CreateFile должно быть столько параметров? и что у нее должно быть такое удачное название? и что нам позарез нужны все аргументы CreateProcess. и что нам нужно 100500 API функций?

Ну если вспоминать именно CreateFile() с её специфическим стилем, то принципиальная разница от open() в том, что в CreateFile() каждая отдельная характеристика метода открытия вынесена в свой метод, а у open() одна общая битовая маска flags. Второе действительно удобнее в нескольких аспектах — разумно понятное количество аргументов и расширяемость (например, было тривиально добавить O_NOFOLLOW, а покажите мне аналог под Windows), но принципиального различия, мне кажется, нет. Одно в другое переходит.

Вообще если вспоминать развитие API, то вряд ли можно вспомнить более классический пример, чем BerkeleyDB.
Версия 1: dbopen() о 5 аргументах (3 из которых взяты из open()).
Версия 2: надо расширить и углубить. Переименовываем в db_open(), расширяем и углубляем.
Версия 3: поняли, что углублять можно до бесконечности, а посему надо куда-то накапливать эти данные. Поэтому делаем db_create(), полученный хэндл набиваем параметрами и затем торжественно зовём dbh->open().
(Дальше там пошли уже пляски с транзакциями и прочей триокисью, это по-своему интересно, но главное уже успели сделать до.)

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

D>В том то и дело, помимо этого еще надо подстраиваться под изменяющиеся бизнес требования,

Как раз хорошо написанный код проще менять при изменении бизнес требований.

D>пока вы будете работать над качеством кода индус будет работать над уверенностью в будущем не обременяя себя заумными принципами.

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

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


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

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

+100. Это еще повезло, что все было хорошо структурировано, бывает и бардак, но с теми же 100500 классами.

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

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

P>Здравствуйте, мыщъх, Вы писали:

М>>всемя? сразу? в каждой программе? ой. а если в первый аргумент кинуть нуль, то одного второго не хватит? кстати, при всем этом изобилии нету форка.
P>ЕМНИП, ты же сам когда-то где-то писал, что виндовый CreateProcess удобнее форка.
на заборах тоже много интересного пишут. и пока одни пишут, другие их поправляют. вот страшие товарищи прочитали и объяснили, что форкнуть процесс стоит дешево, а вызывать CreateProcess -- все равно что в булочную на истребителе летать.

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

N>Здравствуйте, мыщъх, Вы писали:

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

N>Ну если вспоминать именно CreateFile() с её специфическим стилем, то принципиальная разница от open() в том, что в CreateFile() каждая отдельная характеристика метода открытия вынесена в свой метод, а у open() одна общая битовая маска flags. Второе действительно удобнее в нескольких аспектах — разумно понятное количество аргументов и расширяемость (например, было тривиально добавить O_NOFOLLOW, а покажите мне аналог под Windows), но принципиального различия, мне кажется, нет. Одно в другое переходит.

но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.

местами АПИ винды выглядит как издевательство. то у нас есть всего четыре (? уже не помню ?) таймера в win 3x, а то у нас есть всего горстка глобальных атомов в современной NT. вопрос -- ну и как мне предполагается использовать атомы для коммуникации между процессами, если ограничение не на процесс, а на всю систему. 27 или сколько их там -- не помню, но что-то очень мало. и что делать если атомы уже кто-то захавал?! вот тебе и многозачная многопользовательская система. т.е. атомы есть, но пользоваться ими можно только в студенческих лабах. а зачем тогда они есть?

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

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

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

...да тут все зависит от требований к проекту. вот, например, если мы пишем IPS нам нужно в реальном времени успевать делать и детекцию, и анализ. если же наш IPS реально используется как IDS то в реальном времени достаточно выдать хит типа suggestion, а уже в off-line его валидировать и тут уже спешить некуда. в резульате реал-таймовый код становится очень простым, т.к. практически все можно вынести в off-line. но опять -- если слишком сильно увлечься, то мы будет делать хит на каждый пролетающий мимо пакет и чтобы успевать обрабатывать все хиты по мере поступления нам снова потребуется реал-таймовый движок.

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

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

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

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

BBI>Здравствуйте, мыщъх, Вы писали:

М>>>>если писать через API, то это делать программу намертво привязанную к платформе.
BBI>>>И пофиг. Зато оптимально юзаем возможности платформы.
М>>и чем же вызов CreateFile отпимальнее fopen?
BBI>Тем что он прямой. Не проходит через wrapper CRT в которой свои тараканы водятся.
это с какого перепугу он прямой? KERNEL32.DLL это "толстый слой шоколада" над NTDLL.DLL, который идет куда-то вглубь, где сам черт не разберет кто его обрабатывает и сколько там фильтров-драйверов наложено. и CreateFile представляет некую абстракцию реальности, где и файлы и устройства и вообще непонятно что. а CRT как бы очень прозрачная абстракция, хотя, конечно, попытка работы с устройствами через fopen это к терапевту. да и вообще не факт, что вызов fopen дойдет до вызова CreateFile, особенно если мы создаем временный файл и форсированно закрепляем его в памяти (и без изучения исходных текстов CRT мы не может знать как оно отработает в конечном итоге).

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

М>>хотя, вероятно, у нас с вами разные задачи. я вообще не касаюсь гуи и интерфейса.
М>> у меня только ввод и вывод. аллокатор памяти свой, заточенный под конкретные нужны (освобождение памяти в определенные моменты времени).
BBI>Аналогично. У меня сейчас специализция kernel + virtualization + storage.
так ведь виртуализация это очень низкий уровень. тут без API не обойтись. а у меня основная работа идет с блоками памяти. взял блок, обработал, вернул результат. поэтому мне даже libc слишком много, а уж к АПИ обращаться и вовсе необходимости нет.

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

N>Мне непонятно что значит не использовать libc. Винда и только API вызовы, или что-то другое? Под Unix не использовать libc нереально (ну да, есть такие что сами сисколлы под все платформы рисуют, но это же задолбаться можно)
В винде libc/libcp это кусок рантайма, который идёт с прогой. В самой винде есть только WinAPI.

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

...

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

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

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

BBI>Здравствуйте, мыщъх, Вы писали:

М>>вы действительно считаете, что в CreateFile должно быть столько параметров?
BBI>Да, я ими пользуюсь.
интересно как юниксоидам хватает open ? или поставим вопрос иначе: чего не хватает системным вызовам никсов в работе с файлами, что если в win api.

М>> и что у нее должно быть такое удачное название?
BBI>Ну, название не особо удачное. Предложи лучше.
см. posix open. уже давно предложили.

М>> и что нам позарез нужны все аргументы CreateProcess.
BBI>Да, я ими пользуюсь.
всемя? сразу? в каждой программе? ой. а если в первый аргумент кинуть нуль, то одного второго не хватит? кстати, при всем этом изобилии нету форка.

М>> и что нам нужно 100500 API функций?
BBI>Ты предлагаешь оставить одну: void SdelatsZaippis (void); ?
я не предлагаю. я api вообще использую только специфическое (последний раз считывал показания счетчиков производительности и реализовано все это через одно место, можно было бы и через псевдофайловую систему реализовать). а так мне хватает libc.

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

BBI>Здравствуйте, мыщъх, Вы писали:

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

BBI>>>Здравствуйте, мыщъх, Вы писали:

М>>>>вы действительно считаете, что в CreateFile должно быть столько параметров?
BBI>>>Да, я ими пользуюсь.
М>>интересно как юниксоидам хватает open?
BBI>Не хватает.
BBI>int open(const char *pathname, int flags);
BBI>int open(const char *pathname, int flags, mode_t mode);
BBI>int creat(const char *pathname, mode_t mode);

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

М>>кстати, при всем этом изобилии нету форка.
BBI>Архитектурно.
в курсе, что архитектурно. но в винде API разрабатывалось до архитектуры. и система писалась под API, а не API под систему, а система вообще собиралась поддерживать произвольный набор API, где win32 API был не цетром вселенной. поддержка posix была заявлена. и где мой fork в этом случае?

М>>я не предлагаю. я api вообще использую только специфическое (последний раз считывал показания счетчиков производительности и реализовано все это через одно место, можно было бы и через псевдофайловую систему реализовать). а так мне хватает libc.
BBI>Мне его никогда не хватало. Более того, я практически ничем оттуда не пользуюсь дальше базового функционала уровня memcpy, который практически весь давно уже intrinsic в компиляторах.
если писать через API, то это делать программу намертво привязанную к платформе. прямые вызовы API имеют смысл только в системных программах (скажем, вот написал я дампер памяти -- там сплошные API вызовы и смысла помещать их в "обертки" нет, ибо на том же линухе дампер не нужен и мы просто прочтем память процесса как файл).

Здравствуйте, мыщъх, Вы писали:

М>>>если писать через API, то это делать программу намертво привязанную к платформе.
BBI>>И пофиг. Зато оптимально юзаем возможности платформы.
М>и чем же вызов CreateFile отпимальнее fopen?
Тем что он прямой. Не проходит через wrapper CRT в которой свои тараканы водятся.

М>хотя, вероятно, у нас с вами разные задачи. я вообще не касаюсь гуи и интерфейса.
М> у меня только ввод и вывод. аллокатор памяти свой, заточенный под конкретные нужны (освобождение памяти в определенные моменты времени).
Аналогично. У меня сейчас специализция kernel + virtualization + storage.

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

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

N>>Это не ошибка, это намеренная редукция. Первые линкеры целевой среды поддерживали только 6 символов RADIX-50 в имени, внешние символы получали префикс '_', на собственно имя оставалось 5 символов. Все API имена тех времён не длиннее 5 символов.
BBI>Это как в байке что размеры шаттла зависят от ширины лошадиной задницы в 16м веке?

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

N>>Ну да, и системные вызовы не делаешь?
BBI>Что ты под этим понимаешь?
BBI>В винде libc как и libcp это тупо враппер над WinAPI

Мне непонятно что значит не использовать libc. Винда и только API вызовы, или что-то другое? Под Unix не использовать libc нереально (ну да, есть такие что сами сисколлы под все платформы рисуют, но это же задолбаться можно)

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

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

D>>вы забыли основную идею индусского кода — получение прибыли из воздуха

A>Трэш какой-то. Основная идея индусского кода — это быстрое решение поставленной задачи без размышлений о будущем.

индуса когда нибудь живого видели?)
а общались с ним? а стояли у него за спиной и смотрели ход его размышлений?
основная цель индусо-кода получение денег за больший обьем кода
много строк чего то = много денежек
зайдите хотя бы в вики и посмотрите как простые конструкции int a = 3; индуссо кодеры усложняют
и только для того что бы увеличить свои гонорары за результат

а то о чем вы говорите это рефакторинг и к даному сабжу он не имеет отношения

кстати ps: я против KISS

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Eugeny__, Вы писали:

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

НС>Любые крайности — неоптимальны.


Согласен. Просто в последнее время слишком уж часто попадается именно переусложнение на пустом месте, просто "потому что это круто". А нужно — "потому что это лучше решает задачу".

Здравствуйте, мыщъх, Вы писали:

М>>>я за KISS принцип. и мой шеф тоже за него. так что мы нашли друг друга.
N>>Ну если вспоминать именно CreateFile() с её специфическим стилем, то принципиальная разница от open() в том, что в CreateFile() каждая отдельная
N>>Про KISS — мне кажется, что любой, кто ценит своё время, будет его использовать;
М>так ведь делать просто нужно талант иметь и думать головой. с другой стороны... вот предлагал шефу две версии проекта. одна с максимальным использованием всего готового где нашего будет буквально сотня строк кода и что работает тормозно как бронепоезд, но зато универсально, расширяемо, масштабируемо и унифицированно.
М>другой вариант в тысячи (!) раз быстрее по скрости (~10 ms против нескольких минут), но неуниверсально и придется не только писать хз сколько кода, но и дописывать его постоянно в погоне за прогрессом. я думал, что шеф как мудрый человек выберет второй вариант. шеф как мудрый человек выбрал первый. почему? потому что он проще. и дешевле. латентность в принципе удовлетворяет поставленным требованиям. пропускная способность ни ограничена ничем, только бюджетом на железо. а я еще помню упирался и все доказывал, что мы должны быть элегантными и быстрыми. и что собрать в кучу готовые кубики и стянуть их скотчем ума много не надо...
М>...в общем, я пришел к выводу, что простые решения рвут сложные, пусть даже посление очень высокотехнологичные и в теории способы обеспечить любые требования, но на практике все упирается в то, что попытка написать узкоспециализированный код, опережащий уже имеющийся код общего назначения обречена на провал, т.к. по мере расширения требования узкоспециализированный код окажется мертворожденным и его придется практически полностью переписывать.
М>короче, за простые решения потом часто приходится расплачиваться. но сложные решения часто не взлетают.

Ну вот пример типичного "KISS'а" — autotools. Типа как офигено писать "маленькие" тулзы которые стыкуются с друг другом во имя "главной" цели.
Но вы только посмотрите на этот фашизм: http://upload.wikimedia.org/wikipedia/commons/8/84/Autoconf-automake-process.svg
Вот я когда вижу эту картинку, как тут говорят, хочется оторвать руки автору и засунуть куда положено.
С другой стороны есть CMake (для него аналогичная картинка будет содержать только пару действий), он уже не состоит из зоопарка kiss'ов, а сам является непосредственно решателем "главной" цели. И это узкоспециализированное(ну с натяжкой) решение, рвёт солянку autotools по удобству использования, и имхо по скорости.
Я это к тому, что в ряде случаев, усложнить, уйти в узкую специализацию, не вредно, а даже намного полезней kiss'а.

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

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

Большинство не всегда право. А конкретики ты никакой не рассказал, так что непонятно, стоит ли за тебя радоваться или наоборот.

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

BBI>>Ты кстати в курсе что у памяти процесса на разные страницы ещё и разные права доступа вешаются, и что их как то читать/менять надо?
N>Если ты говоришь просто о чтении/записи, то ничего такого не нужно: ты этим просто помешаешь процессу.
N>Но если тебе зачем-то приспичило их поменять, для этого можно придумать ioctl'и. А дальше можешь нарисовать, если тебе нужно, своё API вокруг них.
И вот мы вышли обратно на дерибасовскую...
Если процесс представлять как файл то всё равно придётся делать костыли.
Какая уже тут разница, отдельный API для него или эмуляция через файлы. Но в случае с отдельным API нам не придётся писать подпорки чтоб реализовывать отличия процесса от файла. API выходит чище.

Здравствуйте, Banned by IT, Вы писали:
BBI>Здравствуйте, gegMOPO4, Вы писали:
КБ>>>А если понадобиться формат данных поменять — /procEx будем делать? Или по линуксовски забъем на совместимость?
MOP>>А зачем понадобится формат данных поменять?
BBI>Evolution, baby! (C)

Это революция. При грамотной эволюции проблем не так уж много.

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

D>Навеяно общением с идусским дизайнером...

D>У меня тут создалось впечатление, что индусские программисты склонны к "размазыванию" логики и данных по максимальному количеству компонентов (классов, модулей, хранимых процедур и т.п.). Делают они это весьма уверенно и, помоему, подсознательно. Единственно рациональное объяснение это так они закрепляются на своем месте, т.к. им одним постижим принцип построения этой логики. Возможно им просто так комфортно, а раз комфортно то увеличивается продуктивность.


Полусерьёзно, еслиф чё

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

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

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

Чаще всего зайцы — это молодые люди от 23 до 29 лет, хотя встречаются и престарелые зайцы.
Самое страшное, если ваш тим лид — заяц!

Навеяно общением с идусским дизайнером...

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

Далее все полусерьезно...

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

D> Вот какой прок лично тебе если ты создал расширяемую, поддерживаемую, документированную систему по сравнению с системой где всех этих плюсов нет (при условии что обе прошли тестирование)?

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

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

D>У меня тут создалось впечатление, что индусские программисты склонны к "размазыванию" логики и данных по максимальному количеству компонентов (классов, модулей, хранимых процедур и т.п.). Делают они это весьма уверенно и, помоему, подсознательно. Единственно рациональное объяснение это так они закрепляются на своем месте, т.к. им одним постижим принцип построения этой логики.

Вполне вероятно.

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

D> Возможно им просто так комфортно, а раз комфортно то увеличивается продуктивность.

И зачем такая продуктивность? Найми кого-то другого.

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

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

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

...
N>И зачем такая продуктивность? Найми кого-то другого.

Меня самого наняли.

...
N>Прок тот, что работа программиста, в отличие от пространства на Земле, пока что не ограничена. И лучше стремиться к новым достижениям, чем замыкать на себя старые.

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

Здравствуйте, мыщъх, Вы писали:

...
М>я за KISS принцип. и мой шеф тоже за него. так что мы нашли друг друга. вообще, сравните апи никсов с виндами. вы действительно считаете, что в CreateFile должно быть столько параметров? и что у нее должно быть такое удачное название? и что нам позарез нужны все аргументы CreateProcess. и что нам нужно 100500 API функций?

Я с индусом тоже за него, вопрос в его толковании. Как ваш менеджер его практикует (он же индус)?

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

D>> Вот какой прок лично тебе если ты создал расширяемую, поддерживаемую, документированную систему по сравнению с системой где всех этих плюсов нет (при условии что обе прошли тестирование)?

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

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

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

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

B>Здравствуйте, Eye of Hell, Вы писали:

D>>> Вот какой прок лично тебе если ты создал расширяемую, поддерживаемую, документированную систему по сравнению с системой где всех этих плюсов нет (при условии что обе прошли тестирование)?

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

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

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

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

Здравствуйте, мыщъх, Вы писали:

М>вы действительно считаете, что в CreateFile должно быть столько параметров?
Да, я ими пользуюсь.

М> и что у нее должно быть такое удачное название?
Ну, название не особо удачное. Предложи лучше.

М> и что нам позарез нужны все аргументы CreateProcess.
Да, я ими пользуюсь.

М> и что нам нужно 100500 API функций?
Ты предлагаешь оставить одну: void SdelatsZaippis (void); ?

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

D>Навеяно общением с идусским дизайнером...

В разработке корпоративного программного обеспечения (особенно когда аджайл) самая большая проблема — проблема управления сложностью. По-индусски можно при желании реализовать нечто, если требования будут фиксированными, но если требования меняются каждый день, вносить изменения в код очень сложно. Собственно, индусский код хорош всем, кроме того, что не понятно что надо поправить, чтобы изменился какой-то аспект поведения системы. Чтобы держать все эти факты в голове, нужно быть тем самым индусом. Иначе, придётся тратить время (много времени) на поиск всех неочевидных связей. А когда у тебя есть 300 маленьких классов, в которых каждый напрямую взаимодействует не более чем с 2-3 другими, понять происходящее намного легче, т.к. ты можешь ограничить себя пониманием этих 1+3 классов.

Здравствуйте, мыщъх, Вы писали:

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

ЕМНИП, ты же сам когда-то где-то писал, что виндовый CreateProcess удобнее форка.

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

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

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

Здравствуйте, мыщъх, Вы писали:

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

М>>>я не предлагаю. я api вообще использую только специфическое (последний раз считывал показания счетчиков производительности и реализовано все это через одно место, можно было бы и через псевдофайловую систему реализовать). а так мне хватает libc.
BBI>>Мне его никогда не хватало. Более того, я практически ничем оттуда не пользуюсь дальше базового функционала уровня memcpy, который практически весь давно уже intrinsic в компиляторах.
М>если писать через API, то это делать программу намертво привязанную к платформе.
И пофиг. Зато оптимально юзаем возможности платформы.
Я когда то писал кроссплатформ. Причём платформы отличались сильнее чем win vs lin.
Что то больше не хочется.

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

D>Навеяно общением с идусским дизайнером...

вы забыли основную идею индусского кода — получение прибыли из воздуха

вот пример есть у вас программа

main()
{
 int a = 3;
 printf("%d\n", a);
}

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

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

М>>>>вы действительно считаете, что в CreateFile должно быть столько параметров?
BBI>>>Да, я ими пользуюсь.
М>>интересно как юниксоидам хватает open?
BBI>Не хватает.
BBI>int open(const char *pathname, int flags);
BBI>int open(const char *pathname, int flags, mode_t mode);
BBI>int creat(const char *pathname, mode_t mode);

Это давным-давно одна функция. creat() это враппер для совместимости с кодом 70-х годов, реально даже не везде уже есть. Первая — на самом деле идентична второй в случае !O_CREAT. Двухаргументный open() тоже не везде уже есть.

Если уж говорить про две, то это будет open() и openat(). Но тут линейное логичное развитие.

М>>>> и что у нее должно быть такое удачное название?
BBI>>>Ну, название не особо удачное. Предложи лучше.
М>>см. posix open. уже давно предложили.
BBI>три функции там где в WinAPI одна. Да ещё одна с ошибкой в написании.

Это не ошибка, это намеренная редукция. Первые линкеры целевой среды поддерживали только 6 символов RADIX-50 в имени, внешние символы получали префикс '_', на собственно имя оставалось 5 символов. Все API имена тех времён не длиннее 5 символов.

М>>я не предлагаю. я api вообще использую только специфическое (последний раз считывал показания счетчиков производительности и реализовано все это через одно место, можно было бы и через псевдофайловую систему реализовать). а так мне хватает libc.
BBI>Мне его никогда не хватало. Более того, я практически ничем оттуда не пользуюсь дальше базового функционала уровня memcpy, который практически весь давно уже intrinsic в компиляторах.

Ну да, и системные вызовы не делаешь?

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

N>Это не ошибка, это намеренная редукция. Первые линкеры целевой среды поддерживали только 6 символов RADIX-50 в имени, внешние символы получали префикс '_', на собственно имя оставалось 5 символов. Все API имена тех времён не длиннее 5 символов.
Это как в байке что размеры шаттла зависят от ширины лошадиной задницы в 16м веке?

N>Ну да, и системные вызовы не делаешь?
Что ты под этим понимаешь?
В винде libc как и libcp это тупо враппер над WinAPI

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

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

Любые крайности — неоптимальны.

[лирическое отступление]
Был у нас такой товарищь — тоже считал что мы идиоты, потому что все переусложняем. И что все надо делать проще. И все бы ничего, но у него как то так получалось, что упрощая, он почему то увеличивал сложность тех частей, за которые он не отвечал.
В конце концов нам это надоело, и ему поручили не особо сложный, но полностью вертикальный кусок. Целиком. Ну чтобы небыло отмазок, что мы своими заморочками портим ему жизнь.
В итоге, провозился он месяца два над тем, что можно было сделать за неделю. Хуже того, по его куску было какое то невероятное количество багов. Которые он до увольнения так все и не закрыл.
Ах да, его мегапростое решение в итоге оказалось проще полностью переписать.
[/лирическое отступление]

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

...
EOH>Как раз хорошо написанный код проще менять при изменении бизнес требований.

нужна ли эта простота, может надо делать "плохо"?


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

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

Здравствуйте, мыщъх, Вы писали:

BBI>>Тем что он прямой. Не проходит через wrapper CRT в которой свои тараканы водятся.
М>это с какого перепугу он прямой? KERNEL32.DLL это "толстый слой шоколада" над NTDLL.DLL, который идет куда-то вглубь, где сам черт не разберет кто его обрабатывает и сколько там фильтров-драйверов наложено. и CreateFile представляет некую абстракцию реальности
Ну не можно и напрямую на Native API писать, но там уже становится децл неудобно для прикладного уровня.

М> а CRT как бы очень прозрачная абстракция
Которая в итоге приходит в вызовы WinAPI.

М>да и вообще не факт, что вызов fopen дойдет до вызова CreateFile, особенно если мы создаем временный файл и форсированно закрепляем его в памяти (и без изучения исходных текстов CRT мы не может знать как оно отработает в конечном итоге).
Это уже фантазии пошли.

М>но вообще, си представляет свою абстракцию. а каждая ось свою. если достаточно абстракций си -- работаем с ними. если требуются некии гарантии -- создаем свои врапперы. а баги в CRT в fopen маловероятны.
Дык используй на здоровье. Я ж не призываю всех отринуть неверный путь и узреть истинный свет единственно верного API.
Это вроде тебе было непонятно зачем WinAPI нужно когда тебе "даже libc слишком много" (С).

Здравствуйте, мыщъх, Вы писали:

N>>Ну если вспоминать именно CreateFile() с её специфическим стилем, то принципиальная разница от open() в том, что в CreateFile() каждая отдельная характеристика метода открытия вынесена в свой метод, а у open() одна общая битовая маска flags. Второе действительно удобнее в нескольких аспектах — разумно понятное количество аргументов и расширяемость (например, было тривиально добавить O_NOFOLLOW, а покажите мне аналог под Windows), но принципиального различия, мне кажется, нет. Одно в другое переходит.
М>но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.
Ну да, когда в руках молоток — весь мир похож на гвоздь.
Ну и как ты это всё впихаешь в концепцию файлов? Те же обращения к памяти процесса и счётчики.
Я имел сомнительное удовольствие иметь дело с API, в которых, если проводить аналогию с темой этой ветки "процесс как файл": если мы открыли процесс как файи и читаем оттуда по 4 кб то это будет читаться память процесса а если по 123 байта то будет читаться perfcounter.
API этот состоял из буквально пары функций, но использование его напоминало зверское колдунство с кучей magic numbers.
Вот за такие API надо обрывать руки и засовывать в жопу, где им самое место.

По мне так очень хорошо что разные сущности не смешиваются.
Не приходится для них делать special case и generic кода.

М>а то у нас есть всего горстка глобальных атомов в современной NT. вопрос -- ну и как мне предполагается использовать атомы для коммуникации между процессами, если ограничение не на процесс, а на всю систему.
Это говно появилось в 95й винде и уже лет 11 никто в здравом уме их не использует.

М>27 или сколько их там -- не помню, но что-то очень мало.
Если верить MSDN то лимит == 0xFFFF

М> и что делать если атомы уже кто-то захавал?! вот тебе и многозачная многопользовательская система. т.е. атомы есть, но пользоваться ими можно только в студенческих лабах. а зачем тогда они есть?
для обратной совместимости они есть.

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

PS. KISS кстати ни разу не означает что надо делать меньше функций в API.

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

D>вы забыли основную идею индусского кода — получение прибыли из воздуха

Трэш какой-то. Основная идея индусского кода — это быстрое решение поставленной задачи без размышлений о будущем. То что вы пишете, это совершенно нормальный подход: пока число 3 — это число 3, будет int, как только заказчик говорит, что там кроме числа 3 у него в предметной области бывает ещё строка "fuck", делаем класс — абстрагируемся. Индусский подход в этом случае — не класс сделать, а if написать, переделать код для int в код для string. Получается 2 примерно одинаковых куска кода. Далее выясняется, что заказчику и с числом 3 и со словом "fuck" нужно делать какое-то новое действие: в случае с классом у нас будет всего 1 место (либо 2, но совершенно явных). В случае с индусским подходом будет 2 неявных места.

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

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

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

D>>>вы забыли основную идею индусского кода — получение прибыли из воздуха

A>>Трэш какой-то. Основная идея индусского кода — это быстрое решение поставленной задачи без размышлений о будущем.

D>и только для того что бы увеличить свои гонорары за результат
Это работает ТОЛЬКО в случае, если заказчик платит за строки кода. Мне заказчик уже год платит за то, что кода становится меньше, а фич больше. Я теряю деньги????

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

Постулат: "основная проблема разработки корпоративных программных систем" — это управление сложностью. Есть 2 ключевых инструмента для решения этой проблемы: абстракция и разделение обязанностей. Больше ничего нет, в смысле — вообще ничего. Все паттерны, все дипенденси инжекшны — это фигня, это просто конкретика. В процедурном программировании эти инструменты реализуются через много маленьких процедур. В ООП эти инструменты реализуются через интерфейсы и объекты. Индусы славятся именно тем, что нихера не знают "основную проблему разработки корпоративных программных систем", нихера не знают как эта проблема решается и решают её так, как им приходит в голову, благо, голова у них работает хорошо и они реально могут её решить. Только потом это решение хрен кто поймёт.

D>кстати ps: я против KISS
Знаю что такое KISS, но не знаю полное значение. Одна процедура с сотней ифов это кисс? Сотня маленьких классов по 1 ифу в каждом это кисс? Что-то среднее между ними это кисс?

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

...

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

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

P>Ну вот пример типичного "KISS'а" — autotools.
Это ИМХО отличный пример неправильного понимания KISS авторами.
KISS должен соблюдаться во всём. А они как раз в использовании его нарушили чуть менее чем полностью.

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

D>> Вот какой прок лично тебе если ты создал расширяемую, поддерживаемую, документированную систему по сравнению с системой где всех этих плюсов нет (при условии что обе прошли тестирование)?

EOH>Прок в том что потом (через месяц год, пять лет) будет проще поддерживать и развивать.

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

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


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

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

V>Что совершенно очевидно, ибо сложность задачи — величина конечная снизу.

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

Здравствуйте, мыщъх, Вы писали:

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

N>>Здравствуйте, мыщъх, Вы писали:

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

N>>Ну если вспоминать именно CreateFile() с её специфическим стилем, то принципиальная разница от open() в том, что в CreateFile() каждая отдельная характеристика метода открытия вынесена в свой метод, а у open() одна общая битовая маска flags. Второе действительно удобнее в нескольких аспектах — разумно понятное количество аргументов и расширяемость (например, было тривиально добавить O_NOFOLLOW, а покажите мне аналог под Windows), но принципиального различия, мне кажется, нет. Одно в другое переходит.

М>но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.

Ну если так рассуждать то и в винде через syscall можно что угодно открыть %) Все укладывается в концепцию адресов и регистров.
Ну накатаете вы свои обертки-велосипедики поверх open для разных задач. Да это будет только нужное вам подмножество API, да это будут — родные, знакомые вам велосипедики. Но благодаря этой "простоте" вы только что зря потратили время.

А если понадобиться формат данных поменять — /procEx будем делать? Или по линуксовски забъем на совместимость?

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

М>>но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.

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

L>int _write(
L>   int fd,
L>   const void *buffer,
L>   unsigned int count 
L>);
L>

L>Отдельная функция получения списка процессов дает пользователю возможность получить снимок системы. С файлами такое поведение получить невозможно.

Вы какую-то несуразную мистику рассказываете. Посмотрите на Linux.
Список процессов? Пожалуйста, opendir("/proc"), прочитали список подкаталогов и отобрали все имена, что из одних цифр.
У адресного пространства процесса нет текущей позиции? Но ведь у файла, который его изображает, ничто не мешает сделать такую текущую позицию. Надо? Открываем /proc/$pid/mem и работаем с этим адресным пространством. (В реальности .../mem немного другое, но это был учебный пример.)
Нужно прочитать с какого-то места? lseek() и затем read(). Ну да, можно pread(), чтобы сразу с этого места читать, там и позиция передаётся. Зачем что-то навороченное ещё изобретать, когда все примеры под рукой?

Ну да, надо было уточнить, что речь не о просто файлах, а об FS. Но это jIMHO непринципиально.

L>У файлов вообще мало общего с процессами: файл можно переименовывать, файл можно удалить, после чего он не удалится, а перейдет в специальное состояние, различное под NT и posix. Можно отменить его удаление. У него нет "кода выхода".

WTF "код выхода"?

L></режим КЭП'а>

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

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

М>>но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.
BBI>Ну да, когда в руках молоток — весь мир похож на гвоздь.
BBI>Ну и как ты это всё впихаешь в концепцию файлов? Те же обращения к памяти процесса и счётчики.

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

BBI>Я имел сомнительное удовольствие иметь дело с API, в которых, если проводить аналогию с темой этой ветки "процесс как файл": если мы открыли процесс как файи и читаем оттуда по 4 кб то это будет читаться память процесса а если по 123 байта то будет читаться perfcounter.
BBI>API этот состоял из буквально пары функций, но использование его напоминало зверское колдунство с кучей magic numbers.

Сдуру можно и нефритовый стебель сломать (tm), но зачем так делать?

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

М>>>но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.
BBI>>Ну да, когда в руках молоток — весь мир похож на гвоздь.
BBI>>Ну и как ты это всё впихаешь в концепцию файлов? Те же обращения к памяти процесса и счётчики.

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

N>Сдуру можно и нефритовый стебель сломать (tm), но зачем так делать?
Ну мне твои предложения очень уж это напоминает.

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

...
I>Большинство не всегда право. А конкретики ты никакой не рассказал, так что непонятно, стоит ли за тебя радоваться или наоборот.

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

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

N>>Ну счётчики — ещё может быть, но обращения к памяти процесса — см. мой предыдущий по времени ответ сюда — всё тривиально делается.
BBI>Как именно тривиально?

Ты его прочитал?

BBI>Ты кстати в курсе что у памяти процесса на разные страницы ещё и разные права доступа вешаются, и что их как то читать/менять надо?

Если ты говоришь просто о чтении/записи, то ничего такого не нужно: ты этим просто помешаешь процессу.
Но если тебе зачем-то приспичило их поменять, для этого можно придумать ioctl'и. А дальше можешь нарисовать, если тебе нужно, своё API вокруг них.

N>>Сдуру можно и нефритовый стебель сломать (tm), но зачем так делать?
BBI>Ну мне твои предложения очень уж это напоминает.

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

Здравствуйте, Константин Б., Вы писали:
КБ>А если понадобиться формат данных поменять — /procEx будем делать? Или по линуксовски забъем на совместимость?

А зачем понадобится формат данных поменять?

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


L>>Отдельная функция получения списка процессов дает пользователю возможность получить снимок системы. С файлами такое поведение получить невозможно.

.....

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

Я наверное немного запутанно выразился. Тут я имел ввиду, что интерфейс перечисления файлов в большинстве систем расчитан на то, что файлов в директории может быть очень много, и их перебор полюбому будет делаться в несколько итераций (в windows это FindFirstFile + FindNextFile, или в ядре IRP_MJ_DIRECTORY_CONTROL, в posix насколько я помню readdir). Естественно, пока идет перебор файлов, их количество в директории может меняться, поэтому при большой файловой активности в одной директории результат может быть неконсистентным.

Функция же получения всех процессов (NtQuerySystemInformation) сдизайнена так, что возвращает список процессов одним буфером, т.е. есть некоторый шанс того, что список будет действительно соответствовать состоянию системы в некоторый момент времени. И в 2к оно так и было, прямо под одним локом весь список копировался в user buffer, в xp правда все уже не так.

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

КБ>>А если понадобиться формат данных поменять — /procEx будем делать? Или по линуксовски забъем на совместимость?

MOP>А зачем понадобится формат данных поменять?
Evolution, baby! (C)

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

D>Навеяно общением с идусским дизайнером...

D>У меня тут создалось впечатление, что индусские программисты склонны к "размазыванию" логики и данных по максимальному количеству компонентов (классов, модулей, хранимых процедур и т.п.). Делают они это весьма уверенно и, помоему, подсознательно. Единственно рациональное объяснение это так они закрепляются на своем месте, т.к. им одним постижим принцип построения этой логики. Возможно им просто так комфортно, а раз комфортно то увеличивается продуктивность.

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

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

...
I>Индусские — это слишком мягко сказано. Европейцы, американцы и даже русские слишком часто создают код который ничем не лучше индусского.

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