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

[...]

I>Не сталкивадись с тем как в течение одного проекта ТЗ меняется 3 (три) раза.

Сталкивались, ИМХО, это — нормально. ;) Есть, кстати, такой принцип (очень старый, по-моему, из "законов Мерфи") — "пользователю надо объяснить, чего он хочет".

I>Хотелось бы посмотреть на то, что вы скажете если у вас в первом варианте есть логическая связка данные-интерфейс

Объясни, что означает в данном случае: "логическая связка данные-интерфейс"? Где данные, где интерфейс, есть ли между ними ещё что-то? Как размещна прикладная логика?

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

I>А вот потом одни там какой-то г-к ... Решает, что его персонал ну очень тупой и давай невешивать на всю эту стройную картину бредовые трибования по всякому ограничению ввода со сторомы пользователя (и так все ограничено)

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

Вот здесь можно поточнее?

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

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

Риторика...

I> а студенты это не самые потерянные люди, раз здали сопромат, значит и про список выучат...

Согласен ;) Главное — чтобы хотели.

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

O>Доброго времени суток,

O>Тут вот товарищи долго и упорно спорят про то, что лучше С++, Java, .NET или может даже VB. Причём все почему-то упорно забывают про самый главный инструмент программиста... Угадали? Да, это мозг.
O>И если человек хочет научиться программировать, он должен научиться думать.

Бесспорно. :super: Только я думаю, что используемый язык и его характеристики как средства выражения мыслей и способа компактного документирования программы — очень немаловажная вещь. :shuffle: А отсюда и топик появился.

[...]

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

:) Стану, если он не знает, но хочет знать. А вот если и не хочет знать, да ещё и считает это всё глупым теоретизированием... :crash: ИМХО, здесь очень большая проблема для всей нашей индустрии зарыта.

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

O>>Всем надо знать, всем. Ибо если кто-нибудь из моей команды в production code при частых вставках в начало и отсутсвию необходимости прямого доступа попользует массив вместо списка — он будет уволен.

IT>А ты уверен, что список без прямого доступа в любом случае будет быстрее массива? ;)

Вот не надо передёргивать :-\
Там стоит "И" (and, && ), а при частых вставках в начало массив сильно проигрывает в производительности списку. Спорить о структурах данных можно также долго, как и о языках :down: , можно обсудить проблемы фрагментации памяти при работе со списками и массивами, в отдельной ветке :)

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

IT>>>

IT>>>CString fun(std::string s)
IT>>>{
IT>>>    return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
IT>>>}
IT>>>

КД>Я все правильно напутал ?

Хм. В воскресенье утром моей первой мыслью было _UNICODE.
IT, черт тебя за ногу, это что — поддержка компиляции UNICODE и ANSI программ?

Или это был поток оторванного сознания?

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

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

ГВ>[...]

ГВ>Объясни, что означает в данном случае: "логическая связка данные-интерфейс"? Где данные, где интерфейс, есть ли между ними ещё что-то? Как размещна прикладная логика?

Ясно, что это недостаток в программе. Связка возникает , когда логика (или математика) очень простая но настроек по обработке и выводу данных очень много. Получается, что если хочешь зделать "как бы межплатформенный код" то такого кода будет ну — 20 — 30 % это максимум.
Остальное это взять из элементов управления их состояние записать в глобальные переменные или в члены классов и затем прогнать алгоритм отображения данных снова, что бы "настройки" вступили в силу.
50 % кода — оптимизация перерисовки.
20 % грамотный опрос элементов управления и т.д.
10 % сохраниение в базу данных или еще куда. (оно же чтение)
20-30 % сами мозги проги.

С фантазией у пользователей все впорядке, они в состоянии такого навыдумывать, что только успевай записывать. Вот и получается, что реально настройки программы — это состояние этих самых Box — ов и TextBoxov и т.д.

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


ГВ>Просто почти все, с кем мне приходилось сталкиваться, почти всегда делают одну и ту же концептуальную ошибку, избыточно "сращивая" логику интерфейса и логику приложения (вот я навоевался со своими коллегами MFC-шниками!). А потом вопиют по поводу того, что гад-заказчик потребовал поменять TextBox на ComboBox. Ну, это я не в твой адрес.

Это фигня... сечас у нас задача быстренько Excel переписать. Надоумили связаться с MFCGridCtrl...
Табличка ничего себе, но вот юзеры увидали что — то знакомое и сразу применили весь свой опыт после "Office для чайников"...

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

ГВ>Риторика...

Не, не риторика...
У заказчика ТЗ пишет такойже IT — шник как и я , ну только постарше и уже не может он писать проги. Надоело.
А вот принимает работу Big Shot/ Он компа то кроме как у секретарши на столе на видел ни где.
А согласований сколько А внедрение !!! У там начальства разной степени некомпетентности до 5 человек на одного исполнителя !!!! (САМ считал чуть не запил с горя.) И каждый хочет показать как он во всем разбирается и замечание делать умеет.
В общем ОТДЕЛИТЬ SALES от DEVELOPMENTA ////!!!!!!!!.

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

O>>Недавно отсобеседовали кучу студентов в качестве кандидатов на должность разработчика. Все утверждают, что знают С++, опыт разработки, проекты, все дела. НИ ОДИН не смог внятно рассказать про ассоциативные контейнеры, деревья поиска, сортировки и т.п. Я уже молчу про то, как они С++ знали... А ты говоришь кататься (с) не помню

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

Вы можете стать хорошим программистом, если Вы хотя бы попытались узнать, о чём была речь. К сожалению, если Вы этого обычно не делаете, Вы обречены писать плохие программы. (если Вы конечно не пишете на функциональных или логических языках, речь идёт, как обычно, об ООПе)

I>ТОлько не забывайте о реальности. А реальность, в том, что деньги на корм и подключение к интернету надо зарабатывать.
Мне это удаётся, если вопрос в этом. Но зарабатывать на булку с маслом можно и собирая бутылки на улицах...

I>///синглетона, контейнера, потока (stream), нитей (thread), синхронизаций и прочее и прочее
I>человек ! Которыей знает, что это !!!! Дае тебе господь клиентов, которые знают, ЧТО ОНИ ХОТЯТ!

С клиентами нужно работать, а не ожидать маны небесной. Некоторые делают это интуитивно, некоторые "воспитывают" клиентов. Есть в конце концов более или менее формальные подходы (RUP, XP, MSF, PSP/TSP, etc), в которых всегда так или иначе присутствует фаза (стадия, процесс) анализа. И спецификации (Т3) составляются совместно. Вероятность и частота изменения Т3 в основном (но не только) зависит от профессионализма аналитика и условий бизнеса клиента. Если меняются условия — тут уж деваться некуда, спасти может только продуманная и гибкая архитектура или напряжённый труд

I>Не сталкивадись с тем как в течение одного проекта ТЗ меняется 3 (три) раза.
I>Хотелось бы посмотреть на то, что вы скажете если у вас в первом варианте есть логическая связка данные-интерфейс
I>и серьезная логика обработки любого ввода пользователя через штук эдак 50 диалоговых окон и малюсеньких окошек.

Бывало и хуже.

I> а студенты это не самые потерянные люди, раз здали сопромат, значит и про список выучат...
Никто не говорит о потерянных, просто я почему-то на первом курсе ФФ НГУ уже знал всё это, потому что хотел знать. А многие не знают и не хотят учиться. Считают, что это вполне нормально. Я против тех студентов, которые хотят больших денег в "IT индустрии" но нифига учиться не хотят, а не против тех, кто еще не знает...

Я понятно выразился на этот раз?

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

O>>>Всем надо знать, всем. Ибо если кто-нибудь из моей команды в production code при частых вставках в начало и отсутсвию необходимости прямого доступа попользует массив вместо списка — он будет уволен.

IT>>А ты уверен, что список без прямого доступа в любом случае будет быстрее массива?

O>Вот не надо передёргивать

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

O>Там стоит "И" (and, && ), а при частых вставках в начало массив сильно проигрывает в производительности списку. Спорить о структурах данных можно также долго, как и о языках , можно обсудить проблемы фрагментации памяти при работе со списками и массивами, в отдельной ветке

Правильно, не будем

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

КД>Хм. В воскресенье утром моей первой мыслью было _UNICODE.
КД>IT, черт тебя за ногу, это что — поддержка компиляции UNICODE и ANSI программ?

Да какой там юникод?

Вот, например, ты пишешь MFC GUI приложение, следовательно имеешь CString, с которым работают все MFC'шные классы.

Дальше ты решил сделать это приложение сервером автоматизации, да не кастрированным MFC'шным, а настоящим ATL'ым. Значит ты уже имеешь и CComBSTR.

Теперь ты хочешь работать например с БД через ADO и #import. Получите _bstr_t.

Ну до кучи добавить STL с std:string и вот вам нате весь этот зоопарк в полный рост.

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

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

КД>>Хм. В воскресенье утром моей первой мыслью было _UNICODE.
КД>>IT, черт тебя за ногу, это что — поддержка компиляции UNICODE и ANSI программ?

IT>Да какой там юникод?

Аааа. Я просто по старой памяти — если IT что-то сказал, значит это серьезно. Ну и стал искать скрытый смысл

У меня в программах std::string std::wstring BSTR и AnsiString (из VCL) вполне мирно ужиываются. Главное выбрать из них главных .

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

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

[]
O>Никто не говорит о потерянных, просто я почему-то на первом курсе ФФ НГУ уже знал всё это, потому что хотел знать. А многие не знают и не хотят учиться. Считают, что это вполне нормально. Я против тех студентов, которые хотят больших денег в "IT индустрии" но нифига учиться не хотят, а не против тех, кто еще не знает...

O>Я понятно выразился на этот раз?

нет, а че ты против студентов имеешь? Ты препод что-ли? Я не пойму!
хотят учиться, не хотят.
Жизнь заставляет учить WinAPI, СОМ, SQL и проч. а не алгоритмы быстрой сортировки или поиска подстроки в строке. Да, это круто, когда человек это знает. Но если он не знает как открыть файл или создать окно, я разговаривать с ним даже не буду. И это правильная буржуйская позиция. Платят за то, что приносит конкретные результаты. Я не призываю к тому, что надо забить на алгоритмы. Сам сейчас читаю "Алгоритмы: построение и анализ" Т. Кормена и сотоварищей. Мне это очень интересно. Но до этого я получается программистом не был?

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

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

А>Жизнь заставляет учить WinAPI, СОМ, SQL и проч. а не алгоритмы быстрой сортировки или поиска подстроки в строке. Да, это круто, когда человек это знает. Но если он не знает как открыть файл или создать окно, я разговаривать с ним даже не буду. И это правильная буржуйская позиция. Платят за то, что приносит конкретные результаты. Я не призываю к тому, что надо забить на алгоритмы. Сам сейчас читаю "Алгоритмы: построение и анализ" Т. Кормена и сотоварищей. Мне это очень интересно. Но до этого я получается программистом не был?

А>В общем, кроме необоснованного гона на молодежь, в твоих сообщениях ничего и нет.

Да ты не нервничай так. По большому секрету скажу что деньги системным архитекторам платят больше чем программерам. Так что и WinAPI, COM, SQL тоже не круто. Вон дотнент грядет — и где после этого будут ком и винапи?

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

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

хъ

AVK>Да ты не нервничай так. По большому секрету скажу что деньги системным архитекторам платят больше чем программерам.

ну вот они и пусть будут обязаны знать все это!

AVK>Так что и WinAPI, COM, SQL тоже не круто. Вон дотнент грядет — и где после этого будут ком и винапи?

Там же где и были.

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

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

Ты прям оппортунист какой то.

AVK>>Так что и WinAPI, COM, SQL тоже не круто. Вон дотнент грядет — и где после этого будут ком и винапи?

А>Там же где и были.

Да нет, сейчас они пока еще используются весьма активно

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

O>>Никто не говорит о потерянных, просто я почему-то на первом курсе ФФ НГУ уже знал всё это, потому что хотел знать. А многие не знают и не хотят учиться. Считают, что это вполне нормально. Я против тех студентов, которые хотят больших денег в "IT индустрии" но нифига учиться не хотят, а не против тех, кто еще не знает...

А>нет, а че ты против студентов имеешь? Ты препод что-ли? Я не пойму!

Не препод, но потенциальный потребитель кадров :)

Факт №1. Большинство ищущих работу летом — студенты.
Факт №2. Большинство студентов сами не понимают, чего они хотят делать на работе.
Факт №3. Большинство студентов хотят зарабатывать хорошие деньги, независимо от уровня их знаний.

Факты, конечно, очень спорные, но это то, что я наблюдаю сегодня на рынке.
Мне плевать на факт №1 — мне не важно студент он или нет. Я смотрю на основные две вещи — текущий уровень знаний и желание (вперемешку со способностью) оными знаниями овладевать.
Факт №2 настораживает, но не напрягает. Когда очередной кандидат совершенно теряется при вопросе "чем бы тебе хотелось заниматься" — я всерьез задумываюсь о его судьбе ;) Ответы типа "делать всё, чтобы приносить пользу компании" — слишком размыты. Ответы типа "писать крутые проги и стать кулхацкером" — ну сами понимаете :)
Факт №3 является, скорее всего, следствием мифа о легкости и крутости программирования (и производства ПО) совместно с общим понижающимся (увы) уровнем программистов и повышенным вследствие этого самомнением выпускников и студентов.

Надеюсь не сильно заумно сказал :)

А>хотят учиться, не хотят.

Ты лично хочешь?

А>Жизнь заставляет учить WinAPI, СОМ, SQL и проч. а не алгоритмы быстрой сортировки или поиска подстроки в строке. Да, это круто, когда человек это знает. Но если он не знает как открыть файл или создать окно, я разговаривать с ним даже не буду. И это правильная буржуйская позиция. Платят за то, что приносит конкретные результаты. Я не призываю к тому, что надо забить на алгоритмы. Сам сейчас читаю "Алгоритмы: построение и анализ" Т. Кормена и сотоварищей. Мне это очень интересно. Но до этого я получается программистом не был?

Жизнь заставляет...
Заставляет не жизнь, а вытекающая из желания кушать потребность в деньгах, причём немаловажную роль играет предрасположенность человека к той или иной деятельности. В конце концов существет много профессий, не одними программистами... WinAPI, COM, SQL и прочее — это лишь одна мелкая "гранька" всего многообразия информации в нашем деле. "Буржуйская" позиция тоже бывает разная, не зря же есть PARC, research центры в Microsoft, IBM, Intel и прочих гигантах. И уж там они занимаются отнюдь не winapi... Так что не стоит обобщать до мировых масштабов отдельные затруднения отдельных личностей. А книжка да, не плохая, удачи в познании.

А>В общем, кроме необоснованного гона на молодежь, в твоих сообщениях ничего и нет.

Может быть ты и прав. Но, во-первых, я и сам себя стариком не считаю :) Во-вторых "гон" вполне обоснованный. Раньше (когда и девки были моложе) на 100 человек называющих себя программистами находилось 60 грамотных, умных, опытных "бойцов". Сейчас и десятка не наберётся. Так может происходит девальвация самого термина "программист"?

Скажи, пожалуйста, вот например Вася Пупкин, написавший для своей странички на PHP (ASP, perl, по вкусу) обработку формы "напешите мне што вы думаити пра мой сайт" — программист?

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

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


ГВ>... Это как спор между Эрудицией (набором деталей) и Интеллектом (способностью эти детали выделять и структурировать). Спорить можно бесконечно. Поясню: структура языка (в данном случае — программирования) — это интеллектуальный базис, на основе которого синтезируются производные структуры, а синоним эрудиции в данном случае — набор библиотек, т.е., готовых решений.
ГВ>>> Кстати, знаешь, я понял. Я утверждаю не "обратное", а "перпендикулярное"...
ГВ>>> Именно структура и комбинаторные возможности языка всегда определяют пределы сложности выразимых на нём абстракций, а отнюдь не набор базовых поговорок (библиотек)...

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

ГВ>>>И у C++ этих самых возможностей компактного изложения формулировок на порядок больше, чем у C# + VB вместе взятых.
ГВ>>>Увы и ах, поскольку у тех кто говорит, что "язык и его окружение..." принципиально неверна исходная посылка. C# до C++ ещё расти и расти.

А вот здесь возникает вопрос, внимательно ли ты ознакомился со стандартом C#. Считать его урезанным вариантом С++ неправильно. В C# есть очень много такого чего нет в C++. А вырезано из него не очень много. Я считаю что выкинули именно мусор.
Приведи примеры чего не очень хватает в C# и есть в C++.
Выкинули переопределения некоторых операторов наподобии ->. Но их нехватка как то не замечается.

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



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

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

IT>>В C++ нет событий и делегатов. В C# есть.
ГВ>Можно сделать, если понадобится. Это несложно.

"Можно сделать" — такие аргументы не принимаются (Сделать можно и на ассамблере), главное что уже сделано.
Кстати очень сомневаюсь, что на C++ можно сделать события с такой-же функциональностью, как в C#.
К примеру, с наружи класса в котором определено событие, единственное что можно сделать с событием это добавить- убрать обработчик-делегат. Внутри класса можно вызвать обработчики событий. На С++ если такие события сделать то получется очень криво.


IT>>В C++ нельзя задать видимость и доступ объекта внутри модуля, в C# можно.

ГВ>O'K. Покажи примеры использования? Хотя на C++ подобные штуки элементарно делаются манипулированием директивой "include".

А если внутри одного класса надо объявить другой класс с атрибутом доступа private, чтобы он был невидим снаружи. И например, чтобы внутренний класс мог видеть private поля и функции внешнего класса? Как на C++ такое сделать?

К тому-же с include связано другое важное концептуальное отличие C++ в пользу C#.
Ошибочна идея что, некая сущность должна быть сначала объявлена, а использоваться может только ниже по тексту программы — Это удобно только для разработчиков компиляторов. Даже в C++ эту проблему частично решили — внутри класса порядок обявления методов не играет роли. А с объявлениями самих классов проблема не решена. И это сильно портит жизнь разработчиков.

IT>>В С++ отсутствуют атрибуты и вообще какие либо зачатки аспектного программирования.
ГВ>O'K. Поясни, для чего оно нужно?
Это долго объяснять. Да и в C# это пока, только на зачаточном уровне.

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


O>Не препод, но потенциальный потребитель кадров :)

O>Факт №3 является, скорее всего, следствием мифа о легкости и крутости программирования (и производства ПО) совместно с общим понижающимся (увы) уровнем программистов и повышенным вследствие этого самомнением выпускников и студентов.

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

Третий факт — поразительная вещь. Сейчас головная боль — набор персонала. А причина этой проблемы в следующем.
В теме форума. Смена С++ на С#. Конешно никто не торопится менять компиляторы. Но приходится при слабых обоснованиях применять новые технологии. А под них еще профи не выросли.

Знаете, что сечас золотое дно??? Это автоматизация бух учета. 4 подразделения по стране — франчайзинг 1С заработали намного больше чем бригада аналитиков, которые писали сервер для опроса телемеханики!
Те кто работает с 1С — ну это максимум БЭЙСИК. Програмерами их назвать трудно. Но они окупаются. И готовить просто и нанимать за дешево ...

А сейчас висит контракт — документо оборот по инженерной системе — слияние баз данных + телемех + немного экономики

Проект шлифуют уже 2 месяца человек 10. Напильниками дорабатывают. Там архитектуру словно Фидий проектировал. Афинский храм будет. :-) Заметте ни каких дельфей при реализации нет. :-)...

На 20 листов умных мыслей + столько же картинок с проектом интерфейса.

Так вот ВСЕ можно решить с помощью VC++.

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

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

Будет и COM и DCOM и черте что, так как у клиента телемех весь на них сидит.
Документы будут с помощью OLE в word сразу отправляться. (не забудте о макросах на VB)
До сих не ясно как с web сервера запускать API на компе клиента который лезет на сервер, Решений масса, но что выберут мне пока не сообщили.

В общем на проект ТРИВИАЛЬНЫЙ !!!! Уже неоднократно решенный. Применят 5 или 6 технологий. ВСЕ отностиельно новые — отностельно VC++.
Полно аналогов существующих в мире, но для русского клиента не адаптированных, поэтому и заказали.
Но как эта солянка сборная будет работать ????

ГДЕ бойцы??? Даже за деньги спецов нельзя нанять.

Программистов — уже давно нет. есть SOFTWARE engineers... То есть ремесленник COM технологий.
Слесарь по HTML. и т. д.

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


O>Может быть ты и прав. Но, во-первых, я и сам себя стариком не считаю :) Во-вторых "гон" вполне обоснованный. Раньше (когда и девки были моложе) на 100 человек называющих себя программистами находилось 60 грамотных, умных, опытных "бойцов". Сейчас и десятка не наберётся. Так может происходит девальвация самого термина "программист"?

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

O>>Не препод, но потенциальный потребитель кадров

O>>Факт №3 является, скорее всего, следствием мифа о легкости и крутости программирования (и производства ПО) совместно с общим понижающимся (увы) уровнем программистов и повышенным вследствие этого самомнением выпускников и студентов.

I>Не могу сказать что я потребитель кадров но позволю себе откоментировать эти высказывания.
I>Третий факт — поразительная вещь. Сейчас головная боль — набор персонала. А причина этой проблемы в следующем.
I>В теме форума. Смена С++ на С#. Конешно никто не торопится менять компиляторы. Но приходится при слабых обоснованиях применять новые технологии. А под них еще профи не выросли.

Не скажи. Если ты можешь позволить себе "купить" хорошие кадры — ты их найдёшь. Предложи мне $5k в месяц, комфортные условия труда, возможность обучения и исследований и я всерьёз задумаюсь над этим предложением А если приму — вкалывать буду ого-го
Дальнейшее обсуждение этого вопроса выношу в отдельную ветку в форуме "Работа".

[ золотое дно поскипано ]

I>ГДЕ бойцы??? Даже за деньги спецов нельзя нанять.
Можно. Только нужны ли тебе бойцы?
У меня была одно время назад команда из 14 отличных "бойцов". Вот только трудности возникают там, где нужен не боец, а просто хороший трудяга. Не всегда нужна команда альфа, спецназ и т.п. Иногда нужно просто хорошо сделать дело. См. далее ту же ветку.

I>Программистов — уже давно нет. есть SOFTWARE engineers... То есть ремесленник COM технологий.
I>Слесарь по HTML. и т. д.

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

Когда-то проводил SWOT-анализ вышеупомянутой команды. Сложилась картина альфа-команды В анализе в разделе "Opportunities" была строчка "Подъём завалов", которая тут же естественно рифмовалась со строчкой "Завал подъёмов"

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

SS>К тому-же с include связано другое важное концептуальное отличие C++ в пользу C#.
SS>Ошибочна идея что, некая сущность должна быть сначала объявлена, а использоваться может только ниже по тексту программы — Это удобно только для разработчиков компиляторов. Даже в C++ эту проблему частично решили — внутри класса порядок обявления методов не играет роли. А с объявлениями самих классов проблема не решена. И это сильно портит жизнь разработчиков.

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

... Янус v1.0alpha (только для тестовых целей)

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

Я бы перекинул тему, но что то неохота, нить диалога потеряю.

ЛЕГЕНДА О $5k.

Золотого дна НЕ БУДЕТ.

Дьявол в деталях.

$5k. — в Лондоне — не вопрос... Ты индус по национальности?
если да — то куда отправить резюме — мест 20 наверное есть.

Знаешь индусы пишут там — НУ в индии, за одно и в ЛОНДОНЕ ядро... То бишь основной софт.
За это из около $5k. и платят. Ну только побываешь в том месте где это все пишется, сразу поймешь почему 98% населения ЛОНДОНА это "британцы". Ты просто не сможешь пробится туда. Там все немного темнокожие и любят только своих. А на родине ЗИТЫ и ГИТЫ программисты за еду работают. Ты с ними не сможешь конкурировать, если только не станешь трудится за 500 уе. Для них перевод в ЛОНДОН — это мечта !!!! Они с семьями и тещями и зятями и т.д. едут и едут...

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

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

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

!!!!!____________________ есть только одна зона — это разработка операционок и интернет решений. Там индусы слабоваты.
А все что с математикой связано и со сложной логикой, модельным софтом. К сожалению данная область вне моей компенетции. Сам занимаюсь прикладным ПО.

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

<skipped>

I>На случай будущей межплатформенности (вдруг линух все победит??) Писать интерфейсы будут либо на J++ либо на еще чем-то, о чем 6 мес. назад я даже не слышал.
I>Но логику софта на J++ не написаить. VC++ — одно решение.

Что есть J++ Вы в курсе? О какой межплатформенности J++ может идти речь? Ж))
J++ -- это изобретение MS даже близко не стоит с реальной многоплатформенностью Sun Java 2 Platform (EJB знаете?). J++ только для Windows и поделок вроде апплетов.

Сервера приложений давно и успешно пишутся на Java2 Enterprise Edition, а о C/C++ даже речи не идёт -- слишком критично и дорого обходится слежение за утечками памяти(чтобы их не было). Конечно, для маленьких контор всё едино, т.к. проекты небольшие. Ну не оправдывает себя трудоёмкость написания кода на C/C++ для серверов приложений. Всё идёт к тому, чтобы переложить ответственность за управление памятью на среду исполнения, в частности, на Garbage collector -- трудоёмкость написания приложений уровня предприятия уменьшается на 30-40%.
В этом направлении двигаются и Java, и .Net :user:

I>Будет и COM и DCOM и черте что, так как у клиента телемех весь на них сидит.

Унаследованные системы, понимаешь... :)

I>Документы будут с помощью OLE в word сразу отправляться. (не забудте о макросах на VB)

??? :))
Я думаю, будет что-то независимое от платформы, типа XML!

I>До сих не ясно как с web сервера запускать API на компе клиента который лезет на сервер, Решений масса, но что выберут мне пока не сообщили.

API чего?
А надо ли(риторический вопрос)?