Здравствуйте, BreakPoint, Вы писали:
BP>Язык и среда разработки это всего лишь инструмент. И ценность он приобретает только в руках того, кто умеет им пользоваться.
Ненене. Ценность инструмент приобретает, когда это хороший инструмент. А когда кривизна инструмента оправдывается требованиями к прямоте рук разработчика — это наводит на мысли.

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

G>Еще раз. Я говорю VCL — GUI-centric библиотека.
G>Ты показываешь код без VCL и как-будто опровергаешь мое утверждение.
G>Надо тебе логикой занимться, а не риторикой.

Да какая тут риторика — VCL на 90% может быть использована без каких либо визуальных компонент. Если ты этого не хочешь понимать — твое дело.

DM>>Опс... Ну какой к бабаям метод? Где ты видишь выполнение хоть чего-то? Это ПРИМЕР УСТАНОВКИ СВОЙСТВ И/ИЛИ ОБРАБОТЧИКА. И все.
G>Вот с этого и надо было начинать. А теперь попробуй приведи минимально рабочий вариант приложения с этим кодом.

В предыдущем письме — минимальное рабочее консольное приложение. Комментарии там есть.

DM>>Пример. Хоть один. Маленький. С комментариями. От тебя. Я. Могу. Увидеть? Про конфиги?
G>http://msdn.microsoft.com/ru-ru/netframework/bb499684.aspx
G>Там конфигов хоть обавляй. Мне лень примеры писать, а код рабочих проектов выкладывать нельзя.

Разводить флейм здесь — не лень. А привести простой пример — СТРАШНАЯ ВОЕННАЯ ТАЙНА. Это что ж такое вы пишете, что чтение параметра из конфига засекречено?
Вообще-то наводит на мысли о способности вообще сделать что-то вразумительное.

Флейм заканчиваю. Все что хотел — я сказал, мнения выслушал. Правда ни одного примера крутизны НЕТа так и не увидел.

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

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

G>>Еще раз. Я говорю VCL — GUI-centric библиотека.
G>>Ты показываешь код без VCL и как-будто опровергаешь мое утверждение.
G>>Надо тебе логикой занимться, а не риторикой.

DM>Да какая тут риторика — VCL на 90% может быть использована без каких либо визуальных компонент. Если ты этого не хочешь понимать — твое дело.
Хорошо что может. Но идеология другая. Об этом хаттаб в соседней ветке пишет.

DM>>>Опс... Ну какой к бабаям метод? Где ты видишь выполнение хоть чего-то? Это ПРИМЕР УСТАНОВКИ СВОЙСТВ И/ИЛИ ОБРАБОТЧИКА. И все.
G>>Вот с этого и надо было начинать. А теперь попробуй приведи минимально рабочий вариант приложения с этим кодом.
DM>В предыдущем письме — минимальное рабочее консольное приложение. Комментарии там есть.
Ну не надо играть разными частями тела. Нужен севрер, а не клиент.

DM>>>Пример. Хоть один. Маленький. С комментариями. От тебя. Я. Могу. Увидеть? Про конфиги?
G>>http://msdn.microsoft.com/ru-ru/netframework/bb499684.aspx
G>>Там конфигов хоть обавляй. Мне лень примеры писать, а код рабочих проектов выкладывать нельзя.

DM>Разводить флейм здесь — не лень. А привести простой пример — СТРАШНАЯ ВОЕННАЯ ТАЙНА. Это что ж такое вы пишете, что чтение параметра из конфига засекречено?
Оно не засекречено, я его просто не делаю. Это за меня делает framework.

DM>Флейм заканчиваю. Все что хотел — я сказал, мнения выслушал. Правда ни одного примера крутизны НЕТа так и не увидел.
А ссылку то смотрел? Повторишь такое на делфях?

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

DM>>А что мне мешает?
G>Ну давай. Есть у тебя интерфейс IService с реализацией в классе Service, напиши компонент, который будет из кофига получать интерфейс и реализацию и создавать сервис (с любым транспортом), который будет вызывать методы указанного класса. А на клиенте при этом по IService генерировать обертку длдя вызова удаленных методов.

Ничего невозможного Еще в Delphi 6 реализация интерфейсов для взаимодействия с SOAP сервисами генерилась в рантайме (по RTTI интерфейсов), а то о, чем говоришь ты, сделать еще проще (для человека, 8 лет программировавшего на Delphi, ты задаешь странные вопросы). А уж о взаимозаменяемости транспортов и вспоминать не интересно, изначально MIDAS (ныне DataSnap) работал по туевой их хуче

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

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

DM>>>А что мне мешает?
G>>Ну давай. Есть у тебя интерфейс IService с реализацией в классе Service, напиши компонент, который будет из кофига получать интерфейс и реализацию и создавать сервис (с любым транспортом), который будет вызывать методы указанного класса. А на клиенте при этом по IService генерировать обертку длдя вызова удаленных методов.

H>Ничего невозможного Еще в Delphi 6 реализация интерфейсов для взаимодействия с SOAP сервисами генерилась в рантайме (по RTTI интерфейсов), а то о, чем говоришь ты, сделать еще проще (для человека, 8 лет программировавшего на Delphi, ты задаешь странные вопросы). А уж о взаимозаменяемости транспортов и вспоминать не интересно, изначально MIDAS (ныне DataSnap) работал по туевой их хуче

Ну так что же мы не видим сегодня аналог WCF на делфях?

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

H>>>>Однако, не стоит думать, что VCL претендует на звание решателя всех проблем.
G>>>А вот это плохо.
H>>Это наоборот очень хорошо. Разработчикам можно концентрировать усилия на генеральной линии (гуй + БД), а все остальное решается сторонними компонентами. Просто идеология другая, не платформенная.

G>А вот зря. Потому что разработчики компонент наследуют идеологию стандартной библиотеки.

Очень даже хорошо, когда сторонние разработчики следуют идеологии стандартной библиотеки и рекомендациям (и они таки есть, такие рекомендации) ее создателей. Пользователю (т.е. программисту) легче со всем этим разбираться и работать. К тому же есть возможность не таскать на себе груза неподходящих решений (платформам привет), а использовать лишь то, что требуется и избежать свойственного платформам распухания.

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

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

H>>>>>Однако, не стоит думать, что VCL претендует на звание решателя всех проблем.
G>>>>А вот это плохо.
H>>>Это наоборот очень хорошо. Разработчикам можно концентрировать усилия на генеральной линии (гуй + БД), а все остальное решается сторонними компонентами. Просто идеология другая, не платформенная.

G>>А вот зря. Потому что разработчики компонент наследуют идеологию стандартной библиотеки.

H>Очень даже хорошо, когда сторонние разработчики следуют идеологии стандартной библиотеки и рекомендациям (и они таки есть, такие рекомендации) ее создателей. Пользователю (т.е. программисту) легче со всем этим разбираться и работать. К тому же есть возможность не таскать на себе груза неподходящих решений (платформам привет), а использовать лишь то, что требуется и избежать свойственного платформам распухания.

Но тогда базовая библиотек не должна быть такой узконаправленной, как VCL (гуй+бд).

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

А ты на шарпе с СОМ давно работал? Получишь полное удовлетворение. Динамики еще не вышли.
Все же натив для натива, а манагед для манагеда.
Чем больше инструментов хороших тем лучше.

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

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

А>А ты на шарпе с СОМ давно работал? Получишь полное удовлетворение. Динамики еще не вышли.
Давно, для кома один раз специально писал на VB. Сделал быстро свою обертку несмотря на то что VB и не знаю.
Еще на F# писал скрипты для автоматизации офиса. Тоже очень даже ниче работают.

А>Все же натив для натива, а манагед для манагеда.
Это ты о чем?

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

H>>>>Однако, не стоит думать, что VCL претендует на звание решателя всех проблем.
G>>>А вот это плохо.
H>>Это наоборот очень хорошо. Разработчикам можно концентрировать усилия на генеральной линии (гуй + БД), а все остальное решается сторонними компонентами. Просто идеология другая, не платформенная.

G>А вот зря. Потому что разработчики компонент наследуют идеологию стандартной библиотеки.

Очень даже хорошо, когда сторонние разработчики следуют идеологии стандартной библиотеки и рекомендациям (и они таки есть, такие рекомендации) ее создателей. Пользователю (т.е. программисту) легче со всем этим разбираться и работать. К тому же есть возможность не таскать на себе груза неподходящих решений (платформам привет), а использовать лишь то, что требуется и избежать свойственного платформам распухания.

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

H>>Ничего невозможного Еще в Delphi 6 реализация интерфейсов для взаимодействия с SOAP сервисами генерилась в рантайме (по RTTI интерфейсов), а то о, чем говоришь ты, сделать еще проще (для человека, 8 лет программировавшего на Delphi, ты задаешь странные вопросы). А уж о взаимозаменяемости транспортов и вспоминать не интересно, изначально MIDAS (ныне DataSnap) работал по туевой их хуче

G>Ну так что же мы не видим сегодня аналог WCF на делфях?

Ну так сущности без надобностей плодить не айс Есть DataSnap, WebSnap, Indy.

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

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

H>>>Ничего невозможного Еще в Delphi 6 реализация интерфейсов для взаимодействия с SOAP сервисами генерилась в рантайме (по RTTI интерфейсов), а то о, чем говоришь ты, сделать еще проще (для человека, 8 лет программировавшего на Delphi, ты задаешь странные вопросы). А уж о взаимозаменяемости транспортов и вспоминать не интересно, изначально MIDAS (ныне DataSnap) работал по туевой их хуче

G>>Ну так что же мы не видим сегодня аналог WCF на делфях?

H>Ну так сущности без надобностей плодить не айс Есть DataSnap, WebSnap, Indy.



Ты сам не заметил противоречия в своих словах?
"Плодить без надобности" и тут же 3 вендора подобных решений, которые, вероятнее всего, между собой не совместимы.

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

G>>>А вот зря. Потому что разработчики компонент наследуют идеологию стандартной библиотеки.

H>>Очень даже хорошо, когда сторонние разработчики следуют идеологии стандартной библиотеки и рекомендациям (и они таки есть, такие рекомендации) ее создателей. Пользователю (т.е. программисту) легче со всем этим разбираться и работать. К тому же есть возможность не таскать на себе груза неподходящих решений (платформам привет), а использовать лишь то, что требуется и избежать свойственного платформам распухания.

G>Но тогда базовая библиотек не должна быть такой узконаправленной, как VCL (гуй+бд).

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

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

G>>>Ну так что же мы не видим сегодня аналог WCF на делфях?

H>>Ну так сущности без надобностей плодить не айс Есть DataSnap, WebSnap, Indy.

G>

G>Ты сам не заметил противоречия в своих словах?
G>"Плодить без надобности" и тут же 3 вендора подобных решений, которые, вероятнее всего, между собой не совместимы.

Это не подобные решения. DataSnap -- чистейшая трехзвенка, WebSnap -- вебсервисы, Indy -- клиенты и сервера для множества популярных протоколов, без примеси БД.

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

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

G>>>>Ну так что же мы не видим сегодня аналог WCF на делфях?

H>>>Ну так сущности без надобностей плодить не айс Есть DataSnap, WebSnap, Indy.

G>>

G>>Ты сам не заметил противоречия в своих словах?
G>>"Плодить без надобности" и тут же 3 вендора подобных решений, которые, вероятнее всего, между собой не совместимы.

H>Это не подобные решения. DataSnap -- чистейшая трехзвенка, WebSnap -- вебсервисы, Indy -- клиенты и сервера для множества популярных протоколов, без примеси БД.

А ты хоть в курсе что такое WCF?

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

G>>>Ты сам не заметил противоречия в своих словах?
G>>>"Плодить без надобности" и тут же 3 вендора подобных решений, которые, вероятнее всего, между собой не совместимы.

H>>Это не подобные решения. DataSnap -- чистейшая трехзвенка, WebSnap -- вебсервисы, Indy -- клиенты и сервера для множества популярных протоколов, без примеси БД.

G>А ты хоть в курсе что такое WCF?

Читал. В общих чертах представляю.

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

G>Здравствуйте, Аноним, Вы писали:

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

А>>А ты на шарпе с СОМ давно работал? Получишь полное удовлетворение. Динамики еще не вышли.
G>Давно, для кома один раз специально писал на VB. Сделал быстро свою обертку несмотря на то что VB и не знаю.
G>Еще на F# писал скрипты для автоматизации офиса. Тоже очень даже ниче работают.

А>>Все же натив для натива, а манагед для манагеда.
G>Это ты о чем?

Намного проще использовать натив для кома и прочих нативных библиотеках где хоть параметры и переведены через PlatformInvoke но не везде и не всегда удобно. Сколько проблем с подсчетом ссылок в манагед языках при работе с комом. Почему в большинстве случаев используют для них Домены? В большинстве случаев проще сделать нативного посредника который будет выполнять всю черную работу.
Но поверь я двумя руками за Net особенно линк и функциональщину в разумных пределах.

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

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

G>>Здравствуйте, Аноним, Вы писали:

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

А>>>А ты на шарпе с СОМ давно работал? Получишь полное удовлетворение. Динамики еще не вышли.
G>>Давно, для кома один раз специально писал на VB. Сделал быстро свою обертку несмотря на то что VB и не знаю.
G>>Еще на F# писал скрипты для автоматизации офиса. Тоже очень даже ниче работают.

А>>>Все же натив для натива, а манагед для манагеда.
G>>Это ты о чем?

А>Намного проще использовать натив для кома и прочих нативных библиотеках где хоть параметры и переведены через PlatformInvoke но не везде и не всегда удобно.
Да ну...
Попробуй на C обращаться к COM через IDispatch
Потом сравним с кодом на F#.
Ты вообще в курсе что там делфи генерит при работе с COM? Там очень много выполняется похожего на managed код.

А>Сколько проблем с подсчетом ссылок в манагед языках при работе с комом.
Ровно ноль.

А>Почему в большинстве случаев используют для них Домены? В большинстве случаев проще сделать нативного посредника который будет выполнять всю черную работу.
Это ты о чем?
Наоборот часто бывает оборачивают существующую функциональность в COM, чтобы удобнее было обращаться из .NET.
Это если нативные функции экспортировать неудобно.

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

А>>Намного проще использовать натив для кома и прочих нативных библиотеках где хоть параметры и переведены через PlatformInvoke но не везде и не всегда удобно.
G>Да ну...
G>Попробуй на C обращаться к COM через IDispatch
G>Потом сравним с кодом на F#.
G>Ты вообще в курсе что там делфи генерит при работе с COM? Там очень много выполняется похожего на managed код.

Есть несколько функций для поддержки IDispatch, а так же классов для создания объектов автоматизации и отработка компилятором оле вариантов.
Просто многое в Delphi сделано хорошо, а многое и паршиво. Но для большинства задач вполне хватает.
Если бы туда и консервативного Сборщика мусора.

А>>Сколько проблем с подсчетом ссылок в манагед языках при работе с комом.
G>Ровно ноль.
Угу. Плохо читаешь форум. Когда множество объектов с зависимыми ссылками, и только полная сборка мусора помогает.
Поэтому и выполнение в отдельном домене городят, а в Delphi идет автоматический подсче ссылок при переприсваивании переменных или выход их из области видимости.
Не будешь же ты городить свой юсинг на каждый СОМ объект.

А>>Почему в большинстве случаев используют для них Домены? В большинстве случаев проще сделать нативного посредника который будет выполнять всю черную работу.
G>Это ты о чем?
G>Наоборот часто бывает оборачивают существующую функциональность в COM, чтобы удобнее было обращаться из .NET.
G>Это если нативные функции экспортировать неудобно.
Я про это тоже. Просто Delphi в этом плане очень удобен и быстр как в разработке так и выполнении, хотя компилятор по оптимизации кода и недотягивает до самых быстрых, зато скорость компиляции аналогична нетовской.
Ну и правильно писать нужно

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

D>>Похоже у тебя богатый опыт по общению с "типичными" приложениями на Delphi. Вопрос только в том, на сколько меньше кликов мышкой ты сделаешь для создания нетипичного приложения с помощью своих монад.
G>Лучше спрашивать не насколько, а во сколько. Linq в C# — это монады, в частности с помощью Linq можно в трехзвенке на клиенте типизировано формировать запрос, который будет выполняться на севрере.
G>В .NET 4 появилась еще одна монада — Continuation, реализуемая классами IObservable\IObserver, которая позволяет писать линейно код, который требует асинхроноого взаимодействия (ожидания событий, асинхронный IO)

Ну т.е. Skype или FL Studio ты бы набросал раз в 5 быстрее их создателей? Или даже в 10. Наверное их можно даже не кодить, а накликать в дизайнере.

G>>>>>>>Если разберешься — появится желание забить на делфи и пойти учить цацкель.
D>>>>>>Зачем мне забивать на дельфи, если я на нём прекрасно зарабатываю себе и моей семье на хлеб, на масло и на отдохнуть. И из-за какого-то монада, переходить на что-то модное с уже отлаженного процесса совсем нет желания.
G>>>>>Так ты не программист, ты кодер.
D>>>>Вот и новое толкование понятия "кодер" — это тот, кто зарабатывает себе и своей семье на хлеб, на масло и на отдохнуть
G>>>Кодер — тот кто зарабатывает сейчас, программист — тот кто зарабатывает сейчас, думает о том как будет зарабатывать в будущем и может других этому обучить.

D>>Я зарабатываю сейчас, я зарабатывал 5 лет назад и даже 8 лет назад, когда же наконец я перестану зарабатывать как "кодер" и достигну великого звания "программист"?
G>Нет, оставаясь кодером сейчас ты программистом не станешь никогда.
Аминь. Желаю тебе всю жизнь оставаться программистом