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

OCT>Во–первых, молотом .NET являются функциональные языки
.NET или VB.NET/C#? Функциональные языки вполне неплохо существуют и в рамках самого .NET.

OCT>Любой лиспер поинтересовался бы, зачем, когда есть сборка мусора, стековая архитектура?
Стековая архитектура чего? Вы имеете в виду, что IL-код предназначен для исполнения некой абстрактной стековой машиной?

OCT>В .NET такой источник памяти уже есть — это куча, зачем тогда стек оставили?
Где стек оставили? Покажите пример кода, явно указывающего на присутствие этого Вашего стека. Вы про stackalloc (интересно, а им кто-нить пользуется?) что-ли?

OCT>Поэтому вместо Delphi можно и нужно Ada поставить.
Welcome

Здравствуйте, iyura, Вы писали:
I>Понимаю. У нас весь сырбор разгорелся из-за того, что в управляемых средах не особенно следует обращать внимание на очистку ресурсов — придет GC и все сделает. Так я как раз о том, что не все

Непонятно, откуда взялось заблуждение, что GC должен выполнять очистку всех ресурсов. Сборка мусора реализована для единственного ресурса — памяти. За остальными по-прежнему должен следить сам программист.

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

MC>Здравствуйте, iyura, Вы писали:
I>>Понимаю. У нас весь сырбор разгорелся из-за того, что в управляемых средах не особенно следует обращать внимание на очистку ресурсов — придет GC и все сделает. Так я как раз о том, что не все

MC>Непонятно, откуда взялось заблуждение, что GC должен выполнять очистку всех ресурсов. Сборка мусора реализована для единственного ресурса — памяти. За остальными по-прежнему должен следить сам программист.

Я согласен, что это заблуждение. Но оно опасно тем, что порождает иллюзии. Это из личного опыта — пришел на проект, которым раньше занимались люди слепо верящие в GC. Об IDispose, using и.п. они не заботились. И что самое хреновое — это все как-то работало

Правда никого не заботило то, что при старте приложения при одном открытом окошке с маленькис списком 70Мб памяти было откушено. Мда...сумбурно получается. Короче, программист воспитаный на неуправляемой среде пишет качественнее

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

kuj>А учитывая, что "морды к БД" сейчас обычно в виде web-интерфейса реализуются, то и тут Delphi курит бамбук.

Это скорее твое личное ощущение. Многие морды пишутся не в web

kuj>Про O/RM типа nHibernate или Entity Framework (LINQ for SQL) в Delphi и мечтать не приходится.

А, что есть nHibernate для NET 3.x? B c LINQ и EF тщательнее. Это разные вещи (LINQ for SQL и Entity Framework).
Кроме того EF еще и не вышел

kuj>Классика — пока в лагере Делфи глупые туземцы перебирают SAX парсеры, в лагере .NET уже давно все отпарсено и жители празднуют!

И что? Пока жители NY выбирают колбасу жители CCCP едят одну доступную. Улавливаешь?

kuj пишет:
> hattab, у тебя серьезные пробелы в знании ООП.
ООП и COM — это разные вещи. Скажем так, use cases у COM больше, чем
нужно для ООП.

--
ISO/IEC 8652:1995/Amd 1:2007

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

OCT>kuj пишет:
>> hattab, у тебя серьезные пробелы в знании ООП.
OCT>ООП и COM — это разные вещи. Скажем так, use cases у COM больше, чем
OCT>нужно для ООП.

А зачем в одну кучу варианты использования, ООП и СОМ.
Первое относится варианты использования системы, т.е. это проектирование системы, на этом этапе наплевать какую парадигму программирования использовать
Второе парадигма программирования
Третье технология взаимодействия различных объектов — черных ящиков с известным интерфейсом IUnknown?

Вы что курите, хотя больше похоже на тяжелые синтетические наркотики.

kuj пишет:
> hattab, ты утопил своей глупостью.
>
> Повторяй как мантру:
>
> IUnknown — COM-интерфейс
> Любой интерфейс-наследник IUnknown — COM-интерфейс
> Любой интерфейс-наследник COM-интерфейса — COM-интерфейс
Не согласен. Я думаю, тут hattab как раз прав. COM, как модель,
определяет подмножество. Механизмы COM могут использоваться и для
решения не–COM объектов, но сам COM — это модель. Если интерфейс не
может быть описан в рамках COM, то это не COM–интерфейс. Это интерфейс,
использующий механизмы COM. CORBA объекты в Delphi, я так понимаю, тоже
от IUnknown происходят.

Но в любом случае это переливание из пустого в порожнее. COM–объект, не
COM–объект. Вот то, что у всех интерфейсов к механизмам COM привязка
появляется — это да, это играет роль.

--
ISO/IEC 8652:1995/Amd 1:2007

Сергей пишет:
> Академический интерес: что именно видно на десктопах, может я упустил что?
Я только MathCad видел. Всё. А, ну Janus ещё местный. Итого 2 программы,
большая и маленькая. На Java у меня только toonel.net. Всё. Но это
скорее девиации, чем общее правило.

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

--
ISO/IEC 8652:1995/Amd 1:2007

Mr.Cat пишет:
> Где стек оставили? Покажите пример кода, явно указывающего на
> присутствие этого Вашего стека. Вы про stackalloc (интересно, а им
> кто-нить пользуется?) что-ли?
А из метода можно выйти так, чтобы его кадр остался? Чтобы потом вернуться?

--
ISO/IEC 8652:1995/Amd 1:2007

Bigger пишет:
> Вы что курите, хотя больше похоже на тяжелые синтетические наркотики.
перечитай ещё раз

> А зачем в одну кучу варианты использования, ООП и СОМ.
> Первое относится варианты использования системы, т.е. это проектирование
> системы, на этом этапе наплевать какую парадигму программирования
> использовать
в роли системы реализация COM

--
ISO/IEC 8652:1995/Amd 1:2007

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

OCT>Bigger пишет:
>> Вы что курите, хотя больше похоже на тяжелые синтетические наркотики.
OCT>перечитай ещё раз

Тут сколько не читай, ничего не понятно.
>> А зачем в одну кучу варианты использования, ООП и СОМ.
>> Первое относится варианты использования системы, т.е. это проектирование
>> системы, на этом этапе наплевать какую парадигму программирования
>> использовать
OCT>в роли системы реализация COM

VB6 неполноценный ООП, а ком на нем писать так что в путь

Так чтоже сказать то хотел, медленно и по русски
OCT>--
OCT>ISO/IEC 8652:1995/Amd 1:2007

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

OCT>Mr.Cat пишет:
>> Где стек оставили? Покажите пример кода, явно указывающего на
>> присутствие этого Вашего стека. Вы про stackalloc (интересно, а им
>> кто-нить пользуется?) что-ли?
OCT>А из метода можно выйти так, чтобы его кадр остался? Чтобы потом вернуться?
Чтобы это значило, и где это возможно??????????????????????7

OCT>--
OCT>ISO/IEC 8652:1995/Amd 1:2007

Здравствуйте, OCTAGRAM, Вы писали:
OCT>А из метода можно выйти так, чтобы его кадр остался? Чтобы потом вернуться?

В несколько ограниченном виде — да, с помощью yield. Замыкания (в принципе — из той же оперы — сохранение контекста вызова) в C# тоже имеются.
А теперь объясните, при чем здесь стек.
В принципе, я понимаю, к чему Вы клоните. Однако программист не оперирует такой абстракцией как "некоторый особенный стек, не расположенный на куче". Ограничения и особенности операций передачи управления являются следствием применяемой модели областей видимости и времен жизни объектов. А то, что технически такая модель может быть реализована с помощью стека — это ни о чем не говорит. Если Вы против такой концепции — мне придется Вас расстроить — Вы в меньшинстве. То же самое наблюдается во многих других языках/платформах.

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

kuj>>Ты расскажи это тем, у кого проект "встает" из-за трудноуловимых утечек на недели, если не месяцы. При чем это не плод моего воображения, а вполне реальный факт из моей практики... Правда, случившийся не со мной лично, а в соседнем отделе, которые занимались разработкой на Delphi (год этак 2001-2002).

I>Возможно. Но проекты встают не только из-за утечек памяти. Но еще раз повторюсь — в большинстве случаев ИМХО проблема утечки сильно преувеличена. Из своего немалого опыта работы на С++ могу сказать, что с утечками сталкивался редко, ну, а аот так, чтобы из-за утечки что-то рушилось.... не припомню.

Так в C++ ты ведь наверно используешь smart pointers? Естественно smart pointers сильно снижают вероятность утечки.

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

>> В C# подобный код утечек не вызовет.
OCT>В C# подобный код не напишешь

Напишешь. Не один в один, но функционально такой же.

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

>> hattab, у тебя серьезные пробелы в знании ООП.
OCT>ООП и COM — это разные вещи. Скажем так, use cases у COM больше, чем
OCT>нужно для ООП.

Ась? Что это еще за бред?

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

kuj>>А учитывая, что "морды к БД" сейчас обычно в виде web-интерфейса реализуются, то и тут Delphi курит бамбук.

I>Это скорее твое личное ощущение. Многие морды пишутся не в web
Большинство пишется как раз в виде Web-интерфейса.

kuj>>Про O/RM типа nHibernate или Entity Framework (LINQ for SQL) в Delphi и мечтать не приходится.

I>А, что есть nHibernate для NET 3.x?
А что мешает использовать NH сборки под .NET 3? Есть даже LINQ to nHibernate.

kuj>>Классика — пока в лагере Делфи глупые туземцы перебирают SAX парсеры, в лагере .NET уже давно все отпарсено и жители празднуют!

I>И что? Пока жители NY выбирают колбасу жители CCCP едят одну доступную. Улавливаешь?

Как будто кто-то мешает свой парсер написать.

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

MC>>А Вы считаете, что .NET не предназначен для разработки систем 24х7?

I>Нет, я этого не говорил. Я считаю, что для таких систем и проектирования и кодирование и тестирование должно быть на порядок качественнее. А это уже никакого отношения с .Net/Java/Delphi/C++.... не имеет

Еще и как имеет. Java и .NET позволяют бОльшую часть кода покрыть юнит-тестами, и позволяют применять более высокоуровневые техники: IoC, AOP, O/RM ect

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

kuj>>>Стандартная практика использования IDbConnection в .NET — in-place. То есть по принципу открываем, выполнеяем CRUD операцию(и), закрываем (возвращаем в пул подключений). Даже если забыть закрыть, объект подключения почти тут же станет кандидатом на сборку, так как выйдет за scope. Аналогично с файлами.

I>Мы ведь говорим о "не совсем правильном" стиле программирования.

За не совсем правильный стиль у нас бьют. Больно. Если не помогает, то выгоняют в связи с профнепригодностью.

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

kuj>>>При чем в отличии от Delphi все проще и читабельней благодаря оператору using — отпадает необходимость явно делать try finally.

I>А вот как себя поведет

I>

I>try
I>{
I>    using(obj )
I>    {
I>        если тут облом с obj
I>    }
I>}
I>catch(...........)
I>{
I>   тут хочу рассказать об обломе с obj
I>}
I>

В смысле как? using не делает catch. Соответственно "твой" catch поймает эксепшн.

kuj>>Забыл упомянуть, что для доступа к БД фактически повсеместно используются O/RM, которые сами заботятся о подключениях. Единственное, где надо помнить о using — для TransactionScope`ов.

I>Весьма спорно.

Что именно спорно? Что надо TransactionScope оборачивать в using или явно вызывать Dispose, т.к. это IDisposable объект?

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

kuj>>Тем не менее, не следует ассоциировать закрытие коннэкшн с логикой коммит/роллбэк транзакции. Когда требуется эта логика, то следует явно управлять транзакцией.

I>Понимаю. У нас весь сырбор разгорелся из-за того, что в управляемых средах не особенно следует обращать внимание на очистку ресурсов — придет GC и все сделает. Так я как раз о том, что не все

Так обратного вроде никто и не утверждал.