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

I>>>Кто тебе такое сказал ?
BBI>>Реальность. Тупо пошарился по всем доступным компам.

I>А в инет пробовал выходить или сайты-сервисы-серверы это по твоему не софт или их писать не надо ?
Apache — native
IIS — native (где то там есть managed support)
MSSQL — native

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

H>Так я не против Крутятся себе скриптики на нативных серверах, дергают нативные базы... И с чего бы их считать менеджед софтом? Этак и WoW с Lua кишками можно назвать ненативным
показываем HTML + js — опа, и у нас уже Apache ненативный

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

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

H>То есть именно слой клея ты назвал серверными приложениями?

Кода в этом слое часто больше, чем нативном десктоп-приложении.

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

H>А я о чем написал?

Так речь о том, что 99% софта это менеджед.

I>> И то и другое не нативная разработка, так что все в порядке.

H>Так я не против Крутятся себе скриптики на нативных серверах, дергают нативные базы... И с чего бы их считать менеджед софтом? Этак и WoW с Lua кишками можно назвать ненативным

То есть ты хочешь скрипты Lua назвать нативными ? Ну-ну.

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

I> H>То есть именно слой клея ты назвал серверными приложениями?

I> Кода в этом слое часто больше, чем нативном десктоп-приложении.

В среднем по больнице мерял?

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

I> H>А я о чем написал?

I> Так речь о том, что 99% софта это менеджед.

Если ты о сайтах, то да, это, в массе своей, менеджед клей крутящийся на нативных серваках и юзающий нативные БД. А когда было по другому? Вектор то где?

I> I>> И то и другое не нативная разработка, так что все в порядке.

I> H>Так я не против Крутятся себе скриптики на нативных серверах, дергают нативные базы... И с чего бы их считать менеджед софтом? Этак и WoW с Lua кишками можно назвать ненативным

I> То есть ты хочешь скрипты Lua назвать нативными ? Ну-ну.

Нет, я к тому, что WoW является нативным приложением несмотря на его Lua кишки. Почему иначе должно быть с веб-сайтами/сервисами мне не понятно.

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

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

V>>>Панимаешь... Твой shared state, к которому ты апеллируешь, коль речь идет не о глобальных переменных, не в состоянии самостоятельно быть не-shared, кроме как через примитивы синхронизации.

G>>Еще как в состоянии. Достаточно сделать данные immutable.

V>Не достаточно, коль нам от кода нужно именно поведение, зависящее от состояния.
Тогда надо изолировать. Исключать подобные ошибки. В более менее сложном объем кода UI сильно меньше остальной логики, а state нужен только ему, для stateless-логики передаются параметры и никто снаружи их не поменяет просто так.

V>Обеспечение такой семантики через выделение памяти под каждое новое immutable состояние уж тем более не приемлимо, раз неприемлимы были такие мелочи, как примитивы синхронизации.
Ну это в unmanaged так, а в .NET как раз правильное использование immutable позволяет увеличить быстродействие слегка увеличив расход памяти, а также сделать код многопоточным.


V>>>А их договорились не использовать, и было почему. В этом случае shared он может стать только из-за внешнего кода, из-за того, как его использует тот самый внешний код. Не понимаешь?
G>>Прекрасно понимаю. А также я прекрасно понимаю что это ошибка. А вот ты на пару с ГВ — это понимать не хотите. Вам наверное удобнее быть героями, которые борятся с кучей сложностей, чем попытаться разделить аспекты и уменьшить сложность за счет этого. Например ввести изоляцию с помощью агентов и очередей.

V>А почему ты так уверен, что баг был не в коде реализации как раз агентов и очередей?
Может и там был, ведь пример не я придумал, а ГВ, а он как раз рассказал и показал все, кроме того места где собственно была ошибка.

V>Какие ты еще знаешь способы реализации архитектур СМО, интересно?
Что такое СМО?

V>>>Этот внешний код и сделал некое состояние shared, хотя не должен был его таким делать, согласно спецификации. Непреднамернно, господи, у кого багов не бывает?.. А случай был интересен лишь тем, что в managed такую ошибку найти гораздо сложнее из-за того, что ничего не падает, а якобы работает. Обычная была бы такая плавающая ошибка, ничего нового.
G>>Тут между managed и unmanaged нету разницы, код который случайно начинает шарить может быть написан на чем угодно. Кроме того тут ГВ использует демагогический прием, рассматривая managed и unmanaged отдельно, хотя они являются связанными. В частности unmanaged зависит от того как его вызывают.

V>Описание факта не может являться демагогией, в отличие от навешивания ярлыков, которое ты демонстрируешь. Сухое такое описание банальной ситуации. Подставить туда managed-реализацию вместо unmanaged — ошибка себя в этом месте не проявляет, но она есть, и периодически неуловимо портит важные бизнес-данные. Вот и все, что было сказано.
См пост синклера на эту тему. Это просто случайное совпадение. Выставлять его за правило — глупо.

G>>По сути то что он рассказывает не является проблемами managed и unmanaged, а просто является проблемами плохо кода независимо от того на чем он был написан.
V>Т.е. баги бывают исключительно в плохом коде, что ле?.. договорились... И у тебя за всю жизнь не бывает багов в процессе разработки? А тестеров ваших вы зачем кормите? А юнит тесты (я уверен) нафига исопльзуете? Ведь достаточно же писать "хороший код", это сам по гарант надежности программ...

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



G>>С другой стороны никто не мешает мешает перенести такой подход на десктоп. Только воображения у тех кто десктоп пишет не хватает
V>у тех ли? Вот прога обрабатывает десятки тыщ сообщений в сек, должна принимать бизнес-решения за единицы микросекунд, ты предлагаешь такую задачу делать распределенно? А люди, ставящие хосты с многими десятками ядер наверно дураки поголовно? Ведь можно же "распределенно"?
Ты слово "распределенно" правильно понимаешь? Один запрос все равно обрабатывает как можно меньшее количество машин. В идеале одна. Но производительность машин ограничена, а количество запросов может быть гораздо больше. А если вдруг надо шарить между ними какое-то состояние становится совсем интересно.

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

I>>Работают сиплюсниками. Щас многие конторы берут на работу чуть не гуманитариев, так что меня ничего не удивляет.
BBI>Ну так это проблемы с головой у этих контор.

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

I>>>>Собственно судя по отзывам людей с твоей конторы про с++ на лялихе ...
BBI>>>С моей конторы?
I>>Да.
BBI>Можно ознакомиться?

Извини, разговоры я не записывал на диктофон

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

I>>А в инет пробовал выходить или сайты-сервисы-серверы это по твоему не софт или их писать не надо ?
BBI>Apache — native
BBI>IIS — native (где то там есть managed support)
BBI>MSSQL — native
BBI>

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

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

I>> Кода в этом слое часто больше, чем нативном десктоп-приложении.

H>В среднем по больнице мерял?

У меня достаточно широкий опыт

I>> Так речь о том, что 99% софта это менеджед.

H>Если ты о сайтах, то да, это, в массе своей, менеджед клей крутящийся на нативных серваках и юзающий нативные БД. А когда было по другому? Вектор то где?

Не о сайтах, а о сайтах-сервисах-серверных приложениях. Сайт как правило это часто только морда серверного приложения, сервисы это просто нечто вроде слоя для серверного приложения, а само приложение может делать кучу всякой всячины, например библиотеку Конгресса индексировать или считать всякие формулы умные.

I>> То есть ты хочешь скрипты Lua назвать нативными ? Ну-ну.

H>Нет, я к тому, что WoW является нативным приложением несмотря на его Lua кишки. Почему иначе должно быть с веб-сайтами/сервисами мне не понятно.

WoW является смешаным приложением Это ты сам хочешь назвать его нативным.

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

I> I>> Кода в этом слое часто больше, чем нативном десктоп-приложении.

I> H>В среднем по больнице мерял?

I> У меня достаточно широкий опыт

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

I> H>Если ты о сайтах, то да, это, в массе своей, менеджед клей крутящийся на нативных серваках и юзающий нативные БД. А когда было по другому? Вектор то где?

I> Не о сайтах, а о сайтах-сервисах-серверных приложениях. Сайт как правило это часто только морда серверного приложения, сервисы это просто нечто вроде слоя для серверного приложения, а само приложение может делать кучу всякой всячины, например библиотеку Конгресса индексировать или считать всякие формулы умные.

И с чего ты решил, что все это в 99% реализуется на управляемом коде?

I> H>Нет, я к тому, что WoW является нативным приложением несмотря на его Lua кишки. Почему иначе должно быть с веб-сайтами/сервисами мне не понятно.

I> WoW является смешаным приложением Это ты сам хочешь назвать его нативным.

Менеджед-приложения это прилаги работающие внутри некой управляющей (странно, правда?) среды (не ОС разумеется). WoW (как и прочие скриптуемые приложения) таковым не является, он сам есть реализация исполняющей среды для внутренних скриптов.

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

BBI>IIS — native (где то там есть managed support)

В 7 IIS очень немаленький кусок кода — managed. И это не просто managed support, это важный кусок функционала.

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

I>> Не о сайтах, а о сайтах-сервисах-серверных приложениях. Сайт как правило это часто только морда серверного приложения, сервисы это просто нечто вроде слоя для серверного приложения, а само приложение может делать кучу всякой всячины, например библиотеку Конгресса индексировать или считать всякие формулы умные.

H>И с чего ты решил, что все это в 99% реализуется на управляемом коде?

Разумеется не всё, иначе бы я написал 100% Цифра 99 очевидно это я утрировал имеющийся расклад. Если вычесть игры, то остаются долгоиграющие крупные проекты завязаные на железо, кишки ос и перформанс. Т.е. людей много, масштабы ого-го, а на выходе ровно один продукт. И, да, я знаю, игры пишутся на С++, представь себе. Зато в них вагоны кода _не_ C++ и даже не нативного. БОлее того, сейчас в чистом виде нативные С++ приложения уже сильно большая редкость, а вот чисто менеджед — запросто.

I>> WoW является смешаным приложением Это ты сам хочешь назвать его нативным.

H>Менеджед-приложения это прилаги работающие внутри некой управляющей (странно, правда?) среды (не ОС разумеется). WoW (как и прочие скриптуемые приложения) таковым не является,

Вот так новость — среда не является средой !

H>он сам есть реализация исполняющей среды для внутренних скриптов.

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

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

I> H>И с чего ты решил, что все это в 99% реализуется на управляемом коде?

I> Разумеется не всё, иначе бы я написал 100% Цифра 99 очевидно это я утрировал имеющийся расклад. Если вычесть игры, то остаются долгоиграющие крупные проекты завязаные на железо, кишки ос и перформанс. Т.е. людей много, масштабы ого-го, а на выходе ровно один продукт. И, да, я знаю, игры пишутся на С++, представь себе. Зато в них вагоны кода _не_ C++ и даже не нативного. БОлее того, сейчас в чистом виде нативные С++ приложения уже сильно большая редкость, а вот чисто менеджед — запросто.

Наличие скриптов в том или ином виде не делает приложение ненативным, не говори ерунды. Скрипты, часто, это просто легкая форма связывания кода.

I> I>> WoW является смешаным приложением Это ты сам хочешь назвать его нативным.

I> H>Менеджед-приложения это прилаги работающие внутри некой управляющей (странно, правда?) среды (не ОС разумеется). WoW (как и прочие скриптуемые приложения) таковым не является,

I> Вот так новость — среда не является средой !

I> H>он сам есть реализация исполняющей среды для внутренних скриптов.

I> И тут же ты сам себя поправляешь Внутренние скрипты или не внутренние, разницы никакой, главное что модуль работает внутри управляющей(исполняющей) среды. Потому все скриптуемые приложения они смешаные, нативные + манеджед.

Отлично, теперь я понял почему для тебя 99% софта является менеджед.

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

AVK> BBI>IIS — native (где то там есть managed support)

AVK> В 7 IIS очень немаленький кусок кода — managed. И это не просто managed support, это важный кусок функционала.

Неотъемлемый кусок? Без него IIS перестанет быть веб-сервером?

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

KP>>А почему тогда приложения на плюсах работают быстрее?

AVK>Потому что они не работают быстрее. Сравнивать абстрактное приложение на плюсах с абстрактным на .NET глупо, а такого чтобы одно и то же приложение было написано идентичными по квалификации командами с нуля и на С++ и под .NET, мне такое не встречалось.

Уж насколько я люблю дотнет, но, пожалуй, признаю, что при равной квалификации разработчиков версия на С++ почти всегда будет работать быстрее (отбросим граничные случаи).

Кстати, вот и неплохой пример:
http://blog.evernote.com/2010/10/26/evernote-4-for-windows-is-here/

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

AVK>В 7 IIS очень немаленький кусок кода — managed. И это не просто managed support, это важный кусок функционала.
Ну вот висит у меня запущенный IIS. И в нём Procexp не показывает ничего managed.
Сайт при этом работает. Значит не такой уж и важный этот функционал.

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

G>1) Зачем ты это написал?

Ты просил что-нить про безопасность к исключениям.

G>2) Где тут блокировка писателей?

Прочел бы внимательно, это было дополнение/альтернатива популярному алгоритму read-copy-update для многопоточности.

G>3) Если писать в функциональном стиле именно такой код и получается.

Это НЕ функциональный стиль, это всего-навсего один из способов управления тем самым immutable shared-state. Наличие immutable результата не делает его функциональным автоматически.

G>Еще раз, что ты хочешь сказать?

"Напомните, что я спрашивал?" (С)


G>Ты не понял мысль. В десктопе можно точно также как в вед разделить state и логику. Логика stateless, state — это данные и интерфейс.

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

В общем, совет твой из разряда совета пользовать юнит-тесты. Абсолютно правильный и абсолютно бесполезный для 99.99% коллег.


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

Ну логика-то асинхронная, в нормальном приложении. Сама тоже использует ресурсы... Какое состояние и в какой момент времени менять и на что именно в итоге?
Не торопись отвечать. В общем, есть такая штука, как изоляция транзакций. Этих уровней изоляции и сценариев вокруг этого достаточно много. Давать простой совет по этой теме — демонстрировать поверхностность.

G>Обработка исключений будет сконцентрировала в PL, причем её можно не писать руками, а использовать runtime aop и policy injection для обработки.

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


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

Серьезно?
А я-то думаю, чего это они...

G>Причем от native\managed такое не зависит вообще, я видел подобно поведение и в программах на delphi, и на C++, и .NET или java.

Покажи мне продукты на Дельфи?


G>Даже на курсах постоянно рассказываю истории про то что я видел именно в нативном коде на делфи. Там вообще ужос был с исключениями.

А я кроме Скайпа и программ-то на дельфи не видел...
Счастливчик ты у нас.

G>В .NET не надо схем городить, во-первых сборка мусора есть, во-вторых есть IoC-контейнеры, позволяющие централизовано управлять владением жизни объектов, в третьих писать логику надо с использованием immutable.

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


G>>>Я десктоп практически не пишу, если пишу то это SL для веба или виндафона или же windows-сервисы. Везде подход оправдал себя. Вызывает иногда повышенный расход ресурсов, но зато никаких наведенных эффектов и приложения работают гораздо надежнее.

Не интересовался, для чего тщательнее всего изучают именно относительные метрики надежности? Твое "гораздо более надежное" приложение уровня калькулятора, пусть имеющее надежность ~99.9%, будучи розданным тысяче клиентов, уже упадет хоть однажды с более 60% вероятностью. А если с той же надежностью делать проект в 1000 раз объемнее, то с той же вероятностью это приложение будет падать у каждого первого клиента. В общем, о надежности давай не будем. Веб штука классная, но там каждый отдельный запрос — это такой же маленький изолированный калькулятор, с очень высокой, ввиду своих размеров, абсолютной надежностью. А всю остальную надежность обеспечивает низлежащая инфраструктура. Наверно отсюда толпы индусов в вебе и буйный цвет PHP, из-за такой особенности этой техники.

G>А уже после разработки основного функционала нередко приходится заниматься оптимизацией, удается сократить время работы и затраты памяти на 20% просто конфигурированием ioc-контейнера и кешей.

Делать тебе нечего, за 20% гоняться... Если уж тратить время на оптимизацию, надо получать 2-4 раза, как первое приближение. Лучше на порядок, конечно, но это не всегда получается.

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

КЛ>меня всегда смущало default-initialization вместо value-init. (если я верно помню термины из стандарта, но ты понял о чем я)

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

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

CS>>UI использующий DOM (например WPF и web, browser based UI) это как правило большой набор достаточно мелких объектов которые живут в GC heap.
CS>>При этом в WPF DOM существенно низкоуровневый. Там где в browser используется один объект DOM элемент и его субобъект style (в терминах GCable сущностей) в WPF появляется примерно десяток отдельных GCable things. Т.е. WPF своей моделью создает существенную нагрузку на GC.

КЛ>что это за десяток things?

Каждый DOM элемент в WPF это Common Language Runtime object instance.
Каждый event handler это тоже object instance. Properties там же — GC должен пройттись по ним всем для того чтобы собрать мусор. И т.д.
Десятки GCable things и набегают.

Во всех текущих HTML DOM имплементациях включая мою собственную DOM живет в non-manageable memory space (в терминах .NET) — используется простой и эффективный ref counting.
Если script не работает или он не трогает какие-то элементы то для них GCable wrapper и не создается. Т.е. GC скрипта сканирует очень ограниченный subset объектов.

Плюс алгоритмы layout и rendering работают нативно и с нативными объектами.
Например у меня чтобы определить скажем значение overflow свойства из style элемента нужно просто прочитать значение поля struct style {...}.
Это одна машинная команда. Со всеми вытекающими.

CS>>Особенно на этапе запуска / инициализации всего хозяйства. Для Evernote как приложения запуск как раз и есть один из частых моментов. Приложение предполагается быть легковесным в этом смысле: открыл — сделал заметку — закрыл. Нужно вспомнить что-то: открыл — посмотрел — закрыл.
CS>>Т.е. WPF для такого типа приложений очень неудачный инструмент. Для вещей типа Paint.Net он подходит наверное лучше.

CS>>Ну и потом HTML DOM скажем оперирует более высокоуровневыми конструкциями чем набор примитивов WPF. Т.е. в HTML DOM больше доля native code и memory management не связанной с GC. HTML DOM потенциально более GPU friendly. В WPF же надо конкретно знать детали имплементации чтобы достичь приемлемого результата.

КЛ>я не знаю что такое абстрактный HTML DOM, он везде свой, конкретный. как можно сравнивать WPF OO и абстрактную OO HTML DOM мне не ясно.
HTML DOM он в общем-то стандартный и специфицировнный например http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-core.html

Cравнивать WPF OO и OO HTML DOM можно и нужно. Ибо в принципе одну и ту же функцию выполняет. Практически любую WPF картинку можно воспроизвести в современном browser.
Вот с какой скоростью эти все хозяйства работают и может быть объективным критерием (одним из) оценки технологий.
Собственно об этом и говорим. Evernote в данном случае характерный пример ибо известны две имплементации: WPF и native — можно сравнивать на примерно одном и том же функционале.

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

CS>Каждый DOM элемент в WPF это Common Language Runtime object instance.
CS>Каждый event handler это тоже object instance. Properties там же — GC должен пройттись по ним всем для того чтобы собрать мусор. И т.д.
CS>Десятки GCable things и набегают.
Дык, не получается. Я приводил тест. Создано было более 5000 контролов, в каждом из которых визуальное дерево образуют еще 5-10 вложенных. GC потратил на себя ничтожное время. Да, загрузка медленная, но не из-за GC.

CS>Cравнивать WPF OO и OO HTML DOM можно и нужно. Ибо в принципе одну и ту же функцию выполняет. Практически любую WPF картинку можно воспроизвести в современном browser.
CS>Вот с какой скоростью эти все хозяйства работают и может быть объективным критерием (одним из) оценки технологий.
CS>Собственно об этом и говорим. Evernote в данном случае характерный пример ибо известны две имплементации: WPF и native — можно сравнивать на примерно одном и том же функционале.
Пример с Evernote скоро станет, как Fire And Motion. Конечно, WPF сольет native. Тут без вариантов. Отсутствие интеропа, наличие огромного числа наработок для native кода. Evernote делали для .Net 3.5. Сейчас в WPF шрифты не плывут, известны разные ходы для увеличения пефоманса. И я бы хотел поглядеть на код, тогда смогу сказать, что Evernote-вцы выжали из WPF всё, что смогли. Недавно я установил их клиент: не сказать, что там мега-богатый UI. Не вижу причин, почему на нем WPF должно быть медленнее (исключая запуск .Net).

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

H>Неотъемлемый кусок? Без него IIS перестанет быть веб-сервером?

IIS 7 это далеко не просто веб-сервер, это полноценный сервер приложений.