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

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

S>>>[/list]
RUB>>я есть,
RUB>>диплом на С# писал ))

А>А оверквотингом вас не учили заниматься?
А что такого, если нет опытных разработчиков,
я предлагаю себя, а ваше дело отказаться
P.S кто не стучится, тому не открывают ))

Hello, Spidola!
You wrote on Tue, 29 Jun 2004 09:19:22 GMT:

S> P.S. Полагаю, что пока вы Кнута с Фаулером читаете там на вас штат
S> разработчиков горбится. А иначе зачем вы кому нужны с Кнутом и Фаулером
S> то?

".. нам думать некогда — нам работать надо..." (с)Не мой

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

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

так что :
".. нам думать некогда — нам хук на мышку вешать надо..." (с)мой

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

ST>Hello, Spidola!
ST>You wrote on Tue, 29 Jun 2004 09:24:54 GMT:

S>> Гуру в команде должен быть один, от силы 2 (на большую команду). Хирург,
S>> так называемый. Остальные разработчики должны быть прикладниками. вот с
S>> ними-то и проблема — все мечтают в гуру вылезти. Это как с певцами -
S>> нужен хор, а на пороге сплошные Киркоровы

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

ST>вот и вся арифметика

ST>если хватает на одного — содержите одного, на 2-х — содержите 2-х
ST>если можете себе позволить — просто платите всем нормально

Категорически не согласен иметь нескольких гуру. Толку от них никакого. Одного на 10 человек вполне достаточно, чтобы решать технические проблемы. И нет никакой беды в том, что человек не является гуру. Это, часто, одинокие и замкнутые на работе люди. А работать нужно для того, чтобы жить, а не наоборот...

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

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

ST>Hello, Spidola!
ST>You wrote on Tue, 29 Jun 2004 09:19:22 GMT:

S>> P.S. Полагаю, что пока вы Кнута с Фаулером читаете там на вас штат
S>> разработчиков горбится. А иначе зачем вы кому нужны с Кнутом и Фаулером
S>> то?

ST>".. нам думать некогда — нам работать надо..." (с)Не мой

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

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

ST>так что :
ST>".. нам думать некогда — нам хук на мышку вешать надо..." (с)мой

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

А про хук — так это правильно — надо вешать, пока конкуренты не повесили... Вы как думаете — сотовым телефонам встроенные фотоаппараты нужны? Однако вон все начали встраивать...

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

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

Hello, Spidola!
You wrote on Tue, 29 Jun 2004 11:01:38 GMT:

S> Есть время думать, а есть время реализовывать то, что придумал. Если всё
S> время думать, то с голоду помрёшь. Производство оно и есть производство.
S> Не путайте дизайнеров и архитекторов с программистами и кодировщиками. У
S> них задачи разные.

это в вашем процессе производства есть разделение на архитекторов, програмиистов..., где-то его нет и это тоже правильно

кстати, архитекторы и программисты должны говорить на одном языке именно для этого и существуют книжки фаулера&Co

S> А про хук — так это правильно — надо вешать, пока конкуренты не
S> повесили... Вы как думаете — сотовым телефонам встроенные фотоаппараты
S> нужны? Однако вон все начали встраивать...

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

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

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

S> Короче говоря — конкретные умения, если они как раз и требуются, это
S> хорошо, а не плохо.

эти умения приобретаются за 15 минут в msdn а потом забываются так же просто
(я например уже не помню зачем надо было делать out 20h,20h)

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


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

Хм. Как связано создание своих framework-ов с разработкой компиляторов ?
Для компиляторов уже придумано полно тулов как свободных, так и коммерческих. Изобретать велосипед не нужно.

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

ST>кстати, архитекторы и программисты должны говорить на одном языке именно для этого и существуют книжки фаулера&Co

Ничего не имею против этих замечательных книжек. Тем более если их ещё на практике применять. Реплика была не об этом.

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

ST>не надо ему доказывать, а надо осознать, что он прав, что на клавиатуре удобнее работать

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

S>> Короче говоря — конкретные умения, если они как раз и требуются, это
S>> хорошо, а не плохо.

ST>эти умения приобретаются за 15 минут в msdn а потом забываются так же просто
ST>(я например уже не помню зачем надо было делать out 20h,20h)

Под умениями я понимаю не конкретную строчку восстановления PIC после аппаратного прерывания (слава богу в современном прикладном программировании всё несколько попроще ), а, например, опыт расположения контролов на форме таким образом, чтобы людям было удобно и понятно.

Hello, Spidola!
You wrote on Tue, 29 Jun 2004 12:21:43 GMT:

ST>> не надо ему доказывать, а надо осознать, что он прав, что на
ST>> клавиатуре удобнее работать

S> Я так понял, это ирония? Если да, то смею заверить, что на клавиатуре
S> часто удобнее. Многие досовские приложения до сих пор в почёте засчёт
S> того, что можно на клавиатуре работать. Вы, например, на почту зайдите и
S> загляните в экранчик... В вебе это очень проблематично.

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

А между досом и клавиатурой видимо связь такая же как между виндосом и клавиатурой (они соотносятся как средство пользовательского ввода и ОС).

S>>> Короче говоря — конкретные умения, если они как раз и требуются, это
S>>> хорошо, а не плохо.

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

ST>> эти умения приобретаются за 15 минут в msdn а потом забываются так же
ST>> просто (я например уже не помню зачем надо было делать out 20h,20h)

S> Под умениями я понимаю не конкретную строчку восстановления PIC после
S> аппаратного прерывания (слава богу в современном прикладном
S> программировании всё несколько попроще ), а, например, опыт
S> расположения контролов на форме таким образом, чтобы людям было удобно и
S> понятно.

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

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

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

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

ST>А между досом и клавиатурой видимо связь такая же как между виндосом и клавиатурой (они соотносятся как средство пользовательского ввода и ОС).

Я сейчас объясню просто... Дело в том, что часто пользователи нашего приложения СТОЯТ за столом, а не сидят, а стоя мышкой возить очень неудобно — нужно либо иметь гибкость как у Алины Кабаевой, либо клиенту показывать хорошенький зад, сгибаясь к столу И это ещё не самая большая проблема

S>>>> Короче говоря — конкретные умения, если они как раз и требуются, это
S>>>> хорошо, а не плохо.


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

ST>Как я понимаю, мысль была в том, что нужно много прикладных программистов и меньше системных.
ST>Просто почему-то системных назвали "гуру", хотя можно быть гуру и в юзабилити и в прикладном программировании. Так ?

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

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

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

Уф.

Ну а если я не прав — старгие товарищи меня поправят

Hello, Spidola!
You wrote on Tue, 29 Jun 2004 13:03:27 GMT:

ST>> А между досом и клавиатурой видимо связь такая же как между виндосом и
ST>> клавиатурой (они соотносятся как средство пользовательского ввода и
ST>> ОС).

S> Я сейчас объясню просто... Дело в том, что часто пользователи
S> нашего приложения СТОЯТ за столом, а не сидят, а стоя мышкой возить
S> очень неудобно — нужно либо иметь гибкость как у Алины Кабаевой, либо
S> клиенту показывать хорошенький зад, сгибаясь к столу И это ещё не
S> самая большая проблема

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

ST>> Как я понимаю, мысль была в том, что нужно много прикладных
ST>> программистов и меньше системных. Просто почему-то системных назвали
ST>> "гуру", хотя можно быть гуру и в юзабилити и в прикладном
ST>> программировании. Так ?

S> Ну не совсем так, но близко. Чтобы не запутаться в терминах (в разных
S> книжках одни и те же термины трактуются по разному, к сожалению),
S> поясню, что я имел ввиду под гуру (правда придётся пойти поперёк пути
S> старика Окама введя новый термин). Под "гуру" я понимал так называемого
S> программиста — "этюдника", который блестяще может выполнить практически
S> любую задачу, но только один раз, поскольку второй раз ему такую же
S> задачу делать неинтересно. вот, например, "этюдник" может написать
S> чудесный компонент, которым потом будут пользоваться 100 человек. Однако
S> быть одним из этих 100 человек ему уже неинтересно.

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

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

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

S> Уф.

S> Ну а если я не прав — старгие товарищи меня поправят

With best regards, sts. E-mail: stsvetkov@bitec.ru

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


ST>>> Как я понимаю, мысль была в том, что нужно много прикладных
ST>>> программистов и меньше системных. Просто почему-то системных назвали
ST>>> "гуру", хотя можно быть гуру и в юзабилити и в прикладном
ST>>> программировании. Так ?

S>> Ну не совсем так, но близко. Чтобы не запутаться в терминах (в разных
S>> книжках одни и те же термины трактуются по разному, к сожалению),
S>> поясню, что я имел ввиду под гуру (правда придётся пойти поперёк пути
S>> старика Окама введя новый термин). Под "гуру" я понимал так называемого
S>> программиста — "этюдника", который блестяще может выполнить практически
S>> любую задачу, но только один раз, поскольку второй раз ему такую же
S>> задачу делать неинтересно. вот, например, "этюдник" может написать
S>> чудесный компонент, которым потом будут пользоваться 100 человек. Однако
S>> быть одним из этих 100 человек ему уже неинтересно.

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

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

S>За две недели можно научить человека на курсах переписывать типовые примеры, не более. А потом он ещё два месяца будет сам колупаться в своих задачах, пытаясь адаптировать эти примеры под свою задачу и удивляясь, почему же это на курсах датасет грузился 1 секунду, а мой полчаса грузится...

При чем тут курсы? Речь идет об опытном программисте, который просто до этого не писал на С#. Язык действительно прост и мелкие языковые нюансы не смогут сильно задержать программиста, знающего плюсы, жабу или хотя бы Delphi.

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

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

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

ST>>А между досом и клавиатурой видимо связь такая же как между виндосом и клавиатурой (они соотносятся как средство пользовательского ввода и ОС).

S> Я сейчас объясню просто... Дело в том, что часто пользователи нашего приложения СТОЯТ за столом, а не сидят, а стоя мышкой возить очень неудобно — нужно либо иметь гибкость как у Алины Кабаевой, либо клиенту показывать хорошенький зад, сгибаясь к столу И это ещё не самая большая проблема

S>>>>> Короче говоря — конкретные умения, если они как раз и требуются, это
S>>>>> хорошо, а не плохо.


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

ST>>Как я понимаю, мысль была в том, что нужно много прикладных программистов и меньше системных.
ST>>Просто почему-то системных назвали "гуру", хотя можно быть гуру и в юзабилити и в прикладном программировании. Так ?

S>Ну не совсем так, но близко. Чтобы не запутаться в терминах (в разных книжках одни и те же термины трактуются по разному, к сожалению), поясню, что я имел ввиду под гуру (правда придётся пойти поперёк пути старика Окама введя новый термин). Под "гуру" я понимал так называемого программиста — "этюдника", который блестяще может выполнить практически любую задачу, но только один раз, поскольку второй раз ему такую же задачу делать неинтересно. вот, например, "этюдник" может написать чудесный компонент, которым потом будут пользоваться 100 человек. Однако быть одним из этих 100 человек ему уже неинтересно.

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

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

S>Уф.

S>Ну а если я не прав — старгие товарищи меня поправят
прав, на 90 % точно,
вот мне сейчас до денег, просто пофиг, на 100$ готов работать,
но чтоб проект приколен был, да и руководство не говнистое,
вот блин аш выговориться хочется, ну просто не поймут.
вот если я что нить на программлю, и это будет признано народом, то после это можно спокойно
умирать )) чесслово

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

S>>За две недели можно научить человека на курсах переписывать типовые примеры, не более. А потом он ещё два месяца будет сам колупаться в своих задачах, пытаясь адаптировать эти примеры под свою задачу и удивляясь, почему же это на курсах датасет грузился 1 секунду, а мой полчаса грузится...

iT>При чем тут курсы? Речь идет об опытном программисте, который просто до этого не писал на С#. Язык действительно прост и мелкие языковые нюансы не смогут сильно задержать программиста, знающего плюсы, жабу или хотя бы Delphi.

да тему говоришь,
вот мне нужно было прогу написать, я покапался немного посмотрел и выбрал С#
писал на нем первый раз, но программу успешно продал, и еще спасибо говорили
хотя я сам на java пишу, но там было desktop приложение немного, причем на java до сих-пор
ориентируюсь, и мне наплевать на всякие священные войны )), я гибок и стремлюсь к этому

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

S>>За две недели можно научить человека на курсах переписывать типовые примеры, не более. А потом он ещё два месяца будет сам колупаться в своих задачах, пытаясь адаптировать эти примеры под свою задачу и удивляясь, почему же это на курсах датасет грузился 1 секунду, а мой полчаса грузится...

iT>При чем тут курсы? Речь идет об опытном программисте, который просто до этого не писал на С#. Язык действительно прост и мелкие языковые нюансы не смогут сильно задержать программиста, знающего плюсы, жабу или хотя бы Delphi.

Аргументировать вышесказанное мной непросто — я исхожу из того, что вижу вокруг. Существует масса особенностей языка, которые используются в проекте и которые неизвестны специалистам, ранее на C# не писавшим. Если речь идёт о программе, в которой используются несколько стандартных контролов — то там без разницы, на чём писать. А если человек не знает некоторых особенностей языка, то могут возникнуть трудноловимые ошибки в большой системе, которые приводят в результате к существенным расходам. Хотете пример — пожалуйста: ответтье на вопрос:

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

Не зная особенностей C# можно получить такие проблемы, с которыми потом придётся долго разбираться.

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


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

И это называется проверка на знание C# . Вообще-то это полнейший примитив.
Лучше спросите — что будет, если попытаться откомпилить следующее:

using System;

namespace Experiment
{
    class Experiment
    {
        static void Main()
        {
            Console.WriteLine(2 + null + null + 2 == 4 + null );
        }
    }
}

Спорю, что лично вы, к примеру — верно на этот вопрос без компиляции этого кода не ответите.
P.S. Только всё это — финты ушами. Хороший программер мыслит алгоритмами, причём в наиболее эффективном алгоритмическом базисе, будь то императивный стиль,объектно-ориентированный,логический, функциональный или ещё какой .

Hello, Spidola!
You wrote on Wed, 30 Jun 2004 10:40:08 GMT:

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

S>>> За две недели можно научить человека на курсах переписывать типовые
S>>> примеры, не более. А потом он ещё два месяца будет сам колупаться в
S>>> своих задачах, пытаясь адаптировать эти примеры под свою задачу и
S>>> удивляясь, почему же это на курсах датасет грузился 1 секунду, а мой
S>>> полчаса грузится...

iT>> При чем тут курсы? Речь идет об опытном программисте, который просто
iT>> до этого не писал на С#. Язык действительно прост и мелкие
iT>> языковые нюансы не смогут сильно задержать программиста,
iT>> знающего плюсы, жабу или хотя бы Delphi.

S> Аргументировать вышесказанное мной непросто — я исхожу из того, что вижу
S> вокруг. Существует масса особенностей языка, которые используются в
S> проекте и которые неизвестны специалистам, ранее на C# не писавшим. Если
S> речь идёт о программе, в которой используются несколько стандартных
S> контролов — то там без разницы, на чём писать. А если человек не знает
S> некоторых особенностей языка, то могут возникнуть трудноловимые ошибки в
S> большой системе, которые приводят в результате к существенным расходам.
S> Хотете пример — пожалуйста: ответтье на вопрос:

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

S> Не зная особенностей C# можно получить такие проблемы, с которыми потом
S> придётся долго разбираться.

И что же это за особенности ? (просто я там ничего особенного не нашел — было бы инетересно узнать что считается особенностями)

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

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

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

А> И это называется проверка на знание C# . Вообще-то это полнейший примитив.

Во-первых, вы не ответили. Во-вторых, большинство приходящих на собеседование "специалистов", знающих C++, на данный вопрос ответить не могут. Это факт.

А>P.S. Только всё это — финты ушами. Хороший программер мыслит алгоритмами, причём в наиболее эффективном алгоритмическом базисе, будь то императивный стиль,объектно-ориентированный,логический, функциональный или ещё какой .

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

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

S>Во-первых, вы не ответили. Во-вторых, большинство приходящих на собеседование "специалистов", знающих C++, на данный вопрос ответить не могут. Это факт.
В ISO/IEC 14882 С++ нет ключевого слова finally или семантически близкие ему — есть лишь нестандартные расширения языка. .

А>>P.S. Только всё это — финты ушами. Хороший программер мыслит алгоритмами, причём в наиболее эффективном алгоритмическом базисе, будь то императивный стиль,объектно-ориентированный,логический, функциональный или ещё какой .

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

Ещё раз повторяю — примитивщина этот вопрос.

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

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

S>>Во-первых, вы не ответили. Во-вторых, большинство приходящих на собеседование "специалистов", знающих C++, на данный вопрос ответить не могут. Это факт.
А>В ISO/IEC 14882 С++ нет ключевого слова finally или семантически близкие ему — есть лишь нестандартные расширения языка. .

вот и приходится catch(...) пользоваться.