переформулирую вопрос
имеет ли смысл подстраиваться под производителя некой архитектуры
(читай MS) , придумывающего новые платформы каждые N лет, если жизненный
цикл продукта составляет M лет, причем M > N ?

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

A>переформулирую вопрос
A>имеет ли смысл подстраиваться под производителя некой архитектуры
A>(читай MS) , придумывающего новые платформы каждые N лет, если жизненный
A>цикл продукта составляет M лет, причем M > N ?

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

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

A>переформулирую вопрос
A>имеет ли смысл подстраиваться под производителя некой архитектуры
A>(читай MS) , придумывающего новые платформы каждые N лет, если жизненный
A>цикл продукта составляет M лет, причем M > N ?

Смысл все-таки есть, т.к. новые платформы все-таки берутся не на пустом месте, а стараются взять всё (или почти всё) новое, что на этот момент появилось в IT-индустрии.


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

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

DG>ps.
DG>Ведь если проекту уже 50 лет и ему еще столько же жить, это же не значит, что его надо продолжать писать на асме, потому что так было принято 50 лет назад.

Хм. Есть у нас один проект. Писался 10 лет. В нем есть все — начиная от setjmp и заканчивая STL. Нужно ли это?

Здравствуйте, m.a.g., Вы писали:

MAG>Хм. Есть у нас один проект. Писался 10 лет. В нем есть все — начиная от setjmp и заканчивая STL. Нужно ли это?

Было бы лучше, если были бы только одни setjmp и ни какого STL?


ps
ИМХО, периодически рефакторить старый код тоже надо.

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

DG>
DG>ps
DG>ИМХО, периодически рефакторить старый код тоже надо.

А то потом поздно может быть, тяжело и больно.

DG>Ведь если проекту уже 50 лет и ему еще столько же жить, это же не значит, что его надо продолжать писать >на асме, потому что так было принято 50 лет назад.

а чем тогда объяснить существование до сих пор Кобола на IBM/Mainframe архитектуре?
кстати спрос на таких спецов все еще востребован

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

A>а чем тогда объяснить существование до сих пор Кобола на IBM/Mainframe архитектуре?
A>кстати спрос на таких спецов все еще востребован

Для примера возмем, что продукт написан на MFC (можно взять любую другую "вчерашнюю" технологию)

А теперь ответь на два вопроса:

Ты, как начальник проекта, сможешь найти через 10 лет программиста (потому что MFC-программист, который работал до этого — попал в аварию), который будет хорошо знать MFC и сможет дальше продолжать поддерживать программу?

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

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

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

DG>>Ведь если проекту уже 50 лет и ему еще столько же жить, это же не значит, что его надо продолжать писать >на асме, потому что так было принято 50 лет назад.

A>а чем тогда объяснить существование до сих пор Кобола на IBM/Mainframe архитектуре?
A>кстати спрос на таких спецов все еще востребован

Есть версия кобола для .NET Большинство современных технологий предполагают возможность плавной миграции.

TK>Есть версия кобола для .NET Большинство современных технологий предполагают возможность плавной миграции.

а вот с VB MS очень нехорошо поступил. просто кинул можно сказать. а ведь самое популярное
средство RAD-разработки под Винды было. Delphi имхо гораздо интереснее но существующих
прриложений написанных на VB гораздо больше (особенно в штатах где Delphi почему-то непопулярна)