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

E>Например, механизмы коммуникаций между старыми подсистемами.

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

Д>>или переписывать с их помощью особо проблематичные старые подсистемы.

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

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

E>Мне представляется, что долгоиграющий продукт с проблематичными подсистемами просто не выжил бы.

Это предположение, или точные данные?

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

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

Архитектура изначально могла не расчитываться на интероперабельность с системами на других языках. Например, могло использоваться что-то, что хорошо работало в рамках одного языка. Скажем, собственный протокол на основе коммуникационных возможностей OS. Десять лет назад никто не использовал, скажем, XML-RPC или SOAP для взаимодействия компонентов.

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

Это предположение или точные данные?

E>>Мне представляется, что долгоиграющий продукт с проблематичными подсистемами просто не выжил бы.

Д>Это предположение, или точные данные?

Э... экстраполяция собственного не очень большого опыта. Наверное точно выразился.

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

E>А можно мне за Павла ответить? Ну, например, Base24-card.

А вот не надо за Павла отвечать

E>Да и чего специализированные системы вспоминать. Можно, имхо, на MS Word посмотреть, Visual Studio, IE, Mozilla, Opera. Вряд ли их можно назвать продуктами с коротким временем жизни.

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

ЗЫ. И вообще, студия наполовину на шарпе написана.

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

IT>А вот не надо за Павла отвечать



E>>Да и чего специализированные системы вспоминать. Можно, имхо, на MS Word посмотреть, Visual Studio, IE, Mozilla, Opera. Вряд ли их можно назвать продуктами с коротким временем жизни.

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

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

Вообще, складывается впечатление, что C# гарантирует отличный и безглючный софт. А вот C++ -- 100% гарантия обратного эффекта. Ну не бывает так.

IT>ЗЫ. И вообще, студия наполовину на шарпе написана.

Ничего удивительного, она же должна и шарп поддерживать.

IT wrote:
> ЗЫ. И вообще, студия наполовину на шарпе написана.
Там на Шарпе только мелкие и сравнительно автономные вещи типа панелей
свойств.

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

E>Да и чего специализированные системы вспоминать. Можно, имхо, на MS Word посмотреть, Visual Studio, IE, Mozilla, Opera. Вряд ли их можно назвать продуктами с коротким временем жизни.

Ну, вот возми к примеру Visual Studio. 5.0 и 6.0 — это два разных продукта. Очень разных! Так что совершенно не важно на чем они писались.

6.0 и 7.х (2003) тоже совершенно разные продукты. В 7.х не малый объем кода написан на C#. В 2005-ой студии объем дотнетного кода еще более увеличился, хотя она как раз является развитием 2003-ей.

Уже известно, что в будущем студия будет переписана целиком на нотнете...

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

VD>Ну, вот возми к примеру Visual Studio. 5.0 и 6.0 — это два разных продукта. Очень разных! Так что совершенно не важно на чем они писались.

VD>6.0 и 7.х (2003) тоже совершенно разные продукты. В 7.х не малый объем кода написан на C#. В 2005-ой студии объем дотнетного кода еще более увеличился, хотя она как раз является развитием 2003-ей.

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

VD>Уже известно, что в будущем студия будет переписана целиком на нотнете...

Главное, что следующая версия gvim не будет переписана на дотнете

Здравствуйте, AVC, Вы писали:
.
AVC>Меня удивило только "равнодушие" компилятора.
AVC>Раз такая тема поднята применительно к Nemerle, IMHO, есть опасность, что в той или иной степени могут быть повторены ошибки Си++.

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

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

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

VD>Уже известно, что в будущем студия будет переписана целиком на нотнете...

Откуда дровишки? Я не слышал о планах переписывать; слышал о планах переносить. Т.е. значительные куски кода собирались оставить теми же, но перекомпилировать в режиме C++/CLI.

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

WF>>..и даже не хочешь узнать, что это за фича и как она работает.

CS>Как она работает я знаю или, скажем так, понимаю как сделать.
CS>Я не понимаю зачем.

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

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

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

ПК>Откуда дровишки?

От тех кто говорил с ее разработчиками.

ПК> Я не слышал о планах переписывать; слышал о планах переносить. Т.е. значительные куски кода собирались оставить теми же, но перекомпилировать в режиме C++/CLI.

Я рад за то, что ты понимаешь, что не мог слышать все на свете.

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

E>Вообще, складывается впечатление, что C# гарантирует отличный и безглючный софт. А вот C++ -- 100% гарантия обратного эффекта. Ну не бывает так.

Заметьте! Не я это первый сказал!

Речь не о глючном / безглючном. Выше по ветке Паша делает весьма смелое заявление:

> Так что я не вижу тут проблем. Те кто засиделся скорее огребут от конкурентов чем что-то до добются. <...>

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

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

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

>> ЗЫ. И вообще, студия наполовину на шарпе написана.
C>Там на Шарпе только мелкие и сравнительно автономные вещи типа панелей свойств.

А Microsoft.VSDesigner namespace — это, по-твоему, недоразумение?

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

E>Архитектура изначально могла не расчитываться на интероперабельность с системами на других языках. Например, могло использоваться что-то, что хорошо работало в рамках одного языка. Скажем, собственный протокол на основе коммуникационных возможностей OS. Десять лет назад никто не использовал, скажем, XML-RPC или SOAP для взаимодействия компонентов.

XML в данном случае — это худший выбор из всех возможных. Есть очень много куда более легковесных технологий — C-api, COM и аналоги, командная строка, MMF, пайпы, сокеты и т.д. и т.п.

E>Это предположение или точные данные?

это как раз точные данные

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

IT>

>> Так что я не вижу тут проблем. Те кто засиделся скорее огребут от конкурентов чем что-то до добются. <...>

IT>Эти рассуждения обычно неприменимы к продукту с долгим временем жизни.

IT>Вот мне и интересно, какой именно продукт Паша имеет ввиду, т.к. у меня на этот счёт совсем другое мнение. И заключается оно в том, что чем дольше время жизни проекта, тем раньше надо переходить на новые технологии.

Я говорил о продуктах, которые уже достаточно долго живут, но очередные релизы которых, тем не менее, должны регулярно выходить. Примеры eao197 привел. Могу и я сколько-то добавить (например, см. ссылку в моем профайле на MetaCommunications, там products), но что это поменяет?

P.S.

ПК>Я говорил о продуктах, которые уже достаточно долго живут, но очередные релизы которых, тем не менее, должны регулярно выходить. Примеры eao197 привел.

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

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

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

ПК>Я говорил о продуктах, которые уже достаточно долго живут, но очередные релизы которых, тем не менее, должны регулярно выходить. Примеры eao197 привел. Могу и я сколько-то добавить (например, см. ссылку в моем профайле на MetaCommunications, там products), но что это поменяет?

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

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

ПК>> Примеры eao197 привел. Могу и я сколько-то добавить (например, см. ссылку в моем профайле на MetaCommunications, там products), но что это поменяет?

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

.NET используется только для Web. В продукт входит N приложений, в т.ч. и Web, вот штамп и стоит...

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

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

ПК>.NET используется только для Web. В продукт входит N приложений, в т.ч. и Web, вот штамп и стоит...

Ну так с веба обычно всё плохое и начинается Сначала веб, потом серверок на .NET перепишите, а там и юайщики подтянутся

Hello, "IT"

>>> ЗЫ. И вообще, студия наполовину на шарпе написана.
> C>Там на Шарпе только мелкие и сравнительно автономные вещи типа панелей свойств.
>
> А Microsoft.VSDesigner namespace — это, по-твоему, недоразумение?

Еще скажи, что в System.Data.dll это компилятор C# создал namespace <CppImplementationDetails> и namespace <CrtImplementationDetails>