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

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

Вы очень интересно выбрали профессию повара для аналогии. Но да ладно, ограничим сложность проблемы приготовлением обеда =)

Классическая ситуация для повара и нереальная для программиста — Вы оговариваете меню обеда, потом выполняете чётко известную последовательность действий, со своей неподражаемой 'изюминкой' конечно же, и ву-а-ля! обед готов.

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

Потом придёт клиент и скажет что он передумал, вместо супа из мяса, он хочет суп из рыбы. Это же очень просто, всего лишь надо заменить мясо на рыбу. Ну и остальные ингредиенты подобрать чуть по другому, но это же мелочи. Ах да, и у супа должен быть лёгкий привкус малины — клиент слышал что привкус малины это точный критерий качества супа =). И протр*шись кучу времени, вы таки создаёте суп с малиновым привкусом.

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

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

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

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

O>Я уже предвижу сотни гневных постов в мой адрес, но я и не удивляюсь — реально, правда глаза колет.

O>P.S. Увы, я сам программер, и только озвучил, что думают обычные люди о нас. Интересно узнать мнение самих
O>программистов, что они думают обо всем этом.

А почему именно прграммисты из быв. СССР? То есть индусы,китайы,американцы,etc. справделиво получают, а мы нет?

Здравствуйте, Alexéy Sudáchen, Вы писали:

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

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

AS>Вы очень интересно выбрали профессию повара для аналогии. Но да ладно, ограничим сложность проблемы приготовлением обеда =)

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

Ну вот вы и сами за меня описали что работа повара намного сложнее программиста,

т.к. программисту гораздо проще смешать его "инградиенты" и добиться нужного результата, т.к. это математика 2+2=4, а у повара такой арифметики нет на которую можно было бы опереться и получится сложность которую вы описали.

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


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

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

A>Ну вот вы и сами за меня описали что работа повара намного сложнее программиста,:)

Нет.

A>т.к. программисту гораздо проще смешать его "инградиенты" и добиться нужного результата, т.к. это математика 2+2=4, а у повара такой арифметики нет на которую можно было бы опереться и получится сложность которую вы описали.

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

A>Если у повара заказчик решит вместо щей вдруг рыбный суп — ему придется все готовить с нуля, для программиста вернуться к старой версии или использовать полиморфизм намного проще и дешевле. Повар не может кинуть в суп нечто что будет абстрактной основной и потом при желании подменять ее мясой или рыбой :)

Повар может уйти делать еду клиенту, который задаёт стандартные запросы.

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

Можно. Точный рецепт — это и есть текущая версия. И рецепты можно хранить в любимом SCM.

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

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

A>>>>Возьми любые исходники , возмьи инструкцию по компиляции , скомпили — результат будет что у васи что у пети одинаковый.
0>>>Это не работа программиста
0>>>Соответственно, аналогия неправильная.

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

Ytz>Ок. Вот простая функция:
Ytz>

Ytz>int sum(int* begin, int* end)
Ytz>{
Ytz>    int result = 0;
Ytz>    while (begin != end)
Ytz>        result += *begin++;
Ytz>    return result;
Ytz>}
Ytz>

Ytz>Давай то же самое, но для double. Кстати с этой функцией точно все в порядке?

Ну а теперь возьмем рецепт пирожка с грибами и капустой

Для рецепта вам потребуется:

дрожжевое тесто (замороженное) — 1 шт.
капуста — 1/2 шт.
грибы (свежие) — 200г
мука — 3 ст.л.
растительное масло — по вкусу
соль, специи — по вкусу.

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

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

Выпекать пирожки 20 минут в предварительно разогретой духовке.

Нужно грибы и капусту заменить на мясо. И точно с этим пирожком все в порядке ?

Как думаешь что проще сделать — найти ошибку в твоей задачке аля 2+2+3-3+1-1 = 5 или понять как нужно изменить рецепт приготовления.
В твоей задаче все поддается логике, каждый оператор производит конкретное действие и никакое другое.



A>>Не говоря уже о создании своих рецептов/алгоритмов.

A>>Программист не изобретает алгоритмы, он использует готовые. В этом плане создание прикладного ПО превращается с точки зрения повара в создание празничного стола, где используется совокупность известных алгоримтов ( рецептов/блюд ).

Ytz>Да ты что? Задача: написать софт отдающий файлы по сети. Давай алгоритм. Учел, что количество пользователей может быть разным? Как насчет докачки? Несколько одинаковых загрузок одним клиентом? Удаление файла во время загрузки? Его изменение? Продолжать можно долго.

Ну и что из вышеперечисленного нужно изобретать ?
Многопользователей — идентификация + своя сессия на каждый файл + многопоточность
Докачка — запрос позиции — отдача с нужной позиции ( file.seek — изобретение века )
Удаление файла — ожидание завершения докачек файла с использованием объектов синхронизации или наоборот прерывание всех текущих потоков которые заняли данный файл ( в зависимости от требований ) — вызов функции delete тоже изобретение века просто
Изменение файла — аналогично удалению , только делаем seek и write — вообще свехгениально


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

Ytz>Программист написал софт для ракеты. Ракета полетела, вылез баг, ракета упала. Реальная история.

Ну у повара все также, только пока программист писал софт, он делал ошибки, отлаживал, делал бекапы восстанавливал, copy-pastил код из интернета.
Повару скопипастить удачный салат за 2 секунды не получится И сохранить текущий стол и потом восстановить если что не так.
Программист исправил баг — пустили ракету снова, ему программу не потребовалось переписывать. У повара в суп упал баг ( таракан ) — суп надо заново готовить с нуля.

A>>Алгоритмы в программе подчинены логике, математических алгоритмов вкуса для повара нет, тем самым понять почему плохо получилось и оператвно исправить сложно.
Ytz>С этой самой логикой у многих большие проблемы, даже у тех, кто называет себя программистом.



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

Ytz>Это вообще не ошибка. Ошибки они в логике, спрятаны в миллионах строк и тысячах условий.

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

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

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

A>>Ну вот вы и сами за меня описали что работа повара намного сложнее программиста,

N>Нет.

Да

A>>т.к. программисту гораздо проще смешать его "инградиенты" и добиться нужного результата, т.к. это математика 2+2=4, а у повара такой арифметики нет на которую можно было бы опереться и получится сложность которую вы описали.

N>У обоих одна и та же проблема: недостаточная специфицированность входных данных и внешних условий. Где-то рыба чуть не такая, специи из другого района, а где-то данные примялись. Но повар в состоянии сам внести коррективы, а программисту надо обучать программу.

Ух ты а программисту самому в код коррективы никак нельзя внести ? Ему нужно обучить какую-то программу которая за него внесет ?

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

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

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


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

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

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

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

Ytz>>Давай то же самое, но для double. Кстати с этой функцией точно все в порядке?

A>Ну а теперь возьмем рецепт пирожка с грибами и капустой
A>Нужно грибы и капусту заменить на мясо. И точно с этим пирожком все в порядке ?

Давай по очереди. Ответь сначала на мой вопрос, хочу понять твой уровень как программиста.

A>Как думаешь что проще сделать — найти ошибку в твоей задачке аля 2+2+3-3+1-1 = 5 или понять как нужно изменить рецепт приготовления.
A>В твоей задаче все поддается логике, каждый оператор производит конкретное действие и никакое другое.

Судя по этим словам, уровень никакой, да и с арифметикой не очень.

A>Ну и что из вышеперечисленного нужно изобретать ?
A>Многопользователей — идентификация + своя сессия на каждый файл + многопоточность
A>Докачка — запрос позиции — отдача с нужной позиции ( file.seek — изобретение века )
A>Удаление файла — ожидание завершения докачек файла с использованием объектов синхронизации или наоборот прерывание всех текущих потоков которые заняли данный файл ( в зависимости от требований ) — вызов функции delete тоже изобретение века просто
A>Изменение файла — аналогично удалению , только делаем seek и write — вообще свехгениально

Это не алгоритм, а детский лепет. Осталась неосвещенной масса вопросов, а часть заявленного тобой ну очень спорна. Например, зачем многопоточнось? Как это скажется на расширяемости, скорости и требовательности к ресурсам?

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

Ytz>>Программист написал софт для ракеты. Ракета полетела, вылез баг, ракета упала. Реальная история.

A>Ну у повара все также, только пока программист писал софт, он делал ошибки, отлаживал, делал бекапы восстанавливал, copy-pastил код из интернета.
A>Повару скопипастить удачный салат за 2 секунды не получится

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

A>Программист исправил баг — пустили ракету снова, ему программу не потребовалось переписывать. У повара в суп упал баг ( таракан ) — суп надо заново готовить с нуля.

Молодец. Сравнил ущерб от тарелки с супом с ракетой.

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

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

Ytz>>>Давай то же самое, но для double. Кстати с этой функцией точно все в порядке?

A>>Ну а теперь возьмем рецепт пирожка с грибами и капустой
A>>Нужно грибы и капусту заменить на мясо. И точно с этим пирожком все в порядке ?

Ytz>Давай по очереди. Ответь сначала на мой вопрос, хочу понять твой уровень как программиста.

Ну ты считаешь что алгоритм сложения double которые лежат последовательно в памяти это какое-то ноу-хау изобретение ?
И сдвинуть указатель в цикле на длину double это тоже наверное для тебя уровень кандидата наук ?


A>>Как думаешь что проще сделать — найти ошибку в твоей задачке аля 2+2+3-3+1-1 = 5 или понять как нужно изменить рецепт приготовления.
A>>В твоей задаче все поддается логике, каждый оператор производит конкретное действие и никакое другое.

Ytz>Судя по этим словам, уровень никакой, да и с арифметикой не очень.

Т.е. по твоему мнению поведение твоего кода непредсказуемо и не логично ?
И в арифметике специально допущена ошибка , как пример "сложности" ее поиска.


A>>Ну и что из вышеперечисленного нужно изобретать ?
A>>Многопользователей — идентификация + своя сессия на каждый файл + многопоточность
A>>Докачка — запрос позиции — отдача с нужной позиции ( file.seek — изобретение века )
A>>Удаление файла — ожидание завершения докачек файла с использованием объектов синхронизации или наоборот прерывание всех текущих потоков которые заняли данный файл ( в зависимости от требований ) — вызов функции delete тоже изобретение века просто
A>>Изменение файла — аналогично удалению , только делаем seek и write — вообще свехгениально

Ytz>Это не алгоритм, а детский лепет. Осталась неосвещенной масса вопросов, а часть заявленного тобой ну очень спорна. Например, зачем многопоточнось? Как это скажется на расширяемости, скорости и требовательности к ресурсам?

Какая масса вопросов ? Что тебе подсказать — как реализовать авторизацию с сессией или как работать с файлом ? Как организовать кэш ? Всему этому есть уже готовые решения. Даже если какое-то незнаешь/непомнишь всегда можно "погуглить" освежить.

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



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

Ytz>>>Программист написал софт для ракеты. Ракета полетела, вылез баг, ракета упала. Реальная история.

A>>Ну у повара все также, только пока программист писал софт, он делал ошибки, отлаживал, делал бекапы восстанавливал, copy-pastил код из интернета.
A>>Повару скопипастить удачный салат за 2 секунды не получится

Ytz>Я правильно понял, что кроме копипаста методик разработки ты больше не знаешь?

A>>Программист исправил баг — пустили ракету снова, ему программу не потребовалось переписывать. У повара в суп упал баг ( таракан ) — суп надо заново готовить с нуля.

Ytz>Молодец. Сравнил ущерб от тарелки с супом с ракетой.

Ущерб от неправильной тарелки с супом может быть тоже фатальным , в том числе и для запуска ракеты.
У нас я так чувствую 99% программистов программируют софт для ракет с ядерными боеголовками, которые запускаются без тестирования.
Суп вот не потестируешь особо, даже если тебе вкусно и съедобно у заказчика могут быть проблемы

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

A>Ну ты считаешь что алгоритм сложения double которые лежат последовательно в памяти это какое-то ноу-хау изобретение ?
A>И сдвинуть указатель в цикле на длину double это тоже наверное для тебя уровень кандидата наук ?

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


A>>>Как думаешь что проще сделать — найти ошибку в твоей задачке аля 2+2+3-3+1-1 = 5 или понять как нужно изменить рецепт приготовления.
A>>>В твоей задаче все поддается логике, каждый оператор производит конкретное действие и никакое другое.

Ytz>>Судя по этим словам, уровень никакой, да и с арифметикой не очень.

A>Т.е. по твоему мнению поведение твоего кода непредсказуемо и не логично ?

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

A>И в арифметике специально допущена ошибка , как пример "сложности" ее поиска.

Конечно.

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

Да, лучше тебе в повара, программирование явно не для тебя.

A>Суп вот не потестируешь особо, даже если тебе вкусно и съедобно у заказчика могут быть проблемы

Я уже понял уровень решаемых тобой задач.

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

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

Ytz>Я уже понял уровень решаемых тобой задач.

Да вы просто телепатъ

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

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

AV>>И какое это отношение имеет к программированию?

Ytz>Видимо человек программирует в стиле: "найти компонентик для дельфи". Это по крайней мере бы обьяснило самоуничижение перед поваром.

Дык компоненты для делфи тоже надо как-то собрать воедино. И тут опять общего рецепта не найти.

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

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

Как ты там писал чуть выше? "всегда можно "погуглить" освежить". Не знаешь как в одном потоке отдавать разные файлы разным пользователям? Значит гугл хранит еще очень много интересного для тебя как для программиста.

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

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

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

AV>Как ты там писал чуть выше? "всегда можно "погуглить" освежить". Не знаешь как в одном потоке отдавать разные файлы разным пользователям? Значит гугл хранит еще очень много интересного для тебя как для программиста.

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

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

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

AV>>Как ты там писал чуть выше? "всегда можно "погуглить" освежить". Не знаешь как в одном потоке отдавать разные файлы разным пользователям? Значит гугл хранит еще очень много интересного для тебя как для программиста.

A>Как записывать данные в разные клиентские сокеты в одном потоке — это не проблема. Проблема — это так делать

Какого рода проблема?

A>Но если делать это все в одном потоке то это будет зависимость всех пользователей от проблем одного пользователя/потока. Однопоточный FTP сервер я бы точно не стал делать Как минимум разнесение слушающего серверного сокета которых принимает клиентов чтобы входили без проблем, не зависимо от того кто там сейчас ждет чтения файла, и остальные потоки — которые их обслуживают. Можно в одном потоке обслуживать 1го пользователя, т.е. все его закачки, но это все не тянет на уровень кандидатской работы или изобретения. Мы ж собственно с этого начали.

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

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

A>Как записывать данные в разные клиентские сокеты в одном потоке — это не проблема. Проблема — это так делать
A>Но если делать это все в одном потоке то это будет зависимость всех пользователей от проблем одного пользователя/потока. Однопоточный FTP сервер я бы точно не стал делать Как минимум разнесение слушающего серверного сокета которых принимает клиентов чтобы входили без проблем, не зависимо от того кто там сейчас ждет чтения файла, и остальные потоки — которые их обслуживают. Можно в одном потоке обслуживать 1го пользователя, т.е. все его закачки, но это все не тянет на уровень кандидатской работы или изобретения. Мы ж собственно с этого начали.

Я не буду советовать тебе прочесть любой учебник по сетевому программированию, узнать про механизмы select/poll/epoll и архитектуры серверов, все это тебе ни к чему — иди суп вари

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

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

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

Ytz>>Я уже понял уровень решаемых тобой задач.

A>Да вы просто телепатъ

В остальных вопросах ты, я так понял, ты уже согласился в своей несостоятельности как программист? Ок. Тогда давай на кухню

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

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

O>Другое дело, что ВАЖНО ОБЛАДАТЬ НЕКОЙ ДОЛЕЙ САМОКРИТИКИ, в частности, попытаться посмотреть наc
O>себя глазами оппонента. Иначе можно скатиться до уровня нередивого кодера, получающего баснословные
O>деньги не за работу мозга, а за копипасту с Инета.
вас определенно мучают угрызения совести. колитесь, какой копипасой вы там занимаетесь?

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

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

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

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

O>P.S. Увы, я сам программер, и только озвучил, что думают обычные люди о нас. Интересно узнать мнение самих
O>программистов, что они думают обо всем этом.
Мы думаем, что ты не знаком с обычными людьми. Обычные люди совершенно ничего не знают о зарплатах программистов и понятия не имеют о том, что и как происходит. Ни один обычный человек не будет рассуждать в терминах "копипастить различные программные модули".

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

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

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

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

AV>>>Как ты там писал чуть выше? "всегда можно "погуглить" освежить". Не знаешь как в одном потоке отдавать разные файлы разным пользователям? Значит гугл хранит еще очень много интересного для тебя как для программиста.

A>>Как записывать данные в разные клиентские сокеты в одном потоке — это не проблема. Проблема — это так делать
AV>Какого рода проблема?

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