Привет всем.

Давно задаюсь вопросом, почему в отечественной литературе
так мало внимания уделяется низкоуровневому программированию
Windows. Создается такое впечатление, что это никому не надо
и вовсе неактуально. Но, на мой взгляд, низкая популярность
Kernel Mode Programming связана предже всего с недостаточным
количеством русскоязычной документации и литературы. Кроме того,
я думаю, что навыки программирования в режиме ядра должен иметь
каждый программист, ибо техники, применяемые там, требуют аккуратности
и тем самым прививают качественный стиль программирования. Судите сами,
если вы функцией ExAllocatePool выделите блок памяти и забудете освободить
его при помощи ExFreePool, система вполне может показать синий экран. В то же
время прожужжавшая уши парадигма managed code технологии .NET остается для меня,
магко говоря, непонятной, т.к. сама подталкивает программиста к набрежному расходу ресурсов, тем самым воспитывая неряшливый стиль. Кроме того, на данный момент она остается крайне ресурсоемкой и практически непригодной для разработки критичный по скорости приложений.
Господа посетители RDSN, хочу узнать ваше мнение на этот счет.

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

O>его при помощи ExFreePool, система вполне может показать синий экран. В то же
O>время прожужжавшая уши парадигма managed code технологии .NET остается для меня,
O>магко говоря, непонятной, т.к. сама подталкивает программиста к набрежному расходу ресурсов, тем самым воспитывая неряшливый стиль. Кроме того, на

Спорно. Если посмотреть "поширше", то она также подталкивает к созданию скажем, хардварных GC, или поддержки понятия "указатель" на уровне железа, опять же с целью сделать какой-нибудь GC, хардварной поддержки RAII для всех типов ресурсов.

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

O>Привет всем.

O> Давно задаюсь вопросом, почему в отечественной литературе
O>так мало внимания уделяется низкоуровневому программированию
O>Windows.

Спрос рождает предложение.

O>Создается такое впечатление, что это никому не надо
O>и вовсе неактуально.

Да, ты прав

O>Но, на мой взгляд, низкая популярность
O>Kernel Mode Programming связана предже всего с недостаточным
O>количеством русскоязычной документации и литературы.

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

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

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

O>В то же время прожужжавшая уши парадигма managed code технологии .NET остается для меня,
O>магко говоря, непонятной, т.к. сама подталкивает программиста к набрежному расходу ресурсов, тем самым воспитывая неряшливый стиль.

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

O> Кроме того, на данный момент она остается крайне ресурсоемкой и практически непригодной для разработки критичный по скорости приложений.

Ну... каждому овощу свое время. Оптимизировать надо то, что криточно по времени

Кодёнок wrote:
> Спорно. Если посмотреть "поширше", то она также подталкивает к созданию
> скажем, хардварных GC, или поддержки понятия "указатель" на уровне
> железа, опять же с целью сделать какой-нибудь GC, хардварной поддержки
> RAII для всех типов ресурсов.
Это нереально. Даже если ВСЕ аппаратные ресурсы сделать GCабельными, то
останутся внешние ресурсы (типа курсоров в DB).

Гораздо интереснее было бы совместить детерминированое управление
объектами и GC. Пионер тут (как обычно ) C++, где крайне тщательно
исследована семантика и проблемы детерминированого управления. Сейчас в
C++/CLI прорабатывается взаимодействие с GC. Но как-то это не совсем то,
что хочется.

Orifiel wrote:
>
> Давно задаюсь вопросом, почему в отечественной литературе
> так мало внимания уделяется низкоуровневому программированию
> Windows. Создается такое впечатление, что это никому не надо
> и вовсе неактуально. Но, на мой взгляд, низкая популярность
> Kernel Mode Programming связана предже всего с недостаточным
> количеством русскоязычной документации и литературы. Кроме того,
> я думаю, что навыки программирования в режиме ядра должен иметь
> каждый программист, ибо техники, применяемые там, требуют аккуратности
> и тем самым прививают качественный стиль программирования. Судите сами,

По-моему, community, существующие вокруг Виндовсного kernel-mode
программирования, занимаются примерно следующим:
1. Обсуждением виндовсного ядра на мифически-магическом уровне ("чтобы
XXX заработало, надо подергать за YYY, хотя это нигде и не написано").
2. Обсуждением того, как с помощью недокументированного API можно
написать в 100 строк то, что требует 120 строк, если делать все
абсолютно честно (но зато потребует прочтения половины MSDN).
3. Обсуждением того, как приручить какую-нибудь замороченную фичу, так
и не поняв ее настоящего смысла.
4. Обсуждением того, как заставить работать драйвер с ошибками, не
исправляя, а добавляя новые ошибки.
5. Иногда гуры дают конкретные ответы на наивные вопросы.

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

Поэтому в плане с кем-нибудь потусоваться на предмет kernel mode
програмизма UNIX'овская community гораздо более привлекательна.

> если вы функцией ExAllocatePool выделите блок памяти и забудете освободить
> его при помощи ExFreePool, система вполне может показать синий экран. В
> то же
> время прожужжавшая уши парадигма managed code технологии .NET остается
> для меня,
> магко говоря, непонятной, т.к. сама подталкивает программиста к
> набрежному расходу ресурсов, тем самым воспитывая неряшливый стиль.

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

> Кроме того, на данный момент она остается крайне ресурсоемкой и
> практически непригодной для разработки критичный по скорости приложений.

Это-то как раз не очень важно. Важно то, что .Net'овский рантайм не
является стандартной частью операционной системы, и при этом достаточно
капризен и требователен в плане установки. Если Ваша программа
предназначена для массового пользователя и написана на C#, половину
пользователей Вы потеряли сразу, т.к. они не захотят выкачивать 20Mb
.Net'овского рантайма, и потом трахаться с его установкой.

Cyberax wrote:
>
> Гораздо интереснее было бы совместить детерминированое управление
> объектами и GC. Пионер тут (как обычно ) C++, где крайне тщательно
> исследована семантика и проблемы детерминированого управления. Сейчас в
> C++/CLI прорабатывается взаимодействие с GC. Но как-то это не совсем то,
> что хочется.

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

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

>> Спорно. Если посмотреть "поширше", то она также подталкивает к созданию
>> скажем, хардварных GC, или поддержки понятия "указатель" на уровне
>> железа, опять же с целью сделать какой-нибудь GC, хардварной поддержки
>> RAII для всех типов ресурсов.
C>Это нереально. Даже если ВСЕ аппаратные ресурсы сделать GCабельными, то
C>останутся внешние ресурсы (типа курсоров в DB).

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

К тому же курсоры — это не же аппаратный ресурс, причем тут они?

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

Pzz>Это-то как раз не очень важно. Важно то, что .Net'овский рантайм не
Pzz>является стандартной частью операционной системы, и при этом достаточно
Pzz>капризен и требователен в плане установки. Если Ваша программа
Pzz>предназначена для массового пользователя и написана на C#, половину
Pzz>пользователей Вы потеряли сразу, т.к. они не захотят выкачивать 20Mb
Pzz>.Net'овского рантайма, и потом трахаться с его установкой.
Смею не согласиться. Насчет сложной установки: факты в студию.
Эта ситуация напоминает разработку игр под DirectX. Вы же не будите утверждать, что нефиг писать под DX, так как он, видетели, весит мегов 50 и его качать и ставить надо.
Тенденция такова, что всё больше и больше программ пишутся под fw, и он уже является "базовой" частью windows (тот же sp2). И не говорите, что лично у вас на машине нет fw

Максим Зелинский wrote:

> Pzz>Это-то как раз не очень важно. Важно то, что .Net'овский рантайм не
> Pzz>является стандартной частью операционной системы, и при этом достаточно
> Pzz>капризен и требователен в плане установки. Если Ваша программа
> Pzz>предназначена для массового пользователя и написана на C#, половину
> Pzz>пользователей Вы потеряли сразу, т.к. они не захотят выкачивать 20Mb
> Pzz>.Net'овского рантайма, и потом трахаться с его установкой.
> Смею не согласиться. Насчет сложной установки: факты в студию.

http://russian.joelonsoftware.com/Articles/PleaseSirMayIHaveaLinker.html

Мой личный печальный опыт заключается в том, что мне так и не удалось
поставить .Net на checked build of Windows XP.

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

С играми, наверное, выбора нет...

> Тенденция такова, что всё больше и больше программ пишутся под fw, и он
> уже является "базовой" частью windows (тот же sp2). И не говорите, что
> лично у вас на машине нет fw

А он вошел уже в XP2? Вы уверены?

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

Pzz>Максим Зелинский wrote:

> Тенденция такова, что всё больше и больше программ пишутся под fw, и он
>> уже является "базовой" частью windows (тот же sp2). И не говорите, что
>> лично у вас на машине нет fw

Pzz>А он вошел уже в XP2? Вы уверены?

В Windows2003 .NET Framework 1.1 всегда входил. в R2 вроде бы входит 2.0

В XP он действительно доолжен ставиться вместе с SP2.

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

Pzz wrote:
> Готов поспорить, что в академической среде все это уже обнюхано 20 лет
> назад, если не больше.
Может быть. Однако, одно дело — академические исследование, другое дело
— практический опыт (см. подборку CUJ за десять лет).

Cyberax wrote:
>
>> Готов поспорить, что в академической среде все это уже обнюхано 20 лет
>> назад, если не больше.
> Может быть. Однако, одно дело — академические исследование, другое дело
> — практический опыт (см. подборку CUJ за десять лет).

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

Знаний, которые не прошли этот путь, как-бы в природе не существует...

Pzz wrote:
>> > Готов поспорить, что в академической среде все это уже обнюхано 20 лет
>> > назад, если не больше.
>> Может быть. Однако, одно дело — академические исследование, другое дело
>> — практический опыт (см. подборку CUJ за десять лет).
> Ну я понимаю. Типа, чтобы знания из умной книжки попали в голову рядовых
> программистов, они должны быть разжеваны, описаны в MSDN'е как "новая
> технология" и реализованы в виде библиотеки C++'ных классов.
Я же говорю — прочитайте CUJ. Там много интересного есть.

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

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

Исключения (такая древняя академическая поделка из 70-х годов) тоже
преподнесли кучу сюрпризов. Именно в среде практиков С++ появилось
понятие гарантий безопасности по исключениям (по которой уже достаточно
академических работ написано).

Или темплейты — все логично и понятно. Любой продвинутый программист
скажет, что темплейты образуют простой чистый функциональный язык с
ленивым выполнением. Все вроде просто и понятно — берем учебник по
Scheme и читаем, а потом пишем крутой метакод. Но опять появляются
интересные моменты типа "forwarding problem" или ADL.

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

O> Давно задаюсь вопросом, почему в отечественной литературе
O>так мало внимания уделяется низкоуровневому программированию
O>Windows.

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

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

А это можно на стенку вешать

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

Рынок сейчас требует, чтобы приложения создавались БЫСТРО и хоть как-то, но РАБОТАЛИ, понимаешь?
Все отсюда и пляшет.

1. Как ни крути, задачи которые решают драйверы в основном тривиальны: прислать-переслать байты. Все сложное делает обычно user-mode апликуха. Поэтому писать особо нечего. Реализации разных FS конечно сложны, но кернел мод это или не кернео не иммет значение. Есть тенденция по выносу всего сложного в юзермод.

2. Ты радуйся что ты видишь BSOD как только допускаешь ошибку. Эти ошибки легче всего найти.

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

O> Давно задаюсь вопросом, почему в отечественной литературе
O>так мало внимания уделяется низкоуровневому программированию
O>Windows. Создается такое впечатление, что это никому не надо
O>и вовсе неактуально. Но, на мой взгляд, низкая популярность
O>Kernel Mode Programming связана предже всего с недостаточным
O>количеством русскоязычной документации и литературы. Кроме того,
O>я думаю, что навыки программирования в режиме ядра должен иметь
O>каждый программист, ибо техники, применяемые там, требуют аккуратности
O>и тем самым прививают качественный стиль программирования. Судите сами,
O>если вы функцией ExAllocatePool выделите блок памяти и забудете освободить
O>его при помощи ExFreePool, система вполне может показать синий экран. В то же
O>время прожужжавшая уши парадигма managed code технологии .NET остается для меня,
O>магко говоря, непонятной, т.к. сама подталкивает программиста к набрежному расходу ресурсов, тем самым воспитывая неряшливый стиль. Кроме того, на данный момент она остается крайне ресурсоемкой и практически непригодной для разработки критичный по скорости приложений.
O> Господа посетители RDSN, хочу узнать ваше мнение на этот счет.

Блин, еще один! Держите меня семеро, а то ведь покусаю.

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

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

Pzz>Скорее, она позволяет посадить за клавиатуру тех мартышек, котором 5 лет
Pzz>назад не светило более высокой должности, чем уборщик в оффисе.

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

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

Pzz>Мой личный печальный опыт заключается в том, что мне так и не удалось
Pzz>поставить .Net на checked build of Windows XP.

Хм. А у мартышек получается.

Pzz>А он вошел уже в XP2? Вы уверены?

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

Кстати, SP весит куда больше фрэймворка. Ты его тоже по этим причинам не скачивашь?

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

Pzz>Ну я понимаю. Типа, чтобы знания из умной книжки попали в голову рядовых
Pzz>программистов, они должны быть разжеваны, описаны в MSDN'е как "новая
Pzz>технология" и реализованы в виде библиотеки C++'ных классов.

Pzz>Знаний, которые не прошли этот путь, как-бы в природе не существует...

Все проще. Наплодить кучу гениальных идей могут очень многие. А вот грамотно их структурировать, объеденить и качественно реализовать — нет. Вот и выходит, что идеи придуманные в 70-ых и 80-ых только сейчас находят реальное применение в массовом программировании, да и то появляются темы вроде этой в которых вопрошается "а на хрена все это?... все в керенел срубать ОС...".

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

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

Pzz>>Скорее, она позволяет посадить за клавиатуру тех мартышек, котором 5 лет
Pzz>>назад не светило более высокой должности, чем уборщик в оффисе.

VD>Только что ты обозвал мартышками довольно большую часть аудитории этого сайта.

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

Если утрировать, то у тебя получается примерно следующий абсурд:
Утверждение 1. Все дети боятся зубных врачей.
Утверждение 2. Ни один король не является зубным врачем.
Вывод: Ни один ребенок не будет бояться ни одного короля.

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

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

iT>Рынок сейчас требует, чтобы приложения создавались БЫСТРО и хоть как-то, но РАБОТАЛИ, понимаешь?

Какой-то это фиговый рынок — один такой был уже лет 6 назад. У Вас нет какого-нибудь другого?

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

iT>А это можно на стенку вешать

вместе с автором сего изречения

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

KA>1. Как ни крути, задачи которые решают драйверы в основном тривиальны: прислать-переслать байты. Все сложное делает обычно user-mode апликуха. Поэтому писать особо нечего. Реализации разных FS конечно сложны, но кернел мод это или не кернео не иммет значение. Есть тенденция по выносу всего сложного в юзермод.

Тривиальны, говорите. Тогда ответьте на вопрос, почему программирование драйверов считается самым сложным и почему бытует мнение, что kernel mode programmers самые
продвинутые и толковые.

KA>2. Ты радуйся что ты видишь BSOD как только допускаешь ошибку. Эти ошибки легче всего найти.

Иногда из-за подобных ошибок мне приходилось заново устанавливать Винду. Так что
радости мало.

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


VD>Блин, еще один! Держите меня семеро, а то ведь покусаю.

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

Язык С++ возник, чтоб не соврать, в 1983 г. И продолжает рулить. А всякие шарпы скоро
спишут за ненадобностью, как это фактически уже случилось с COM. А сколько шумихи было
вокруг COM! Что же касается управляемого кода, то подобные парадигмы уже давно реализованы на С++ в виде smart pointer (ATL/WTL), auto pointer (STL) и shared pointer
(boost). Причем, заметьте, вышеуказанные библиотеки я уважаю и часто использую при написании user mode applications. Причем размеры их на порядок ниже аналогичных про на
VB.NET и C#.

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

O>Тривиальны, говорите. Тогда ответьте на вопрос, почему программирование драйверов считается самым сложным и почему бытует мнение, что kernel mode programmers самые
O>продвинутые и толковые.

Подозреваю, что такое мнение существует исключительно среди kernel mode programmers

Igor Trofimov wrote:
> Не хватало нам на пару с "Нейрохирургией для чайников" еще и
> "Программирования в режиме ядра за три дня".
> Ты тираж не продаж такой книжки, если ее напишет кто.
Я бы купил — чтобы на стенку прибить

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

O>Язык С++ возник, чтоб не соврать, в 1983 г. И продолжает рулить.

C++ -- это классный язык! Долголетия ему и процветания!

O>А всякие шарпы скоро спишут за ненадобностью,

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

Мне в последнее время вспоминается книга "Автомобиль за сто лет", года 85-го издания. Там прослеживалась история развития автомобилестроения. И проводилось интересное сравнение прогулки на автомобиле начала века и 80-х годов. Начало века -- это грохочущая, трясущаяся, открытая, абсолютно небезопасная, несущаяся со страшной по тем временам скоростью по еще более страшным дорогам того времени самодвижущаяся повозка. Для того, чтобы пользоваться автомобилем того времени нужно было обладать не только обширными техническими навыками, но и иметь крепкое здоровье. А уже впечатления от поездки на таком автомобиле -- это отдельная тема
Современные автомобили предоставляют совсем другой уровень комфорта, надежности, безопасности. Они не требуют от автомобилистов серьезных технических навыков или отличного здоровья. Зато, в отличии от начала века, автомобили сейчас повсюду. И, хотя мощность современных автомобилей значительно больше, чем у старых, в обычной жизни скорость передвижения в машине по городу не настолько уж и изменилась.

С языками программирования происходит то же самое. Все больше и больше людей нуждаются в инструментах для программирования. Поэтому инструменты должны соответствовать текущему уровню пользователей. Это объективный процесс.

Если кому-то не нравится, что какой-нибудь студент за неделю на C# или Java делает больше, чем ты за месяц на C++, то значит, что тебе либо пора менять инструмент, либо область. Хочется возиться с запчастями, не вылазить из гаража неделями, получать адреналин от бешенной езды в абсолютно небезопасной самодвижущейся повозке -- ищи соответствующую область. Автогонки, например, Формула-1. Это я образно.

На самом деле мне интересно увидеть, на что народ будет фанатеть после C#.

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



E>С языками программирования происходит то же самое. Все больше и больше людей нуждаются в инструментах для программирования. Поэтому инструменты должны соответствовать текущему уровню пользователей. Это объективный процесс.

E>Если кому-то не нравится, что какой-нибудь студент за неделю на C# или Java делает больше, чем ты за месяц на C++, то значит, что тебе либо пора менять инструмент, либо область.

Вот здесь вы правы. Вспоминаю случай из собественной практики. Я довольно долго програмил
на С++ Builder и считал этот инструмент крутым, т.к. мог не трахать мозги с написанием GUI и одновременно использовать WinAPI, STL, COM без всяких проблем. Причем, что самое
странное, программы, написанные на BCB5 и BCB6, у меня шли отлично и практически не глючили. Пока не стал читать сообщения на форумах, где прямо говорилось, что правильные пацаны пишут на VC, а тот, кто пишет на Delphy/Builder — голимый <censored>. После этого забил на билдер и стал писать на VC, используя WTL, хотя фирме было глубоко пофиг, на чем я пишу. Потом програмить на VC/WTL мне ужасно понравилось (ну привык и все тут) и я стал с отвращением смотреть на Delphi и набиравшую тогда обороты технологию .NET. Сейчас думаю положить болт на WTL и писать на голом API и чистом С, ибо использовать WTL и С++ уже как-то не прикольно. Ведь мэтры — Русинович и Рихтер — пишут на голом API, а первый даже не использует С++.

Хочется возиться с запчастями, не вылазить из гаража неделями, получать адреналин от бешенной езды в абсолютно небезопасной самодвижущейся повозке -- ищи соответствующую область. Автогонки, например, Формула-1. Это я образно.

E>На самом деле мне интересно увидеть, на что народ будет фанатеть после C#.

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


O>Вот здесь вы правы. Вспоминаю случай из собественной практики. Я довольно долго програмил
O>на С++ Builder и считал этот инструмент крутым, т.к. мог не трахать мозги с написанием GUI и одновременно использовать WinAPI, STL, COM без всяких проблем.

Очень повезло, а у меня был случай, когда пример из MSDN на VC++ компилировался и работал без проблем, а на билдере глучил как черт знает что.

Причем, что самое
O>странное, программы, написанные на BCB5 и BCB6, у меня шли отлично и практически не глючили. Пока не стал читать сообщения на форумах, где прямо говорилось, что правильные пацаны пишут на VC, а тот, кто пишет на Delphy/Builder — голимый мудак. После этого забил на билдер и стал писать на VC, используя WTL, хотя фирме было глубоко пофиг, на чем я пишу. Потом програмить на VC/WTL мне ужасно понравилось (ну привык и все тут) и я стал с отвращением смотреть на Delphi и набиравшую тогда обороты технологию .NET. Сейчас думаю положить болт на WTL и писать на голом API и чистом С, ибо использовать WTL и С++ уже как-то не прикольно. Ведь мэтры — Русинович и Рихтер — пишут на голом API, а первый даже не использует С++.

Ну мэтры ( Рихтер ) как раз пишут на .NET. И что то как то не сильно жаждет писать под "голым" С++.

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

O>Сейчас думаю положить болт на WTL и писать на голом API и чистом С, ибо использовать WTL и С++ уже как-то не прикольно.

Странный критерий оценки для выбора рабочего инструмента: "прикольность".

O>Ведь мэтры — Русинович и Рихтер — пишут на голом API, а первый даже не использует С++.

Ну, на чистом C вообще много чего написано. Linux, например, и BSD.

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

В>Ну мэтры ( Рихтер ) как раз пишут на .NET. И что то как то не сильно жаждет писать под "голым" С++.

Кстати, не ради флейма, а просто интересно: Рихтер кроме книг какой-нибудь реальный софт пишет?

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

E>Здравствуйте, Ведмедь, Вы писали:

В>>Ну мэтры ( Рихтер ) как раз пишут на .NET. И что то как то не сильно жаждет писать под "голым" С++.

E>Кстати, не ради флейма, а просто интересно: Рихтер кроме книг какой-нибудь реальный софт пишет?

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

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

O>на С++ Builder и считал этот инструмент крутым, т.к. мог не трахать мозги с написанием GUI и одновременно использовать WinAPI, STL, COM без всяких проблем. Причем, что самое
O>странное, программы, написанные на BCB5 и BCB6, у меня шли отлично и практически не глючили. Пока не стал читать сообщения на форумах, где прямо говорилось, что правильные пацаны пишут на VC, а тот, кто пишет на Delphy/Builder — голимый мудак. После этого забил на билдер и стал писать на VC, используя WTL, хотя фирме было глубоко пофиг, на чем я пишу. Потом програмить на VC/WTL мне ужасно понравилось (ну привык и все тут) и я стал с отвращением смотреть на Delphi и набиравшую тогда обороты технологию .NET. Сейчас думаю положить болт на WTL и писать на голом API и чистом С, ибо использовать WTL и С++ уже как-то не прикольно. Ведь мэтры — Русинович и Рихтер — пишут на голом API, а первый даже не использует С++.

Чертовски интересно. Для тебя важнее всего — что думают о технологии другие, а не что она представляет из себя на самом деле, и что дает для процесса работы?

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

Ну, вот беседа плавно и перешла в обычное русло.

Поздравляю вас господа с очередным C# vs. C++.

2ALL: Ну, что сразу в мусор снести или кому-то охота кости поразмять?

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

VD>Поздравляю вас господа с очередным C# vs. C++.

Не, Влад, здесь

Автор: Orifiel
Дата: 11.01.06

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

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

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

"Крутым", "мэтры пишут на голом", "правильные пацаны", "использовать WTL и С++ уже как-то не прикольно" — ты чем там вообще занимаешься Для тебя есть ещё практически значимые различия C++/WTL и C++Builder/VCL кроме того, что на первом пишут крутые пацаны, а на втором нет?

O>на С++ Builder и считал этот инструмент крутым, т.к. мог не трахать мозги с написанием GUI и одновременно использовать WinAPI, STL, COM без всяких проблем. Причем, что самое странное, программы, написанные на BCB5 и BCB6, у меня шли отлично и практически не глючили.

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

O>Сейчас думаю положить болт на WTL и писать на голом API и чистом С, ибо использовать WTL и С++ уже как-то не прикольно. Ведь мэтры — Русинович и Рихтер — пишут на голом API, а первый даже не использует С++.

Ну так скорее начинай. Потом может на wasm.ru тебе понравится.

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

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

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

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

Pzz>http://russian.joelonsoftware.com/Articles/PleaseSirMayIHaveaLinker.html

Pzz>Мой личный печальный опыт заключается в том, что мне так и не удалось
Pzz>поставить .Net на checked build of Windows XP.
Ну чтож, клиника...

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

Pzz>С играми, наверное, выбора нет...
Это почему, сударь? Вы знаете, есть еще, во всяком случаи, пару библиотек для разработки. Но разработчики выбрали DX. Сейчас многие разработчики выбирают fw.

>> Тенденция такова, что всё больше и больше программ пишутся под fw, и он
>> уже является "базовой" частью windows (тот же sp2). И не говорите, что
>> лично у вас на машине нет fw

Pzz>А он вошел уже в XP2? Вы уверены?
В общем, да Кстати, представляете, на моём сотовом (imate sp3i) то же есть fw и ничего качать и ставить не надо

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

E>На самом деле мне интересно увидеть, на что народ будет фанатеть после C#.

Аналогично. Метапрограмминг может?

E>На самом деле мне интересно увидеть, на что народ будет фанатеть после C#.

Concurrent и Distributed Programming, имхо

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

E>Не, Влад, здесь

Автор: Orifiel
Дата: 11.01.06

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

Это надо отметить как "краткое содержание ветки".

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

iT>Рынок сейчас требует, чтобы приложения создавались БЫСТРО и хоть как-то, но РАБОТАЛИ, понимаешь?

Спасибо! Много смеялся. Я вообще всегда много смеюсь, когда читаю не "marketing requirements", а "рынок требует". Вообще, это замечательное свойство калек с английского — рубить мозги.

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

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

Так что, вот это:

Рынок сейчас требует, чтобы приложения создавались БЫСТРО и хоть как-то, но РАБОТАЛИ [...]

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

Разумеется, чем меньше "time to market", тем, как правило (но не всегда!), лучше. Ну так это всегда было, нашёл чему удивляться!

iT>Все отсюда и пляшет.

Ага, интересно так пляшет... если снизу подсмотреть.

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

E>Кстати, не ради флейма, а просто интересно: Рихтер кроме книг какой-нибудь реальный софт пишет?

Бери выше:

Wintellect is a training, consulting and debugging firm that specializes in .NET and Windows technologies whose mission is to help companies build better software, faster. The company was founded in spring 2000 by three developers — Jeff Prosise, Jeffrey Richter, and John Robbins — and businessman Lewis Frazer.

А вот он со старым другом Биллом:

Здравствуйте, Ведмедь,

E>>Кстати, не ради флейма, а просто интересно: Рихтер кроме книг какой-нибудь реальный софт пишет?

В>Да я думаю что нет Как и Русинович, впрочем. Поэтому он и может себе позволить писать на чистом С

Руссинович пишет. http://winternals.com/
Не считая массы бесплатных утилит, которые имеют большую академическую и практическую ценности.

В>Это нам, простым смертным, приходится всякой фигней заниматься, а они стратЭги

Угу, у простых смертных нет такого:

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

O> Давно задаюсь вопросом, почему в отечественной литературе так мало внимания уделяется низкоуровневому программированию Windows.

Ну есть книжка Солдатова...
А зачем именно на русском?

O>Создается такое впечатление, что это никому не надо и вовсе неактуально.
O>Но, на мой взгляд, низкая популярность Kernel Mode Programming связана предже всего с недостаточным количеством русскоязычной документации и литературы.

На семом деле, это сговор. С целью поднятия цен.

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

ИМХО это "всего лишь" приучает изучать документацию и думать головой, а не компилировать первый попавшийся сорец из инета.

Ну и понимать, как работает конкретная ОС это помогает.

А "качественный стиль" — он ИМХО для каждого инструмента свой.

O>Судите сами, если вы функцией ExAllocatePool выделите блок памяти и забудете освободить его при помощи ExFreePool, система вполне может показать синий экран.

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

Кстати, вызвать такие функции сейчас не очень просто

O>В то же время прожужжавшая уши парадигма managed code технологии .NET остается для меня, магко говоря, непонятной, т.к. сама подталкивает программиста к набрежному расходу ресурсов, тем самым воспитывая неряшливый стиль.

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

O>Кроме того, на данный момент она остается крайне ресурсоемкой и практически непригодной для разработки критичный по скорости приложений.

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

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

E>>На самом деле мне интересно увидеть, на что народ будет фанатеть после C#.

AVK>Аналогично. Метапрограмминг может?

Может быть, хотя я сомневаюсь.

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

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

M>Concurrent и Distributed Programming, имхо

А почему ты так думаешь? В этом направлении работы давно ведутся, даже я в чем-то подобном участвую

Автор: Евгений Охотников
Дата: 30.12.05

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

Имхо, у Java и C# (так же как у Python/Ruby) широкая область для применения. Можно написать стотысячный вариант часиков для десктопа, или очередной Notepad, или программку для хранения рецептов. А можно и корпоративную информационную систему или Web-портал. Т.е. область применения очень широка. У Concurrent и Distributed ниша гораздо меньше.

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

E>Может быть, хотя я сомневаюсь.

E>Да чего гадать, нужно всего-то лет десять подождать. Может кто-то из нас еще и программировать будет.

декларативные языки в целом и DSL в частности, это однозначно

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

E>>На самом деле мне интересно увидеть, на что народ будет фанатеть после C#.

M>Concurrent и Distributed Programming, имхо

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

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

E>>Да чего гадать, нужно всего-то лет десять подождать. Может кто-то из нас еще и программировать будет.

Д>декларативные языки в целом и DSL в частности, это однозначно

По поводу DSL для меня это не так однозначно. Посуди сам, языков программирования существует множество, а вот удачных среди них не так уж мало (если за степень удачности брать, хотя бы, степень известности). Развитие DSL будет означать увеличение количества языков, но процент удачных, имхо, останется таким же. А это значит, что большому количеству программистов придется столкнуться с неудачными DSL и пользоваться неудобными инструментами. Поэтому ситуация с DSL мне напоминает ситуацию с макросами в C/C++: хорошая в умелых руках штука стала головной болью, настолько большой, что препроцессором рекомендуют пользоваться как можно реже.

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

GN>Здравствуйте, Ведмедь,

E>>>Кстати, не ради флейма, а просто интересно: Рихтер кроме книг какой-нибудь реальный софт пишет?

В>>Да я думаю что нет Как и Русинович, впрочем. Поэтому он и может себе позволить писать на чистом С

GN>Руссинович пишет. http://winternals.com/

GN>Не считая массы бесплатных утилит, которые имеют большую академическую и практическую ценности.

Да, только большинство программистов пишет не утилиты. Что то я не вижу у них CRM или ERP решений. А наборы качественно написанных, но утилит. Поэтому последнее время мне как то интересней почитать Якобсона, Буча или Фаулера.

В>>Это нам, простым смертным, приходится всякой фигней заниматься, а они стратЭги

GN>Угу, у простых смертных нет такого:
GN>

К сожалению не могу загрузить картинку и понять, чего нет у простых смертных

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

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

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

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

B>Здравствуйте, Ведмедь, Вы писали:

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

B>Давно мечтают о том, что человек только формулирует задачу, а компутер ее решает.
B>Практически с самого появления компьютеров

Ну в принципе все к тому идет. Правда медленно

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

E>По поводу DSL для меня это не так однозначно. Посуди сам, языков программирования существует множество, а вот удачных среди них не так уж мало (если за степень удачности брать, хотя бы, степень известности). Развитие DSL будет означать увеличение количества языков, но процент удачных, имхо, останется таким же. А это значит, что большому количеству программистов придется столкнуться с неудачными DSL и пользоваться неудобными инструментами. Поэтому ситуация с DSL мне напоминает ситуацию с макросами в C/C++: хорошая в умелых руках штука стала головной болью, настолько большой, что препроцессором рекомендуют пользоваться как можно реже.

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

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

Д>ты немного путаешь. DSL и язык общего назначения — это две очень большие разницы.

Эта разница скроется, как только на DSL нужно будет не только декларации делать, но еще и какую-то логику программировать.
А так можно еще сравнить DSL с API. Очень не просто удачный API сразу придумать (чтобы right thing

Автор: sch
Дата: 09.01.06

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

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

Ну да. Сначала сохраняем конфиг в ini-файлах, потом упираемся в ограничения, переходим на XML с XSD, приплетаем навороченные XML-редакторы для редактирования и понеслась
Или наоборот, в XML с XSD сохраняем то, что замечательно разместилось бы в ini-файлах.

M>>Concurrent и Distributed Programming, имхо

E>А почему ты так думаешь? В этом направлении работы давно ведутся, даже я в чем-то подобном участвую

Автор: Евгений Охотников
Дата: 30.12.05

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

Чисто субъективное мнение. Или может я неправильно выразился. Я имел в виду нечто вроде network-transparent programming.

МС толкает идею все прграммы на сервере, вы скачиваете только то, что вам нужно и работаете. Все эти SOAP, Corba, COM, Service-Oriented Programming — костыли, предназначенные на прозрачное взаимодействие программ в теоретически неограниченно удаленных друг от друга системах. А главное что? Доступ к информации и управление ею — вне зависимости от того, где находится информация и где находится оператор.

Это, кстати, даже для того же Офиса микросовтовского актуально. Стандартный "документооборот", что я пока видел на разных фирмах — туча расшаренных файлов на разных компьютерах (или на одном сервере) и с десяток людей, работающих с ними в режиме read-only. Причем всех надо учить, что и где лежит, а также предупреждать, что файлы не нужно стирать под страхом жизни. По меньшей мере неудобно.

E>Имхо, у Java и C# (так же как у Python/Ruby) широкая область для применения. Можно написать стотысячный вариант часиков для десктопа, или очередной Notepad, или программку для хранения рецептов. А можно и корпоративную информационную систему или Web-портал. Т.е. область применения очень широка. У Concurrent и Distributed ниша гораздо меньше.

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

M>МС толкает идею все прграммы на сервере, вы скачиваете только то, что вам нужно и работаете. Все эти SOAP, Corba, COM, Service-Oriented Programming — костыли, предназначенные на прозрачное взаимодействие программ в теоретически неограниченно удаленных друг от друга системах. А главное что? Доступ к информации и управление ею — вне зависимости от того, где находится информация и где находится оператор.

Значит я тебя правильно понял. И сам думаю о том же

Автор: eao197
Дата: 12.01.06

.

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

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

В>Да, только большинство программистов пишет не утилиты. Что то я не вижу у них CRM или ERP решений. А наборы качественно написанных, но утилит.

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

В>Поэтому последнее время мне как то интересней почитать Якобсона, Буча или Фаулера.

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

В>>>Это нам, простым смертным, приходится всякой фигней заниматься, а они стратЭги

GN>>Угу, у простых смертных нет такого:
GN>>

В>К сожалению не могу загрузить картинку и понять, чего нет у простых смертных

RSDN DDoS ? Что-то даже дизайн сайта поменялся В левом верхнем углу на главной странице сайта — "Microsoft gold certified partner".

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

GN>Здравствуйте, Ведмедь, Вы писали:

В>>Да, только большинство программистов пишет не утилиты. Что то я не вижу у них CRM или ERP решений. А наборы качественно написанных, но утилит.

GN>Очевидно, каждый работает в том направлении, в котором разбирается лучше всего. Руссинович пишет KMD. Да, это никому не нужно, но без этого совсем ничего не будет работать

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

В>>Поэтому последнее время мне как то интересней почитать Якобсона, Буча или Фаулера.

GN>Из упоминания уважаемых авторов следует, что Руссинович не пишет софт? Мне тоже интеречно многие вещи почитать, но это к делу не относится.

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

GN>>>Угу, у простых смертных нет такого:
GN>>>

Понятно. У меня была такая мысль. Значит и мы оказывается не простые смертные

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

В>Ну как сказать. Я имел ввиду, что сейчас я занимаюсь не теми задачами, которыми занимается Русинович и Рихтер, а теми, которые обсуждают Фаулер и Якобсон.

Ну дык, по этому поводу есть старая притча:

Был однажды программист, который работал с микропроцессорами.
— Смотри, как хорошо мне здесь! — сказал он программисту мейнфреймов, который зашел к нему. — У меня есть собственная операционная система и устройство для хранения файлов. Я ни с кем не делю свои ресурсы. Программное обеспечение самодостаточно и легко в обращении. Почему бы тебе не уйти с твоей теперешней работы и не присоединиться ко мне здесь?
Тогда программист мейнфреймов начал описывать другу свою систему, говоря:
— Мейнфрейм восседает в вычислительном центре, как древний мудрец погруженный в медитацию. Его дисковые накопители раскинулись из конца в конец, как огромный электронный океан. Программное обеспечение многогранно, как брильянт и переплетено, как первобытные джунгли. Программы, каждая уникальна, движутся сквозь систему, как быстротекущая река. Вот почему я счастлив там, где я есть.
Программист микрокомпьютеров, услышав это, надолго замолчал. Hо два программиста остались друзьями до конца своих дней.

В>Значит и мы оказывается не простые смертные

Поздравляю

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

B>>Давно мечтают о том, что человек только формулирует задачу, а компутер ее решает.
B>>Практически с самого появления компьютеров
В>Ну в принципе все к тому идет. Правда медленно
Нет. Это случилось в момент появления компьютеров. Человек формулирует задачу, а компьютер ее решает.
Проблема в том что сформулировать задачу так чтобы эту формулировку понял компьютер сама по себе не простая задача...
По большому счету программисты это всеголишь переводчики с человеческого языка на язык компьютера.

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

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

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

E>Значит я тебя правильно понял. И сам думаю о том же

Автор: eao197
Дата: 12.01.06

.

Дураки думают одинаково, в смысле, умные люди всегда придут к одинаковым выводам

ГВ>Я вообще всегда много смеюсь, когда читаю не "marketing requirements", а "рынок требует".

Ммм.. а почему? Поясните, может посмеемся вместе.

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

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

Решение об издании книжки будут принимать исходя из возможного тиража, который раскупят. Если на 100 программеров офисных/учетных/веб приложений приходится один научник или ядреный (от слова ядро) системщик, то какую книжку скорее издадут и раскупят? Вот, о чем я говорю.

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

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

E>Эта разница скроется, как только на DSL нужно будет не только декларации делать, но еще и какую-то логику программировать.

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

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

O>Тривиальны, говорите. Тогда ответьте на вопрос, почему программирование драйверов считается самым сложным и почему бытует мнение, что kernel mode programmers самые продвинутые и толковые.

Это возможно доказать или подтвердить чем либо?

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

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

Кё>"Крутым", "мэтры пишут на голом", "правильные пацаны", "использовать WTL и С++ уже как-то не прикольно" — ты чем там вообще занимаешься Для тебя есть ещё практически значимые различия C++/WTL и C++Builder/VCL кроме того, что на первом пишут крутые пацаны, а на втором нет?

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


O>>на С++ Builder и считал этот инструмент крутым, т.к. мог не трахать мозги с написанием GUI и одновременно использовать WinAPI, STL, COM без всяких проблем. Причем, что самое странное, программы, написанные на BCB5 и BCB6, у меня шли отлично и практически не глючили.

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

O>>Сейчас думаю положить болт на WTL и писать на голом API и чистом С, ибо использовать WTL и С++ уже как-то не прикольно. Ведь мэтры — Русинович и Рихтер — пишут на голом API, а первый даже не использует С++.

Кё>Ну так скорее начинай. Потом может на wasm.ru тебе понравится.

На мой взгляд, идеи, пропагандируемые на wasm.ru, иначе как абсурдом не назовешь. Знание
ассемблера нужно прежде всего для понимания логики работы операционки и компиляторов, а не для программирования WinGUI и COM. Для этого вполне годятся С++ и паскаль. В моих же задачах вопросы GUI не являются определяющими, так почему же не потратить лишних пару-тройку дней на создание "легковесного" продуменного GUI в стиле Русиновича и Рихтера.

Кё>Я в принципе не против, если для человека моральное удовлетворение от того, что он как настоящий хакер использовал "крутые" инструменты и справился с задачей, не даёт трезво оценить преимущества и недостатки этих инструментов и сравнить их с другими... или насколько будет реально использовать их в большем по объему проекте... А кстати кому-нибудь приходилось иметь в подчинении такого человека? Что от него ждать?

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

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

O>>Тривиальны, говорите. Тогда ответьте на вопрос, почему программирование драйверов считается самым сложным и почему бытует мнение, что kernel mode programmers самые
O>>продвинутые и толковые.

Д>Подозреваю, что такое мнение существует исключительно среди kernel mode programmers

В том то и дело, что не только среди них. Я лично знаком с одним человеком, который десять лет писал на Turbo Pascal под MSDOS и пять лет — на VC/MFC под Windows. Однако во время знакомства с ядром NT у него, как он сам выразился, первые три месяца была мысль "да как такое вообще можно писать", а окончательно освоил ядро он только спустя года полтора. Да и на любом собеседовании рейтинг соискателя резко растет, когда он владеет kernel mode programming.

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

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

Есть рынок наёмного труда. Там нужны такие-то и такие-то специалисты. Сейчас нужно много C#, Java, C++. Раньше нужно было много C, Delphi. Всё. Понты "не ширпотреб, а high tech" тут ни при чем: на работе ты выпускаешь то, что тебе скажут.

O>А визитной карточкой любого программера по давно устоявшемуся мнению является средство разработки. Так зачем же, используя "непопулярное" средство, давать повод усомниться в твоей квалификации.

Первый раз слышку такое мнение.

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

O>На мой взгляд, идеи, пропагандируемые на wasm.ru, иначе как абсурдом не назовешь. Знание
O>ассемблера нужно прежде всего для понимания логики работы операционки и компиляторов,

Это клише, неверные причём. Как ассемблер поможет тебе понять логику ОС или компилятора? Какие моменты их логики ты уже понял?

O>В моих же задачах вопросы GUI не являются определяющими, так почему же не потратить лишних пару-тройку дней на создание "легковесного" продуменного GUI в стиле Русиновича и Рихтера.

Где посмотреть на GUI Русиновича и Рихтера?

Мой мнение — ты просто не понимаешь, о чем говоришь.

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

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

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

Кё>>"Крутым", "мэтры пишут на голом", "правильные пацаны", "использовать WTL и С++ уже как-то не прикольно" — ты чем там вообще занимаешься Для тебя есть ещё практически значимые различия C++/WTL и C++Builder/VCL кроме того, что на первом пишут крутые пацаны, а на втором нет?

O>Да, различия, безспорно, есть, но вопрос не в этом. В программировании, как и в любой деятельности, есть спецы, выпускающие ширпотреб, а есть квалифицированные разработчики,
O>выпускающие high tech. А визитной карточкой любого программера по давно устоявшемуся мнению является средство разработки. Так зачем же, используя "непопулярное" средство, давать повод усомниться в твоей квалификации.

Средство становится популярным только потому что им удобнее пользоваться. И никогда средство разработки не давало повода усомниться в квалификации. Повод усомниться в квалификации только код и результат. А каким средством этого достигли-другой вопрос.

O>>>на С++ Builder и считал этот инструмент крутым, т.к. мог не трахать мозги с написанием GUI и одновременно использовать WinAPI, STL, COM без всяких проблем. Причем, что самое странное, программы, написанные на BCB5 и BCB6, у меня шли отлично и практически не глючили.


O>На мой взгляд, идеи, пропагандируемые на wasm.ru, иначе как абсурдом не назовешь. Знание
O>ассемблера нужно прежде всего для понимания логики работы операционки и компиляторов, а не для программирования WinGUI и COM. Для этого вполне годятся С++ и паскаль. В моих же задачах вопросы GUI не являются определяющими, так почему же не потратить лишних пару-тройку дней на создание "легковесного" продуменного GUI в стиле Русиновича и Рихтера.

Все GUI, которые я видел от Рихтера и Русиновича действительно можно назвать легковесными.. Но вся проблема в том, что при заказном софте надо делать богатые функционалностью GUI и что самое главное ИХ НАДО ДЕЛАТЬ БЫСТРО. И пары-тройки дней здесь просто нет. ПОтому что за пару тройку дней ВСЕ должно быть отгружено на тестирование. Бывают и такие случаи. Бывают, когда критичесике вещи приходится и на лету решать. И не позвадую я тому человеку, которые будет эти проблемы решать на чистом API.

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

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

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

Кё>Есть рынок наёмного труда. Там нужны такие-то и такие-то специалисты. Сейчас нужно много C#, Java, C++. Раньше нужно было много C, Delphi. Всё. Понты "не ширпотреб, а high tech" тут ни при чем: на работе ты выпускаешь то, что тебе скажут.

O>>А визитной карточкой любого программера по давно устоявшемуся мнению является средство разработки. Так зачем же, используя "непопулярное" средство, давать повод усомниться в твоей квалификации.

Кё>Первый раз слышку такое мнение.

Кё>Что ещё за визитные карточки ты придумал? Если что-то и годится на роль визитной карточки, так это полезные и известные проекты, которые он сделал, неважно на чём.

O>>На мой взгляд, идеи, пропагандируемые на wasm.ru, иначе как абсурдом не назовешь. Знание
O>>ассемблера нужно прежде всего для понимания логики работы операционки и компиляторов,

Кё>Это клише, неверные причём. Как ассемблер поможет тебе понять логику ОС или компилятора? Какие моменты их логики ты уже понял?

Очень многое. Как формируются таблицы GDT и прерываний, как происходит переход из реального режима процессора в защищенный, как переключаются задачи, как различаются понятия "память режима ядра" и "память режима пользователя", как работают шлюзы вызовов процедур из разных колец защиты процессора, как работают ловушки, как устроена страничная память и многое другое. Не зная ассемблера, я не вполне представлял себе, как устроены вышеприведенные механизмы. И только изучив последний, стал четко понимать, who is who and how it works.

O>>В моих же задачах вопросы GUI не являются определяющими, так почему же не потратить лишних пару-тройку дней на создание "легковесного" продуменного GUI в стиле Русиновича и Рихтера.

Кё>Где посмотреть на GUI Русиновича и Рихтера?

Кё>Мой мнение — ты просто не понимаешь, о чем говоришь.

Пардон. Такие продукты, как filemon, regmon, tokenmon и многие другие я, как говорится,
разбирал до бита, в том числе ту часть, что работает в UserMode. И не устаю поражаться, как можна создать такое, вообще не используя С++.

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

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

O>>Тривиальны, говорите. Тогда ответьте на вопрос, почему программирование драйверов считается самым сложным и почему бытует мнение, что kernel mode programmers самые продвинутые и толковые.

VD>Это возможно доказать или подтвердить чем либо?

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

Это мнение тянется ещё с тех времён, когда сложность программ мерялась операторами и тсроками кода.
Системный программист 1-3 строки в день отлаженного кода на ассемблере, а прикладной 300-400 строк.

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

O>В том то и дело, что не только среди них. Я лично знаком с одним человеком, который десять лет писал на Turbo Pascal под MSDOS и пять лет — на VC/MFC под Windows. Однако во время знакомства с ядром NT у него, как он сам выразился, первые три месяца была мысль "да как такое вообще можно писать"

Написать — ядро NT? действительно, чертовски трудно

O>, а окончательно освоил ядро он только спустя года полтора.

интересно, а что именно отняло у него столько времени?

O>Да и на любом собеседовании рейтинг соискателя резко растет, когда он владеет kernel mode programming.

ты это проверял сам хотя бы на одном собеседовании? В какой области, если проверял?

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

O>Очень многое. Как формируются таблицы GDT и прерываний, как происходит переход из реального режима процессора в защищенный, как переключаются задачи, как различаются понятия "память режима ядра" и "память режима пользователя", как работают шлюзы вызовов процедур из разных колец защиты процессора, как работают ловушки, как устроена страничная память и многое другое. Не зная ассемблера, я не вполне представлял себе, как устроены вышеприведенные механизмы. И только изучив последний, стал четко понимать, who is who and how it works.

Эээээ... А где здесь компиляторы? И это относится не только к ОС но к апаратуре. Попробуй применить свои знания под MacOS. Или под Sun. Или программировать для встраиваемых устройств. Или сигнальные процессоры. Как тебе поможеть автоматизировать большу распределенную фирму тонкое знание ядра одной системы?

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

O>>>В моих же задачах вопросы GUI не являются определяющими, так почему же не потратить лишних пару-тройку дней на создание "легковесного" продуменного GUI в стиле Русиновича и Рихтера.

O>Пардон. Такие продукты, как filemon, regmon, tokenmon и многие другие я, как говорится,
O>разбирал до бита, в том числе ту часть, что работает в UserMode. И не устаю поражаться, как можна создать такое, вообще не используя С++.

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

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

S>ГМ не дам ссылок, искать лениво,

А. Ну, тогда будем считать твои заявления на этот счет выдачей желаемого тебе за действительное.

S> но в классике считается, что чем "ниже" уровень разрабатываемого ПО, тем трудней отладка.

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

S>Это мнение тянется ещё с тех времён, когда сложность программ мерялась операторами и тсроками кода.

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

S>Системный программист 1-3 строки в день отлаженного кода на ассемблере, а прикладной 300-400 строк.

Это вообще что-то не вообразимое. За 3 строки в день надо памятник не рукотворный воздвигать. Прямо на бюсте героя.

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

ГМ, батенька моя, классиков читать надо, как бы это не Брукс приводил такую статистику, или кто-то его уровня, и не нам с Вами, ну уж точно не мне грить, что эти люди

"не умеет уважать чужой труд и опыт"

ЗЫ За отсутсвием желания искать цитаты — не вижу перспектив в дисскусии, да и не интересно это мне ж)

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

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

S>ГМ, батенька моя, классиков читать надо, как бы это не Брукс приводил такую статистику, или кто-то его уровня, и не нам с Вами, ну уж точно не мне грить, что эти люди
S>

S>"не умеет уважать чужой труд и опыт"

S>ЗЫ За отсутсвием желания искать цитаты — не вижу перспектив в дисскусии, да и не интересно это мне ж)

Это действительно Брукс приводил статистику, но не такую. Он приводил статистику к тому, что за 40 лет производительность труда среднего программиста не изменилась, как делает он свои положенные строчки кода, так и делает, ни строчкой больше( правда на мой взглчяд некоторая строчка кода на С# это несколько десяток, а то и стотен строчек кода на асьме). У Брукса нигде нельзя встретить различие программистов по тому чем они занимаются. У него программисты отличаются ролями в команде( Хирург, Помошник, Инструменталист и т.д ). У него в книге даже такого поняти как "системный" программист нету. Так что тут я думаю сцылка в небо.

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

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

S>ГМ, батенька моя, классиков читать надо, как бы это не Брукс приводил такую статистику,

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

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

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

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

Кё>>Это клише, неверные причём. Как ассемблер поможет тебе понять логику ОС или компилятора? Какие моменты их логики ты уже понял?

O>Очень многое. Как формируются таблицы GDT и прерываний, как происходит переход из реального режима процессора в защищенный, как переключаются задачи, как различаются понятия "память режима ядра" и "память режима пользователя", как работают шлюзы вызовов процедур из разных колец защиты процессора, как работают ловушки, как устроена страничная память и многое другое. Не зная ассемблера, я не вполне представлял себе, как устроены вышеприведенные механизмы. И только изучив последний, стал четко понимать, who is who and how it works.

И причём тут ассемблер? Без него всё это не понять?

Кё>>Где посмотреть на GUI Русиновича и Рихтера?

Кё>>Мой мнение — ты просто не понимаешь, о чем говоришь.

O>Пардон. Такие продукты, как filemon, regmon, tokenmon и многие другие я, как говорится,
O>разбирал до бита, в том числе ту часть, что работает в UserMode. И не устаю поражаться, как можна создать такое, вообще не используя С++.

В интерфейсе этих программ ничего нет... Чему там удивляться? Создать такое очень просто: RegisterClass, CreateWindow, DialogBox, GetMessage. Это API ОС. На С++ и всех других языках тебе пришлось бы сделать 100% то же самое, в том же самом порядке. Знание kernel mode programming тут помощи не окажет. У меня сейчас студент-практикант, который ничего подобного не знает и вообще пишет довольно ужасно выглядящий код тем не менее, успешно сделал такой интерфейс в двух программках (причём мимолетом — к интерфейсу нет ни одного требования, был бы VB, меня бы устроило). Тестовое задание на некоторые позиции С++ программистов у нас заключается в создании программы на чистом API с таким же интерфейсом; новички и опытные программеры выолпняют без затруднений. Где ты в интерфейсной части filemon чудеса программерской мысли увидел, я вообще не понимаю.

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

В>Это действительно Брукс приводил статистику, но не такую. Он приводил статистику к тому, что за 40 лет производительность труда среднего программиста не изменилась, как делает он свои положенные строчки кода, так и делает, ни строчкой больше( правда на мой взглчяд некоторая строчка кода на С# это несколько десяток, а то и стотен строчек кода на асьме). У Брукса нигде нельзя встретить различие программистов по тому чем они занимаются. У него программисты отличаются ролями в команде( Хирург, Помошник, Инструменталист и т.д ). У него в книге даже такого поняти как "системный" программист нету. Так что тут я думаю сцылка в небо.

ГМ, Вы правы, но только отчасти, Он не делит людей на системных и прикладных программистов, но:

8.8
Данные Брукса по OS/360 согласуются с данными Харра: 0,6-0,8 тысяч
строк кода на человеко-год для операционных систем и 2-3 тысячи для
компиляторов.

Цитата отсюда

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


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

Виноват однако, неправильная формулировка:

Re[4]: Программирование в режиме ядра Windows

Автор: srggal
Дата: 17.01.06

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

В свою очередь в разработку входит и отладка

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



S>

S>8.8
S>Данные Брукса по OS/360 согласуются с данными Харра: 0,6-0,8 тысяч
S>строк кода на человеко-год для операционных систем и 2-3 тысячи для
S>компиляторов.

S>Цитата отсюда

Только тут есть один на мой взгляд нюанс. В контексте разговора не говорилось о разработчиках ОС, а о "kernel mode programmer". На мой взгляд разработчик систем это горааааздо более узкая прослойка тех людей, кто имеет предтавление о ядре ОС

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

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



S>>

S>>8.8
S>>Данные Брукса по OS/360 согласуются с данными Харра: 0,6-0,8 тысяч
S>>строк кода на человеко-год для операционных систем и 2-3 тысячи для
S>>компиляторов.

S>>Цитата отсюда

В>Только тут есть один на мой взгляд нюанс. В контексте разговора не говорилось о разработчиках ОС, а о "kernel mode programmer". На мой взгляд разработчик систем это горааааздо более узкая прослойка тех людей, кто имеет предтавление о ядре ОС

Но Вы согласны с тем, что и те и другие называются системными програмистами ?

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

Т.е. ссылка не в небо ?

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


S>Но Вы согласны с тем, что и те и другие называются системными програмистами ?



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

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

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

S>

S>У Брукса нигде нельзя встретить различие программистов по тому чем они занимаются. У него программисты отличаются ролями в команде( Хирург, Помошник, Инструменталист и т.д ). У него в книге даже такого поняти как "системный" программист нету. Так что тут я думаю сцылка в небо.

S>Т.е. ссылка не в небо ?
S>

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

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


В>Только различие между ними примерно такое — первые разработаывают системы на несколько милионов строк кода, а вторые используют эти системы, реализуя как максимум несколько тысяч строк кода. Разница в масштабе и сложности системы.
+1

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

В>И знания полученные при программировании на уровне ядра никак не помогут разработать сложную распределенную систему.
-1

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

В>Не совсем согласен, на мой взгляд Брукс в данном случае говорит не о квалификации программистов а о сложности различных типов задач.
-1

Разве Сложность задач не подразумевают требования к квалификации работников решающих эти задачи ?

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

E>По поводу DSL для меня это не так однозначно. Посуди сам, языков программирования существует множество, а вот удачных среди них не так уж мало (если за степень удачности брать, хотя бы, степень известности).

Для определения степени удачности языка нужны критерии. C3 — вроде бы вполне удачный язык, но я бы ни за что не рискнул применить его, скажем, в системе аналогичной 1С для внутреннего языка. VB.Net, кстати, тоже.

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

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

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

E>Развитие DSL будет означать увеличение количества языков, но процент удачных, имхо, останется таким же.

Я вижу современный удачный DSL как слегка "обрезанный" некий заведомо удачный ЯП.

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

S>

S>ГМ не дам ссылок, искать лениво, но в классике считается, что чем "ниже" уровень разрабатываемого ПО, тем трудней разработка.

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

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

Кстати, язык 1С — это как раз клон VB.

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

VD>Это естественно, так что с такой формулировкой никто спорить не будет. Как в проче и с тем, что это только одна грань сложности. Еще бывают объемные, высоконаучные, и просто сложные для понимания человека задачи. И их решение тоже требует высоко класса специалистов. Так что разработчик дров — это проффесионал в своем деле, а разработчик компиляторов в другом. И любой из них не умнее, и не глупее какого нибудь разработчика корпоративной информационной системы. Все завист от личных качеств и желания учиться новому.
+1

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

ЗЫ Первый раз Мы с Вами хоть в чем-то сошлись во мнении

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

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

V>Я уже как-то приводил пример, что опасно на подобный прикладной уровень выносить банальный null. Вот не должно быть такой сущности в принципе. Либо надо возвращать правильное значение, либо генерировать ошибку.

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

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

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

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

E>Так в том-то и дело. Хорошо, когда созданием DSL занимается человек с опытом, четким представлением о том, что ему нужно, выработанными критериями, зравым смыслом, нюхом и, я бы сюда добавил, чувством прекрасного. Он, вероятно, сможет избежать многих просчетов на начальном этапе. Но вот, если ошибка была допущена и, к примеру, в язык внесен банальный null и на этом варианте языка будет наклепано много отлаженного кода, то изъять null из языка будет очень не просто.

E>И лично мне кажется, что если средства создания DSL станут широкодоступны, то таких детских ошибок проектирования DSL будет множество. Просто потому, что все кому не лень будут свои DSL создавать. А потом думать, нужно это было или нет

абсолютно то же самое можно сказать про любой API

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

Д>абсолютно то же самое можно сказать про любой API

Так ведь я тебе об этом уже и говорил

Автор: eao197
Дата: 12.01.06

:

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

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

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

E> а вот с параллельным использованием нескольких разных синтаксисов...
Например, в ОКамле это запросто.

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

E>> а вот с параллельным использованием нескольких разных синтаксисов...
PA>Например, в ОКамле это запросто.

Дык, в JSP страницах это то же запросто: HTML+JavaScript+Java. Только удобно ли это, и хорошо ли это -- другой вопрос.

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

E>Здравствуйте, Programmierer AG, Вы писали:

E>>> а вот с параллельным использованием нескольких разных синтаксисов...
PA>>Например, в ОКамле это запросто.

E>Дык, в JSP страницах это то же запросто: HTML+JavaScript+Java. Только удобно ли это, и хорошо ли это -- другой вопрос.

Нет, с ОКамлом хуже .
HTML+JavaScript+Java — это скорее пример связки различных языков, Java — логика, HTML+JavaScript — уровень представления, нормальная ситуация. Здесь можно еще SQL, XML и мейкфайлы вспомнить, это несколько из другой оперы.

А на ОКамле можно расширять и изменять синтаксис языка (сейчас, например, распространены 2 версии, стандартная и revised) или создавать маленькие встроенные DSL. Например,
вот здесь: http://www.cl.cam.ac.uk/users/jrh/atp/index.html, язык для записи формул мат. логики внутри программы:

let p32 = hornprove (* вот это еще обычный ОКамл, а на следующей строчке начинаются формулы *)
 <<(forall x. P(x) /\ (G(x) \/ H(x)) ==> Q(x)) /\
   (forall x. Q(x) /\ H(x) ==> J(x)) /\
   (forall x. R(x) ==> H(x)) ==>
   (forall x. P(x) /\ R(x) ==> J(x))>>;;

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

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

>>При чем ошибке в драйверах обычно "стоят" меньше, чем в заказном софте.

В смысле ошибка в драйвере стоит меньше (т.е от нее меньше проблем), чем от ошибки в заказном софте?
В QNX должно так быть, а в Win'де и IMHO в Unix'ах — это полный 3.14здец (IMHO слово как раз по случаю морадерам просьба не банить )

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

VD>Кстати, язык 1С — это как раз клон VB.

язык 1C — это клон просто понятия "скриптовый язык"... хотя, по возможностям на VBScript весьма похож

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

ГВ>>Я вообще всегда много смеюсь, когда читаю не "marketing requirements", а "рынок требует".

iT>Ммм.. а почему? Поясните, может посмеемся вместе.

Игра слов. В отрыве от контекста можно перевести как "требования маркетинга", что имеет слегка иной оттенок.

ГВ>>>Я вообще всегда много смеюсь, когда читаю не "marketing requirements", а "рынок требует".
iT>>Ммм.. а почему? Поясните, может посмеемся вместе.
V>Игра слов. В отрыве от контекста можно перевести как "требования маркетинга", что имеет слегка иной оттенок.

Непонятно. Во-первых, "marketing requirements" сложно перевести как "рынок требует"...
Во-вторых, откуда вообще тут взялись английские слова? Я их не писал.
В общем, я не понял шутки.

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

M>Это, кстати, даже для того же Офиса микросовтовского актуально. Стандартный "документооборот", что я пока видел на разных фирмах — туча расшаренных файлов на разных компьютерах (или на одном сервере) и с десяток людей, работающих с ними в режиме read-only. Причем всех надо учить, что и где лежит, а также предупреждать, что файлы не нужно стирать под страхом жизни. По меньшей мере неудобно.

У MS офиса есть SharePoint, с которым интегрированы все офисные продукты.

С Уважением, Andir!

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

ГВ>>>>Я вообще всегда много смеюсь, когда читаю не "marketing requirements", а "рынок требует".
iT>>>Ммм.. а почему? Поясните, может посмеемся вместе.
V>>Игра слов. В отрыве от контекста можно перевести как "требования маркетинга", что имеет слегка иной оттенок.

iT>Непонятно. Во-первых, "marketing requirements" сложно перевести как "рынок требует"...

В том и шютка, предполагается, что на западе говорят первое, а у нас переводят как второе

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

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

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

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

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

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

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

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

А у всех остальных, даже будь многократная разница в "мастерстве", фактическая наблюдаемая отдача отличается не так сильно (это я заодно отвечаю на твои мысли в "О жизни"). ИМХО, это происходит потому что и те и другие заняты не сильно отличающимися по сложности задачами. И я часто наблюдаю, как на этих несложных задачах "менее одаренные" личности работают гораздо эффективнее. Т.е. быстрее и качественнее. Не знакома такая ситуация? Объяснить, почему так происходит?

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

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

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

Не обязательно в науку. Есть еще Open Source

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

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

E>Не обязательно в науку. Есть еще Open Source

Если к Open Source добавить GPL и Linux, получится сектанство

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

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

E>>Не обязательно в науку. Есть еще Open Source

Кё>Если к Open Source добавить GPL и Linux, получится сектанство

Извини за резкость, но причем здесь сектантство и Linux?
Речь идет о возможности самовыражения. Представь себе человека, которому довелось поучаствовать в разработке компилятра или СУБД. Ему понравилось, сильно понравилось. Да вот только судьба распорядилась так, что приходится заниматься Web-разработкой для того, чтобы семью кормить. А хочется компиляторы делать. Что остается? Бросить все, и пытаться устроится в EDG? Или пытаться на своей работе внедрять собственные велосипеды?

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

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

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

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

+1