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

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

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

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

Спрошу прямо — проекты с драйверами были? Если нет — тогда вам меня не понять, поскольку у меня было и то, и то

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

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

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

AS>Спрошу прямо — проекты с драйверами были? Если нет — тогда вам меня не понять, поскольку у меня было и то, и >то

нет. хотя очень давно и писал под ДОС.
я не хотел ничего плохого сказать про драйверщиков — но по моему охват предметной области у таких задач довольно узкий. например вряд ли ты занимаясь драйверами столкнешься в одном проекте с хранимыми процедурами в базах, C++/COM, C#, ASP.NET и программированием мобильных телефонов до кучи. при создании корпоративных систем с чем только не приходится работать, все намешано

A>я не хотел ничего плохого сказать про драйверщиков — но по моему охват предметной области у таких задач довольно узкий. например вряд ли ты занимаясь драйверами столкнешься в одном проекте с хранимыми процедурами в базах, C++/COM, C#, ASP.NET и программированием мобильных телефонов до кучи. при создании корпоративных систем с чем только не приходится работать, все намешано

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

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

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

AS>>Спрошу прямо — проекты с драйверами были? Если нет — тогда вам меня не понять, поскольку у меня было и то, и >то

A>нет. хотя очень давно и писал под ДОС.

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

A>я не хотел ничего плохого сказать про драйверщиков — но по моему охват предметной области у таких задач довольно узкий. например вряд ли ты занимаясь драйверами столкнешься в одном проекте с хранимыми процедурами в базах, C++/COM, C#, ASP.NET и программированием мобильных телефонов до кучи. при создании корпоративных систем с чем только не приходится работать, все намешано

В общем, вам уже довольно верно ответили, но я все же напишу. Охват предметной области низкоуровневого программирования что ни на есть самый широкий, поскольку влияние драйвера может проявляется где угодно, даже в ваших любимых базах данных (там же io\net используется весьма интенсивно, или что еще интереснее — в LPC\RPC И попробовать понять, что где и как — подчас очень сложно. Необходимо разбираться во всех деталях функционирования операционной системы, прикладого ПО и т.д. и т.п — в общем то, эти вещи обычно недокументированы либо документированы так, что лучше и не надо бы совсем. Затем, драйвер _обязан_ работать абсолюбтно стабильно, быть высокопроизводительным и вопросы синхронизации тут выходят на передний план. Посему квалификация специалистов, которые пишут драйвера, обычно на порядки выше, чем общесистемных, а уж тем более тех, которые занимаются разработкой корпоративного софта или просто технологов. Заметьте, я говорю _обычно_, а не всегда. Ровно так же, как и квалификация тех, кто пишет конфиги к 1с, обычно ниже квалификации общесистемщиков. Спроектировать сложную информационную систему, как ни странно, довольно просто — есть куча паттернов, есть просто у кого спросить\почитать — обычный итерационный процесс, который ограничивается временем\желанием\средствами. Есть готовые решения и компоненты, которые можно отсмотреть, потестировать, понять. В случае же с низкоуровневым программингом этого ничего обычно нет. В общем, объяснять долго, вам все равно придется верить (или не верить) на слово. Так вот, обычно низкоуровневое программирование — это удел злых бородатых\небритых мужиков с вечно красными глазами, которые во сне видят прохождение IRP по стеку и понимают, что, где и когда он там рушит. Когда девушка говорит, что она пишет на С++ — это почти нормально, ну, бывает. Но драйвера — это сильно, на самом деле

>на есть самый широкий, поскольку влияние драйвера может проявляется где угодно, даже в ваших любимых базах данных (там же io\net >используется весьма интенсивно, или что еще интереснее — в LPC\RPC И попробовать понять, что где и как — подчас очень сложно.

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

>>на есть самый широкий, поскольку влияние драйвера может проявляется где угодно, даже в ваших любимых базах данных (там же io\net >используется весьма интенсивно, или что еще интереснее — в LPC\RPC И попробовать понять, что где и как — подчас очень сложно.

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

И это все, что вам есть ответить? Мдя, слАбо.. Впрочем, это тут оффтопик

AS>И это все, что вам есть ответить? Мдя, слАбо.. Впрочем, это тут оффтопик

с этим в священные войны. я не хочу тут эту тему развивать "кто сильнее слон или кит"

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

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

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

Пытался или ПИШЕТ? Это как бы разные понятия. Можно скомпилить пример из ДДК, и при этом говорить что пытался писать драйвер. Мы не про это речь ведем, а про разработчкиков драйверов реальных устройств. Я знаком с некоторыми, и вот что-то такого не замечал. Обычно с введением в кернел повышается общая квалификация программиста, поскольку там начинаются проблемы совсем другого порядка. В связи с этим и изменяется его собственное позиционирование. Но вот чтобы считать "круче только горы" — вам не кажется, что это как-то по-детски совсем, и напоминает замеры гениталиями в школьном туалете?

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

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

AS>Пытался или ПИШЕТ? Это как бы разные понятия.

Т.е. пока только пытался, то шансы еще есть, а если уж пишет то все?

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

Я тоже знаком. И вот, что характерно, замечаю регулярно. Тут на рсдн топиков предостаточно на эту тему, в том числе и этот.

AS> Обычно с введением в кернел повышается общая квалификация программиста, поскольку там начинаются проблемы совсем другого порядка.

Да да да. Куда там бедным прикладным программистам... Вобщем не надо сказок — в свое время мне пришлось написать несколько драйверов (успешно), никаких проблем другого порядка там нет. Они просто другие. Точно так же как в случае написания серверов приложений есть свои сложные проблемы, в GUI свои, в SQL свои и т.д.

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

Именно что напоминает.

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

AS>>Пытался или ПИШЕТ? Это как бы разные понятия.

AVK>Т.е. пока только пытался, то шансы еще есть, а если уж пишет то все?

Это вот к чему фраза? Непонятно..

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

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

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

AS>> Обычно с введением в кернел повышается общая квалификация программиста, поскольку там начинаются проблемы совсем другого порядка.

AVK>Да да да. Куда там бедным прикладным программистам... Вобщем не надо сказок — в свое время мне пришлось написать несколько драйверов (успешно), никаких проблем другого порядка там нет. Они просто другие. Точно так же как в случае написания серверов приложений есть свои сложные проблемы, в GUI свои, в SQL свои и т.д.

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

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

AVK>Именно что напоминает.



В общем, я предлагаю остаться при своих мнениях.

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

AS>Не согласен.

А тут не надо соглашаться, это факт, который можно проверить. Вот свежий пример:
Re[4]: Программирование в режиме ядра Windows

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

O>>продвинутые и толковые.

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

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

И такое, уж поверь, я встречаю на rsdn не первый раз.

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

Это не важно. Сравни: "обычно все драйверописатели ничего не умеют".

AS>Это так. Но там уровень документированности выше, есть у кого спросить, где посмотреть\почитать.

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

AS>Ошибки в драйвере стоят в сотни раз больше, чем в юзер-приложении, вы это должны понимать.

Не, непонимаю. Вот, к примеру, во что обойдется ошибка в коде сервера приложений, работающего в режиме 24х7 можно представить. А драйвера?

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

AS>Спрошу прямо — проекты с драйверами были? Если нет — тогда вам меня не понять, поскольку у меня было и то, и то

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

AS>>Спрошу прямо — проекты с драйверами были? Если нет — тогда вам меня не понять, поскольку у меня было и то, и то

Д>куда уж нам понять человека, который достиг Истинного Просветления

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

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

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

AVK>А тут не надо соглашаться, это факт, который можно проверить. Вот свежий пример:
AVK>Re[4]: Программирование в режиме ядра Windows

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

AVK>

O>>продвинутые и толковые.

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

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

AVK>И такое, уж поверь, я встречаю на rsdn не первый раз.

И с чем вы в выделенном не согласны? Кстати, что за драйвера писали вы? Если что то уровня "доступ к порту", то понятно. Если нормальный fs\фильтр драйвер — дело другое.

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

AVK>Это не важно. Сравни: "обычно все драйверописатели ничего не умеют".

Важно. Сравните "Обычно программисты 1С круче прикладных". Нормально?

AS>>Это так. Но там уровень документированности выше, есть у кого спросить, где посмотреть\почитать.

AVK> Позволю себе повториться — не суди о том, что не знаешь. И там попадаются места, которые документированны плохо.
AVK>Например VSIP.

Ключевое слово — попадаются

AS>>Ошибки в драйвере стоят в сотни раз больше, чем в юзер-приложении, вы это должны понимать.

AVK>Не, непонимаю. Вот, к примеру, во что обойдется ошибка в коде сервера приложений, работающего в режиме 24х7 можно представить. А драйвера?

Ошибка приложения:
Вывалится сервис, который перезапустится либо сам, либо вручную
Ошибка драйвера:
Зависнет система (и _все_ сервисы, которые она предоставляет, особенно круто, если это произойдет во время бэкапа), повредится fs, убьется железяка, которой он управляет и т.д и т.п.). В общем, ошибка в приложении обычно влияет только на это приложение, ошибка драйвера — обычно на систему целиком и обычно самым фатальным образом.
По-моему, это очевидно и обсуждению как бы не подлежит. В общем, далее эта ветка обсуждения для меня — RO. Удачи.

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

AS>И с чем вы в выделенном не согласны? Кстати, что за драйвера писали вы? Если что то уровня "доступ к порту", то понятно. Если нормальный fs\фильтр драйвер — дело другое.

Ну да, сценарий повторяется с точностью до слов. Ты там чего то про пенисометрию писал?

AVK>>Это не важно. Сравни: "обычно все драйверописатели ничего не умеют".

AS>Важно. Сравните "Обычно программисты 1С круче прикладных". Нормально?

Нет. А по твоему что, нормально?

AVK>> Позволю себе повториться — не суди о том, что не знаешь. И там попадаются места, которые документированны плохо.
AVK>>Например VSIP.

AS>Ключевое слово — попадаются

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

AVK>>Не, непонимаю. Вот, к примеру, во что обойдется ошибка в коде сервера приложений, работающего в режиме 24х7 можно представить. А драйвера?

AS>Ошибка приложения:
AS>Вывалится сервис, который перезапустится либо сам, либо вручную

Ага, и накроется масса транзакций.

AS>Ошибка драйвера:
AS>Зависнет система (и _все_ сервисы, которые она предоставляет, особенно круто, если это произойдет во время бэкапа), повредится fs, убьется железяка, которой он управляет и т.д и т.п.). В общем, ошибка в приложении обычно влияет только на это приложение, ошибка драйвера — обычно на систему целиком и обычно самым фатальным образом.По-моему, это очевидно и обсуждению как бы не подлежит.



AS> В общем, далее эта ветка обсуждения для меня — RO. Удачи.

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

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

AS>Офигенная шутка. Так и хочется сказать — "слив засчитан"

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

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

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

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


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

AS>PS Я свою точку зрения высказал, засим для себя эту ветку закрываю. Всем успехов.

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

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


A>а почему вы думаете что низкоуровневое программирование это высший пилотаж?


тут ничего сложного нет. Хотя, несколько рутинных моментов напрягают:

— очень муторная отладка. Часто для отладки нужно перезапускать target каждый раз. Часто при crash-ах нужно грузиться в Safe Mode и убирать свой драйвер.
— сложная синхронизация потоков. Все real-time.
— сложная security model. Твой thread работает из под разных процессов и нужно учитывать security context.
— жесткие требования на performace и stack (==12 Kb).
— плохо документированные API методы. Много reseach. Есть вообще "голые" места, только через news group. I.e Dynamic disks.
— API в kernel имеет много ограничений и исключений.
— сильная зависимость на третии компоненты и драйвера. Если вы пишете file filter driver, то нужно учитывать, что может присутствовать еще несколько фильтров, которые еще и неправильно перехватывают операции.
— лучше писать на голом С, т.к. тогда можно сделать код "paged".

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

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

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

AS>>Ошибки в драйвере стоят в сотни раз больше, чем в юзер-приложении, вы это должны понимать.
AVK>Не, непонимаю. Вот, к примеру, во что обойдется ошибка в коде сервера приложений, работающего в режиме 24х7 можно представить. А драйвера?
Смотря какой драйвер. Смотря какая система.
Не следует сравнивать стоимость ошибки в драйвере, управляющем какой-либо железкой в космической технике, со стоимостью ошибки в небольшой биллинговой системе, крутящейся в локальной сетке нескольких домов маленького района.
И наоборот, соответственно.

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

_>- лучше писать на голом С, т.к. тогда можно сделать код "paged".

Поясни?
Чем голый C лучше "одетого"?
Если точнее, то я н еопнял два момента.
1) "голый" -- это не плюсы или без библиотек?
2) что такое сделать код "paged"? Что-то типа оверлеев?

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

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

_>>- лучше писать на голом С, т.к. тогда можно сделать код "paged".

E>Поясни?
E>Чем голый C лучше "одетого"?
E>Если точнее, то я н еопнял два момента.
E>1) "голый" -- это не плюсы или без библиотек?
E>2) что такое сделать код "paged"? Что-то типа оверлеев?


есть такая "прагма"
#pragma alloc_text(PAGE, <function>)

У нее есть один большой недостаток
"The alloc_text pragma does not handle C++ member functions or overloaded functions."
т.е. для класса ее не определишь, ей extern "C" подавай.

можно почитать
здесь

E>2) что такое сделать код "paged"? Что-то типа оверлеев?
есть 2 типа памяти в kernel: paged и non-paged. paged -- Дешево, non-paged -- дорого, т.к. это обычная физическая. paged — виртуальная память и управляется memory manager-ом. non-paged память может быть accessed в любой момент, а paged только в Passive IRQL (такой уродский метод синхронизации в kernel когда блокируешь процессор для всех thread кроме своего).

Код драйвера по умолчанию находится в non-paged. Если вы знаете, что ваш код всегда passive (для очень могих случаев это справедливо), то нет смысла делать его non-paged, т.к. пустая трата ресурса. В этом случае надо объявить функции как "alloc_text(PAGE)" и писать их на "C", без плюсов. Что, естественно, напрягает.

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

для функций kernel API указывают уровень

Callers of <function> must be running at IRQL PASSIVE_LEVEL.

здесь

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

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

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

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

AVK>>Не, непонимаю. Вот, к примеру, во что обойдется ошибка в коде сервера приложений, работающего в режиме 24х7 можно представить. А драйвера?
ggg>Смотря какой драйвер. Смотря какая система.
ggg>Не следует сравнивать стоимость ошибки в драйвере, управляющем какой-либо железкой в космической технике, со стоимостью ошибки в небольшой биллинговой системе, крутящейся в локальной сетке нескольких домов маленького района.
ggg>И наоборот, соответственно.

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

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

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

Особенно хотелось бы услышать про применение фильтров ФС.

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

_>есть такая "прагма"
_>#pragma alloc_text(PAGE, <function>)

_>У нее есть один большой недостаток
_>"The alloc_text pragma does not handle C++ member functions or overloaded functions."
_>т.е. для класса ее не определишь, ей extern "C" подавай.

_>можно почитать
_>здесь

Спасибо за разъясниения.
А если попробовать в качестве <function> использовать декорированное имя?
Вторая идея более прикольная. Можно попробовать ещё и такую безумную схему:
1) слинковать всё в либу с pure C интерфейсом
2) Перелинкоать эту либу, с def-файлом, в котором все c++ входы переназначаются в какие-то pure-C имена
3) Понаписать для этих имён прагм.

Правда тогда при отладке без поллитра точно ничего не поймёшь

Кстати, ещё и такой момент, что в C++ коде много невных вызовов rt, но скорее всего это тоже обходится, если вышеперечислю трюки помогают

Но, насколько я понимаю, есть неявные вызовы и в C.
Например функция

void process(void)
{
    int array[4096] = { 0, 0 };
    process_data( array );
};

неявно позовёт memset
и даже

void process(void)
{
    int array[4096];
    get_data( array );
    process_data( array );
};

вызовет в начале себя код в rt, который обратится к каждой странице стекового фрейма.

Как решают такие проблемы? Или волшебная прагма всё побеждает сама?

_>в kernel очень много таких мелких ограничений, но сложного ничего нет. Правда, эти ограничения раздражают порой.

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

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

спасибо за советы. Я думаю, что-то можно придумать, хотя проще забить page/not page и делать все на c++. Неоптимально, но работает

E>Здравствуйте, pavel_turbin, Вы писали:
E>Но, насколько я понимаю, есть неявные вызовы и в C.
E>Например функция
E>

E>void process(void)
E>{
E>    int array[4096] = { 0, 0 };
E>    process_data( array );
E>};
E>

E>вызовет в начале себя код в rt, который обратится к каждой странице стекового фрейма.

стек ограничен 12 Kb. Если вы напишете такую конструкцию ("int array[4096]") в kernel, то очень большой риск поиметь BSOD. Хуже того, crash может и не случится пока не появится 3-ий драйвер, который работает вашем стеке, например какой-нибудь filter. Т.о. в отладке на чистой системе все работает, но иногда падает у клиентов. Вот гадость.

Для отловли таких блох нужно юзать Prefast, он измеряет стак.

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


_>стек ограничен 12 Kb. Если вы напишете такую конструкцию ("int array[4096]") в kernel, то очень большой риск поиметь BSOD. Хуже того, crash может и не случится пока не появится 3-ий драйвер, который работает вашем стеке, например какой-нибудь filter. Т.о. в отладке на чистой системе все работает, но иногда падает у клиентов. Вот гадость.

_>Для отловли таких блох нужно юзать Prefast, он измеряет стак.

А других таких неявных вызовов rt не бывает что ли?

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


_>>Для отловли таких блох нужно юзать Prefast, он измеряет стак.

E>А других таких неявных вызовов rt не бывает что ли?

теоритически недолжно быть. На стеке объекты не создают. Вообще в kernel-e поменьше всего нужно использовать никогда не знаешь как это аукнится.

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


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

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

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

AVK> в которых очередной "профессионал" драйверостроения начинает доказывать насколько он крут и насколько все остальные лохи. От прикладников такое если и бывает слышно, то значительно реже.
Но ведь дыма без огня не бывает, так? Вот некоторые наблюдения.
1) В большинстве случаев в компаниях, специализирующихся на системном программировании, больше порядка, чем в каких-нибудь прикладных ERP, игроделанье или вебе.
Можно внедрить (за откат?) полуглючную ERP-систему, худо бедно она будет работать (ну наймут побольше персонала в крайнем случае). Деньги получены. Все.
Можно по-быстрому написать дешевую игрушку (для гопников?), которую "пипл схавает" (если в ней будет, к примеру, много голых девок и музыка группы Ленинград). Деньги заработаны, прибыль получена. Все.
А вот с системным программированием так не прокатит — ни разу не слышал о понятиях "драйвер-трэшак", "драйвер для быдла", "откат за внедрение драйвера".
Лохами я никого не обзываю, просто системные вещи — это _другая_ _область_, где все по определению более грамотно должно быть, иначе совсем ничего не выйдет.


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

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

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

AVK>> в которых очередной "профессионал" драйверостроения начинает доказывать насколько он крут и насколько все остальные лохи. От прикладников такое если и бывает слышно, то значительно реже.
ggg>Но ведь дыма без огня не бывает, так? Вот некоторые наблюдения.
ggg>1) В большинстве случаев в компаниях, специализирующихся на системном программировании, больше порядка, чем в каких-нибудь прикладных ERP, игроделанье или вебе.

Факты в студию. Я такой зависимости не наблюдал.

ggg>Лохами я никого не обзываю, просто системные вещи — это _другая_ _область_, где все по определению более грамотно должно быть,

Определение в студию.

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

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

ggg>3) "Цена вхождения" в системное программирование выше.

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

ggg> Человеку с хорошим базовым (лишь базовым) уровнем программирования потребуется гораздо больше времени на разбор DDK и написание хоть как-то работающего драйвера, чем на изучение J2EE, например

Очень сомнительное утверждение, без каких либо доказательств.

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

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

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

AVK>Очень сомнительное утверждение, без каких либо доказательств.
Самое смешное, что косяки в драйверах вовсе не так редки, как об этом хотят думать некоторые. Иначе чем объяснить основную отмазку производителей железа "скачайте последние драйвера". Или косяки в драйверах S3 от того, что драйвера писать — это вышшый пилотаж, а косяки в ERP — от того, что программеры тупые?

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

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

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


Это одно из того, что относится к "не только"

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

N>Это одно из того, что относится к "не только"

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

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

AVK>Обойтись. Неоднократно наблюдал, когда люди просто правили примеры из DDK под собственные нужды. Большого ума для этого не надо.
Я еще раз говорю — речь о компаниях, специализирующихся именно на системном программировании (RTSoft, auriga, SWD (swd.ru)). Там примеры из DDK под собственные нужды не правят.

AVK>точно так же нахрапом нельзя ни сервер приложений написать, ни пакет расширения к VS, ни еще кучу других вещей.
Недавно на rsdn была ссылка на тему "в биллинге от CBOSS не используются внешние ключи и что-то там еще". Т.е. получается, можно написать немалую биллинговую систему (и она вполне себе работала!), игнорируя теорию и принципы СУБД.
Написать серьезный драйвер, игнорируя основные принципы, невозможно.


ggg>>3) "Цена вхождения" в системное программирование выше.
AVK>А цена вхождения в проектирование больших приложений еще выше.
А я говорю именно о программировании.
В проектирование без серьезного опыта программирования я бы никого не допускал.
Раз уж сказали про проектирование: прикладная область допускает существование "кодеров" (или программистов, кодирующих по ТЗ, которое им кто-то составил). В драйверах часто это не так — толпы кодеров с начальными знаниями вы там не найдете.

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

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

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

AVK>>Факты в студию. Я такой зависимости не наблюдал.
ggg>Вот примеры "трэшовых"(рассказ самих разработчиков) и "откатных" ("черные внедрения") проектов из прикладных областей.
ggg>Обратите внимание, речь идет о крупных серьезных компаниях.

Это ничего не доказывает. Я могу привести обратных примеров массу. Например Microsoft.

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

А что такое "системное программирование"?

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

А чего так? Чем драйвера на коленке отличаются от прикладного софта на коленке? Халтура, она везде халтура, вне зависимости от конкретной области.

AVK>>Обойтись. Неоднократно наблюдал, когда люди просто правили примеры из DDK под собственные нужды. Большого ума для этого не надо.
ggg>Я еще раз говорю — речь о компаниях, специализирующихся именно на системном программировании (RTSoft, auriga, SWD (swd.ru)). Там примеры из DDK под собственные нужды не правят.

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

AVK>>точно так же нахрапом нельзя ни сервер приложений написать, ни пакет расширения к VS, ни еще кучу других вещей.
ggg>Недавно на rsdn была ссылка на тему "в биллинге от CBOSS не используются внешние ключи и что-то там еще". Т.е. получается, можно написать немалую биллинговую систему (и она вполне себе работала!), игнорируя теорию и принципы СУБД.

Ну и что? Иногда это оправдано.

ggg>Написать серьезный драйвер, игнорируя основные принципы, невозможно.

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

AVK>>А цена вхождения в проектирование больших приложений еще выше.
ggg>А я говорю именно о программировании.

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

ggg>В проектирование без серьезного опыта программирования я бы никого не допускал.

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

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

Да есть там все. Сам лично наблюдал.

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

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

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

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

AVK>Ну так тогда и бери в качестве сравнения компании, профессионально занимающиеся разработкой софта — Microsoft, Sun etc.
А с Microsoft и Sun надо бы сравнить QNX, а не swd.ru


AVK>А то здорово получается — сравнивать конторы в соседней подворотне с ведущими компаниями страны. Так можно много чего доказать.
Где это я говорил о "подворотне", или по твоему CBoss и крупнейшие внедренцы ERP в России — это "конторы в соседней подворотне"?

AVK>с ведущими компаниями страны.
А профессиональной разработкой драйверов и не будут в "подворотнях" заниматься.

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


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


ggg>>Раз уж сказали про проектирование: прикладная область допускает существование "кодеров" (или программистов, кодирующих по ТЗ, которое им кто-то составил). В драйверах часто это не так — толпы кодеров с начальными знаниями вы там не найдете.
AVK>Да есть там все. Сам лично наблюдал.
Это те студенты, которые примеры из ДДК под свои нужны правили? В "конторе в соседней подворотне"?



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

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

ggg>А вот с системным программированием так не прокатит — ни разу не слышал о понятиях "драйвер-трэшак", "драйвер для быдла", "откат за внедрение драйвера".


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


ggg>Лохами я никого не обзываю, просто системные вещи — это _другая_ _область_, где все по определению более грамотно должно быть, иначе совсем ничего не выйдет.

И это тоже тем же авторам


ggg>3) "Цена вхождения" в системное программирование выше. Человеку с хорошим базовым (лишь базовым) уровнем программирования потребуется гораздо больше времени на разбор DDK и написание хоть как-то работающего драйвера, чем на изучение J2EE, например, и написание хоть как-то работающего приложения.

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

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

ggg>А меня удивляет, что, например, в этом треде много людей, "пробовавших и писавших успешные драйверы", перешли вдруг в прикладную область. При этом утверждая, что "драйверы — это ничего особенно". Зарплаты программистов-драйверистов повыше будут (примеры компаний я приводил). Что ж вы побросали-то "возню с ядром"?

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

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

AVK>>Ну так тогда и бери в качестве сравнения компании, профессионально занимающиеся разработкой софта — Microsoft, Sun etc.
ggg>А с Microsoft и Sun надо бы сравнить QNX, а не swd.ru

Ну сравни.

AVK>>А то здорово получается — сравнивать конторы в соседней подворотне с ведущими компаниями страны. Так можно много чего доказать.
ggg>Где это я говорил о "подворотне", или по твоему CBoss и крупнейшие внедренцы ERP в России — это "конторы в соседней подворотне"?

CBOSS то? Еще хуже. Только это к предметной области имеет слабое отношение.

AVK>>с ведущими компаниями страны.
ggg>А профессиональной разработкой драйверов и не будут в "подворотнях" заниматься.

О как, профессиональной. Ну так и профессиональной разработкой прикладного софта там тоже заниматься не будут.

AVK>>То какие то истории про внедренцев приводишь, то рассказываешь про архитектурные косяки биллинга от CBOSS.
ggg>Ты сам просил факты о том, что в прикладной области больше мусорных и трешовых проектов (даже в крупных компаниях) — я их привел.

Не, я другое просил. Я просил доказательство твоим словам:

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

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

ggg> Подобных проектов от крупных компаний, разрабатывающих системный софт, я не знаю.

Ну тогда и не делай столь далеко идущих выводов, они неверные.

AVK>>Драйверы, они всегда игнорируют основные принципы архитектуры ПО ввиду сильных технических ограничений. Так что на эту тему я бы не заикался.
ggg>"Основные принципы архитекутры ПО" неконкретно, можно многое тут наговорить.

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

ggg> А конкретные принципы работы ядра — совсем другое дело.

Другое это какое? И, заметь, я ведь не о построении ядра говорил, а о построении драйверов.

AVK>>Да есть там все. Сам лично наблюдал.
ggg>Это те студенты, которые примеры из ДДК под свои нужны правили?

Сначала примеры правили, потом сами стали писать.

ggg> В "конторе в соседней подворотне"?

Нет, контора была довольно серьезной, заказ военным.

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

А что тут такого?

ggg> При этом утверждая, что "драйверы — это ничего особенно".

Представь себе да.

ggg> Зарплаты программистов-драйверистов повыше будут (примеры компаний я приводил).

А примеры зарплат?

ggg> Что ж вы побросали-то "возню с ядром"?

Спроса нет на такое.

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

AFAIK ты сейчас занимаешься разработкой ERP системы под .NET. Давай-ка мы её скачаем (дай линк) и дружно посмотрим, на паттерны, архитектуру и прочее обилие умностей, который были выше по треду.

P.S.: Вы за 10 лет научились хоть Ораклиные связанные переменные нормально использовать ? Дельфевые билды полуторалетной давности этого не делают, а их исходники это просто нечто!!! Мы иногда в них заглядываем, когда встречаем очередной глюк

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

IID>AFAIK ты сейчас занимаешься разработкой ERP системы под .NET.

Я много чем занимаюсь.

IID> Давай-ка мы её скачаем (дай линк) и дружно посмотрим, на паттерны, архитектуру и прочее обилие умностей, который были выше по треду.

Не скачаете по причине того, что она не готова для публичного показа.

IID>P.S.: Вы за 10 лет научились хоть Ораклиные связанные переменные нормально использовать ? Дельфевые билды полуторалетной давности этого не делают, а их исходники это просто нечто!!! Мы иногда в них заглядываем, когда встречаем очередной глюк

К чему это хамство?

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

IID>>P.S.: Вы за 10 лет научились хоть Ораклиные связанные переменные нормально использовать ? Дельфевые билды полуторалетной давности этого не делают, а их исходники это просто нечто!!! Мы иногда в них заглядываем, когда встречаем очередной глюк

AVK>К чему это хамство?

Разве это хамство ? Всего лишь константация фактов. Читаем тут

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

AVK>>К чему это хамство?

IID>Разве это хамство ? Всего лишь константация фактов. Читаем тут

Какое отношение имеет Парус 8 ко мне? Я этот продукт не разрабатывал, не разрабатываю и разрабатывать не буду.

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

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

AVK>>>К чему это хамство?

IID>>Разве это хамство ? Всего лишь константация фактов. Читаем тут

AVK>Какое отношение имеет Парус 8 ко мне? Я этот продукт не разрабатывал, не разрабатываю и разрабатывать не буду.

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

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

AVK>>Какое отношение имеет Парус 8 ко мне? Я этот продукт не разрабатывал, не разрабатываю и разрабатывать не буду.

IID>Ну ты лично может и не разрабатываешь, но контора твоя разрабатывает.

Однако ты на меня персонально наехал.

IID> И это отличный пример отвратительного качества прикладного софта, программисты которого не потрудились изучить принципы работы БД, на которой основан продукт.

И что это доказывает? Неужели что все прикладные программисты лохи?

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

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

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

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

AVK>>>Какое отношение имеет Парус 8 ко мне? Я этот продукт не разрабатывал, не разрабатываю и разрабатывать не буду.

IID>>Ну ты лично может и не разрабатываешь, но контора твоя разрабатывает.

AVK>Однако ты на меня персонально наехал.

IID>> И это отличный пример отвратительного качества прикладного софта, программисты которого не потрудились изучить принципы работы БД, на которой основан продукт.

AVK>И что это доказывает? Неужели что все прикладные программисты лохи?

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

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

Вывод какой ? Изделия фирмы ПАРУС приравниваем изделиям Хунь Тань и все довольны ?

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

IID>Вывод какой? Изделия фирмы ПАРУС приравниваем изделиям Хунь Тань и все довольны?

А при чем здесь изделия фирмы Парус? Речь то не об этом.

>Erop Ты это расскажи, например, авторам драйверов к тайваньским сканерам.

Многие драйверы сканеров (под винду) — не kernel mode. Драйверы сканеров в Linux — вне ядра, по сути это аналог "драйвера для доступа к параллельному порту". Данная ветка же началась с обиды на пост

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

Ну сколько можно повторять, что магическое слово "драйвер" может означать все что угодно ?!


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

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

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

Однако во время знакомства с ядром NT у него, как он сам выразился, первые три месяца была мысль "да как такое вообще можно писать", а окончательно освоил ядро он только спустя года полтора. Да и на любом собеседовании рейтинг соискателя резко растет, когда он владеет kernel mode programming

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

>AVK А примеры зарплат?
Я ж давал ссылки на компании. Там есть открытые вакансии (как в Москве, Питере, так и Казани). В Москве там зарплаты для программиста-специалиста — от 2К у.е. в месяц.
>AVK Спроса нет на такое.
Почему ты откровенную неправду говоришь?! Упомянутые мной компании набирают людей, и открывают программистские центры не только в Москве и Питере, но и некоторых других российских городах.
В Москве и Питере даже в вузы приходят, отбирают группы студентов (интересующихся), занятия проводят, чтобы потом на работу шли к ним.

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

>AVK А при чем здесь изделия фирмы Парус? Речь то не об этом.
Речь о том, что какую бы прикладную разработку в этой теме не затронули, ты говоришь либо "это контора из подворотни", либо "а в драйверах китайца тоже глюки". Тогда уж приводи конкретные примеры (хотя бы три-четыре, как я выше приводил)
1) прикладных проектов, где грамотно использованы все "паттерны", "принципы из книжки ..." и прочие
2) конкретные примеры российских компаний (а не абстрактные плевки в сторону Тайваня или Китая), где ужасно поставлена разработка серьезных системных вещей (драйверов файловых систем или сложных железок — не сканеров, разумеется).

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

IID>ак раз то, о чём говорил AndrewS выше по ветке — драйверист так бы не лажанулся.

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

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


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

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

Эээ, народ, это очередной "Visual Basic/C# vs C/C++". На самом деле всё зависит от задачи. Драйверописание это отдельный раздел программирования и часть кодинговая может быть немного сложнее (Win32Api же сложнее чем .NET). Что не делает драйверописание в целом сложнее чем написание более высокоуровневых приложений за счёт смещения акцента на бизнес-логике.
Иллюстрируя, прикладник более близок к сложностям реального мира чем системщик а системщик, в свою очередь, более близок к сложностям низкоуровневого программирования. Тут следовало бы нарисовать диаграмму но мне лень

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

ЗЫ. Я сам не понял что я написал .

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

>>AVK Не надо даже далеко в облака залетать, открой Гамму и Ко
ggg>Назови хотя бы четыре крупные (российские, известные, чтобы проверить легко было) компании, где это правильно и разумно используется.

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

>>AVK И, заметь, я ведь не о построении ядра говорил, а о построении драйверов.
ggg>Тебя же обидел вот этот пост (см. начало темы). Здесь именно о ядре (и о соответствующих драйверах в режиме ядра).

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

ggg>Почему ты откровенную неправду говоришь?!

Потому что это правда.

>>AVK Тут кривых драйвером примеров приводилась масса.
ggg>Не заметил ни одного _конкретного_ примера.

Драйвера S3 до самого конца. Драйвера nVidia времен Riva128, драйвера Voodoo, драйвера 100Мбит сетевух на DECовском чипе, драйвера звуковых карт Creative, референсные драйвера тюнеров Philips. Это то, что сразу вспомнил.

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

Это хорошая демонстрация того, что дело не в драйверах, а в людях.

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

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

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

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

ggg>>Почему ты откровенную неправду говоришь?!
AVK>Потому что это правда.
Из серии "Я так сказал", да? Теперь перечитайте, пожалуйста, мои примеры (о спросе на работников в упомянутых компаниях) и дайте более развёрнутое обоснование.

AVK>Драйвера S3 до самого конца. Драйвера nVidia времен Riva128, драйвера Voodoo, драйвера 100Мбит сетевух на DECовском чипе, драйвера звуковых карт Creative, референсные драйвера тюнеров Philips. Это то, что сразу вспомнил.
Ага, это все российские компании, занимающиеся системным программированием.

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

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

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

AVK>> Парус. По крайней мере в нашем отделе.
ggg>Только один отдел в одной компании Парус? А остальные, надо полагать, "подворотня"?

Не знаю. Тебе одного мало?

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

На примере Паруса видно, что качество конкретного отдела никак не зависит от другого отдела.

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

О как интересно, уже системное ПО. А что такое системное ПО?

ggg>>>Почему ты откровенную неправду говоришь?!
AVK>>Потому что это правда.
ggg>Из серии "Я так сказал", да?

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

ggg> Теперь перечитайте, пожалуйста, мои примеры (о спросе на работников в упомянутых компаниях) и дайте более развёрнутое обоснование.

Могу как ты.
Ага, это все российские компании, занимающиеся прикладным программированием.

AVK>>Драйвера S3 до самого конца. Драйвера nVidia времен Riva128, драйвера Voodoo, драйвера 100Мбит сетевух на DECовском чипе, драйвера звуковых карт Creative, референсные драйвера тюнеров Philips. Это то, что сразу вспомнил.
ggg>) Ага, это все российские компании, занимающиеся системным программированием.

А я просто не знаю ни одного известного софта или железки с российскими драйверами. Ах да, знаю — AVP Monitor и Dr.Web Spaider, при установке которых перестает работать половина софта
Хотя, впрочем, чего это я. Получается что особым талантом отличаются исключительно российские драйверописатели. Я правильно понял?

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

А без хамства?

ggg>Да, и обратите внимание на логическую ошибку. Из того, что какой-то системщик — сноб (по вашему мнению), не следует, что все системщики снобы.

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

ggg> Равно как и то, что снобизм данного системщика (или всех) вытекает из области его деятельности.

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

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

C>Эээ, народ, это очередной "Visual Basic/C# vs C/C++". На самом деле всё зависит от задачи. Драйверописание это отдельный раздел программирования и часть кодинговая может быть немного сложнее (Win32Api же сложнее чем .NET). Что не делает драйверописание в целом сложнее чем написание более высокоуровневых приложений за счёт смещения акцента на бизнес-логике.

ИМХО это очевидно, что не мешает отдельным представителям быть с этим активно несогласными.

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

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

C>>Эээ, народ, это очередной "Visual Basic/C# vs C/C++". На самом деле всё зависит от задачи. Драйверописание это отдельный раздел программирования и часть кодинговая может быть немного сложнее (Win32Api же сложнее чем .NET). Что не делает драйверописание в целом сложнее чем написание более высокоуровневых приложений за счёт смещения акцента на бизнес-логике.

AVK>ИМХО это очевидно, что не мешает отдельным представителям быть с этим активно несогласными.

Это проходит

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

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

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

Может, это твое болезненное восприятие, а?

AVK>А что такое системное ПО?
Тебе трудно сходить на сайты названных мной компаний?

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

>AVK Спроса нет на такое.
Почему ты откровенную неправду говоришь?! Упомянутые мной компании набирают людей, и открывают программистские центры не только в Москве и Питере, но и некоторых других российских городах [Казани хотя бы].
В Москве и Питере даже в вузы приходят, отбирают группы студентов (интересующихся), занятия проводят, чтобы потом на работу шли к ним.

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

Если ты не обращаешь внимание на примеры, то нафиг мне их писать, я и промолчать могу. А ты продолжай кричать о "снобизме драйверистов" и об "отсутствии спроса на знания ядра". Глядишь, те, кто 10 лет назад пробовали писать на asm под DOS (а потом сравнивают это с kernel mode programming), с тобой согласятся.

AVK>Могу как ты.
Видимо, не можешь. Сказать "драйвер вешает пол-системы" — это уровень домохозяйки. Если уж рассуждаешь об ошибках, кидай ссылки на конкретные описания конкретных ошибок (как тебе делали в случае с недостатками и ошибками в прикладном ПО).

AVK>Хотя, впрочем, чего это я. Получается что особым талантом отличаются исключительно российские драйверописатели. Я правильно понял?
Я просто знаю, как организована разработка в некоторых российских компаниях. Как организована разработка в Philips или NVidia — не знаю.

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

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


Chipset> Это проходит
Ага, с высоты лет виднее

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

AVK>>О как интересно, уже системное ПО.
ggg>Да, ты сам о нем с первой страницы говоришь.

Ссылку, плиз.

ggg>Кстати, кому ни показывал этот тред, никто не заметил понтов и снобизма в цитате, на которую ты обиделся

А показывал исключительно своим коллегам?

ggg>Может, это твое болезненное восприятие, а?

Оскорбления — признак того, что аргументы кончились.

AVK>>А что такое системное ПО?
ggg>Тебе трудно сходить на сайты названных мной компаний?

И что я там должен увидеть?

ggg>И после этого ты все равно мне говоришь, что "спроса на такое нет".

Если сравнивать со спросом на все остальное — нет.

ggg>Если ты не обращаешь внимание на примеры, то нафиг мне их писать, я и промолчать могу. А ты продолжай кричать о "снобизме драйверистов" и об "отсутствии спроса на знания ядра". Глядишь, те, кто 10 лет назад пробовали писать на asm под DOS (а потом сравнивают это с kernel mode programming), с тобой согласятся.

Ну да, куда уж нам, сирым.

AVK>>Могу как ты.
ggg>Видимо, не можешь. Сказать "драйвер вешает пол-системы" — это уровень домохозяйки. Если уж рассуждаешь об ошибках, кидай ссылки на конкретные описания конкретных ошибок (как тебе делали в случае с недостатками и ошибками в прикладном ПО).

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

AVK>>Хотя, впрочем, чего это я. Получается что особым талантом отличаются исключительно российские драйверописатели. Я правильно понял?
ggg>Я просто знаю, как организована разработка в некоторых российских компаниях. Как организована разработка в Philips или NVidia — не знаю.

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

AVK>>А я этого и не утверждал. Я всего лишь сказал что среди драйверописателей их значительно больше среднего. Сей топик служит лучшим доказательством.
ggg>Не служит.

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

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

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

ggg>Яркий пример: ты находишься в святом заблуждении, что "спрос на ковыряние в ядре отстутствует" — и даже не прочитал примеры про вакансии и зарплаты!

У нас форум есть с предложениями о работе. По нему можно неплохо составить примерную картину рынка труда IT.

ggg>Chipset> Это проходит
ggg>Ага, с высоты лет виднее

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

Гы-Гы-Гы!
Ты с чем не согласен-то? С китайскими драйверами?
Так я тоже с нимим не согласен,а куда деваться-то?

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


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

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

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

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

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

а что тогда понимается под "специальными знаниями"? Знания API и особенностей реализации, что ли?

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

>>>AVK Не надо даже далеко в облака залетать, открой Гамму и Ко
ggg>>Назови хотя бы четыре крупные (российские, известные, чтобы проверить легко было) компании, где это правильно и разумно используется.

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

А это как-то неприлично поинтересоваться где они работают?

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

I>А это как-то неприлично поинтересоваться где они работают?

Почему? Прилично. Просто неинтересно.

E>Гы-Гы-Гы!
E>Ты с чем не согласен-то?
Неужели мое объяснение (пост 04.02.06 15:22) не понятно?


E>С китайскими драйверами?
С твоим примером про драйверы сканеров в теме, спровоцированной цитатой о "kernel mode programming".

ggg>>Да, ты сам о нем с первой страницы говоришь.
AVK>Ссылку, плиз.
В четвертый раз привести цитату с первой страницы, которая тебя обидела? Мне тяжело общаться с человеком, для которого слова "драйвер сканера" и "kernel mode" стоят на одном уровне.

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


AVK>Если сравнивать со спросом на все остальное — нет.
О, ты опять сравниваешь со всем остальным — то есть с "подворотнями", внедренцами ERP за откат, баблорубами из Паруса (ссылку про "пипл хавает" тебе IID приводил) и прочим мусором? А если сравнивать только положительные примеры российских работодателей — что-то с твоей стороны не видно конкретных примеров.


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

AVK>Я больше ориентируюсь на молодежь, которая этот топик читает.
Та молодежь (если и забредет сюда в Священные войны с какого-нибудь qnx.org.ru), которая понимает разницу между "драйвер сканера", "пытался писать драйвер" и "kernel mode programming", хотя бы посмотрит на мои примеры положительных работодателей — auriga, swd (www.swd.ru), rtsoft.
И даже та молодежь, для которой слова "kernel mode" мало что пока значат, но есть интерес, увидит, что те же компании согласны обучать студентов (например, в Москве)

Та молодежь, которая интересуется прикладными вещами, она что узнает из темы? Где примеры положительных работодателей — отдел, в котором работает AVK и который еще ничего не выпустил?



AVK>У нас форум есть с предложениями о работе. По нему можно неплохо составить примерную картину рынка труда IT.
RSDN — ресурс скорее для прикладников. Что хорошо видно хотя бы из тематических форумов (людей, знающих .NET тут гораздо больше, чем знающих QNX например). И составлять по такому форуму картину рынка труда IT — однобоко. Если бы ты хотя бы по headhunter'у судил о рынке, я бы, может, промолчал.
Работодатель скорее поместит вакансию по СРВ на qnx.org.ru, чем на RSDN, где многие смутно представляют разницу между "пытаться писать драйвер сканера" и "kernel mode".
И еще — если человек интересуется QNX, он хотя бы краем уха слышал об swd (или в крайнем случае о том, что где-то в Питере есть компания, занимающаяся подобными вещами). И он будет искать (самые нормальные) вакансии именно там, на сайте. Кстати, QNX популярен в России, и есть не только в Питере и Москве.
Не следует преувеличивать значение RSDN

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

ggg> Мне тяжело общаться с человеком, для которого слова "драйвер сканера" и "kernel mode" стоят на одном уровне.

Ссылку в студию, где я говорил, что это одно и то же.

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

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

AVK>>Если сравнивать со спросом на все остальное — нет.
ggg>О, ты опять сравниваешь со всем остальным — то есть с "подворотнями", внедренцами ERP за откат, баблорубами из Паруса (ссылку про "пипл хавает" тебе IID приводил) и прочим мусором?

Ты сам то этот Парус видел? Или тебе все равно, лишь бы тебе выгодно было?

ggg> А если сравнивать только положительные примеры российских работодателей — что-то с твоей стороны не видно конкретных примеров.

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

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

Почему не выпустил? Выпустил. Например Web-интерфейс к конструктору отраслевых решений. Только тебе это все равно ни о чем не скажет.

AVK>>У нас форум есть с предложениями о работе. По нему можно неплохо составить примерную картину рынка труда IT.
ggg>RSDN — ресурс скорее для прикладников. Что хорошо видно хотя бы из тематических форумов (людей, знающих .NET тут гораздо больше, чем знающих QNX например).

А их вобще больше. И прикладников вобще больше, чем этих самых kernel mode.

ggg>Не следует преувеличивать значение RSDN

Да здравствует QNX

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

S>Самое смешное, что косяки в драйверах вовсе не так редки, как об этом хотят думать некоторые. Иначе чем объяснить основную отмазку производителей железа "скачайте последние драйвера". Или косяки в драйверах S3 от того, что драйвера писать — это вышшый пилотаж, а косяки в ERP — от того, что программеры тупые?

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

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

ggg>Почему-то мне не составило труда назвать несколько российских компаний, на хорошем уровне занимающихся системным софтом.

О прикладниках...

1С
Abbyy
JetBrains

Это с ходу, только про тех кто на слуху.

ggg>2) конкретные примеры российских компаний (а не абстрактные плевки в сторону Тайваня или Китая), где ужасно поставлена разработка серьезных системных вещей (драйверов файловых систем или сложных железок — не сканеров, разумеется).

А почему собственно не сканеров?
Приобретателю такой техники пофигу, kernel mode или не kernel.

Корявых драйверов несть числа. Чистая правда там написана.

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

C>Эээ, народ, это очередной "Visual Basic/C# vs C/C++". На самом деле всё зависит от задачи. Драйверописание это отдельный раздел программирования и часть кодинговая может быть немного сложнее (Win32Api же сложнее чем .NET). Что не делает драйверописание в целом сложнее чем написание более высокоуровневых приложений за счёт смещения акцента на бизнес-логике.

Win32Api в ядре? Мдя...

D>О прикладниках...

D>1С
Слишком много разных направлений (от игр до бухгалтерии, да и в самой бухгалтерии куча всего разного). Не все одинаково хорошо.
D>Abbyy
Поиск на RSDN выдает не самые приятные факты.
А по поводу вакансий
Программист C++ в Abbyy, опыт работы 1-3 года &mdash; до 900 дол.
Это считается хорошим для прикладников?

На том же сайте вакансия Junior Developer (опыт программирования на C от 1 года;
опыт или теоретические знания в области ядра UNIX/Linux и написания драйверов) — до 1500.

Щас придет Andrew VK и скажет, что это системщикам за "снобизм" и "понты" доплачивают


D>А почему собственно не сканеров?
D>Приобретателю такой техники пофигу, kernel mode или не kernel.
Эта ветка вызвана утверждениями типа

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

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

Еще Andrew S говорил (а потом я повторял), что не надо цепляться к слову "драйвер": они разные, и знания, необходимые для их создания, — совершенно разные по объему.

Если что то уровня "доступ к порту", то понятно. Если нормальный fs\фильтр драйвер — дело другое. (c) Andrew S

.

Здравствуйте, Дарней, Вы писали:
Д>Ну а про такую "мелочь", что время от времени эти дрова убивали всю систему, я и упоминать не буду
У Эриксона вообще надо уволить нахрен весь отдел по разработке для PC. Я не так уж много софта от них встречал, но то что видел — катастрофический отстой. При этом параноидальное нежелание открывать API... Явно этим рулит кто-то фантастически некомпетентный. Я бы на их месте открыл API и дал волунтирам возможность написать хоть что-то рабочее. Кстати, никто не в курсе — у них сейчас хотя бы сами телефоны юзабельные стали? В старых моделях (которые еще просто ериксон, без сони) сделано столько юзабилити ляпов, что по ним просто лекции можно читать.

Здравствуйте, ggg.

Сразу скажу, что я не собираюсь участвовать в перепалке "kernel mode/user mode". С моей точки зрения, подобное разделение нерелевантно. Есть люди, пишущие ответственные части системы(неважно, в Ring0 оно работает или нет) и есть люди, пишущие остальное.

Просто вы хотели примеры успешных прикладных компаний, AVK не привёл примеров. Я только "исправил" ситуацию

D>>1С
ggg>Слишком много разных направлений (от игр до бухгалтерии, да и в самой бухгалтерии куча всего разного). Не все одинаково хорошо.
D>>Abbyy
ggg>Поиск на RSDN выдает не самые приятные факты.
ggg>А по поводу вакансий
ggg>Программист C++ в Abbyy, опыт работы 1-3 года &mdash; до 900 дол.
ggg>Это считается хорошим для прикладников?

Немного о деньгах. Можно писать ядро файнридера, а можно GUI для Lingvo. Согласитесь, эти задачи требуют "немножко" разных навыков и квалификации. На ядро файнридера [сразу] никто людей искать на headhunter не будет.
У меня работает знакомый в Abbyy, так вот он не производит впечатления низкооплачиваемого человека.
Кроме того, никто не будет писать "потолок". Я какое-то время занимался собеседованием приходящих людей в одной фирме.. так вот, это представить невозможно, насколько странные люди приходят порой.

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

D>>А почему собственно не сканеров?
D>>Приобретателю такой техники пофигу, kernel mode или не kernel.
ggg>Эта ветка вызвана утверждениями типа
ggg>

ggg>Обычно с введением в кернел повышается общая квалификация программиста, поскольку там начинаются проблемы совсем другого порядка.

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

Я уж позанудствую, извините..

Ветка видимо отделена от какой-то другой, так что сейчас оценить сложно.
Но первое сообщение этой темы:

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

D>Сразу скажу, что я не собираюсь участвовать в перепалке "kernel mode/user mode".
Да, пожалуй закругляться пора (уже по кругу разгворы идут).

D>Сразу скажу, что я не собираюсь участвовать в перепалке "kernel mode/user mode". С моей точки зрения, подобное разделение нерелевантно. Есть люди, пишущие ответственные части системы(неважно, в Ring0 оно работает или нет) и есть люди, пишущие остальное.
D>Просто вы хотели примеры успешных прикладных компаний, AVK не привёл примеров. Я только "исправил" ситуацию
С выделенным полностью соглашусь.
Только добавлю, что задач по ответственным частям системы в низкоуровневых компаниях (хотя бы из примеров выше) побольше, чем в прикладных (хотя бы из вашего примера). В Абби фактически 2 основных проекта (лингво и файнридер), и ответственные части — это получается, движок лингво и файнридера.
Условно считаем, что, к примеру, для драйвера ФС нужна серьезная квалификация, и для движка файнридера — тоже. Но проектов, уровня ФС драйвера, в одной компании, спец-ся на системном ПО, — много, и число растет. Поэтому и процент сотрудников, делающих ответственные части, — выше.
Плюс в Абби ответственные задачи "разбавляются" написанием того же GUI для Лингво.

D>Немного о деньгах. Можно писать ядро файнридера, а можно GUI для Lingvo. Согласитесь, эти задачи требуют "немножко" разных навыков и квалификации. На ядро файнридера [сразу] никто людей искать на headhunter не будет.
D>У меня работает знакомый в Abbyy, так вот он не производит впечатления низкооплачиваемого человека.
D>Кроме того, никто не будет писать "потолок". Я какое-то время занимался собеседованием приходящих людей в одной фирме.. так вот, это представить невозможно, насколько странные люди приходят порой.
Ну, ваши рассуждения справедливы и для второй вакансии из моего поста выше — на linux embedded начинающему тоже не будут сразу доверять многое, и не будут по максимуму платить, и также не напишут "потолок". Я поэтому и привел "начальные вакансии", для сравнения.
Ну и AVK говорил, что "спроса нет на ковыряние в ядре". Я лишь говорю: есть. Просто про прикладные 1С, Абби, СБосс и т.д. слышали многие, а вот про системные компании просто разговоров мало, вот и думают некоторые, что спросу нет.

D>Возвращаясь немного выше по сообщению, к теме разделения на ответственные и остальные части системы. Согласитесь, что требования к надёжности движка той же платформы 1С или движка файнридера вряд ли ниже, чем к драйверам.
Я полностью согласен, что для написания движка файнридера, например, нужна серьезная квалификация. Не ниже (а может, и выше), чем для kernel mode драйвера. Но — какой процент прикладных разработчиков работает над такими задачами? Согласно моим наблюдениям (у меня из бывших однокурсников шли в Abbyy работать) — этот процент (людей, работающих над такими серьезными задачами) в прикладной области пониже, чем в системной. Задач для малоквалифицированных работников в той же Abbyy немало (вы к ним GUI для Лингво вроде бы отнесли). И далеко не каждый начинающий в Abbyy дойдет до уровня "движка файнридера" (просто людей столько на движок не нужно).


D>Я уж позанудствую, извините..

D>Ветка видимо отделена от какой-то другой, так что сейчас оценить сложно.
D>Но первое сообщение этой темы:
D>

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

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

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

S>У Эриксона вообще надо уволить нахрен весь отдел по разработке для PC. Я не так уж много софта от них встречал, но то что видел — катастрофический отстой. При этом параноидальное нежелание открывать API... Явно этим рулит кто-то фантастически некомпетентный. Я бы на их месте открыл API и дал волунтирам возможность написать хоть что-то рабочее. Кстати, никто не в курсе — у них сейчас хотя бы сами телефоны юзабельные стали? В старых моделях (которые еще просто ериксон, без сони) сделано столько юзабилити ляпов, что по ним просто лекции можно читать.

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

Здравствуйте, Дарней, Вы писали:
Д>телефоны у них сейчас вполне приличные, в отличие от софта. Хотя у других сотовых компаний софт ничем не лучше.
Д>Во всяком случае, это касается того софта, который я видел лично. Может быть, кому то и довелось видеть "синюю птицу" — нормального качества софт для телефонов
Я у эриков две вещи больше всего "люблю":
1. В списке разговоров прокрутка имя-номер-время автоматическая. Умрешь дожидаться, когда оно соизволит тебе все это показать. Почему нельзя было сделать это по навигационным кнопкам — убей не понимаю.
2. В списке разговоров время показывается только для сегодняшних вызовов. Убил бы нафиг. В десять минут первого ночи уже невозможно понять, когда тебе звонили — только что или сутки назад.

Они это исправили наконец?

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

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

S>Они это исправили наконец?

п.2 исправили, как говорят
насчет первого не знаю

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

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

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

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

AVK>Почему не выпустил? Выпустил. Например Web-интерфейс к конструктору отраслевых решений. Только тебе это все равно ни о чем не скажет.

А можно ссылку на анонс (или демку где скачать)? Хотелось бы сравнить с 1с-овским веб-решением.

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

I>А можно ссылку на анонс (или демку где скачать)? Хотелось бы сравнить с 1с-овским веб-решением.

ХЗ, я этим не занимаюсь. Знаю что точно есть на диске, который Парус распространяет среди своих партнеров.

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

S>У Эриксона вообще надо уволить нахрен весь отдел по разработке для PC.

Я бы обобщил данный вывод на всех производителей мобилок.

Здравствуйте, AndrewVK, Вы писали:
S>>У Эриксона вообще надо уволить нахрен весь отдел по разработке для PC.
AVK>Я бы обобщил данный вывод на всех производителей мобилок.
Кстати, у меня есть гнусное подозрение, что весь этот доп.софт был как раз саутсорсен в страны третьего мира, как нестратегический. Хотя... такое г могут и свои написать.

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

AVK>>точно так же нахрапом нельзя ни сервер приложений написать, ни пакет расширения к VS, ни еще кучу других вещей.
ggg>Недавно на rsdn была ссылка на тему "в биллинге от CBOSS не используются внешние ключи и что-то там еще". Т.е. получается, можно написать немалую биллинговую систему (и она вполне себе работала!), игнорируя теорию и принципы СУБД.
ggg>Написать серьезный драйвер, игнорируя основные принципы, невозможно.

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

P.S. Мысли вслух. На рынке полно работоспособных с виду драйверов, и нет ни одной приличной биллинговой системы. К чему бы это...

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

G>P.S. Мысли вслух. На рынке полно работоспособных с виду драйверов, и нет ни одной приличной биллинговой системы. К чему бы это...

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

P.S. Hello world!!!

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

A>>по моему спроектировать распределенную ОО-систему, скажем для управления тех.процессом на предпрятии, намного сложнее.

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

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

а ты отвечаешь "все работы хороши — выбирай на вкус", т.е. не в кассу

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

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

ggg>3) "Цена вхождения" в системное программирование выше. Человеку с хорошим базовым (лишь базовым) уровнем программирования потребуется гораздо больше времени на разбор DDK и написание хоть как-то работающего драйвера, чем на изучение J2EE, например, и написание хоть как-то работающего приложения.

Ну да, мне 1С-ники тоже рассказывали, что фигли там ваши java и c#, "цена вхождения в 1С" куда выше. И в чем-то были правы. Потому что 1с-никам нужно уметь не столько программировать, сколько отлично знать бухгалтерию, учет, и т.п.(иногда эти знания лучше, чем у бухов и руководителей предприятий, куда это все внедряется).
Вобщем, каждый свое болото хвалит.
А на деле получается, как уже говорили, сравнение кто сильнее: слон или кит. Потому как сравнить можно что-то четко измеримое. Понятие "крутость программиста" не есть измеримое.

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


AVK>Драйвера S3 до самого конца. Драйвера nVidia времен Riva128, драйвера Voodoo, драйвера 100Мбит сетевух на DECовском чипе, драйвера звуковых карт Creative, референсные драйвера тюнеров Philips. Это то, что сразу вспомнил.

Драйвера безпроводных сетевух D-Link(регулярный BSOD на всех машинах, пока не поставили обновленные дрова из инета).
Первые драйвера для телефона Samsung D600(как раз в то время, когда они только появились, и еще рекламировались на каждом углу) это та еще сказка (по мотивам фильма ужасов).

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

E__>Первые драйвера для телефона Samsung D600(как раз в то время, когда они только появились, и еще рекламировались на каждом углу) это та еще сказка (по мотивам фильма ужасов).

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

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

Д>телефоны у них сейчас вполне приличные, в отличие от софта. Хотя у других сотовых компаний софт ничем не лучше.

Какое-то время спустя... Их телефоны действительно многие хвалят. Лично я их софт не видел. Не довелось пользоваться их продукцией.

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

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

Ай какая радость. Я вот DDK MVP, и ни разу в такой славной нитке не поучаствовал

Несколько соображений.

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

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

Несложно догадаться, что между этими двумя классами задач есть принципиальная разница, даже на уровне руководства проектами (о чем и писал Гапертон), не говоря уж о технических уровнях.

Разница эта приводит, например, вот к чему: в "прикладных" проектах действительно применим паттерн "1 умный архитектор — орава посредственных кодеров". Там реально ниже требования к профессионализму программиста. Там устроят посредственности. Продукт все равно будет работать, и работать удовлетворительно. Вон тут жаловались, что у CBOSS нету декларативных внешних ключей. И чего? плохо работает? а почему-то МТС на нем жил долгое время. Региональные мобильные провайдеры по сей день живут.

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

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

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

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

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

Ну вот пример. В 90ые годы писали на таких языках, как Клиппер и Кларион — помните такие? на них решали реальные задачи для реальных бизнесов, года с 91 была написана немеряна куча самописок на Клиппере для автоматизации совершенно реальных потребностей достаточно серьезных организаций — участки финансового учета, кадровый учет, кажется, старая версия Паруса (1994) тоже на Клиппере была написана. Технологии реально и успешно использовались, и жили до массового перехода на SQL и сервера баз данных, который произошел во второй половине 90х — 95-00 есть довольно точная временная оценка этого перехода в московском ИТ. Короче — реальные тулы для реальных задач.

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

А PowerBuilder? а на Access что-то тоже программировали? а FoxPro? вот это все семейство одного уровня. Кто-то лучше поддерживает SQL, кто-то хуже, но философия у них у всех примерно одинакова. "Потащи Data Control мышкой, положи на форму".

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

Сравним разработку складского учета на Клиппере и разработку сервера приложений на COM и ATL. Кому-то приходилось делать и то, и другое? При разработке на COM/C++/ATL возникает ощущение эдакого создания своей ручной работы, хотя там и есть стандарные кубики типа _com_ptr_t и классов ATL. А на датабазных тулах того поколения? сборка мозаики из стандарных кубиков. Стандартная и туповатая. Разница примерно та же, что между художником (пусть и художником-оформителем вывесок) и маляром.

Это я вот к чему. Старик Маслоу сказал, что у нормальной личности (ну пусть относительно нормальной) есть тенденция к саморазвитию. Есть тенденция ставить себе challenges и их решать.

Вырасти из клиппериста в Си++ника — это таки challenge, ибо разница между двумя языками — примерно такая же, как между вступительными задачками по математике на мехмат МГУ и в борисоглебский (городок такой рядом с Урюпинском есть) пед.

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

Но мне очевидно, что математики на мехмате МГУ — это качественно иной уровень.

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

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

Вот это и есть разница между рядовым (не-руководящим) системным программистом и рядовым программистом-прикладником.

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

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

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

В сторону: я вот предвижу, придет сейчас сюда ПиЭм или тимлид из какого-нить Сибосса и скажет "да что этот Линукс, фигня это все, несерьезно, вот бизнес-приложения — другое дело!". Или произнесет еще какую заяву из серии "умное не востребовано на рынке".

Вот у меня при таких выступлениях (обычно ими занимаются люди, которые, возможно, толковые администраторы и управленцы, но никогда не были хорошими программистами) возникает ассоциация с бригадиром грузчиков или там прапорщиком, который орет на тему "да хули они там на своем мехмате МГУ фигней маются! вот чугуний таскать — это да, Дело!". И действительно дело. И чугуний народу нужен, и дело это для настоящих мужиков. Только вот _разницы в уровнях мехматянина и профессионального таскателя чугуния_ это не отменяет. Хотя да, мехматянин мог до поступления и чугуний потаскать — в армии, например.

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

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

Какие у нас еще есть пути самореализации умных прикладников? Два назову с ходу просто по материалам этого форума.

Во-первых, это погружение в детали и нюансы конкретных _тулов_. Не _платформ_, а _тулов_. Разница очевидна — для успешной работы с платформой нужно знать почти все ее нюансы, а для успешной работы с тулом совсем не обязательно знать все его возможности. 20% зачастую хватит. Зачем открывать все лезвия в ноже Victorinox, если задача — карандаш наточить?

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

Потому лично мне такая возможность тула просто не интересна. Я знаю саму концепцию RTTI. Я знаю, что она полезна дай бог в 5% задач. И я знаю, что, если мне она будет действительно нужна, я ее сляпаю за 10 минут на макросе типа MFCшного DECLARE_DYNAMIC, и сделаю это без багов (делов-то). При этом я буду иметь контроль над имплементацией, а не полагаться на компилятор, и смогу сделать такой class object, какой нужен мне под конкретную задачу, а не какой нужен Страуструпу в его башне из слоновой кости.

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

Сидим как-то с коллегой с бывшей работы (великолепный Си++ник и архитектор) на одной из Платформ, слушаем бессмертное выступление Шатохина, который "потерял здоровье от Джавы" . После выступления со всех сторон пошли ремарки типа "а вы пользуетесь ABC? нет, XYZ намного лучше!". Я прослушал это несколько минут и говорю коллеге — "смотри. Здесь почти все обсуждение идет — о _тулах_. Тут обсуждают не задачи и методы их решения, а кто с каким тулом игрался". Коллега согласился.

Интеллектуальна ли такая деятельность? да. Бесспорно. Головоломки с темплейтами тройного уровня вложения — не сразу поддаются решению. Это вполне достойный полет интеллекта.

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

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

Так же злом является использование наворочанных узкоспециальных фич не по делу. RTTI не по делу (пиши полиморфно!). Лямбды не по делу (лямбды полезны в узких конкретных случаях), и прочее такое.

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

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

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

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

Но вспомним, что написано в книгах. Просмотрел по диагонали этот знаменитый текст про 10 главных паттернов — и понял, как персонаж Мольера, что я всю жизнь говорил прозой что все это я давно знаю и пользуюсь каждый день, что, например, паттерн визитора — это и до боли известный IPersistStream::Save(IStream*), и IoSetCompletionRoutine, где нижележащий драйвер "посещается" completion contextом через адаптер под названием IRP, и прочее такое. Эти паттерны (не поименованные) есть еще в книжке VAX/VMS Internals, про ОС 70х годов.

Все это и так понятно. Оттого, что я назову это "паттерн визитора", суть не изменится, как не изменится и решение задачи.

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

Я больше скажу. Не думаю, что Пушкин или Байрон знали, что такое аблаут

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

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

Еще один путь профессионального саморазвития девелопера — это уход в управленцы. Или вообще смена рода деятельности.

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

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

Я не буду говорить, что драйверист (да а почему только драйверист? мало серьезных задач, не ляпаемых из стандартных кубиков, и не представляющих собой кучу мелких скриптиков для SQL Server или для IE/Мозиллы?) обязательно превосходит архитектора-прикладника интеллектуально и круче него только горы. Я буду говорить, что по степени интеллектуальности эти виды деятельности примерно одинаковы, при этом у драйвериста интеллект идет прямо в лоб на достижение цели. Более "целеположенная" работа. Кому-то это нравится, кому-то это кажется занудным. Тут уже дело вкуса.

Здравствуйте, Maxim S. Shatskih, Вы писали:

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

MSS>При разработке на COM/C++/ATL возникает ощущение эдакого создания своей ручной работы, хотя там и есть стандарные кубики типа _com_ptr_t и классов ATL.
Это не кирпичики, а костыли нужные исключительно из-за убогости С++.

MSS>Ну или — нахрена лямбды? сложно дать этому куску кода какое-то имя, и сделать из него просто функцию? читабельнее будет. Значительно.
Это ты так говоришь исключительно по тому что не понимаешь ФВП(функции высшего порядка).
А пользоваться ими без полноценных замыканий почти не возможно.

MSS>Интеллектуальна ли такая деятельность? да. Бесспорно. Головоломки с темплейтами тройного уровня вложения — не сразу поддаются решению. Это вполне достойный полет интеллекта.
Только совершенно бесполезный.
Те абсолютно.

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

MSS>Так же злом является использование наворочанных узкоспециальных фич не по делу. RTTI не по делу (пиши полиморфно!).
Не всегда возможно.

MSS>Лямбды не по делу (лямбды полезны в узких конкретных случаях), и прочее такое.
Гы! Утверждение типа:

Циклы не по делу (циклы полезны в узких конкретных случаях), и прочее такое.

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

MSS>- уход в высокие эмпиреи чистой архитектуры-по-книжке — тоже достойное для интеллекта занятие.
Паттерны это отходы жизнедейтельности архитекторов. (С) вродбе Гапертон

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

MSS>>Ну или — нахрена лямбды? сложно дать этому куску кода какое-то имя, и сделать из него просто функцию? читабельнее будет. Значительно.
WH>Это ты так говоришь исключительно по тому что не понимаешь ФВП(функции высшего порядка).
WH>А пользоваться ими без полноценных замыканий почти не возможно.

А почему замыкание не может иметь имя?
Вот по языкам, с которыми приходилось часто сталкиваться:
— C (gcc'шные расширения): есть вложенные функции, которые могут быть переданы по указателю куда-то наружу, при этом создаётся "трамплин" (trampoline), добавляющий заданный при его создании аргумент. (Иногда ещё такое средство называется thunk.)
— Perl: единственный вариант создать замыкание — определить функцию внутри создающей, которая захватит значение переменной на момент её создания.
— Python: есть и lambda, и вариант создания вложенной функции. В обоих случаях, опять же, происходит создание ссылки на переменную со значением в момент создания.

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

На самом деле имя замыкания сильно полезно для учёта (раскрутка стека, etc.) Я не поддерживаю заявление, что так "значительно читабельнее" — случаи бывают разные — но польза таки есть.

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

N>- C (gcc'шные расширения):
Для полноценных замыканий нужен ГЦ. В С у нас уже появился ГЦ?

N>- Perl:
N>- Python:
Языки мутанты.

N>На самом деле имя замыкания сильно полезно для учёта (раскрутка стека, etc.) Я не поддерживаю заявление, что так "значительно читабельнее" — случаи бывают разные — но польза таки есть.
Практика работы на немерле показывает что именованные локальные функции засовывают в ФВП в двух случаях:
1)Много кода.
2)По ходу дела кусок кода используется несколько раз.
А заводить целую функцию ради выражения a + b когда можно написать (a, b) => a + b ИМХО маразм.

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

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

N>>- C (gcc'шные расширения):
WH>Для полноценных замыканий нужен ГЦ. В С у нас уже появился ГЦ?

Нет, там ограничение, что такой трамплин живёт столько, сколько живёт породившая его внешняя функция. Тем не менее это даёт возможность делать свои специфические callback'и с полным контекстом. Я от Си в принципе большего тут и не жду. Конечно, в общем случае хотелось бы ещё и библиотечку создания трамплинов собственными силами (чтобы не зависеть от жизненного цикла фрейма), но обычно можно и без этого обойтись.

N>>- Perl:
N>>- Python:
WH>Языки мутанты.

Вот так вот — одним ярлыком срезали два утверждения:) Да, полемический приём знатный, уважаю. А по сути? (Я уж не говорю, что эти "мутанты" дают работу и удовлетворённых пользователей мне и ещё массе знакомых)

N>>На самом деле имя замыкания сильно полезно для учёта (раскрутка стека, etc.) Я не поддерживаю заявление, что так "значительно читабельнее" — случаи бывают разные — но польза таки есть.
WH>Практика работы на немерле показывает что именованные локальные функции засовывают в ФВП в двух случаях:
WH>1)Много кода.
WH>2)По ходу дела кусок кода используется несколько раз.
WH>А заводить целую функцию ради выражения a + b когда можно написать (a, b) => a + b ИМХО маразм.

Ну так и в "мутантном", по-Вашему, питоне я могу написать

lambda a,b: a+b

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

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

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

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

N>Ну так и в "мутантном", по-Вашему, питоне я могу написать

lambda a,b: a+b

в таком же месте. Но как Вы потом будете разбираться, например, откуда появилась эта функция? А если она прошла по ссылке через десяток других функций, затем была вставлена в ещё парочку замыканий? Если у неё есть имя — оно будет напечатано (не знаю как в Nemerle, но в питоне — точно), с точностью до модуля и собственно функции. Для поиска это полезно. А у Вас?
N>Будете весь код грепать?
1)Отладчик еще никто не отменял.
2)Данный сценарий случается мягко говоря не часто.
Ибо далеко таскать функцию както не часто приходится. В основном получается что-то типа list.Map(x => x.SomeProp);

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

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

N>>Нет, там ограничение, что такой трамплин живёт столько, сколько живёт породившая его внешняя функция. Тем не менее это даёт возможность делать свои специфические callback'и с полным контекстом. Я от Си в принципе большего тут и не жду. Конечно, в общем случае хотелось бы ещё и библиотечку создания трамплинов собственными силами (чтобы не зависеть от жизненного цикла фрейма), но обычно можно и без этого обойтись.
WH>Это все очень убого.

Безусловно, по сравнению с ФЯ — убого. Но я не жду большего от переносимого ассемблера.

N>>Вот так вот — одним ярлыком срезали два утверждения:) Да, полемический приём знатный, уважаю. А по сути? (Я уж не говорю, что эти "мутанты" дают работу и удовлетворённых пользователей мне и ещё массе знакомых)
WH>Ну что поделать если авторы этих языков тащат туда что попало.

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

N>>Ну так и в "мутантном", по-Вашему, питоне я могу написать

lambda a,b: a+b

в таком же месте. Но как Вы потом будете разбираться, например, откуда появилась эта функция? А если она прошла по ссылке через десяток других функций, затем была вставлена в ещё парочку замыканий? Если у неё есть имя — оно будет напечатано (не знаю как в Nemerle, но в питоне — точно), с точностью до модуля и собственно функции. Для поиска это полезно. А у Вас?
N>>Будете весь код грепать?
WH>1)Отладчик еще никто не отменял.

Отладчик? Издеваетесь?;( У меня потоки в сотни сообщений, требующих сложной и тяжёлой обработки, в секунду.
Даже слово "отладчик" тут запрещено.

WH>2)Данный сценарий случается мягко говоря не часто.
WH>Ибо далеко таскать функцию както не часто приходится. В основном получается что-то типа list.Map(x => x.SomeProp);

Кому как. Мне приходится и "далеко" таскать функцию. Типичный вариант — callback таймера.

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

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

N>Отладчик? Издеваетесь?;( У меня потоки в сотни сообщений, требующих сложной и тяжёлой обработки, в секунду.
N>Даже слово "отладчик" тут запрещено.
Сотни сообщений в секунду на питоне?! Да вы батенька редкостный извращенец.

N>Кому как. Мне приходится и "далеко" таскать функцию. Типичный вариант — callback таймера.
А причем тут тамер? Изначально речь шла о ФВП. Не забыл?

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

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

N>>Я, конечно, понимаю, что секция форума обязывает пофлеймить без обоснований, но меня сейчас интересует именно практический результат. По которому мне питон важнее видимого только в этом форуме Nemerle:))
WH>Это дело времени. Питон сильно старше.

... и жизненная среда у него шире. Nemerle не для .NET уже есть?

N>>Отладчик? Издеваетесь?;( У меня потоки в сотни сообщений, требующих сложной и тяжёлой обработки, в секунду.
N>>Даже слово "отладчик" тут запрещено.
WH>Сотни сообщений в секунду на питоне?! Да вы батенька редкостный извращенец. :)))

Это не я.:)

N>>Кому как. Мне приходится и "далеко" таскать функцию. Типичный вариант — callback таймера.
WH>А причем тут тамер?

А почему бы и нет?

WH>Изначально речь шла о ФВП. Не забыл?

Не забыл. Но — тем более.

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


N>- Perl: единственный вариант создать замыкание — определить функцию внутри создающей, которая захватит значение переменной на момент её создания.

[...]

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

Справедливости ради. В perl'е можно писать:

sub makeclosure {
    my $arg = shift;
    return sub { print $arg; }
}

Т.е. именовать совсем не обязательно.

Hi WolfHound

N>>Отладчик? Издеваетесь?;( У меня потоки в сотни сообщений, требующих сложной и тяжёлой обработки, в секунду.
N>>Даже слово "отладчик" тут запрещено.
WH>Сотни сообщений в секунду на питоне?! Да вы батенька редкостный извращенец.

А что здесь такого извращенного? Если инструмент позволяет обрабатывать данные с такой скоростью, то почему не надо (нельзя) его использовать?


--
С Уважением

A>а почему вы думаете что низкоуровневое программирование это высший пилотаж?
A>все драйверщики так думают.

Правильно, это _низший_ пилотаж! Опасный бреющий полёт, а не витание в облаках.

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

I>Правильно, это _низший_ пилотаж! Опасный бреющий полёт, а не витание в облаках.

Ага. На собранном вручную "кукурузнике", с навигацией по компасу и карте.

I>>Правильно, это _низший_ пилотаж! Опасный бреющий полёт, а не витание в облаках.

AF>Ага. На собранном вручную "кукурузнике", с навигацией по компасу и карте.

Ну правильно. Вождение багги, тем более гонки на них — это существенно иная задача по сравнению с вождением Газели или тем более Лансера.

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

N>>Отладчик? Издеваетесь?;( У меня потоки в сотни сообщений, требующих сложной и тяжёлой обработки, в секунду.
N>>Даже слово "отладчик" тут запрещено.
WH>Сотни сообщений в секунду на питоне?! Да вы батенька редкостный извращенец.
Знаю, что у одного из наших заказчиков есть система учета движения товаров, написаная на Питоне и работающая с десятками запросов в секунду на стареньком сервере с PIII.

Почему бы, собственно, и нет? 3D-моделер на Питоне же есть

C>Знаю, что у одного из наших заказчиков есть система учета движения товаров, написаная на Питоне и работающая с десятками запросов в секунду на стареньком сервере с PIII.

А кто-то мерил скорость Питона по сравнению с Перлом, PHP, VBScript?

У Перла скорость — отличная, у VBScript — хорошая, у PHP — дрянная.