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

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

H>>Синклер, не смеши общественность Знаешь, как оно бывает в больших конторах? А бывает так, что над проектом работают люди из совершенно разных поколений.
G>Это как раз отсуствие контроля.

Очень смешно. Предлагаешь устроить повальный террор в виде массовых увольнений?

H>>Стоит ли говорить о том, что пристрастия, которые таки являются определяющими, у всех разные, а работодатель не больной на голову, чтоб инвестировать в переучивание всей толпы на новые фишки "современных технологий".
G>В первую очередь работодатель не больной на голову чтобы набирать людей с абсолютно разными пристрастиями.

Смысл фразы о программистах из разных поколений от тебя ускользнул? Я поясню: пришли на работу молодые программисты, но не на место старых... Так понятно?

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

То, что ты не видел таких контор, говорит только о твоем опыте. А ты видел не софтверные конторы, где программистов >200? Я в такой работал, и даже не возьмусь посчитать сколько языков там использовалось.

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

AV>Ааа, в этом отношении. Так никто из внешних программистов не пишет модули для сервера. Они пишут только куски программ, которые крутятся под аппсервером. Даже если ляжет какой-то модуль, то он утянет за собой только одно приложение.
Вот в этом месте мне и непонятно. Если у вас приложения настолько изолированы от апп.сервера, то не всё ли равно, на чём он написан?
Если не изолированы — то неуправляемые языки, мягко говоря, несут некоторый риск.

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

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

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

H>>>Синклер, не смеши общественность Знаешь, как оно бывает в больших конторах? А бывает так, что над проектом работают люди из совершенно разных поколений.
G>>Это как раз отсуствие контроля.
H>Очень смешно. Предлагаешь устроить повальный террор в виде массовых увольнений?
А причем тут это? Контролем в данном случае является банальное ограничение на используемые языки и технологии.
Если каждый программист начнет писать модули на том, что вздумается, то никакой аппсервер делу не поможет.

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

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


G>>Да и вообще это плохая идея, как уже обяснили многократно.
AV>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно.
Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности, а если они запускаются в разных процессах, то получится SOA.

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

H>>>>Синклер, не смеши общественность Знаешь, как оно бывает в больших конторах? А бывает так, что над проектом работают люди из совершенно разных поколений.
G>>>Это как раз отсуствие контроля.
H>>Очень смешно. Предлагаешь устроить повальный террор в виде массовых увольнений?
G>А причем тут это? Контролем в данном случае является банальное ограничение на используемые языки и технологии.
G>Если каждый программист начнет писать модули на том, что вздумается, то никакой аппсервер делу не поможет.

Запретительные меры ничего не решают. Работа просто встанет.

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

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

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

G>>>Да и вообще это плохая идея, как уже обяснили многократно.
AV>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно.
G>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности, а если они запускаются в разных процессах, то получится SOA.

И давно, скажем, COM считается SOA?

Hi gandjustas

G>>>Да и вообще это плохая идея, как уже обяснили многократно.
AV>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно.
G>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности,

Это ты так решил? Так тебя никто не заставляет. А во вторых, как быть с разными managed? Разносить по разным процессам? Спасибо, но иногда лучне не делать так.

Hi gandjustas

G>Если каждый программист начнет писать модули на том, что вздумается, то никакой аппсервер делу не поможет.

А где-то говорилось такое? Не припомню. Так что не стоит придумывать себе самому страшилки.

А вот разные части задачи бывает решать на разных языках, то бывает такое.

Hi Sinclair

AV>>Ааа, в этом отношении. Так никто из внешних программистов не пишет модули для сервера. Они пишут только куски программ, которые крутятся под аппсервером. Даже если ляжет какой-то модуль, то он утянет за собой только одно приложение.
S>Вот в этом месте мне и непонятно. Если у вас приложения настолько изолированы от апп.сервера, то не всё ли равно, на чём он написан?

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

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

C>> M>Действительно серьезного большого кросплатформенного софта (и чтобы еще на слузу) на Qt я особо не видел. Ну, кроме Qoogle Earth и Skyope (который, несмотря на всю кросплатформенность Qt, для Линукса развивается с большим опозданием)
C>> На Windows он просто Skype не использует, вроде.
M>Эээ? Не понял?
Тормозил, на Windows Skype не использует QT. Изначально его вообще не Дельфи писали.

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

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

G>>>>Да и вообще это плохая идея, как уже обяснили многократно.
AV>>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно.
G>>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности, а если они запускаются в разных процессах, то получится SOA.

H>И давно, скажем, COM считается SOA?

COM-объекты не являются сервисами в понимании SOA, хотя общие принципы можно найти везде.

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

AV>Hi gandjustas

G>>>>Да и вообще это плохая идея, как уже обяснили многократно.
AV>>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно.
G>>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности,

AV>Это ты так решил?
Вообще-то AV валит весь процесс, независимо от ваших желаний и моих решений.

AV>А во вторых, как быть с разными managed? Разносить по разным процессам?
Необязательно. Если хост-процесс будет только запускать рантайм и грузить туда указанный модуль, то можно и в одном, все равно взаимодействие модулей пойдет через какие-нибудь пайпы.

AV>Спасибо, но иногда лучне не делать так.
Слово "иногда" звучит очень часто?
Что это за "иногда"? Как часто это "иногда" случается?
Такое ощущение, что вся затея с аппсервером только из-за этого "иногда".

Hi gandjustas

G>>>>>Да и вообще это плохая идея, как уже обяснили многократно.
AV>>>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно.
G>>>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности,

AV>>Это ты так решил?
G>Вообще-то AV валит весь процесс, независимо от ваших желаний и моих решений.

А AV обязательно будет при использовании unmanaged? Да и не так он страшен в данном случае. Так как это никак не скажется на работе самого сервера.

AV>>А во вторых, как быть с разными managed? Разносить по разным процессам?
G>Необязательно. Если хост-процесс будет только запускать рантайм и грузить туда указанный модуль, то можно и в одном, все равно взаимодействие модулей пойдет через какие-нибудь пайпы.

Медленно. Тем более, что хост-процесс еще много чего делает полезного.

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

VR>вот. допустим, ASP.NET MVC — это мощная платформа для быстрой и качественной веб-разработки.

Хороший пример этому rsdn...

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

AV>Hi gandjustas

G>>>>>>Да и вообще это плохая идея, как уже обяснили многократно.
AV>>>>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно.
G>>>>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности,

AV>>>Это ты так решил?
G>>Вообще-то AV валит весь процесс, независимо от ваших желаний и моих решений.

AV>А AV обязательно будет при использовании unmanaged?
Обязательно, гарантировать обратное вы не можете.

AV>Да и не так он страшен в данном случае. Так как это никак не скажется на работе самого сервера.
Все умрут один сервер останется? Кому он только нужен будет?

AV>>>А во вторых, как быть с разными managed? Разносить по разным процессам?
G>>Необязательно. Если хост-процесс будет только запускать рантайм и грузить туда указанный модуль, то можно и в одном, все равно взаимодействие модулей пойдет через какие-нибудь пайпы.
AV>Медленно. Тем более, что хост-процесс еще много чего делает полезного.
Ну если вызовы нечасты, то пофиг медленно или нет. А если часты, то все равно не все вызовы будут managed-managed и часть пойдет через теже пайпы.
Ну это кончено если вы заботитесь о безопасности и надежности.

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

KV>Тогда уж проще от КСВ отписаться, тут везде срач фанатов
Да регулярно отписываюсь, тока потом скучно становится. Все таки иногда тут и интересное почитать можно пока флеймеры да тролли не проснулись.

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


VR>>вот. допустим, ASP.NET MVC — это мощная платформа для быстрой и качественной веб-разработки.

DS>Хороший пример этому rsdn...

Ну во-первых, rsdn не имеет ровным счетом никакого отношения к ASP.NET MVC.
Во-вторых, если бы он написан на том же python, то скорее-всего он бы вообще загнулся под такими-то нагрузками.

Hi gandjustas

G>>>>>>>Да и вообще это плохая идея, как уже обяснили многократно.
AV>>>>>>Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно.
G>>>>>Запуск в одном процессе managed и unmanaged модулей неприемлем с точки зрения надежности и безопасности,

AV>>>>Это ты так решил?
G>>>Вообще-то AV валит весь процесс, независимо от ваших желаний и моих решений.

AV>>А AV обязательно будет при использовании unmanaged?
G>Обязательно, гарантировать обратное вы не можете.

Ага. А вероятность встретить/не встретить мамонта тоже 50/50.
И как же ты программируешь, извелся весь наверное. Ведь твои проги крутятся на системе, которая вся насквозь unmanaged.

AV>>Да и не так он страшен в данном случае. Так как это никак не скажется на работе самого сервера.
G>Все умрут один сервер останется? Кому он только нужен будет?


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

AV>>>>А во вторых, как быть с разными managed? Разносить по разным процессам?
G>>>Необязательно. Если хост-процесс будет только запускать рантайм и грузить туда указанный модуль, то можно и в одном, все равно взаимодействие модулей пойдет через какие-нибудь пайпы.
AV>>Медленно. Тем более, что хост-процесс еще много чего делает полезного.
G>Ну если вызовы нечасты, то пофиг медленно или нет. А если часты, то все равно не все вызовы будут managed-managed и часть пойдет через теже пайпы.

Зачем пайпы использовать, если можно просто дернуть нужный метод у нужного компонента?

G>Ну это кончено если вы заботитесь о безопасности и надежности.

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

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

C>Ну во-первых, rsdn не имеет ровным счетом никакого отношения к ASP.NET MVC.

Ну тогда извините, я не большой знаток МСовских базвордов

C>Во-вторых, если бы он написан на том же python, то скорее-всего он бы вообще загнулся под такими-то нагрузками.

Как скажете.

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

C>>Ну во-первых, rsdn не имеет ровным счетом никакого отношения к ASP.NET MVC.

DS>Ну тогда извините, я не большой знаток МСовских базвордов

Зачем тогда пишете, раз не знаток?