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

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

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

Знаете что говорят про ружье на стене?

Hi criosray

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

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

C>Знаете что говорят про ружье на стене?

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

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

AV>Hi criosray

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

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

C>>Знаете что говорят про ружье на стене?

AV>Знаю, поэтому и были предприняты необходимые действия, чтобы патрона не оказалось.

Какие например?

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

AV>Hi gandjustas

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

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

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

AV>Ага. А вероятность встретить/не встретить мамонта тоже 50/50.
Причем тут вероятность?
Вы же продаетет фактически аппсервер, который может запустить в одном хост-процессе managed и unmanaged код, как вы гарантируете что AV в unmanaged коде не свалит кучу managed модулей, которые могут никак не относиться к тому приложению, которому требуется unmanaged модуль.

AV>И как же ты программируешь, извелся весь наверное. Ведь твои проги крутятся на системе, которая вся насквозь unmanaged.
Для ядра этой системы все подряд модули не пишут, а процессы пользовательского режима как раз изолированны друг от друга.

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

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

Все админы делятся на две категории — те кто делает бекапы, и те кто их будет делать

Hi gandjustas

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

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

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

AV>>Ага. А вероятность встретить/не встретить мамонта тоже 50/50.
G>Причем тут вероятность?
G>Вы же продаетет фактически аппсервер, который может запустить в одном хост-процессе managed и unmanaged код, как вы гарантируете что AV в unmanaged коде не свалит кучу managed модулей, которые могут никак не относиться к тому приложению, которому требуется unmanaged модуль.

А разные приложения крутятся в разных процессах. Сервер тоже отдельный процесс. Хотя некоторая часть аппсервера находится в одном процессе с приложением. Но эта часть никак не может оказать влияния на работу сервера. И как же AV в компоненте одного приложения может оказать влияние на другие приложения и сам сервер?

AV>>И как же ты программируешь, извелся весь наверное. Ведь твои проги крутятся на системе, которая вся насквозь unmanaged.
G>Для ядра этой системы все подряд модули не пишут, а процессы пользовательского режима как раз изолированны друг от друга.

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

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

Смотри выше.

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

G>

G>Все админы делятся на две категории — те кто делает бекапы, и те кто их будет делать

Если пользоваться этой фразой, то бекапы были с самого начала.

Hi gandjustas

G>Какие например?

Смотри ответ на другое свое сообщение.

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

C>Вы вообще видели VS 2k8 + Resharper 4.1 связку? Явно не видели...

Решарпер действительно бесподобен, но и вы слишком категоричны, вот напрмиер по своему опыту python+eclipse:

C>Как скорость может быть одинаковой, если нету ни мощных средств для рефакторинга,
мощных как в решарпере нет, простые вполне есть.

C>ни intellisense,
есть

C> ни удобных и быстрых средств для навигации по коду,
есть

C>ни средств для динамического анализа кода на соответствие определенным правилам,
есть, PyLint — во многом устраняет недостатки "динамичности" (проверяет вызовы методов и т.п. — т.е. те ошибки которые как пправило в рантайме )

C>ни удобного отладчика,
выделенное — субъективно, а так — есть

C>ни модуля для запуска модульных тестов,
есть

C>ни модуля для взаимодействия с системой контроля версий,
есть

C>ни модуля для дизайна схемы классов,
нет, но я этим и в стуии ни разу не пользовался.

C>ни модуля для дизайна форм, ни модуля для дизайна страниц, ни... много другого?
html редактор есть, редактор форм — а каких? winforms чтоли ? если например для GUI на python взять PyQT — то там вполне себе нормальный дизайнер

C> Тормозил, на Windows Skype не использует QT. Изначально его вообще не Дельфи писали.

Однако 0_о. Что, в принципе, только подтверждает тот факт, что все дело н в языке программирования и н в платформе, а в руках

Правда, у вынь- и макос-версии скайпа почти паритет пофичам, по-моему. А вот в Линуксе — увы

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

AV>А разные приложения крутятся в разных процессах. Сервер тоже отдельный процесс. Хотя некоторая часть аппсервера находится в одном процессе с приложением. Но эта часть никак не может оказать влияния на работу сервера.

Тогда зачем вам аппсервер, если компоненты грузятся в процесс приложения?

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

C>> Тормозил, на Windows Skype не использует QT. Изначально его вообще не Дельфи писали.
M>Однако 0_о. Что, в принципе, только подтверждает тот факт, что все дело н в языке программирования и н в платформе, а в руках
M>Правда, у вынь- и макос-версии скайпа почти паритет пофичам, по-моему. А вот в Линуксе — увы
Вообще-то, сейчас в Линуксовой версии вроде все фичи Виндовой есть. Насколько я понимаю, они постепенно переходят к общей кодовой базе для всех платформ.

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

KV>3. Он мешает развиваться дальше. Те, кто в этой теме будет особо рьяно защищать шарп — помяните мое слово: пройдет 10 лет (хотя, скорее всего — и того меньше) и вы станете такими же бухтящими старперами (я не про возраст) коими сейчас являются некоторые из местных оголтелых плюсников.

От имени оголтелых плюсников решительно заявляю

1. C# никуда не денется и никакого конца ему не будет. Его претензии на всеобщность будут похоронены и он просто займет свое место в мире ИТ. Точнее, уже занял.
2. Все прочие языки — то же самое. Включая С++

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

C>>Вы вообще видели VS 2k8 + Resharper 4.1 связку? Явно не видели...

M>Решарпер действительно бесподобен, но и вы слишком категоричны, вот напрмиер по своему опыту python+eclipse:

Вы невнимательно читали ветку. Речь шла о том, что мол на пайтоне можно писать код так же быстро, как на C#, но без использования специальных сред разработки.

Что до эклипс — да, там почти все есть только на фоне VS+Resharper весьма и весьма слабо.

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

S>Сейчас динамично развивается питон. Достаточно легок (осваивается человеком даже с очень средними способностями), не тянет за собой монстра ввиде VS и Питон бесплатен, портабелен практически на все платформы, поддерживается гигантом типа google — это один из их внутренних языков.

Питон плохая замена овсу, тфу ты, Шарпу.

Уроветь у него примерно такой же как у Шарпа, но ко всему прочему Питон интерпретатор. Все что можно получить в питоне — это скриптообразное метапрограммирование.

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

S>Да, но производительность написания кода резко упадет.

Дохотр, а у меня производительность на питоне в 30 раз ниже чем не шарпе. На на немерле еще раз в 5-1- выше. Что я делаю не так?

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

Рельно языки отличаются только:
1. Возможностями. И тут у питона и шарпа даш на даш. Питон имеет мощьное метапрограммирование и по причинам своей динамической природы упрощает создание обобщенных реализаций, но при этом Питон резко проигрывает по скорости получаемых програм, не имеет возможностей вроде LINQ-а, имеет значительно более слабую поддержку IDE (и это не лечится по причине скриптовости).
2. Особенностями рантайма. Шарпа требует дотнет, а Питон собственный рантайм. При этом Шарп компилируется в эффективный машинный код, а Питон — нет.

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

S>нифига. На Питоне и C#+VS пишется примерно с одной и тойже скоростью. Вот если из связки C# VS убрать VS, то все — труба, погрязнешь в рутине.

Фанат ты. Потому и мнение у тебя такое.

Писать на чем угодно в нотпэде медленее чем если есть мощьная IDE подсказывающая тебе список функций (методов) и предоставляющая рефакторинг.

Но даже если считать твое мнение серьезным, то все равно не ясно зачем переходить на Питон. Ведь IDE же уже есть (и не одна), а с ней разницы в скорости кодирования и поддержки кода нет. Так зачем же получать более медленный исполняемые файлы не получая за это ничего в замен?

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

__>Здравствуйте, Anton Batenev, Вы писали:

AB>>А делать простое get-set свойство, которое ни чем (по сути) не отличается? Хотя мне тут сказали про бинарную совместимость — это действительно повод для некоторых случаев.

__>Повод делать property — это более OO-way . В будущем, как уже заметили, будет меньше проблемм.

Вопрос начинающего шарпера: Что мона сделать с полем, но нельзя сделать со свойством, кроме передачи в метод по ссылке??

То есть на мой взгляд:

class MyClass
{
int Prop;
}

и

class MyClass
{
int Prop {get; set;};
}

кроме упомянутого выше отличия со ссылками — свойства и поля — эквивалентны. Или я не прав?

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

C>Вы вообще видели VS 2k8 + 4.1 связку? Явно не видели...

Может сначала следовало бы дождаться ответа?

C>Как скорость может быть одинаковой, если нету ни мощных средств для рефакторинга, ни intellisense, ни удобных и быстрых средств для навигации по коду, ни средств для динамического анализа кода на соответствие определенным правилам, ни удобного отладчика, ни модуля для запуска модульных тестов, ни модуля для взаимодействия с системой контроля версий, ни модуля для дизайна схемы классов, ни модуля для дизайна форм, ни модуля для дизайна страниц, ни... много другого?

А кто тебе сказал, что для Питона нет IDE?
Они конечно не такие мощные как Resharper, но в купе с динамичностью языка получается весьма не плохо.

Hi gandjustas

AV>>А разные приложения крутятся в разных процессах. Сервер тоже отдельный процесс. Хотя некоторая часть аппсервера находится в одном процессе с приложением. Но эта часть никак не может оказать влияния на работу сервера.

G>Тогда зачем вам аппсервер, если компоненты грузятся в процесс приложения?

Затем же зачем и другие аппсервера.

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

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

VR>спорный момент
VR>сишарп, до версии 3.0 имел очень понятный и ясный синтаксис
VR>сча, согласен, как накрутили всяких лямбд, синтаксис становится всё запутанней и запутанней, но и даже сейчас каким-то "непростым" трудно его назвать

Разочарую тебя. В Питоне всякие лябды были с самого рождения (ну, или очень довно). Так что тем у кого мозг не в силах освоить всякие лямбды в этом мире становится жить все сложнее и сложнее. Даже в Яве есть локальные классы и подобие замыканий, что в сущности не доработанные лябды.

Но есть один выход! Нашей необъятной родине очень нужны дворники!

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

C>Те же лямбды раньше реализовывались анонимными делегатами.

Уважаемый, запомни на будущее. То о чем ты ведешь речь называется "анонимными методами".

C>Мы недавно переводили проект с С# 2 на С# 3 — код стал гораздо лаконичнее и читабельнее.

Если бы вы перевели его скажем на Немерле или F# (с умом), то он бы стал еще более лаконичным и читабельным (раз эдак в 5).