и предлагаю продолжить дискуссию здесь. Вероятно, обсуждением также заинтересуется Pavel_Lechenko.
Амбула.
Собственно, тезисы, котрые я предлагаю для оспаривания выглядят так:
1. .Net более всего подходит для построения коммуникационных инфраструктур.
2. Не всякая программа (в т.ч. и серверная) лучше всего реализуется средствами, ориентированными на построение коммуникаций.
3. (Вероятно, самый спорный тезис.) В программе, изначально не ориентированной на коммуникационные сервисы лучше всего предусмотреть просто интерфейс в инфраструктуру .Net, чтобы реализовывать коммуникационные задачи его средствами.
4. Если стоит задача обеспечения переносимости программы, не ориентированной на коммуникации, то .Net годится только для обеспечения коммуникационных сервисов на платформе Windows, а потому и не может быть выбран в качестве основного средства реализации.
Под словами "ориентация на ZZZZ" я подразумеваю, что ZZZZ есть основное назначение программы, без которого она не может существовать. Примеры:
— текстовый редактор ориентирован на редактирование текстов;
— SourceSafe ориентирован на хранение деревьев версий файлов;
— операционная система ориентирована на управление вычислительными процессами и ресурсами ЭВМ (блин, благородный древний слог );
Из этого, кстати, может следовать ещё пара интересных соображений.
5. Ориентированное на коммуникации программное обеспечение занимается исключительно обслуживанием коммуникаций и разрабатывается только для обслуживания коммуникаций.
6. Веб-сервис есть только способ осуществления коммуникации.
Признаюсь, что сформулированные тезисы далеко не бесспорны и для меня, а потому, собственно, жду pro & contra. Только одна просьба. Коллеги, давайте поменьше употреблять выражения типа "шаг вперёд", "светлое будущее" и т.п., чтобы не уподобляться автору статьи, упомянутой здесь
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Собственно, тезисы, котрые я предлагаю для оспаривания выглядят так:
ГВ>1. .Net более всего подходит для построения коммуникационных инфраструктур.
Возьмем ADO.NET и рассмотрим его не как технологию соединения программы с СУБД, а как тенхологию взяимодействия именно с БД. SOA стандартных конролов, способных взаимодействовать с Data Access провайдерами + Obj Spaces + XML поддержка
Возьмем ASP.NET (Web Forms). Что может хоть близко стоять с это технологией? На мой взгляд, вообще ничего.
Возьмем WinForms. Если рассматривать только часть отображения граффического интерфейса, то пока тут могут найтись конкуренты. Но если брать в учет дизайн поддержку, биндинг данных и, в будующем, XAML + Avalon, то конкуренты или быстро превратяться в NET, или вообще исчезнут.
ГВ>2. Не всякая программа (в т.ч. и серверная) лучше всего реализуется средствами, ориентированными на построение коммуникаций.
Не понятно. Ты имелл ввиду background программу, работаущую на сервере? Так зачем ей вообще коммутировать с кем то.
ГВ>3. (Вероятно, самый спорный тезис.) В программе, изначально не ориентированной на коммуникационные сервисы лучше всего предусмотреть просто интерфейс в инфраструктуру .Net, чтобы реализовывать коммуникационные задачи его средствами.
Выше было описано, что лучше максимально реализовать все средствами НЕТ. Конечно, можно нафигачить веб сервисы и общаться с ними на уровне сокетов. Но, веб сервисы, на мой взгляд, не очень удачное решение для внутрикорпоративного взаимодействия. Так же, что нам предоставляеться к веб сервисам в качестве бесплатного прибамбаса
1) WSE. Очень полезная вещь. Чтобы реализовать для клиента нужную ф-ть, потребудеться очень и очень много времени.
2) Indigo (для всех видов коммуникаций). Тут без комментариев.
ГВ>4. Если стоит задача обеспечения переносимости программы, не ориентированной на коммуникации, то .Net годится только для обеспечения коммуникационных сервисов на платформе Windows, а потому и не может быть выбран в качестве основного средства реализации.
Подожди. Фраза "не ориентированной на коммуникации" и "для обеспечения коммуникационных сервисов" себе противоречат. Конкретнее, плиз.
ГВ>5. Ориентированное на коммуникации программное обеспечение занимается исключительно обслуживанием коммуникаций и разрабатывается только для обслуживания коммуникаций.
Согласен.
ГВ>6. Веб-сервис есть только способ осуществления коммуникации.
Здравствуйте, mikа, Вы писали:
ГВ>>Собственно, тезисы, котрые я предлагаю для оспаривания выглядят так: ГВ>>1. .Net более всего подходит для построения коммуникационных инфраструктур.
M>Возьмем ADO.NET и рассмотрим его не как технологию соединения программы с СУБД, а как тенхологию взяимодействия именно с БД.
M> SOA стандартных конролов, способных взаимодействовать с Data Access провайдерами
Ну, ещё один способ непосредственной связи presentation-layer и data-layer. И что это кардинально меняет?
M> + Obj Spaces
M> + XML поддержка
А что это значит? ИМХО, это всего лишь один из форматов обмена данными, не более того. Да, он применяется везде, где только можно и нельзя, ну и что? ИМХО, LISP-представление значительно удобнее и проще.
M>Возьмем ASP.NET (Web Forms). Что может хоть близко стоять с это технологией? На мой взгляд, вообще ничего.
Докажи. Особенно правомерность обобщения "вообще". ИМХО, рядом с неё может стоять всё, что угодно, что обеспечит определённую платформонезависимость отображения.
M>Возьмем WinForms. Если рассматривать только часть отображения граффического интерфейса, то пока тут могут найтись конкуренты. Но если брать в учет дизайн поддержку, биндинг данных и, в будующем, XAML + Avalon, то конкуренты или быстро превратяться в NET, или вообще исчезнут.
Почему? Потому что все будут сметены мегавозможностями Avalon? Неубедительно. Ну год, ну два и появятся преемники, если это кому-нибудь будет нужно.
ГВ>>2. Не всякая программа (в т.ч. и серверная) лучше всего реализуется средствами, ориентированными на построение коммуникаций. M>Не понятно. Ты имелл ввиду background программу, работаущую на сервере? Так зачем ей вообще коммутировать с кем то.
Но доступ-то к ней по любому нужен. Другое дело, что основная задача, ради которой она запускается — совсем не коммуникационная, а какая-то ещё. Ну пусть тот же поиск данных, или сбор информации для OLAP.
ГВ>>3. (Вероятно, самый спорный тезис.) В программе, изначально не ориентированной на коммуникационные сервисы лучше всего предусмотреть просто интерфейс в инфраструктуру .Net, чтобы реализовывать коммуникационные задачи его средствами. M>Выше было описано, что лучше максимально реализовать все средствами НЕТ. Конечно, можно нафигачить веб сервисы и общаться с ними на уровне сокетов.
Причём тут сокеты? И зачем делать общаться с веб-сервисами на уровне сокетов?
M>Но, веб сервисы, на мой взгляд, не очень удачное решение для внутрикорпоративного взаимодействия. Так же, что нам предоставляеться к веб сервисам в качестве бесплатного прибамбаса M>1) WSE. Очень полезная вещь. Чтобы реализовать для клиента нужную ф-ть, потребудеться очень и очень много времени.
Э... а эту аббревиатуру можно раскрыть?
M>2) Indigo (для всех видов коммуникаций). Тут без комментариев.
Угу, именно, что для всех видов коммуникаций. Только почему это он в виде бесплатного прибамбаса к веб-сервисам? ИМХО, всё как раз наоброт обстоит.
ГВ>>4. Если стоит задача обеспечения переносимости программы, не ориентированной на коммуникации, то .Net годится только для обеспечения коммуникационных сервисов на платформе Windows, а потому и не может быть выбран в качестве основного средства реализации. M>Подожди. Фраза "не ориентированной на коммуникации" и "для обеспечения коммуникационных сервисов" себе противоречат. Конкретнее, плиз.
Нет, противоречия здесь нет. Программа сама по себе может быть и не ориентированной на коммуникации, но в то же время, у неё могут быть отдельные коммуникационные возможности. Тот же самый поиск в отдельных случаях может работать на локальном десктопе, а может — и из-под веб-сервиса. Веб-сервис можно добавить, можно убрать, возможности программы поиска от этого не изменятся.
ГВ>>5. Ориентированное на коммуникации программное обеспечение занимается исключительно обслуживанием коммуникаций и разрабатывается только для обслуживания коммуникаций. M>Согласен.
ГВ>>6. Веб-сервис есть только способ осуществления коммуникации. M>Его для его и создавали.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Там, одного комментария не хватает:
M> + Obj Spaces
А они-то что кардинально меняют?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
M>Возьмем ADO.NET и рассмотрим его не как технологию соединения программы с СУБД, а как тенхологию взяимодействия именно с БД. SOA стандартных конролов, способных взаимодействовать с Data Access провайдерами + Obj Spaces + XML поддержка
M>Возьмем ASP.NET (Web Forms). Что может хоть близко стоять с это технологией? На мой взгляд, вообще ничего.
А причем тут .Net вообще? в приведенных примерах .Net это не технология а средство, инструмент.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, Геннадий Васильев, Вы писали:
M>> SOA стандартных конролов, способных взаимодействовать с Data Access провайдерами ГВ>Ну, ещё один способ непосредственной связи presentation-layer и data-layer. И что это кардинально меняет?
А кто сказал что это data-layer? Вот допустим я написал веб сервис. Он мне возвращает список товаров. Потом создал DataGrid и прибиндил к нему этот сервис. Я разве что то соединил? Нет. Я решил проблему без лишнего гемморного кода. При этом, веб сервис это не уровень доступа данных Это Business уровень, его фасад.
M>> + Obj Spaces ГВ>А они-то что кардинально меняют?
Чесно говоря, я и сам пока не понял зачем их вообще создавали, если все кричали что Юкон, Юкон. Но в любом случае, щас проведу маркетинговую беседу
Зайди на форум .NET и увидишь, что самый оцененный топик сейчас — это статья ИТ про RSDN.Framework.Data. Неспроста. Маппинг данных народу хочеться, а не возюкаться с SqlXXX классами. Чтоб быстро и эффективно (по времени разработки, разумеется).
M>> + XML поддержка ГВ>А что это значит? ИМХО, это всего лишь один из форматов обмена данными, не более того. Да, он применяется везде, где только можно и нельзя, ну и что? ИМХО, LISP-представление значительно удобнее и проще.
Вообщем, еще одна тема, XML и LISP.
Xml удобен для общения. Не нужно ничего нового изучать. Вот он протокол и все им пользуйтесь. А что ЛИСП. Я его не знаю. Следовательно, его не знаю и мои сервисы. Какой же он тогда удобный?
M>>Возьмем ASP.NET (Web Forms). Что может хоть близко стоять с это технологией? На мой взгляд, вообще ничего. ГВ>Докажи. Особенно правомерность обобщения "вообще". ИМХО, рядом с неё может стоять всё, что угодно, что обеспечит определённую платформонезависимость отображения.
ASP.NET удобен не своей платформонезависимостью (зачем браузеру знать, какая операционка хостит сервер?). Он предоставляет богатый выбор элементов управления, удобность в доступе данных, отладку, визуальную разработку (ну тут скорее всего спасибо студии), легкость программирования "низов" (аналоги ISAPI фильтров и расширение, которые можно создать в считанные минуты и так же развернуть). Плюс куча разных стартовых движков.
M>>Возьмем WinForms. Если рассматривать только часть отображения граффического интерфейса, то пока тут могут найтись конкуренты. Но если брать в учет дизайн поддержку, биндинг данных и, в будующем, XAML + Avalon, то конкуренты или быстро превратяться в NET, или вообще исчезнут.
ГВ>Почему? Потому что все будут сметены мегавозможностями Avalon? Неубедительно. Ну год, ну два и появятся преемники, если это кому-нибудь будет нужно.
Появяться. Сначала Avalon 2. Потом Avalon 3. На самом деле сама технология мне не интересна. Ну там скорость увеличиться, красивее. Мне это все лично по боку. Я первую проблему могу решить покупкой нового компа, вторую — я вообще не люблю попугаев. Но вот интересна сама идея вокруг XAML. Ну что могут предложить "конкуренты". Често говоря, я вижу только одного конкурента языку C# (ниче, если я конкретно). C# Builder
ГВ>>>2. Не всякая программа (в т.ч. и серверная) лучше всего реализуется средствами, ориентированными на построение коммуникаций. M>>Не понятно. Ты имелл ввиду background программу, работаущую на сервере? Так зачем ей вообще коммутировать с кем то.
ГВ>Но доступ-то к ней по любому нужен. Другое дело, что основная задача, ради которой она запускается — совсем не коммуникационная, а какая-то ещё. Ну пусть тот же поиск данных, или сбор информации для OLAP.
NT Services. Как можно подключиться к контроллеру этих сервисов с другой машины. Через оснастку. Какие тут еще коммуникации. Да, там есть RPC. Но все так хитро скрыто, что не нужно разработчику об этом знать.
Кстати, NT сервисы так же легко и приятно разрабатывать на Нете. Говорю это как программист, писавщий их сначала на голом АПИ, затем на аттрибутном ATL. Позднее на НЕТ.
ГВ>>>3. (Вероятно, самый спорный тезис.) В программе, изначально не ориентированной на коммуникационные сервисы лучше всего предусмотреть просто интерфейс в инфраструктуру .Net, чтобы реализовывать коммуникационные задачи его средствами. M>>Выше было описано, что лучше максимально реализовать все средствами НЕТ. Конечно, можно нафигачить веб сервисы и общаться с ними на уровне сокетов.
ГВ>Причём тут сокеты? И зачем делать общаться с веб-сервисами на уровне сокетов?
А как ты хочешь с ними общаться? В Нете уже есть классы, реализующие определенный слой абстракции. В Яве тоже есть (но я ее рассматриваю как Нет. Тот же мифический тяжеловестный рантайм, те же тормоза, та же легкость в разработке). А в других языках разве что то наблюдается? Да, и тем более, реализуй это, тут же потребуються дополнительные возможности, которые сейчас успешно берет на себя WSE. И эту библиотеку тоже реализовывать!?
M>>Но, веб сервисы, на мой взгляд, не очень удачное решение для внутрикорпоративного взаимодействия. Так же, что нам предоставляеться к веб сервисам в качестве бесплатного прибамбаса M>>1) WSE. Очень полезная вещь. Чтобы реализовать для клиента нужную ф-ть, потребудеться очень и очень много времени. ГВ>Э... а эту аббревиатуру можно раскрыть?
Web Services Enhancements. Предоставлял (я его помню по первой версии) шифромание траффика, аутентификацию, транзакционность, легкость в работе с DIME.
M>>2) Indigo (для всех видов коммуникаций). Тут без комментариев.
ГВ>Угу, именно, что для всех видов коммуникаций. Только почему это он в виде бесплатного прибамбаса к веб-сервисам? ИМХО, всё как раз наоброт обстоит.
Не. Только WSE бесплтаный прибамбас Ладно, а конкретно есть что нить по этому пункту. Ее на клиенте тоже самому придеться реализовывать?
ГВ>>>4. Если стоит задача обеспечения переносимости программы, не ориентированной на коммуникации, то .Net годится только для обеспечения коммуникационных сервисов на платформе Windows, а потому и не может быть выбран в качестве основного средства реализации. M>>Подожди. Фраза "не ориентированной на коммуникации" и "для обеспечения коммуникационных сервисов" себе противоречат. Конкретнее, плиз.
ГВ>Нет, противоречия здесь нет. Программа сама по себе может быть и не ориентированной на коммуникации, но в то же время, у неё могут быть отдельные коммуникационные возможности. Тот же самый поиск в отдельных случаях может работать на локальном десктопе, а может — и из-под веб-сервиса. Веб-сервис можно добавить, можно убрать, возможности программы поиска от этого не изменятся.
Здравствуйте, mikа, Вы писали:
ГВ>>Программа сама по себе может быть и не ориентированной на коммуникации, но в то же время, у неё могут быть отдельные коммуникационные возможности. Тот же самый поиск в отдельных случаях может работать на локальном десктопе, а может — и из-под веб-сервиса. Веб-сервис можно добавить, можно убрать, возможности программы поиска от этого не изменятся.
Знаешь, после этого высказывания ты меня навел на одну мысль. Может я покажусь слишком дерзким, тогда заранее прости.
А ты вообще представляешь что такое .NET? Тебя что то все на коммуникацию тянет. Может ассоциации с .NETWORK
Я вот лично не представляю, зачем веб сервису нужно обращаться к локальной программе, написанной, допустим на C++, и возвращать спикой файлов. Почему все это нельзя сразу написать на НЕТ? Возможности у него самые большие. Зачем тогда мучиться и писать что-то на другом языке?
Здравствуйте, mikа, Вы писали:
M>Я вот лично не представляю, зачем веб сервису нужно обращаться к локальной программе, написанной, допустим на C++, и возвращать спикой файлов. Почему все это нельзя сразу написать на НЕТ? Возможности у него самые большие. Зачем тогда мучиться и писать что-то на другом языке?
А как же унаследованный код? А сложные вычисления? Вы вспоминали DataGrid -- но неужели вы хотите и кластерные вычисления для них писать на Шарпе? Вдобавок -- почему мучаться? Сложную вычислительную логику целесообразнее реализовать на С++, а просто сложную -- на Хаскеле. Правда в отношении последнего .Net даёт надежду на простую и безболезненную интеграцию с остальным кодом. За это --
M>Я вот лично не представляю, зачем веб сервису нужно обращаться к локальной программе, написанной, допустим на C++, и
А веб сервис эжто не локальная программа, выполняющаяся на сервере? И какая разница на чем она написана?
Мы не о языковом срекдстве говорим а о технологии (или я один ? )
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
ГВ>1. .Net более всего подходит для построения коммуникационных инфраструктур.
Есть два толкования.
".NET больше подходит для коммуникаций, чем другие среды (напр. J2EE, Corba)"
".NET больше подходит для коммуникаций, чем для других вещей (напр. рисования или мат. функций)"
Похоже, ты имел ввиду второе.
Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. Преимущества вытекают отсюда. Одно из основных — безопасность. Перефразируя твою фразу,
.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры.
Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. Грубо говоря, C со товарищи.
Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры.
Если же говорить о коммуникациях, то тут преимущества, вроде бы, не такие уж принципиальные. Метаданные — да, это то, что упрощает поддержку коммуникаций. Но метаданные есть и в "старых" архитектурах. Например в COM TLB достаточно метаданных, чтобы обеспечить приличные коммуникационные возможности. Ведь известно, что в Win2003 обычные COM-компоненты могут публиковаться как те же веб-сервисы.
Если же сравнивать с Java, то тут я вообще не понимаю, какие особые преимущества есть у .NET. Конечно, всё подчищено, время-то идёт. Assembly/Type identity однозначно определено, custom атрибуты — тоже очень полезное приобретение. Сам IL вроде для JIT-компиляции больше заточен. Но это не столь принципиальные преимущества (ну, разве что атрибуты). То есть коммуникационные возможности Java должны быть, потенциально, сравнимы с .NET.
Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl.
Здравствуйте, mikа, Вы писали:
M>Здравствуйте, Геннадий Васильев, Вы писали:
M>>> SOA стандартных конролов, способных взаимодействовать с Data Access провайдерами ГВ>>Ну, ещё один способ непосредственной связи presentation-layer и data-layer. И что это кардинально меняет?
M>А кто сказал что это data-layer? Вот допустим я написал веб сервис. Он мне возвращает список товаров. Потом создал DataGrid и прибиндил к нему этот сервис. Я разве что то соединил? Нет. Я решил проблему без лишнего гемморного кода. При этом, веб сервис это не уровень доступа данных Это Business уровень, его фасад.
Хорошо, согласен, таким образом ты прикрутил исходящий от сервера поток данных к презентационному слою. Т.е., выполнил работу по коммутированию потока данных. DataGrid написан средствами .Net. Значит, коммуникации + представление. Почти убеждаешь...
Но с другой стороны — собственный продукт Microsoft и окошки бы не умел рисовать? Я DataGrid глубоко не ковырял, но что-то мне подсказывает, что он, всё-таки, как и любой custom control обеспечивается службами самой Windows: очередями сообщений, WM_PAINT-ами и прочим. И ещё: если у тебя вместо плоской таблицы появится древовидная структура, то и вместо DataGrid придётся что-то другое вешать, не правда ли?
M>>> + Obj Spaces ГВ>>А они-то что кардинально меняют?
M>Чесно говоря, я и сам пока не понял зачем их вообще создавали, если все кричали что Юкон, Юкон. Но в любом случае, щас проведу маркетинговую беседу
Ну давай, проводи.
M>Зайди на форум .NET и увидишь, что самый оцененный топик сейчас — это статья ИТ про RSDN.Framework.Data. Неспроста. Маппинг данных народу хочеться, а не возюкаться с SqlXXX классами. Чтоб быстро и эффективно (по времени разработки, разумеется).
Ну, маппинг — тема отдельная и достаточно большая. К дотнету, ИМХО, она относится очень даже косвенно, хотя, если хочешь, то можно поковырять и её. Да, на дотнете CRUD стало делать легко. Но объектно-реляционный маппинг одним только CRUD не ограничивается, это простейшая штуковина, которая при наличии устаканенного подхода к описанию и чтению структуры класса лепится вполпинка почти на любом языке.
M>>> + XML поддержка ГВ>>А что это значит? ИМХО, это всего лишь один из форматов обмена данными, не более того. Да, он применяется везде, где только можно и нельзя, ну и что? ИМХО, LISP-представление значительно удобнее и проще. M>Вообщем, еще одна тема, XML и LISP. M>Xml удобен для общения. Не нужно ничего нового изучать. Вот он протокол и все им пользуйтесь. А что ЛИСП. Я его не знаю. Следовательно, его не знаю и мои сервисы. Какой же он тогда удобный?
Для веб-сервисов, может быть и неудобный. Пока. А так, вобщем-то, покомпактнее XML будет. Да и нет необходимости XSLT изобретать: все трансформации можно описать на том же LISP. Единственное серьёзное отличие: человеку его потруднее читать, чем XML и не так уж он и годится для разметки текста. Ну впрочем, ладно, это к теме не относится.
M>>>Возьмем ASP.NET (Web Forms). Что может хоть близко стоять с это технологией? На мой взгляд, вообще ничего. ГВ>>Докажи. Особенно правомерность обобщения "вообще". ИМХО, рядом с неё может стоять всё, что угодно, что обеспечит определённую платформонезависимость отображения.
M>ASP.NET удобен не своей платформонезависимостью (зачем браузеру знать, какая операционка хостит сервер?). Он предоставляет богатый выбор элементов управления, удобность в доступе данных, отладку, визуальную разработку (ну тут скорее всего спасибо студии), легкость программирования "низов" (аналоги ISAPI фильтров и расширение, которые можно создать в считанные минуты и так же развернуть). Плюс куча разных стартовых движков.
Да, но назначение ASP — работа в коммуникационной среде. Каких бы прибамбасов там ни было, "среда" для ASP всё равно — коммуникационная. Ну, плюс ещё презентативная логика в определённом смысле.
M>>>Возьмем WinForms. Если рассматривать только часть отображения граффического интерфейса, то пока тут могут найтись конкуренты. Но если брать в учет дизайн поддержку, биндинг данных и, в будующем, XAML + Avalon, то конкуренты или быстро превратяться в NET, или вообще исчезнут. ГВ>>Почему? Потому что все будут сметены мегавозможностями Avalon? Неубедительно. Ну год, ну два и появятся преемники, если это кому-нибудь будет нужно. M>Появяться. Сначала Avalon 2. Потом Avalon 3. На самом деле сама технология мне не интересна. Ну там скорость увеличиться, красивее. Мне это все лично по боку. Я первую проблему могу решить покупкой нового компа, вторую — я вообще не люблю попугаев. Но вот интересна сама идея вокруг XAML. Ну что могут предложить "конкуренты". Често говоря, я вижу только одного конкурента языку C# (ниче, если я конкретно). C# Builder
Хорошо, тогда не будем гадать на кофейной гуще. Поживём-посмотрим.
ГВ>>>>2. Не всякая программа (в т.ч. и серверная) лучше всего реализуется средствами, ориентированными на построение коммуникаций. M>>>Не понятно. Ты имелл ввиду background программу, работаущую на сервере? Так зачем ей вообще коммутировать с кем то. ГВ>>Но доступ-то к ней по любому нужен. Другое дело, что основная задача, ради которой она запускается — совсем не коммуникационная, а какая-то ещё. Ну пусть тот же поиск данных, или сбор информации для OLAP.
M>NT Services. Как можно подключиться к контроллеру этих сервисов с другой машины. Через оснастку. Какие тут еще коммуникации. Да, там есть RPC. Но все так хитро скрыто, что не нужно разработчику об этом знать.
Да, нет. Мир одной только NT не ограничивается.
M>Кстати, NT сервисы так же легко и приятно разрабатывать на Нете. Говорю это как программист, писавщий их сначала на голом АПИ, затем на аттрибутном ATL. Позднее на НЕТ.
Да знаю, знаю.
ГВ>>>>3. (Вероятно, самый спорный тезис.) В программе, изначально не ориентированной на коммуникационные сервисы лучше всего предусмотреть просто интерфейс в инфраструктуру .Net, чтобы реализовывать коммуникационные задачи его средствами. M>>>Выше было описано, что лучше максимально реализовать все средствами НЕТ. Конечно, можно нафигачить веб сервисы и общаться с ними на уровне сокетов.
ГВ>>Причём тут сокеты? И зачем делать общаться с веб-сервисами на уровне сокетов?
M>А как ты хочешь с ними общаться?
Ну, я вообще-то думаю, что с веб-сервисами лучше всего через SOAP общаться, а сокеты нужны там, где производительность SOAP не устраивает.
M>В Нете уже есть классы, реализующие определенный слой абстракции. В Яве тоже есть (но я ее рассматриваю как Нет. Тот же мифический тяжеловестный рантайм, те же тормоза, та же легкость в разработке). А в других языках разве что то наблюдается? Да, и тем более, реализуй это, тут же потребуються дополнительные возможности, которые сейчас успешно берет на себя WSE. И эту библиотеку тоже реализовывать!?
Может быть и так, может быть и нет. Во всяком случае, это никак не противоречит тому, что .Net ориентирована в первую очередь на коммуникации и их обслуживание.
M>>>Но, веб сервисы, на мой взгляд, не очень удачное решение для внутрикорпоративного взаимодействия. Так же, что нам предоставляеться к веб сервисам в качестве бесплатного прибамбаса M>>>1) WSE. Очень полезная вещь. Чтобы реализовать для клиента нужную ф-ть, потребудеться очень и очень много времени. ГВ>>Э... а эту аббревиатуру можно раскрыть?
M>Web Services Enhancements. Предоставлял (я его помню по первой версии) шифромание траффика, аутентификацию, транзакционность, легкость в работе с DIME.
Коммуникации.
шифромание траффика — коммуникации
аутентификацию — коммуникации, поскольку решение об авторизации всё равно принимается той системой, что обеспечивает функционирование веб-сервиса
транзакционность — коммуникационная поддержка транзакций, поскольку транзакции реально обеспечиваются базами данных и прочими провайдерами (в некоторых случаях, они могут быть написаны на "чистом" .Net).
DIME — лучше всего на этот счёт скажет MSDN:
DIME and WS-Attachments form a simple and efficient solution for packaging attachments with SOAP messages.
То есть — поддержка коммуникационного протокола.
Вывод: WSE, как и сами веб-сервисы — только коммуникационная приблуда. Хорошая, но коммуникационная.
M>>>2) Indigo (для всех видов коммуникаций). Тут без комментариев. ГВ>>Угу, именно, что для всех видов коммуникаций. Только почему это он в виде бесплатного прибамбаса к веб-сервисам? ИМХО, всё как раз наоброт обстоит. M>Не. Только WSE бесплтаный прибамбас Ладно, а конкретно есть что нить по этому пункту.
Не в платности/бесплатности дело. Всё равно — коммуникационный.
M>Ее на клиенте тоже самому придеться реализовывать?
Только объясни, плз., кого, "её" на клиенте реализоывать?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
ГВ>>>Программа сама по себе может быть и не ориентированной на коммуникации, но в то же время, у неё могут быть отдельные коммуникационные возможности. Тот же самый поиск в отдельных случаях может работать на локальном десктопе, а может — и из-под веб-сервиса. Веб-сервис можно добавить, можно убрать, возможности программы поиска от этого не изменятся.
M>Знаешь, после этого высказывания ты меня навел на одну мысль. Может я покажусь слишком дерзким, тогда заранее прости.
M>А ты вообще представляешь что такое .NET? Тебя что то все на коммуникацию тянет. Может ассоциации с .NETWORK
Да, представляю. Но ассоциации с коммуникациями у меня не из-за .Network, а именно из-за внутренностей самого .Net.
M>Я вот лично не представляю, зачем веб сервису нужно обращаться к локальной программе, написанной, допустим на C++, и возвращать спикой файлов.
Странно... зачем? Затем, чтобы получить от неё какую-то информацию. Или заставить её что-то сделать.
M>Почему все это нельзя сразу написать на НЕТ? Возможности у него самые большие. Зачем тогда мучиться и писать что-то на другом языке?
Ну, Mika... "Возможности у него самые большие." Самые большие по сравнению с чем? Возможности-то большие, вопрос в том, для чего они лучше всего годятся. На VB можно, в принципе, любую программу написать, но не факт, что она позволит удовлетоврить предъявляемым к ней требованиям. Мне приходилось с АБС на VB сталкиваться — так этот монстр на четырёхпроцессорном сервере двух пользователей с трудом обслуживал.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, dad, Вы писали:
dad>Мы не о языковом срекдстве говорим а о технологии (или я один ? )
Не один
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mihailik, Вы писали:
ГВ>>1. .Net более всего подходит для построения коммуникационных инфраструктур. M>Есть два толкования. M>".NET больше подходит для коммуникаций, чем другие среды (напр. J2EE, Corba)" M>".NET больше подходит для коммуникаций, чем для других вещей (напр. рисования или мат. функций)" M>Похоже, ты имел ввиду второе.
Да, именно.
M>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. Преимущества вытекают отсюда. Одно из основных — безопасность. Перефразируя твою фразу, M>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. Грубо говоря, C со товарищи.
Не совсем так. С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". Но с другой стороны, .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость, а заодно и переносимость. Так сказать — fool protection у неё получше. Просто в Java доступ к небезопасным возможностям сложнее, чем в .Net => шаловливые ручонки будут менее шаловливыми. Хм... Вот тебе, бабушка и Юрьев день.
Собственно, безопасность приложения для других обычно обеспечивается механизмами разделения адресных пространств средствами ОС. Более надёжного механизма, ИМХО, ещё не придумали.
M>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры.
Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй...
M>Если же говорить о коммуникациях, то тут преимущества, вроде бы, не такие уж принципиальные. Метаданные — да, это то, что упрощает поддержку коммуникаций. Но метаданные есть и в "старых" архитектурах. Например в COM TLB достаточно метаданных, чтобы обеспечить приличные коммуникационные возможности. Ведь известно, что в Win2003 обычные COM-компоненты могут публиковаться как те же веб-сервисы.
ИМХО, здесь основное преимущество в том, что ты можешь относительно просто отобразить одну и ту же структуру вызовов на разные способы их оформления. Ну, например: COM -> SOAP, COM -> custom, SOAP -> что-то ещё. Что, кстати и подтверждается возможностями Win2003.
M>Если же сравнивать с Java, то тут я вообще не понимаю, какие особые преимущества есть у .NET. Конечно, всё подчищено, время-то идёт. Assembly/Type identity однозначно определено, custom атрибуты — тоже очень полезное приобретение. Сам IL вроде для JIT-компиляции больше заточен. Но это не столь принципиальные преимущества (ну, разве что атрибуты). То есть коммуникационные возможности Java должны быть, потенциально, сравнимы с .NET.
Так они и так сравнимы именно за счёт библиотек. Просто скорость адаптации коммуникационных приложений к "новым веяниям" на Java, ИМХО, будет несколько ниже, чем на .Net. Но опять таки, — не так уж это и принципиально.
M>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl.
Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
dad>>Мы не о языковом срекдстве говорим а о технологии (или я один ? ) ГВ>Не один
Просто топик похож на обсуждение .Net, а в тексте было заявлено о яве.
Помоему даже беглый взгляд показывает, что ява превосходит .net во всех остношениях. Сказывается академический , а не коммерческий подход.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, dad, Вы писали:
dad>>>Мы не о языковом срекдстве говорим а о технологии (или я один ? ) ГВ>>Не один
dad>Просто топик похож на обсуждение .Net, а в тексте было заявлено о яве. dad>Помоему даже беглый взгляд показывает, что ява превосходит .net во всех остношениях.
Ты только очень громко этого не говори.
dad>Сказывается академический , а не коммерческий подход.
Да здесь ещё много тем подняться может. А о Java, ИМХО, не упомянуть просто не получится. Куда ж мы без неё в контексте коммуникаций.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
M>>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. Преимущества вытекают отсюда. Одно из основных — безопасность. Перефразируя твою фразу, M>>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. Грубо говоря, C со товарищи.
ГВ>Не совсем так. С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". Но с другой стороны, .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость
В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
Во всяком случае, я бы не назвал неудобство работы с JNI преимуществом Явы. Хотя это, конечно, и усиливает барьер для издевательств над безопасностью.
M>>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры.
ГВ>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй...
Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
M>>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl.
ГВ>Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить.
Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
R>Вы вспоминали DataGrid -- но неужели вы хотите и кластерные вычисления для них писать на Шарпе?
Смотря какие вычисления. Бизнес-логику, к примеру самое оно — на шарпе.
R> Вдобавок -- почему мучаться? Сложную вычислительную логику целесообразнее реализовать на С++
Это и будет "мучаться". Шарп значительно проще и прозрачнее сей.
R> а просто сложную -- на Хаскеле. Правда в отношении последнего .Net даёт надежду на простую и безболезненную интеграцию с остальным кодом. За это --
Ну, если уж про интеграцию, то C++ грех жаловаться. Интегрироность по самое нехочу.
dad>>Помоему даже беглый взгляд показывает, что ява превосходит .net во всех остношениях.
ГВ>Ты только очень громко этого не говори.
У Явы, по-моему, есть только два серьёзных преимущества:
— накоплено много кода, программистов и общей инерции
— есть реальная переносимость для мощных серверов
dad>>Сказывается академический , а не коммерческий подход.
Вообще-то Ява — более уважаемый в академических кругах язык. Его в любом серьёзном американском универе учат.
ГВ>Да здесь ещё много тем подняться может. А о Java, ИМХО, не упомянуть просто не получится. Куда ж мы без неё в контексте коммуникаций.
А что, в Яве навороченые комуникации? Поделись, товарищ, ты, видно разбираешься в вопросе. Сделай краткий обзорчик для многочисленных дотнетовцев.
dad>>Помоему даже беглый взгляд показывает, что ява превосходит .net во всех остношениях.
ГВ>Ты только очень громко этого не говори.
У Явы, по-моему, есть только два серьёзных преимущества:
— накоплено много кода, программистов и общей инерции
— есть реальная переносимость для мощных серверов
dad>>Сказывается академический , а не коммерческий подход.
Вообще-то Ява — более уважаемый в академических кругах язык. Его в любом серьёзном американском универе учат.
ГВ>Да здесь ещё много тем подняться может. А о Java, ИМХО, не упомянуть просто не получится. Куда ж мы без неё в контексте коммуникаций.
А что, в Яве навороченые комуникации? Поделись, товарищ, ты, видно разбираешься в вопросе. Сделай краткий обзорчик для многочисленных дотнетовцев.
M>>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. Преимущества вытекают отсюда. Одно из основных — безопасность. Перефразируя твою фразу, M>>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. Грубо говоря, C со товарищи.
ГВ>Не совсем так. С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". Но с другой стороны, .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость
В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
Во всяком случае, я бы не назвал неудобство работы с JNI преимуществом Явы. Хотя это, конечно, и усиливает барьер для издевательств над безопасностью.
M>>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры.
ГВ>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй...
Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
M>>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl.
ГВ>Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить.
Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
ГВ>Ну, Mika... "Возможности у него самые большие." Самые большие по сравнению с чем?
На дотнете разработка быстрее происходит. По сравнению со "старыми" языками, конечно. Из-за того, что управляемость+метаданные приносят существенные преимущества.
Ну и плюс библиотеки, если уж не только теорию рассматривать.
Здравствуйте, Геннадий Васильев, Вы писали:
M>>А кто сказал что это data-layer? Вот допустим я написал веб сервис. Он мне возвращает список товаров. Потом создал DataGrid и прибиндил к нему этот сервис. Я разве что то соединил? Нет. Я решил проблему без лишнего гемморного кода. При этом, веб сервис это не уровень доступа данных Это Business уровень, его фасад.
ГВ>Хорошо, согласен, таким образом ты прикрутил исходящий от сервера поток данных к презентационному слою. Т.е., выполнил работу по коммутированию потока данных. DataGrid написан средствами .Net. Значит, коммуникации + представление. Почти убеждаешь...
Если бы увидел корень мысли, то совсем бы убедился и не было сомнений
ГВ>Но с другой стороны — собственный продукт Microsoft и окошки бы не умел рисовать? Я DataGrid глубоко не ковырял, но что-то мне подсказывает, что он, всё-таки, как и любой custom control обеспечивается службами самой Windows: очередями сообщений, WM_PAINT-ами и прочим. И ещё: если у тебя вместо плоской таблицы появится древовидная структура, то и вместо DataGrid придётся что-то другое вешать, не правда ли?
Честно говоря я имел ввиду System.Web.UI.WebControls.DataGrid. Этот не зависит от ОС. Но и если использовать виндовый, то чтобы сделать древовидную структуру не особо нужно что то изобретать. Возьми в пример кучу контоолов такого типа на codeproject.com Наследники от DataGrid, реализующую нужную ф-ть.
M>>Зайди на форум .NET и увидишь, что самый оцененный топик сейчас — это статья ИТ про RSDN.Framework.Data. Неспроста. Маппинг данных народу хочеться, а не возюкаться с SqlXXX классами. Чтоб быстро и эффективно (по времени разработки, разумеется).
ГВ>Ну, маппинг — тема отдельная и достаточно большая. К дотнету, ИМХО, она относится очень даже косвенно, хотя, если хочешь, то можно поковырять и её. Да, на дотнете CRUD стало делать легко. Но объектно-реляционный маппинг одним только CRUD не ограничивается,
Согласен. Но согласись, зачем что то реализовывать, когда вот оно, готовое. Или вы у нас велосипеды предпочитаете?
ГВ>это простейшая штуковина, которая при наличии устаканенного подхода к описанию и чтению структуры класса лепится вполпинка почти на любом языке.
Ну да. Конечно. Я как погляжу на всякие шаблонные классы на C++, так жалко программиство становится.
M>>Xml удобен для общения. Не нужно ничего нового изучать. Вот он протокол и все им пользуйтесь. А что ЛИСП. Я его не знаю. Следовательно, его не знаю и мои сервисы. Какой же он тогда удобный?
ГВ>Для веб-сервисов, может быть и неудобный. Пока. А так, вобщем-то, покомпактнее XML будет. Да и нет необходимости XSLT изобретать: все трансформации можно описать на том же LISP. Единственное серьёзное отличие: человеку его потруднее читать, чем XML и не так уж он и годится для разметки текста. Ну впрочем, ладно, это к теме не относится.
Даже SUN поняла что будующее за XML... Ну, вообщем, ладно. Пишем все на LISP =)
ГВ>Да, но назначение ASP — работа в коммуникационной среде. Каких бы прибамбасов там ни было, "среда" для ASP всё равно — коммуникационная. Ну, плюс ещё презентативная логика в определённом смысле.
Честно говоря, если взглянуть глубже, то ASP это не только коммуникация. Что то мне подсказывает
ГВ>Хорошо, тогда не будем гадать на кофейной гуще. Поживём-посмотрим.
Хм. Дык, ведь уже. Или ты что то другое имеешь ввиду?
M>>NT Services. Как можно подключиться к контроллеру этих сервисов с другой машины. Через оснастку. Какие тут еще коммуникации. Да, там есть RPC. Но все так хитро скрыто, что не нужно разработчику об этом знать.
ГВ>Да, нет. Мир одной только NT не ограничивается.
Ну я имел ввиду подобие. Сервисы, демоны. Как хочешь обзови. В чем вопрос то?
ГВ> Ну, я вообще-то думаю, что с веб-сервисами лучше всего через SOAP общаться,
Я и не знал, что soap стал у нас транспортным протоколом
ГВ>а сокеты нужны там, где производительность SOAP не устраивает.
Честно говоря, я на remoting так могу запрос создать, что он будем измеряться в порядке в несколько байт. Вообщем, сокетный размер пакетов... Я просто часто вижу, как люди не разобравшись в инструменте, категорически его отвергают по каким-то своим внутренним убеждениям. Может сказваеться фраза "Винда must die, Линух рулит"?
M>>В Нете уже есть классы, реализующие определенный слой абстракции. В Яве тоже есть (но я ее рассматриваю как Нет. Тот же мифический тяжеловестный рантайм, те же тормоза, та же легкость в разработке). А в других языках разве что то наблюдается? Да, и тем более, реализуй это, тут же потребуються дополнительные возможности, которые сейчас успешно берет на себя WSE. И эту библиотеку тоже реализовывать!?
ГВ>Может быть и так, может быть и нет. Во всяком случае, это никак не противоречит тому, что .Net ориентирована в первую очередь на коммуникации и их обслуживание.
Давай тогда решим, какие ты типы программ имеешь ввиду, подрузомевая в них "не коммуникативные"
ГВ>Только объясни, плз., кого, "её" на клиенте реализоывать?
Indigo
ГВ>Да, представляю. Но ассоциации с коммуникациями у меня не из-за .Network, а именно из-за внутренностей самого .Net.
не всякий программист .NET может похвастаться, что он знает его внутренности.
ГВ>Странно... зачем? Затем, чтобы получить от неё какую-то информацию. Или заставить её что-то сделать.
Ага. Я просто подумал, что программу написал на нейтив только из-за того, что не любят .NET. Бывают такие
M>>Почему все это нельзя сразу написать на НЕТ? Возможности у него самые большие. Зачем тогда мучиться и писать что-то на другом языке?
ГВ>Самые большие по сравнению с чем?
Скажу громко. Из всего что ты приведешь. Более того, я докажу тебе, что ты плохо подходишь к решению проблемы при выборе нужного инструмента для реализации того или иного программмного продукта. Как пример, описанное тобою ниже.
ГВ>Возможности-то большие, вопрос в том, для чего они лучше всего годятся. На VB можно, в принципе, любую программу написать, но не факт, что она позволит удовлетоврить предъявляемым к ней требованиям. Мне приходилось с АБС на VB сталкиваться — так этот монстр на четырёхпроцессорном сервере двух пользователей с трудом обслуживал.
К чему ты это привел? К тому что ВБ для этого не преднозначен. Так кто бы спорил. Пользуйтесь VB.NET
Здравствуйте, mihailik, Вы писали:
M>> Често говоря, я вижу только одного конкурента языку C# (ниче, если я конкретно). C# Builder
M>Да ладно, какой он конкурент? Компилятор тот же, и среда малость глючноватая.
M>Можно ещё SharpDevelop вспомнить из таких "конкурентов".
SharpDevelop — среда
C# Builder — язык + среда. Удобнее для старта. Тот же Web Matrix тоже ничего. Вообщем, песочница явно видна
Здравствуйте, dad, Вы писали:
M>>Вообще-то Ява — более уважаемый в академических кругах язык. Его в любом серьёзном американском универе учат.
dad>А я о чем????
А у нас Паскалю. О чем это говорит. Только о том, что язык это инструмент. Захочешь — научишь. И не более
M>>>Вообще-то Ява — более уважаемый в академических кругах язык. Его в любом серьёзном американском универе учат.
dad>>А я о чем????
M>А у нас Паскалю. О чем это говорит. Только о том, что язык это инструмент. Захочешь — научишь. И не более
В нормальных институтах языкам не учат, там учат технологиям. А под явой я имею ввиду совокупность технологии
в целом и архитектуру тоже.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, dad, Вы писали:
dad>В нормальных институтах языкам не учат, там учат технологиям. А под явой я имею ввиду совокупность технологии dad>в целом и архитектуру тоже.
Воообще и технологиям не учат Ибо пока учишься они и состариться могут. Обычный факт. Я пока учился, три раза языки менял (и собственно технологии).
Учат методологиям. Вот наверное что ты имеешь ввиду.
dad>>В нормальных институтах языкам не учат, там учат технологиям. А под явой я имею ввиду совокупность технологии dad>>в целом и архитектуру тоже.
M>Воообще и технологиям не учат Ибо пока учишься они и состариться могут. Обычный факт. Я пока учился, три раза языки менял (и собственно технологии).
Там где я учился язык реализации мог быть любым (особенно на старших курсах). Что ты подразумеваешь под технологие?
M>Учат методологиям. Вот наверное что ты имеешь ввиду.
Это кстати, повод для беседы. Что такое технология, а что такое методология.
в курсе преподается теория , лекции например по организации систем управления базами данных, и лабораторные работы по написанию своих хранилищ данных. При написании использовались материалы курса структуры данных, индексы там ввиде b+ дерева и т.д. что из этого явлется технологией а что методологией?
или теория компиляторов в которых применяется
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
M>>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. Преимущества вытекают отсюда. Одно из основных — безопасность. Перефразируя твою фразу, M>>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. Грубо говоря, C со товарищи.
ГВ>Не совсем так. С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". Но с другой стороны, .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость
В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
Во всяком случае, я бы не назвал неудобство работы с JNI преимуществом Явы. Хотя это, конечно, и усиливает барьер для издевательств над безопасностью.
M>>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры.
ГВ>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй...
Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
M>>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl.
ГВ>Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить.
Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
ГВ>Ну, Mika... "Возможности у него самые большие." Самые большие по сравнению с чем?
На дотнете разработка быстрее происходит. По сравнению со "старыми" языками, конечно. Из-за того, что управляемость+метаданные приносят существенные преимущества.
Ну и плюс библиотеки, если уж не только теорию рассматривать.
M>>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. Преимущества вытекают отсюда. Одно из основных — безопасность. Перефразируя твою фразу, M>>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. Грубо говоря, C со товарищи.
ГВ>Не совсем так. С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". Но с другой стороны, .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость
В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
Во всяком случае, я бы не назвал неудобство работы с JNI преимуществом Явы. Хотя это, конечно, и усиливает барьер для издевательств над безопасностью.
M>>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры.
ГВ>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй...
Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
M>>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl.
ГВ>Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить.
Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
M>На дотнете разработка быстрее происходит. По сравнению со "старыми" языками, конечно. Из-за того, что управляемость+метаданные приносят существенные преимущества.
M>Ну и плюс библиотеки, если уж не только теорию рассматривать.
замучил лошить уже пятый раз получаю этот пост..
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
M>>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. Преимущества вытекают отсюда. Одно из основных — безопасность. Перефразируя твою фразу, M>>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. Грубо говоря, C со товарищи.
ГВ>Не совсем так. С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". Но с другой стороны, .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость
В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
Во всяком случае, я бы не назвал неудобство работы с JNI преимуществом Явы. Хотя это, конечно, и усиливает барьер для издевательств над безопасностью.
M>>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры.
ГВ>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй...
Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
M>>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl.
ГВ>Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить.
Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
M>>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. Преимущества вытекают отсюда. Одно из основных — безопасность. Перефразируя твою фразу, M>>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. Грубо говоря, C со товарищи.
ГВ>Не совсем так. С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". Но с другой стороны, .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость
В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
Во всяком случае, я бы не назвал неудобство работы с JNI преимуществом Явы. Хотя это, конечно, и усиливает барьер для издевательств над безопасностью.
M>>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры.
ГВ>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй...
Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
M>>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl.
ГВ>Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить.
Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
M>>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. Преимущества вытекают отсюда. Одно из основных — безопасность. Перефразируя твою фразу, M>>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. Грубо говоря, C со товарищи.
ГВ>Не совсем так. С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". Но с другой стороны, .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость
В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
Во всяком случае, я бы не назвал неудобство работы с JNI преимуществом Явы. Хотя это, конечно, и усиливает барьер для издевательств над безопасностью.
M>>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры.
ГВ>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй...
Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
M>>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl.
ГВ>Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить.
Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
dad>>Помоему даже беглый взгляд показывает, что ява превосходит .net во всех остношениях.
ГВ>Ты только очень громко этого не говори.
У Явы, по-моему, есть только два серьёзных преимущества:
— накоплено много кода, программистов и общей инерции
— есть реальная переносимость для мощных серверов
dad>>Сказывается академический , а не коммерческий подход.
Вообще-то Ява — более уважаемый в академических кругах язык. Его в любом серьёзном американском универе учат.
ГВ>Да здесь ещё много тем подняться может. А о Java, ИМХО, не упомянуть просто не получится. Куда ж мы без неё в контексте коммуникаций.
А что, в Яве навороченые комуникации? Поделись, товарищ, ты, видно разбираешься в вопросе. Сделай краткий обзорчик для многочисленных дотнетовцев.
M>>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. Преимущества вытекают отсюда. Одно из основных — безопасность. Перефразируя твою фразу, M>>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. Грубо говоря, C со товарищи.
ГВ>Не совсем так. С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". Но с другой стороны, .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость
В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
Во всяком случае, я бы не назвал неудобство работы с JNI преимуществом Явы. Хотя это, конечно, и усиливает барьер для издевательств над безопасностью.
M>>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры.
ГВ>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй...
Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
M>>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl.
ГВ>Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить.
Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
Здравствуйте, mikа, Вы писали:
M>>>А кто сказал что это data-layer? Вот допустим я написал веб сервис. Он мне возвращает список товаров. Потом создал DataGrid и прибиндил к нему этот сервис. Я разве что то соединил? Нет. Я решил проблему без лишнего гемморного кода. При этом, веб сервис это не уровень доступа данных Это Business уровень, его фасад. ГВ>>Хорошо, согласен, таким образом ты прикрутил исходящий от сервера поток данных к презентационному слою. Т.е., выполнил работу по коммутированию потока данных. DataGrid написан средствами .Net. Значит, коммуникации + представление. Почти убеждаешь...
M>Если бы увидел корень мысли, то совсем бы убедился и не было сомнений
Озвучь тогда корень мысли. Она же твоя. Пока что я понял то, что было понятно и раньше. Ключевое слово "фасад", т.е. — обеспечение коммуникаций в том или ином смысле.
На самом деле, "геморрный код", о котором ты говоришь, появляется, только тогда, когда архитектура перекошена в пользу презентационного слоя и никто не думает о возможной мутации софта. А байндинг — это вообще мелочи. Приятные, конечно, но мелочи.
ГВ>>Но с другой стороны — собственный продукт Microsoft и окошки бы не умел рисовать? Я DataGrid глубоко не ковырял, но что-то мне подсказывает, что он, всё-таки, как и любой custom control обеспечивается службами самой Windows: очередями сообщений, WM_PAINT-ами и прочим. И ещё: если у тебя вместо плоской таблицы появится древовидная структура, то и вместо DataGrid придётся что-то другое вешать, не правда ли?
M>Честно говоря я имел ввиду System.Web.UI.WebControls.DataGrid. Этот не зависит от ОС. Но и если использовать виндовый, то чтобы сделать древовидную структуру не особо нужно что то изобретать. Возьми в пример кучу контоолов такого типа на codeproject.com Наследники от DataGrid, реализующую нужную ф-ть.
Вобщем-то, как ни поверни, а всё равно только интерейс пользователя получается.
M>>>Зайди на форум .NET и увидишь, что самый оцененный топик сейчас — это статья ИТ про RSDN.Framework.Data. Неспроста. Маппинг данных народу хочеться, а не возюкаться с SqlXXX классами. Чтоб быстро и эффективно (по времени разработки, разумеется). ГВ>>Ну, маппинг — тема отдельная и достаточно большая. К дотнету, ИМХО, она относится очень даже косвенно, хотя, если хочешь, то можно поковырять и её. Да, на дотнете CRUD стало делать легко. Но объектно-реляционный маппинг одним только CRUD не ограничивается, M>Согласен. Но согласись, зачем что то реализовывать, когда вот оно, готовое. Или вы у нас велосипеды предпочитаете?
Э... "за морем телушка — полушка, да рупь перевоз". Знаешь такую пословицу? По мне, так лучше за неделю сделать простенький CRUD теми средствами, которые под рукой, чем тащить весь .Net и ещё интерфейс к нему.
M>>>Xml удобен для общения. Не нужно ничего нового изучать. Вот он протокол и все им пользуйтесь. А что ЛИСП. Я его не знаю. Следовательно, его не знаю и мои сервисы. Какой же он тогда удобный? ГВ>>Для веб-сервисов, может быть и неудобный. Пока. А так, вобщем-то, покомпактнее XML будет. Да и нет необходимости XSLT изобретать: все трансформации можно описать на том же LISP. Единственное серьёзное отличие: человеку его потруднее читать, чем XML и не так уж он и годится для разметки текста. Ну впрочем, ладно, это к теме не относится. M>Даже SUN поняла что будующее за XML... Ну, вообщем, ладно. Пишем все на LISP =)
Личные проблемы Sun. Хорошо , но дело не в этом. ИМХО, использование XML на уровне коммуникаций вообще... кхм, не очень хорошая практика.
ГВ>>Да, но назначение ASP — работа в коммуникационной среде. Каких бы прибамбасов там ни было, "среда" для ASP всё равно — коммуникационная. Ну, плюс ещё презентативная логика в определённом смысле. M>Честно говоря, если взглянуть глубже, то ASP это не только коммуникация. Что то мне подсказывает
Да, конечно, не только коммуникация. Ещё и генерация страниц для интерфейса пользователя. Даже частично бизнес-логику на нём делают. Даже иногда полностью. Я не спорю, что ASP.NET — относительно хорошая штука, хотя на самом деле с её помощью (как и с ASP) запросто создаётся перекос в сторону "программирования на форме". Впрочем, это ещё с Delphi и VB пошло...
Но только всё равно контекст его применения ограничивается пользовательским интерфейсом к Web-приложениям. Интересно, для desktop-варианта тоже нужно интерфейс пользователя средствами ASP.NET городить?
ГВ>>Хорошо, тогда не будем гадать на кофейной гуще. Поживём-посмотрим. M>Хм. Дык, ведь уже. Или ты что то другое имеешь ввиду?
Не знаю. Знаю только, что свято место пусто не бывает, и на него всегда много желающих.
[...]
ГВ>> Ну, я вообще-то думаю, что с веб-сервисами лучше всего через SOAP общаться, M>Я и не знал, что soap стал у нас транспортным протоколом
Я и не думал, что ты имеешь ввиду транспортный протокол.
ГВ>>а сокеты нужны там, где производительность SOAP не устраивает. M>Честно говоря, я на remoting так могу запрос создать, что он будем измеряться в порядке в несколько байт. Вообщем, сокетный размер пакетов...
А причём тут remoting? Это, кстати, тоже сугубо коммуникационная приблуда. Необходимость в нём "резко уничтожается", если на обоих машинах установлены одни и те же версии софта. Вопрос, собственно не в том, чтобы найти "наилучший" способ передать объект или его интерфейс на другую машину. Проблема в том, чтобы допустить все приколы линий связи в той или иной точке обработки, т.е. — определить концепцию "разнесения" объектов. А remoting у нас в качестве реализации или просто проинсталлированы соответствующие библиотеки на обоих машинах, или что-то ещё — это уж дело тридесятое.
Не знаю, как тебе, а мне что-то подсказывает, что совсем не все серверные объекты ездят на клиента.
M>Я просто часто вижу, как люди не разобравшись в инструменте, категорически его отвергают по каким-то своим внутренним убеждениям.
Я тоже такое часто вижу. Но я ведь и не отвергаю .Net Зачем?
M>>>В Нете уже есть классы, реализующие определенный слой абстракции. В Яве тоже есть (но я ее рассматриваю как Нет. Тот же мифический тяжеловестный рантайм, те же тормоза, та же легкость в разработке). А в других языках разве что то наблюдается? Да, и тем более, реализуй это, тут же потребуються дополнительные возможности, которые сейчас успешно берет на себя WSE. И эту библиотеку тоже реализовывать!?
ГВ>>Может быть и так, может быть и нет. Во всяком случае, это никак не противоречит тому, что .Net ориентирована в первую очередь на коммуникации и их обслуживание. M>Давай тогда решим, какие ты типы программ имеешь ввиду, подрузомевая в них "не коммуникативные"
Как ни странно, но в первую очередь — бизнес-софт, который по моим наблюдениям часто делается с допуском "отмеряй микрометром — отрубай топором".
ГВ>>Только объясни, плз., кого, "её" на клиенте реализоывать? M>Indigo
Зачем? Если клиент предоставляет пользователю исключительно UI, то ему весь букет Indigo даром не нужен. По-любому в таком случае нужен отдельный серверный модуль, который будет раскидывать поток данных от пользователя по программам-получателям.
ГВ>>Да, представляю. Но ассоциации с коммуникациями у меня не из-за .Network, а именно из-за внутренностей самого .Net. M>не всякий программист .NET может похвастаться, что он знает его внутренности.
Ты мне льстишь.
M>>>Почему все это нельзя сразу написать на НЕТ? Возможности у него самые большие. Зачем тогда мучиться и писать что-то на другом языке? ГВ>>Самые большие по сравнению с чем? M>Скажу громко. Из всего что ты приведешь.
Не хило. Тогда привожу пример: переносимая CRM-система. Нужно обеспечить переносимость серверной части: Sparc-Wintel-Linux-FreeBSD. Клиенты могут сидеть на Linux, MacOS и Wintel. Переносимость серверной части — для того, чтобы можно было продать подороже/подешевле при случае. Переносимость клиентской части — вполне реальная потребность, например, для издательского дома. Ну правда, для них, скорее MacOS + Wintel. Ну... ещё присовокупим сюда необходимость интеграции всего этого хозяйства с... ну, например 1С и почтовыми шлюзами.
M>Более того, я докажу тебе, что ты плохо подходишь к решению проблемы при выборе нужного инструмента для реализации того или иного программмного продукта. Как пример, описанное тобою ниже.
Если ты думаешь, что это я писал эту АБС, то крупно ошибаешься. Если думаешь, что я тебя буду однозначно агитировать "за C++" во всех случаях, то тоже крупно ошибаешься.
ГВ>>Возможности-то большие, вопрос в том, для чего они лучше всего годятся. На VB можно, в принципе, любую программу написать, но не факт, что она позволит удовлетоврить предъявляемым к ней требованиям. Мне приходилось с АБС на VB сталкиваться — так этот монстр на четырёхпроцессорном сервере двух пользователей с трудом обслуживал. M>К чему ты это привел? К тому что ВБ для этого не преднозначен. Так кто бы спорил. Пользуйтесь VB.NET
К тому, что многое на многом можно написать. "вопрос в том, для чего они лучше всего годятся".
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
[цитаты малость урезаны] M>>>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. M>>>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>>>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. ГВ>>С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость M>В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
ИМХО, если для приложения требуется unsafe, то ему его всё равно дадут. Вопрос на самом деле в том, насколько легко потребовать unsafe. Собственно, его применение как раз накрывает медным тазом всю переносимость и для Java и для .Net.
M>>>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры. ГВ>>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй... M>Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
Пусть стреляет. Но тогда реальной переносимости между процессорными архитектурами совсем не получается.
M>>>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl. ГВ>>Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить. M>Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
Или ASP.ONE. Впрочем, это уже совсем другая история. Главное другое: xxxxx Server Pages — по сути обеспечивают коммуникации (ИМХО), а точнее — коммуникацию пользователя с программой в среде Web. Так что, это ничего под Луной не меняет.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
M>>>А кто сказал что это data-layer? Вот допустим я написал веб сервис. Он мне возвращает список товаров. Потом создал DataGrid и прибиндил к нему этот сервис. Я разве что то соединил? Нет. Я решил проблему без лишнего гемморного кода. При этом, веб сервис это не уровень доступа данных Это Business уровень, его фасад. ГВ>>Хорошо, согласен, таким образом ты прикрутил исходящий от сервера поток данных к презентационному слою. Т.е., выполнил работу по коммутированию потока данных. DataGrid написан средствами .Net. Значит, коммуникации + представление. Почти убеждаешь...
M>Если бы увидел корень мысли, то совсем бы убедился и не было сомнений
Озвучь тогда корень мысли. Она же твоя. Пока что я понял то, что было понятно и раньше. Ключевое слово "фасад", т.е. — обеспечение коммуникаций в том или ином смысле.
На самом деле, "геморрный код", о котором ты говоришь, появляется, только тогда, когда архитектура перекошена в пользу презентационного слоя и никто не думает о возможной мутации софта. А байндинг — это вообще мелочи. Приятные, конечно, но мелочи.
ГВ>>Но с другой стороны — собственный продукт Microsoft и окошки бы не умел рисовать? Я DataGrid глубоко не ковырял, но что-то мне подсказывает, что он, всё-таки, как и любой custom control обеспечивается службами самой Windows: очередями сообщений, WM_PAINT-ами и прочим. И ещё: если у тебя вместо плоской таблицы появится древовидная структура, то и вместо DataGrid придётся что-то другое вешать, не правда ли?
M>Честно говоря я имел ввиду System.Web.UI.WebControls.DataGrid. Этот не зависит от ОС. Но и если использовать виндовый, то чтобы сделать древовидную структуру не особо нужно что то изобретать. Возьми в пример кучу контоолов такого типа на codeproject.com Наследники от DataGrid, реализующую нужную ф-ть.
Вобщем-то, как ни поверни, а всё равно только интерейс пользователя получается.
M>>>Зайди на форум .NET и увидишь, что самый оцененный топик сейчас — это статья ИТ про RSDN.Framework.Data. Неспроста. Маппинг данных народу хочеться, а не возюкаться с SqlXXX классами. Чтоб быстро и эффективно (по времени разработки, разумеется). ГВ>>Ну, маппинг — тема отдельная и достаточно большая. К дотнету, ИМХО, она относится очень даже косвенно, хотя, если хочешь, то можно поковырять и её. Да, на дотнете CRUD стало делать легко. Но объектно-реляционный маппинг одним только CRUD не ограничивается, M>Согласен. Но согласись, зачем что то реализовывать, когда вот оно, готовое. Или вы у нас велосипеды предпочитаете?
Э... "за морем телушка — полушка, да рупь перевоз". Знаешь такую пословицу? По мне, так лучше за неделю сделать простенький CRUD теми средствами, которые под рукой, чем тащить весь .Net и ещё интерфейс к нему.
M>>>Xml удобен для общения. Не нужно ничего нового изучать. Вот он протокол и все им пользуйтесь. А что ЛИСП. Я его не знаю. Следовательно, его не знаю и мои сервисы. Какой же он тогда удобный? ГВ>>Для веб-сервисов, может быть и неудобный. Пока. А так, вобщем-то, покомпактнее XML будет. Да и нет необходимости XSLT изобретать: все трансформации можно описать на том же LISP. Единственное серьёзное отличие: человеку его потруднее читать, чем XML и не так уж он и годится для разметки текста. Ну впрочем, ладно, это к теме не относится. M>Даже SUN поняла что будующее за XML... Ну, вообщем, ладно. Пишем все на LISP =)
Личные проблемы Sun. Хорошо , но дело не в этом. ИМХО, использование XML на уровне коммуникаций вообще... кхм, не очень хорошая практика.
ГВ>>Да, но назначение ASP — работа в коммуникационной среде. Каких бы прибамбасов там ни было, "среда" для ASP всё равно — коммуникационная. Ну, плюс ещё презентативная логика в определённом смысле. M>Честно говоря, если взглянуть глубже, то ASP это не только коммуникация. Что то мне подсказывает
Да, конечно, не только коммуникация. Ещё и генерация страниц для интерфейса пользователя. Даже частично бизнес-логику на нём делают. Даже иногда полностью. Я не спорю, что ASP.NET — относительно хорошая штука, хотя на самом деле с её помощью (как и с ASP) запросто создаётся перекос в сторону "программирования на форме". Впрочем, это ещё с Delphi и VB пошло...
Но только всё равно контекст его применения ограничивается пользовательским интерфейсом к Web-приложениям. Интересно, для desktop-варианта тоже нужно интерфейс пользователя средствами ASP.NET городить?
ГВ>>Хорошо, тогда не будем гадать на кофейной гуще. Поживём-посмотрим. M>Хм. Дык, ведь уже. Или ты что то другое имеешь ввиду?
Не знаю. Знаю только, что свято место пусто не бывает, и на него всегда много желающих.
[...]
ГВ>> Ну, я вообще-то думаю, что с веб-сервисами лучше всего через SOAP общаться, M>Я и не знал, что soap стал у нас транспортным протоколом
Я и не думал, что ты имеешь ввиду транспортный протокол.
ГВ>>а сокеты нужны там, где производительность SOAP не устраивает. M>Честно говоря, я на remoting так могу запрос создать, что он будем измеряться в порядке в несколько байт. Вообщем, сокетный размер пакетов...
А причём тут remoting? Это, кстати, тоже сугубо коммуникационная приблуда. Необходимость в нём "резко уничтожается", если на обоих машинах установлены одни и те же версии софта. Вопрос, собственно не в том, чтобы найти "наилучший" способ передать объект или его интерфейс на другую машину. Проблема в том, чтобы допустить все приколы линий связи в той или иной точке обработки, т.е. — определить концепцию "разнесения" объектов. А remoting у нас в качестве реализации или просто проинсталлированы соответствующие библиотеки на обоих машинах, или что-то ещё — это уж дело тридесятое.
Не знаю, как тебе, а мне что-то подсказывает, что совсем не все серверные объекты ездят на клиента.
M>Я просто часто вижу, как люди не разобравшись в инструменте, категорически его отвергают по каким-то своим внутренним убеждениям.
Я тоже такое часто вижу. Но я ведь и не отвергаю .Net Зачем?
M>>>В Нете уже есть классы, реализующие определенный слой абстракции. В Яве тоже есть (но я ее рассматриваю как Нет. Тот же мифический тяжеловестный рантайм, те же тормоза, та же легкость в разработке). А в других языках разве что то наблюдается? Да, и тем более, реализуй это, тут же потребуються дополнительные возможности, которые сейчас успешно берет на себя WSE. И эту библиотеку тоже реализовывать!?
ГВ>>Может быть и так, может быть и нет. Во всяком случае, это никак не противоречит тому, что .Net ориентирована в первую очередь на коммуникации и их обслуживание. M>Давай тогда решим, какие ты типы программ имеешь ввиду, подрузомевая в них "не коммуникативные"
Как ни странно, но в первую очередь — бизнес-софт, который по моим наблюдениям часто делается с допуском "отмеряй микрометром — отрубай топором".
ГВ>>Только объясни, плз., кого, "её" на клиенте реализоывать? M>Indigo
Зачем? Если клиент предоставляет пользователю исключительно UI, то ему весь букет Indigo даром не нужен. По-любому в таком случае нужен отдельный серверный модуль, который будет раскидывать поток данных от пользователя по программам-получателям.
ГВ>>Да, представляю. Но ассоциации с коммуникациями у меня не из-за .Network, а именно из-за внутренностей самого .Net. M>не всякий программист .NET может похвастаться, что он знает его внутренности.
Ты мне льстишь.
M>>>Почему все это нельзя сразу написать на НЕТ? Возможности у него самые большие. Зачем тогда мучиться и писать что-то на другом языке? ГВ>>Самые большие по сравнению с чем? M>Скажу громко. Из всего что ты приведешь.
Не хило. Тогда привожу пример: переносимая CRM-система. Нужно обеспечить переносимость серверной части: Sparc-Wintel-Linux-FreeBSD. Клиенты могут сидеть на Linux, MacOS и Wintel. Переносимость серверной части — для того, чтобы можно было продать подороже/подешевле при случае. Переносимость клиентской части — вполне реальная потребность, например, для издательского дома. Ну правда, для них, скорее MacOS + Wintel. Ну... ещё присовокупим сюда необходимость интеграции всего этого хозяйства с... ну, например 1С и почтовыми шлюзами.
M>Более того, я докажу тебе, что ты плохо подходишь к решению проблемы при выборе нужного инструмента для реализации того или иного программмного продукта. Как пример, описанное тобою ниже.
Если ты думаешь, что это я писал эту АБС, то крупно ошибаешься. Если думаешь, что я тебя буду однозначно агитировать "за C++" во всех случаях, то тоже крупно ошибаешься.
ГВ>>Возможности-то большие, вопрос в том, для чего они лучше всего годятся. На VB можно, в принципе, любую программу написать, но не факт, что она позволит удовлетоврить предъявляемым к ней требованиям. Мне приходилось с АБС на VB сталкиваться — так этот монстр на четырёхпроцессорном сервере двух пользователей с трудом обслуживал. M>К чему ты это привел? К тому что ВБ для этого не преднозначен. Так кто бы спорил. Пользуйтесь VB.NET
К тому, что многое на многом можно написать. "вопрос в том, для чего они лучше всего годятся".
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
[цитаты малость урезаны] M>>>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. M>>>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>>>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. ГВ>>С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость M>В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
ИМХО, если для приложения требуется unsafe, то ему его всё равно дадут. Вопрос на самом деле в том, насколько легко потребовать unsafe. Собственно, его применение как раз накрывает медным тазом всю переносимость и для Java и для .Net.
M>>>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры. ГВ>>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй... M>Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
Пусть стреляет. Но тогда реальной переносимости между процессорными архитектурами совсем не получается.
M>>>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl. ГВ>>Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить. M>Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
Или ASP.ONE. Впрочем, это уже совсем другая история. Главное другое: xxxxx Server Pages — по сути обеспечивают коммуникации (ИМХО), а точнее — коммуникацию пользователя с программой в среде Web. Так что, это ничего под Луной не меняет.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mihailik, Вы писали:
dad>>>Помоему даже беглый взгляд показывает, что ява превосходит .net во всех остношениях. ГВ>>Ты только очень громко этого не говори. M>У Явы, по-моему, есть только два серьёзных преимущества: M>— накоплено много кода, программистов и общей инерции M>— есть реальная переносимость для мощных серверов
Эти преимущества не так уж мало стОят. Особенно второе.
ГВ>>Да здесь ещё много тем подняться может. А о Java, ИМХО, не упомянуть просто не получится. Куда ж мы без неё в контексте коммуникаций.
M>А что, в Яве навороченые комуникации?
Вопрос не в навороченности коммуникаций, а в контексте обсуждения.
M>Может, мы какие идеи себе приспособим
Основная идея лежит на поверхности и давно уже приспособлена и COM, и CORBA, и Java, и .Net: и называется она — интерфейсы.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
M>>>А кто сказал что это data-layer? Вот допустим я написал веб сервис. Он мне возвращает список товаров. Потом создал DataGrid и прибиндил к нему этот сервис. Я разве что то соединил? Нет. Я решил проблему без лишнего гемморного кода. При этом, веб сервис это не уровень доступа данных Это Business уровень, его фасад. ГВ>>Хорошо, согласен, таким образом ты прикрутил исходящий от сервера поток данных к презентационному слою. Т.е., выполнил работу по коммутированию потока данных. DataGrid написан средствами .Net. Значит, коммуникации + представление. Почти убеждаешь...
M>Если бы увидел корень мысли, то совсем бы убедился и не было сомнений
Озвучь тогда корень мысли. Она же твоя. Пока что я понял то, что было понятно и раньше. Ключевое слово "фасад", т.е. — обеспечение коммуникаций в том или ином смысле.
На самом деле, "геморрный код", о котором ты говоришь, появляется, только тогда, когда архитектура перекошена в пользу презентационного слоя и никто не думает о возможной мутации софта. А байндинг — это вообще мелочи. Приятные, конечно, но мелочи.
ГВ>>Но с другой стороны — собственный продукт Microsoft и окошки бы не умел рисовать? Я DataGrid глубоко не ковырял, но что-то мне подсказывает, что он, всё-таки, как и любой custom control обеспечивается службами самой Windows: очередями сообщений, WM_PAINT-ами и прочим. И ещё: если у тебя вместо плоской таблицы появится древовидная структура, то и вместо DataGrid придётся что-то другое вешать, не правда ли?
M>Честно говоря я имел ввиду System.Web.UI.WebControls.DataGrid. Этот не зависит от ОС. Но и если использовать виндовый, то чтобы сделать древовидную структуру не особо нужно что то изобретать. Возьми в пример кучу контоолов такого типа на codeproject.com Наследники от DataGrid, реализующую нужную ф-ть.
Вобщем-то, как ни поверни, а всё равно только интерейс пользователя получается.
M>>>Зайди на форум .NET и увидишь, что самый оцененный топик сейчас — это статья ИТ про RSDN.Framework.Data. Неспроста. Маппинг данных народу хочеться, а не возюкаться с SqlXXX классами. Чтоб быстро и эффективно (по времени разработки, разумеется). ГВ>>Ну, маппинг — тема отдельная и достаточно большая. К дотнету, ИМХО, она относится очень даже косвенно, хотя, если хочешь, то можно поковырять и её. Да, на дотнете CRUD стало делать легко. Но объектно-реляционный маппинг одним только CRUD не ограничивается, M>Согласен. Но согласись, зачем что то реализовывать, когда вот оно, готовое. Или вы у нас велосипеды предпочитаете?
Э... "за морем телушка — полушка, да рупь перевоз". Знаешь такую пословицу? По мне, так лучше за неделю сделать простенький CRUD теми средствами, которые под рукой, чем тащить весь .Net и ещё интерфейс к нему.
M>>>Xml удобен для общения. Не нужно ничего нового изучать. Вот он протокол и все им пользуйтесь. А что ЛИСП. Я его не знаю. Следовательно, его не знаю и мои сервисы. Какой же он тогда удобный? ГВ>>Для веб-сервисов, может быть и неудобный. Пока. А так, вобщем-то, покомпактнее XML будет. Да и нет необходимости XSLT изобретать: все трансформации можно описать на том же LISP. Единственное серьёзное отличие: человеку его потруднее читать, чем XML и не так уж он и годится для разметки текста. Ну впрочем, ладно, это к теме не относится. M>Даже SUN поняла что будующее за XML... Ну, вообщем, ладно. Пишем все на LISP =)
Личные проблемы Sun. Хорошо , но дело не в этом. ИМХО, использование XML на уровне коммуникаций вообще... кхм, не очень хорошая практика.
ГВ>>Да, но назначение ASP — работа в коммуникационной среде. Каких бы прибамбасов там ни было, "среда" для ASP всё равно — коммуникационная. Ну, плюс ещё презентативная логика в определённом смысле. M>Честно говоря, если взглянуть глубже, то ASP это не только коммуникация. Что то мне подсказывает
Да, конечно, не только коммуникация. Ещё и генерация страниц для интерфейса пользователя. Даже частично бизнес-логику на нём делают. Даже иногда полностью. Я не спорю, что ASP.NET — относительно хорошая штука, хотя на самом деле с её помощью (как и с ASP) запросто создаётся перекос в сторону "программирования на форме". Впрочем, это ещё с Delphi и VB пошло...
Но только всё равно контекст его применения ограничивается пользовательским интерфейсом к Web-приложениям. Интересно, для desktop-варианта тоже нужно интерфейс пользователя средствами ASP.NET городить?
ГВ>>Хорошо, тогда не будем гадать на кофейной гуще. Поживём-посмотрим. M>Хм. Дык, ведь уже. Или ты что то другое имеешь ввиду?
Не знаю. Знаю только, что свято место пусто не бывает, и на него всегда много желающих.
[...]
ГВ>> Ну, я вообще-то думаю, что с веб-сервисами лучше всего через SOAP общаться, M>Я и не знал, что soap стал у нас транспортным протоколом
Я и не думал, что ты имеешь ввиду транспортный протокол.
ГВ>>а сокеты нужны там, где производительность SOAP не устраивает. M>Честно говоря, я на remoting так могу запрос создать, что он будем измеряться в порядке в несколько байт. Вообщем, сокетный размер пакетов...
А причём тут remoting? Это, кстати, тоже сугубо коммуникационная приблуда. Необходимость в нём "резко уничтожается", если на обоих машинах установлены одни и те же версии софта. Вопрос, собственно не в том, чтобы найти "наилучший" способ передать объект или его интерфейс на другую машину. Проблема в том, чтобы допустить все приколы линий связи в той или иной точке обработки, т.е. — определить концепцию "разнесения" объектов. А remoting у нас в качестве реализации или просто проинсталлированы соответствующие библиотеки на обоих машинах, или что-то ещё — это уж дело тридесятое.
Не знаю, как тебе, а мне что-то подсказывает, что совсем не все серверные объекты ездят на клиента.
M>Я просто часто вижу, как люди не разобравшись в инструменте, категорически его отвергают по каким-то своим внутренним убеждениям.
Я тоже такое часто вижу. Но я ведь и не отвергаю .Net Зачем?
M>>>В Нете уже есть классы, реализующие определенный слой абстракции. В Яве тоже есть (но я ее рассматриваю как Нет. Тот же мифический тяжеловестный рантайм, те же тормоза, та же легкость в разработке). А в других языках разве что то наблюдается? Да, и тем более, реализуй это, тут же потребуються дополнительные возможности, которые сейчас успешно берет на себя WSE. И эту библиотеку тоже реализовывать!?
ГВ>>Может быть и так, может быть и нет. Во всяком случае, это никак не противоречит тому, что .Net ориентирована в первую очередь на коммуникации и их обслуживание. M>Давай тогда решим, какие ты типы программ имеешь ввиду, подрузомевая в них "не коммуникативные"
Как ни странно, но в первую очередь — бизнес-софт, который по моим наблюдениям часто делается с допуском "отмеряй микрометром — отрубай топором".
ГВ>>Только объясни, плз., кого, "её" на клиенте реализоывать? M>Indigo
Зачем? Если клиент предоставляет пользователю исключительно UI, то ему весь букет Indigo даром не нужен. По-любому в таком случае нужен отдельный серверный модуль, который будет раскидывать поток данных от пользователя по программам-получателям.
ГВ>>Да, представляю. Но ассоциации с коммуникациями у меня не из-за .Network, а именно из-за внутренностей самого .Net. M>не всякий программист .NET может похвастаться, что он знает его внутренности.
Ты мне льстишь.
M>>>Почему все это нельзя сразу написать на НЕТ? Возможности у него самые большие. Зачем тогда мучиться и писать что-то на другом языке? ГВ>>Самые большие по сравнению с чем? M>Скажу громко. Из всего что ты приведешь.
Не хило. Тогда привожу пример: переносимая CRM-система. Нужно обеспечить переносимость серверной части: Sparc-Wintel-Linux-FreeBSD. Клиенты могут сидеть на Linux, MacOS и Wintel. Переносимость серверной части — для того, чтобы можно было продать подороже/подешевле при случае. Переносимость клиентской части — вполне реальная потребность, например, для издательского дома. Ну правда, для них, скорее MacOS + Wintel. Ну... ещё присовокупим сюда необходимость интеграции всего этого хозяйства с... ну, например 1С и почтовыми шлюзами.
M>Более того, я докажу тебе, что ты плохо подходишь к решению проблемы при выборе нужного инструмента для реализации того или иного программмного продукта. Как пример, описанное тобою ниже.
Если ты думаешь, что это я писал эту АБС, то крупно ошибаешься. Если думаешь, что я тебя буду однозначно агитировать "за C++" во всех случаях, то тоже крупно ошибаешься.
ГВ>>Возможности-то большие, вопрос в том, для чего они лучше всего годятся. На VB можно, в принципе, любую программу написать, но не факт, что она позволит удовлетоврить предъявляемым к ней требованиям. Мне приходилось с АБС на VB сталкиваться — так этот монстр на четырёхпроцессорном сервере двух пользователей с трудом обслуживал. M>К чему ты это привел? К тому что ВБ для этого не преднозначен. Так кто бы спорил. Пользуйтесь VB.NET
К тому, что многое на многом можно написать. "вопрос в том, для чего они лучше всего годятся".
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
[цитаты малость урезаны] M>>>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. M>>>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>>>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. ГВ>>С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость M>В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
ИМХО, если для приложения требуется unsafe, то ему его всё равно дадут. Вопрос на самом деле в том, насколько легко потребовать unsafe. Собственно, его применение как раз накрывает медным тазом всю переносимость и для Java и для .Net.
M>>>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры. ГВ>>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй... M>Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
Пусть стреляет. Но тогда реальной переносимости между процессорными архитектурами совсем не получается.
M>>>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl. ГВ>>Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить. M>Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
Или ASP.ONE. Впрочем, это уже совсем другая история. Главное другое: xxxxx Server Pages — по сути обеспечивают коммуникации (ИМХО), а точнее — коммуникацию пользователя с программой в среде Web. Так что, это ничего под Луной не меняет.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mihailik, Вы писали:
dad>>>Помоему даже беглый взгляд показывает, что ява превосходит .net во всех остношениях. ГВ>>Ты только очень громко этого не говори. M>У Явы, по-моему, есть только два серьёзных преимущества: M>— накоплено много кода, программистов и общей инерции M>— есть реальная переносимость для мощных серверов
Эти преимущества не так уж мало стОят. Особенно второе.
ГВ>>Да здесь ещё много тем подняться может. А о Java, ИМХО, не упомянуть просто не получится. Куда ж мы без неё в контексте коммуникаций.
M>А что, в Яве навороченые комуникации?
Вопрос не в навороченности коммуникаций, а в контексте обсуждения.
M>Может, мы какие идеи себе приспособим
Основная идея лежит на поверхности и давно уже приспособлена и COM, и CORBA, и Java, и .Net: и называется она — интерфейсы.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
M>>>А кто сказал что это data-layer? Вот допустим я написал веб сервис. Он мне возвращает список товаров. Потом создал DataGrid и прибиндил к нему этот сервис. Я разве что то соединил? Нет. Я решил проблему без лишнего гемморного кода. При этом, веб сервис это не уровень доступа данных Это Business уровень, его фасад. ГВ>>Хорошо, согласен, таким образом ты прикрутил исходящий от сервера поток данных к презентационному слою. Т.е., выполнил работу по коммутированию потока данных. DataGrid написан средствами .Net. Значит, коммуникации + представление. Почти убеждаешь...
M>Если бы увидел корень мысли, то совсем бы убедился и не было сомнений
Озвучь тогда корень мысли. Она же твоя. Пока что я понял то, что было понятно и раньше. Ключевое слово "фасад", т.е. — обеспечение коммуникаций в том или ином смысле.
На самом деле, "геморрный код", о котором ты говоришь, появляется, только тогда, когда архитектура перекошена в пользу презентационного слоя и никто не думает о возможной мутации софта. А байндинг — это вообще мелочи. Приятные, конечно, но мелочи.
ГВ>>Но с другой стороны — собственный продукт Microsoft и окошки бы не умел рисовать? Я DataGrid глубоко не ковырял, но что-то мне подсказывает, что он, всё-таки, как и любой custom control обеспечивается службами самой Windows: очередями сообщений, WM_PAINT-ами и прочим. И ещё: если у тебя вместо плоской таблицы появится древовидная структура, то и вместо DataGrid придётся что-то другое вешать, не правда ли?
M>Честно говоря я имел ввиду System.Web.UI.WebControls.DataGrid. Этот не зависит от ОС. Но и если использовать виндовый, то чтобы сделать древовидную структуру не особо нужно что то изобретать. Возьми в пример кучу контоолов такого типа на codeproject.com Наследники от DataGrid, реализующую нужную ф-ть.
Вобщем-то, как ни поверни, а всё равно только интерейс пользователя получается.
M>>>Зайди на форум .NET и увидишь, что самый оцененный топик сейчас — это статья ИТ про RSDN.Framework.Data. Неспроста. Маппинг данных народу хочеться, а не возюкаться с SqlXXX классами. Чтоб быстро и эффективно (по времени разработки, разумеется). ГВ>>Ну, маппинг — тема отдельная и достаточно большая. К дотнету, ИМХО, она относится очень даже косвенно, хотя, если хочешь, то можно поковырять и её. Да, на дотнете CRUD стало делать легко. Но объектно-реляционный маппинг одним только CRUD не ограничивается, M>Согласен. Но согласись, зачем что то реализовывать, когда вот оно, готовое. Или вы у нас велосипеды предпочитаете?
Э... "за морем телушка — полушка, да рупь перевоз". Знаешь такую пословицу? По мне, так лучше за неделю сделать простенький CRUD теми средствами, которые под рукой, чем тащить весь .Net и ещё интерфейс к нему.
M>>>Xml удобен для общения. Не нужно ничего нового изучать. Вот он протокол и все им пользуйтесь. А что ЛИСП. Я его не знаю. Следовательно, его не знаю и мои сервисы. Какой же он тогда удобный? ГВ>>Для веб-сервисов, может быть и неудобный. Пока. А так, вобщем-то, покомпактнее XML будет. Да и нет необходимости XSLT изобретать: все трансформации можно описать на том же LISP. Единственное серьёзное отличие: человеку его потруднее читать, чем XML и не так уж он и годится для разметки текста. Ну впрочем, ладно, это к теме не относится. M>Даже SUN поняла что будующее за XML... Ну, вообщем, ладно. Пишем все на LISP =)
Личные проблемы Sun. Хорошо , но дело не в этом. ИМХО, использование XML на уровне коммуникаций вообще... кхм, не очень хорошая практика.
ГВ>>Да, но назначение ASP — работа в коммуникационной среде. Каких бы прибамбасов там ни было, "среда" для ASP всё равно — коммуникационная. Ну, плюс ещё презентативная логика в определённом смысле. M>Честно говоря, если взглянуть глубже, то ASP это не только коммуникация. Что то мне подсказывает
Да, конечно, не только коммуникация. Ещё и генерация страниц для интерфейса пользователя. Даже частично бизнес-логику на нём делают. Даже иногда полностью. Я не спорю, что ASP.NET — относительно хорошая штука, хотя на самом деле с её помощью (как и с ASP) запросто создаётся перекос в сторону "программирования на форме". Впрочем, это ещё с Delphi и VB пошло...
Но только всё равно контекст его применения ограничивается пользовательским интерфейсом к Web-приложениям. Интересно, для desktop-варианта тоже нужно интерфейс пользователя средствами ASP.NET городить?
ГВ>>Хорошо, тогда не будем гадать на кофейной гуще. Поживём-посмотрим. M>Хм. Дык, ведь уже. Или ты что то другое имеешь ввиду?
Не знаю. Знаю только, что свято место пусто не бывает, и на него всегда много желающих.
[...]
ГВ>> Ну, я вообще-то думаю, что с веб-сервисами лучше всего через SOAP общаться, M>Я и не знал, что soap стал у нас транспортным протоколом
Я и не думал, что ты имеешь ввиду транспортный протокол.
ГВ>>а сокеты нужны там, где производительность SOAP не устраивает. M>Честно говоря, я на remoting так могу запрос создать, что он будем измеряться в порядке в несколько байт. Вообщем, сокетный размер пакетов...
А причём тут remoting? Это, кстати, тоже сугубо коммуникационная приблуда. Необходимость в нём "резко уничтожается", если на обоих машинах установлены одни и те же версии софта. Вопрос, собственно не в том, чтобы найти "наилучший" способ передать объект или его интерфейс на другую машину. Проблема в том, чтобы допустить все приколы линий связи в той или иной точке обработки, т.е. — определить концепцию "разнесения" объектов. А remoting у нас в качестве реализации или просто проинсталлированы соответствующие библиотеки на обоих машинах, или что-то ещё — это уж дело тридесятое.
Не знаю, как тебе, а мне что-то подсказывает, что совсем не все серверные объекты ездят на клиента.
M>Я просто часто вижу, как люди не разобравшись в инструменте, категорически его отвергают по каким-то своим внутренним убеждениям.
Я тоже такое часто вижу. Но я ведь и не отвергаю .Net Зачем?
M>>>В Нете уже есть классы, реализующие определенный слой абстракции. В Яве тоже есть (но я ее рассматриваю как Нет. Тот же мифический тяжеловестный рантайм, те же тормоза, та же легкость в разработке). А в других языках разве что то наблюдается? Да, и тем более, реализуй это, тут же потребуються дополнительные возможности, которые сейчас успешно берет на себя WSE. И эту библиотеку тоже реализовывать!?
ГВ>>Может быть и так, может быть и нет. Во всяком случае, это никак не противоречит тому, что .Net ориентирована в первую очередь на коммуникации и их обслуживание. M>Давай тогда решим, какие ты типы программ имеешь ввиду, подрузомевая в них "не коммуникативные"
Как ни странно, но в первую очередь — бизнес-софт, который по моим наблюдениям часто делается с допуском "отмеряй микрометром — отрубай топором".
ГВ>>Только объясни, плз., кого, "её" на клиенте реализоывать? M>Indigo
Зачем? Если клиент предоставляет пользователю исключительно UI, то ему весь букет Indigo даром не нужен. По-любому в таком случае нужен отдельный серверный модуль, который будет раскидывать поток данных от пользователя по программам-получателям.
ГВ>>Да, представляю. Но ассоциации с коммуникациями у меня не из-за .Network, а именно из-за внутренностей самого .Net. M>не всякий программист .NET может похвастаться, что он знает его внутренности.
Ты мне льстишь.
M>>>Почему все это нельзя сразу написать на НЕТ? Возможности у него самые большие. Зачем тогда мучиться и писать что-то на другом языке? ГВ>>Самые большие по сравнению с чем? M>Скажу громко. Из всего что ты приведешь.
Не хило. Тогда привожу пример: переносимая CRM-система. Нужно обеспечить переносимость серверной части: Sparc-Wintel-Linux-FreeBSD. Клиенты могут сидеть на Linux, MacOS и Wintel. Переносимость серверной части — для того, чтобы можно было продать подороже/подешевле при случае. Переносимость клиентской части — вполне реальная потребность, например, для издательского дома. Ну правда, для них, скорее MacOS + Wintel. Ну... ещё присовокупим сюда необходимость интеграции всего этого хозяйства с... ну, например 1С и почтовыми шлюзами.
M>Более того, я докажу тебе, что ты плохо подходишь к решению проблемы при выборе нужного инструмента для реализации того или иного программмного продукта. Как пример, описанное тобою ниже.
Если ты думаешь, что это я писал эту АБС, то крупно ошибаешься. Если думаешь, что я тебя буду однозначно агитировать "за C++" во всех случаях, то тоже крупно ошибаешься.
ГВ>>Возможности-то большие, вопрос в том, для чего они лучше всего годятся. На VB можно, в принципе, любую программу написать, но не факт, что она позволит удовлетоврить предъявляемым к ней требованиям. Мне приходилось с АБС на VB сталкиваться — так этот монстр на четырёхпроцессорном сервере двух пользователей с трудом обслуживал. M>К чему ты это привел? К тому что ВБ для этого не преднозначен. Так кто бы спорил. Пользуйтесь VB.NET
К тому, что многое на многом можно написать. "вопрос в том, для чего они лучше всего годятся".
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
[цитаты малость урезаны] M>>>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. M>>>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>>>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. ГВ>>С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость M>В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
ИМХО, если для приложения требуется unsafe, то ему его всё равно дадут. Вопрос на самом деле в том, насколько легко потребовать unsafe. Собственно, его применение как раз накрывает медным тазом всю переносимость и для Java и для .Net.
M>>>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры. ГВ>>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй... M>Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
Пусть стреляет. Но тогда реальной переносимости между процессорными архитектурами совсем не получается.
M>>>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl. ГВ>>Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить. M>Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
Или ASP.ONE. Впрочем, это уже совсем другая история. Главное другое: xxxxx Server Pages — по сути обеспечивают коммуникации (ИМХО), а точнее — коммуникацию пользователя с программой в среде Web. Так что, это ничего под Луной не меняет.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mihailik, Вы писали:
dad>>>Помоему даже беглый взгляд показывает, что ява превосходит .net во всех остношениях. ГВ>>Ты только очень громко этого не говори. M>У Явы, по-моему, есть только два серьёзных преимущества: M>— накоплено много кода, программистов и общей инерции M>— есть реальная переносимость для мощных серверов
Эти преимущества не так уж мало стОят. Особенно второе.
ГВ>>Да здесь ещё много тем подняться может. А о Java, ИМХО, не упомянуть просто не получится. Куда ж мы без неё в контексте коммуникаций.
M>А что, в Яве навороченые комуникации?
Вопрос не в навороченности коммуникаций, а в контексте обсуждения.
M>Может, мы какие идеи себе приспособим
Основная идея лежит на поверхности и давно уже приспособлена и COM, и CORBA, и Java, и .Net: и называется она — интерфейсы.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
M>Ага. Я просто подумал, что программу написал на нейтив только из-за того, что не любят .NET. Бывают такие
Кстати, справедливо и обратное
M>>>Почему все это нельзя сразу написать на НЕТ? Возможности у него самые большие. Зачем тогда мучиться и писать что-то на другом языке?
ГВ>>Самые большие по сравнению с чем?
M>Скажу громко. Из всего что ты приведешь. Более того, я докажу тебе, что ты плохо подходишь к решению проблемы при выборе нужного инструмента для реализации того или иного программмного продукта. Как пример, описанное тобою ниже.
Похоже на юношеский максимализм, не находишь?
С твоих слов .net мне начинает казаться серебрянной пулей.
Разъясни, пожалуйста, если я чего-то не понимаю. .NET — это самая прогрессивная технология на данный момент, которой в большинстве случаев, нет альтернативы?
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, dad, Вы писали:
dad>замучил лошить уже пятый раз получаю этот пост..
Причем тут лошить? Это связь хреновая. У меня такое тоже бывало
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, mikа, Вы писали:
M>Вот как станет поменьше глюков, так цены ему не будет.
Какие глюки? Он ведь на .net написан.
Серьезно: на так уж там много глюков — вполне комфортно использую его длительное время.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, Геннадий Васильев, Вы писали:
M>>Если бы увидел корень мысли, то совсем бы убедился и не было сомнений
ГВ>Озвучь тогда корень мысли. Она же твоя. Пока что я понял то, что было понятно и раньше. Ключевое слово "фасад", т.е. — обеспечение коммуникаций в том или ином смысле.
Вот это я оставлю на конец нашей беседы-спора. Хочу сделать маленький авторский трик.
ГВ>На самом деле, "геморрный код", о котором ты говоришь, появляется, только тогда, когда архитектура перекошена в пользу презентационного слоя и никто не думает о возможной мутации софта.
А где я про это писал?
ГВ>А байндинг — это вообще мелочи. Приятные, конечно, но мелочи.
Так так. А ты вообще с сервера как собираешься данные получать? Через святой дух?
M>>Честно говоря я имел ввиду System.Web.UI.WebControls.DataGrid. Этот не зависит от ОС. Но и если использовать виндовый, то чтобы сделать древовидную структуру не особо нужно что то изобретать. Возьми в пример кучу контоолов такого типа на codeproject.com Наследники от DataGrid, реализующую нужную ф-ть.
ГВ>Вобщем-то, как ни поверни, а всё равно только интерейс пользователя получается.
Точно! Вот мы и нашли второе место для .NET
ГВ>Э... "за морем телушка — полушка, да рупь перевоз". Знаешь такую пословицу? По мне, так лучше за неделю сделать простенький CRUD теми средствами, которые под рукой, чем тащить весь .Net и ещё интерфейс к нему.
Если все изначально писать правильно — на Нете, то ничего тащить не надо.
ГВ>Личные проблемы Sun. Хорошо , но дело не в этом. ИМХО, использование XML на уровне коммуникаций вообще... кхм, не очень хорошая практика.
Почему? Из за большого размера? Ну дык это только сейчас кажеться.
Если клиенты долго ожидают ответа, купить выделенку. Даже в нашей глухомани это обычное явление.
Если долго сервер обрабатывает запросы, заапгрейдить проц.
Если вы являетесь рьяным приверженцем LISP-а, сделайте общение клиента с сервером на нем.
В чем проблема?
ГВ>>>Да, но назначение ASP — работа в коммуникационной среде. Каких бы прибамбасов там ни было, "среда" для ASP всё равно — коммуникационная. Ну, плюс ещё презентативная логика в определённом смысле. M>>Честно говоря, если взглянуть глубже, то ASP это не только коммуникация. Что то мне подсказывает
ГВ>... запросто создаётся перекос в сторону "программирования на форме". Впрочем, это ещё с Delphi и VB пошло...
И правильно пошло.
ГВ>Но только всё равно контекст его применения ограничивается пользовательским интерфейсом к Web-приложениям. Интересно, для desktop-варианта тоже нужно интерфейс пользователя средствами ASP.NET городить?
Я думаю не стоит. Ведь .NET предоставляет богатый инсрументарий. Чем тебе WinForms не понравился?
ГВ>Не знаю. Знаю только, что свято место пусто не бывает, и на него всегда много желающих.
Перечисляй.
ГВ>А причём тут remoting? Это, кстати, тоже сугубо коммуникационная приблуда. Необходимость в нём "резко уничтожается", если на обоих машинах установлены одни и те же версии софта.
Опа, а это то тут при чем?
ГВ>Вопрос, собственно не в том, чтобы найти "наилучший" способ передать объект или его интерфейс на другую машину. Проблема в том, чтобы допустить все приколы линий связи в той или иной точке обработки, т.е. — определить концепцию "разнесения" объектов. А remoting у нас в качестве реализации или просто проинсталлированы соответствующие библиотеки на обоих машинах, или что-то ещё — это уж дело тридесятое.
Ну приколы связи, это вообшем то проблема прошлого века. Вероятно, тебе она кажется до сих пор весомой только по тому, что ты не используешь стандатрные вещи. Я уже даже не говорю про .NET. А вот насчет логики обработки... Тут все зависит от ее необходимости, и как ты ее собираешься решить.
ГВ>Не знаю, как тебе, а мне что-то подсказывает, что совсем не все серверные объекты ездят на клиента.
Честно говоря, я вообще такую концепцию не применяю. И Remoting кстати это не позволяет, если не настроить обратную связь. Так что ничего на клиента не ездеет. Они оба (клиент, сервер) общаються через сторонние сущности.
M>>Я просто часто вижу, как люди не разобравшись в инструменте, категорически его отвергают по каким-то своим внутренним убеждениям. ГВ>Я тоже такое часто вижу. Но я ведь и не отвергаю .Net Зачем?
Ты его просто игнорируешь
M>>Давай тогда решим, какие ты типы программ имеешь ввиду, подрузомевая в них "не коммуникативные" ГВ>Как ни странно, но в первую очередь — бизнес-софт,
А что значит "бизнес-софт"? Мы обсуждаем, где конкретно место .NET. И я просил привести реальные места, а не абстрактное название. Или ты считаешь, что на .NET нельзя написать бизнес-софт?
ГВ>который по моим наблюдениям часто делается с допуском "отмеряй микрометром — отрубай топором".
Ну это твои личные наблюдения. Предлагаю их не рассматривать
ГВ>>>Только объясни, плз., кого, "её" на клиенте реализоывать? M>>Indigo ГВ>Зачем? Если клиент предоставляет пользователю исключительно UI, то ему весь букет Indigo даром не нужен.
Хм. Не понял. А зачем весь. Только то, что позволяет куда то подключаться.
ГВ>По-любому в таком случае нужен отдельный серверный модуль, который будет раскидывать поток данных от пользователя по программам-получателям.
К чему ты это сказал?
ГВ>Нужно обеспечить переносимость серверной части: Sparc-Wintel-Linux-FreeBSD. Клиенты могут сидеть на Linux, MacOS и Wintel. Переносимость серверной части — для того, чтобы можно было продать подороже/подешевле при случае. Переносимость клиентской части — вполне реальная потребность, например, для издательского дома. Ну правда, для них, скорее MacOS + Wintel. Ну... ещё присовокупим сюда необходимость интеграции всего этого хозяйства с... ну, например 1С и почтовыми шлюзами.
Тут скорее всего подойдет Ява. Переносимость у Нет в другой сфере (архитектура процессора и КПК). Хотя, может и Моно поможет, но правда там ф-ть очень мизерная
M>>Более того, я докажу тебе, что ты плохо подходишь к решению проблемы при выборе нужного инструмента для реализации того или иного программмного продукта. Как пример, описанное тобою ниже. ГВ>Если ты думаешь, что это я писал эту АБС, то крупно ошибаешься. Если думаешь, что я тебя буду однозначно агитировать "за C++" во всех случаях, то тоже крупно ошибаешься.
Еще бы. Я уже вижу к чему ты клонишь В наших рядах пополнение
ГВ>К тому, что многое на многом можно написать. "вопрос в том, для чего они лучше всего годятся".
многое. Вот клучевое слово. Если у тебя есть время, для того чтобы создать систему с различными подходами и разными языками, то вообщем-то, и спор дальше не имеет вести смысл. За бесконечность я смогу сделать все что угодно.
Здравствуйте, is, Вы писали:
is>Здравствуйте, mikа, Вы писали:
M>>Ага. Я просто подумал, что программу написал на нейтив только из-за того, что не любят .NET. Бывают такие
is>Кстати, справедливо и обратное
Я не говорю, что все нужно писать на Нете. Низкоуровневое, как заметил Геннадий, нужно писать на Нете. К сожалению, я не по этой части. Но тут с ним согласен. В остальном же, .NET — это реальный выигрыш. Тат что тут криминального, если я хочу упростить решение задачи?
is>Похоже на юношеский максимализм, не находишь?
Полегче на поворотах. Если тебе не нравиться дискуссия — не читай ее.
is>Разъясни, пожалуйста, если я чего-то не понимаю. .NET — это самая прогрессивная технология на данный момент, которой в большинстве случаев, нет альтернативы?
Есть. Но альтернатива состоит из совокупности. А .NET один. Тоесть, лучше использовать один язык программирования, к которому ты привык за долгие годы, и которые сможет так же легко реализовать задачу, как альтернативное средство во всех сферах, чем питаться сборной солянкой. Геннадий предлагаем нам супчик
Здравствуйте, is, Вы писали:
is>Какие глюки? Он ведь на .net написан.
Может ты форумом ошибся. Это "Философия программирования". Юмор у нас в другой ветке.
is>Серьезно: на так уж там много глюков — вполне комфортно использую его длительное время.
А кто сказал, что это плохая приблуда. Это отличная вещи и при некоторых обстоятельствах даже не заменимая.
Перед типичной программой стоят следующие задачи (и проблемы):
1. Пользовательский интерфейс
2. Доступ к БД
3. Бизнес задачи (много разнородных объектов, частоменяющие требования)
4. Коммуникация между компьютерами
5. Вычислительные задачи (числа, числа и еще раз числа)
6. Оптимизация (опять много разнородных объектов, частоменяющиеся требования, много вычислений)
7. Стыковка с чужими библиотеками.
8. Стыковка с другими приложениями
9. Устойчивость (легко восстанавливается при ошибке, легкая локализация утечек памяти)
10. Безопасность.
11. Версионность.
С помощью чего будут решаться данные задачи? Что будет фундаментом?
ps
На данный момент, .Net выглядит хорошим кандидатом в качестве фундамента для решения всех вышеперечисленных задач.
ГВ> ИМХО, использование XML на уровне коммуникаций вообще... кхм, не очень хорошая практика.
Причина Вашего такого мнения?
Как Вы предлагаете решать следующие задачи без xml-я?:
1. Обмен данными между разноплатформенными программами
2. Обмен данными между программами разных производителей
3. Версионность
4. Автоматическая генерация проксей, адаптеров, конвертеров и т.д.
5. Создание универсальных проксей, адаптеров, конвертеров, хранилищ и т.д.
6. Разноплановость клиентов. Типичный пример: данный форум. Клиенты: NNTP, Janus, Browser, RSS, почта и т.д.
7. Мета-описание формата данных.
M>>В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
ГВ>ИМХО, если для приложения требуется unsafe, то ему его всё равно дадут. Вопрос на самом деле в том, насколько легко потребовать unsafe.
Это примерно как потребовать прав на NTFS-файл. Кому положено, тому легко потребовать. Кому неположено — не то что нелегко. Просто никак
ГВ> Собственно, его применение как раз накрывает медным тазом всю переносимость и для Java и для .Net.
Нет, unsafe не связан напрямую с переносимостью. Unsafe в .NET — это, грубо говоря, оперирование с указателями. Само по себе оно не платформозависимо. Просто применяется оно обычно для Platform Invoke (работа с внешними функциями).
ГВ>>>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй... M>>Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
ГВ>Пусть стреляет. Но тогда реальной переносимости между процессорными архитектурами совсем не получается.
Здрасте! IA64 отличается от x86 просто совершенно. Вообще, совсем другой процессор.
Кстати, если говорить именно о переносимости и забыть на время о серверах, то на карманных ПК уже существует .NET Compact Framework.
M>>Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
ГВ>Или ASP.ONE. Впрочем, это уже совсем другая история. Главное другое: xxxxx Server Pages — по сути обеспечивают коммуникации (ИМХО), а точнее — коммуникацию пользователя с программой в среде Web.
Ну нет, я не согласен! Ты с ходу взял смешал слой представления с коммуникациями. ASP/JSP — это однозначно слой представления. Так и Word у тебя будет средством коммуникации.
dad>>>>Помоему даже беглый взгляд показывает, что ява превосходит .net во всех остношениях.
M>>— накоплено много кода, программистов и общей инерции M>>— есть реальная переносимость для мощных серверов
ГВ>Эти преимущества не так уж мало стОят. Особенно второе.
Хорошие преимущества, я ж не спорю. Но "во всех отношениях" это какой-то Явный перебор
M>>Может, мы какие идеи себе приспособим ГВ>Основная идея лежит на поверхности и давно уже приспособлена и COM, и CORBA, и Java, и .Net: и называется она — интерфейсы.
Ну, интерфейсы на сегодняшний день уже обсуждать смысла нет. Освоено и используется. Интерестно, нет ли в Явном "ремотинге" чего-то ещё полезного, что можно в дотнетовском ремотинге использовать.
На самом деле, конечно, это несколько праздный вопрос. Дотнетовский ремотинг как раз сейчас полностью перестраивается (Indigo), кто его знает чего там нет и что там будет? Но всё равно ознакомится с конкурентами полезно.
is>Похоже на юношеский максимализм, не находишь?
is>Разъясни, пожалуйста, если я чего-то не понимаю. .NET — это самая прогрессивная технология на данный момент, которой в большинстве случаев, нет альтернативы?
А это похоже на академический консерватизм
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
DG>>>4. Автоматическая генерация проксей, адаптеров, конвертеров и т.д.
dad>>это что такое?
>Так же можно реализовать кучу адаптеров и конвертеров, которые будут влиять на процесс генерации кода.
собственно я и хотел узнать не что такое "автоматическое генерация", а что такое прокси и адаптеры.
про прокси теперь я понял, непонятно что такое адаптер и конвертер, которые влияют на процесс "генерации года"
и что такое "генерация кода" и зачем это нужно? (сильное ощущение что опять что то очень навороченное фирмой микросовт над простыми и понятными вещами)
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, dad, Вы писали:
dad>собственно я и хотел узнать не что такое "автоматическое генерация", а что такое прокси и адаптеры. dad>про прокси теперь я понял, непонятно что такое адаптер и конвертер, которые влияют на процесс "генерации года" dad>и что такое "генерация кода" и зачем это нужно? (сильное ощущение что опять что то очень навороченное фирмой микросовт над простыми и понятными вещами)
Ну, если сразу подходить с таким желанием узнать про новую для тебя функциональность, то конечно. Зачем вообще MS существует?
Cледующие подобные вопросы в соответствующий форум.
Генерация кода нужна для того, чтобы работать не с Xml (SOAP) а с какими-то классами (прокси-объектами). Адаптер и конвертер нужен для того, чтобы процесс генерации был управляемым. Допустим, для разлиицных типов клиентов строиться разные типы проксей, добавляються сущности, с которые работают эти прокси-обекты.
M>Cледующие подобные вопросы в соответствующий форум.
M>Генерация кода нужна для того, чтобы работать не с Xml (SOAP) а с какими-то классами (прокси-объектами). Адаптер и конвертер нужен для того, чтобы процесс генерации был управляемым. Допустим, для разлиицных типов клиентов строиться разные типы проксей, добавляються сущности, с которые работают эти прокси-обекты.
так я и думал, rpc только в текстовом формате (xml) а терминов то ..
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, DarkGray, Вы писали:
DG>Вот Вы говорите: .Net — это только коммуникации и точка. DG>Предложите тогда, пожалуйста, реальную альтернативу .Net-у?
DG>Перед типичной программой стоят следующие задачи (и проблемы): DG>1. Пользовательский интерфейс
Допускаю, что для UI .Net подходит неплохо, с учётом той горы библиотек, что уже есть.
DG>2. Доступ к БД
Ты и сам знаешь, сколько API существует. AFAIK, самый универсальный пока что — ODBC (что жаль, но такова селяви). А дальше всё зависит от БД.
DG>3. Бизнес задачи (много разнородных объектов, частоменяющие требования)
А если из этого пункта убрать обобщения? Вот такими качествами: "много разнородных объектов, частоменяющие требования" обладает абсолютно любая "живая" программа.
DG>4. Коммуникация между компьютерами
Коммуникации. Вопрос снимается, поскольку здесь применение .Net я не собираюсь оспаривать.
DG>5. Вычислительные задачи (числа, числа и еще раз числа)
C++ с native-библиотеками или Fortran. C каких это пор .Net стал лучшей системой, ориентированной именно на вычисления? Он на UI и коммуникации ориентирован.
DG>6. Оптимизация (опять много разнородных объектов, частоменяющиеся требования, много вычислений)
Это — задача компилятора. Любого. Или .Net уже научился переливать объектный код за границы COM-интерфейсов.
DG>7. Стыковка с чужими библиотеками.
Какими? Если с плюсовыми, то лучше на плюсах, если Java, то аналогично.
DG>8. Стыковка с другими приложениями
А ты можешь сказать что-то общее о "других приложениях"? Я лично не рискнул бы так обобщать.
DG>9. Устойчивость (легко восстанавливается при ошибке, легкая локализация утечек памяти)
Ерунда. Падает вплоть до выноса W2K вместе с собой. С утечками памяти как бороться — так это в форум "проектирование". Восстановление при ошибке — полезная, но не экстраординарная фича: что мне толку как пользователю с того, что Янус вываливал по 5-10 раз сообщения об ошибке? Если бы это была какая-нибудь "автоматическая семантика восстановления", то ещё ладно, а stack trace... Это даже не смешно. А утечки памяти и на плюсах попросту не допускаются при разумном подходе.
DG>10. Безопасность.
Не понял, какую именно безопасность ты имеешь ввиду? Их две: в смысле ограничения доступа пользователей к функциональности и блокировки доступа к памяти или unmanaged-ресурсам.
DG>11. Версионность.
Хм. А это большая проблема? Вроде как Object Factory + Version Select Policy + ещё совсем немного составляют достойную альтернативу .Net-овскому встроенному механизму, да и реализуется несложно, если, конечно, не считать std::vector объектом версионирования, что было бы приятно, но по большей части — совершенно ни к чему.
DG>С помощью чего будут решаться данные задачи? Что будет фундаментом?
Голова, конечно. Это единственный фундамент.
DG>ps DG>На данный момент, .Net выглядит хорошим кандидатом в качестве фундамента для решения всех вышеперечисленных задач.
Технология не может быть фундаментом решения всех данных задач, увы.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
M>>>Если бы увидел корень мысли, то совсем бы убедился и не было сомнений ГВ>>Озвучь тогда корень мысли. Она же твоя. Пока что я понял то, что было понятно и раньше. Ключевое слово "фасад", т.е. — обеспечение коммуникаций в том или ином смысле. M>Вот это я оставлю на конец нашей беседы-спора. Хочу сделать маленький авторский трик.
Ну, ладно.
ГВ>>На самом деле, "геморрный код", о котором ты говоришь, появляется, только тогда, когда архитектура перекошена в пользу презентационного слоя и никто не думает о возможной мутации софта.
M>А где я про это писал?
M>>А кто сказал что это data-layer? Вот допустим я написал веб сервис. Он мне возвращает список товаров. Потом создал DataGrid и прибиндил к нему этот сервис. Я разве что то соединил? Нет. Я решил проблему без лишнего гемморного кода. При этом, веб сервис это не уровень доступа данных Это Business уровень, его фасад.
ГВ>>А байндинг — это вообще мелочи. Приятные, конечно, но мелочи. M>Так так. А ты вообще с сервера как собираешься данные получать? Через святой дух?
Я имею ввиду — мелочи в смысле сложности их реализации.
M>>>Честно говоря я имел ввиду System.Web.UI.WebControls.DataGrid. Этот не зависит от ОС. Но и если использовать виндовый, то чтобы сделать древовидную структуру не особо нужно что то изобретать. Возьми в пример кучу контоолов такого типа на codeproject.com Наследники от DataGrid, реализующую нужную ф-ть. ГВ>>Вобщем-то, как ни поверни, а всё равно только интерейс пользователя получается. M>Точно! Вот мы и нашли второе место для .NET
Пусть так. Пока что.
ГВ>>Э... "за морем телушка — полушка, да рупь перевоз". Знаешь такую пословицу? По мне, так лучше за неделю сделать простенький CRUD теми средствами, которые под рукой, чем тащить весь .Net и ещё интерфейс к нему. M>Если все изначально писать правильно — на Нете, то ничего тащить не надо.
Не доказано.
ГВ>>Личные проблемы Sun. Хорошо , но дело не в этом. ИМХО, использование XML на уровне коммуникаций вообще... кхм, не очень хорошая практика. M>Почему? Из за большого размера? Ну дык это только сейчас кажеться.
Это будет всегда так. Если бы это было не так, то мы бы сейчас поголовно писали с использованием интерпретируемого, а не компилируемого кода.
M>Если клиенты долго ожидают ответа, купить выделенку. Даже в нашей глухомани это обычное явление. M>Если долго сервер обрабатывает запросы, заапгрейдить проц. M>Если вы являетесь рьяным приверженцем LISP-а, сделайте общение клиента с сервером на нем.
M>В чем проблема?
В принципиально неверном подходе: "высока у стула ножка — подпилю её немножко". Только вместо стула подпиливается пол, на котором он стоит.
ГВ>>>>Да, но назначение ASP — работа в коммуникационной среде. Каких бы прибамбасов там ни было, "среда" для ASP всё равно — коммуникационная. Ну, плюс ещё презентативная логика в определённом смысле. M>>>Честно говоря, если взглянуть глубже, то ASP это не только коммуникация. Что то мне подсказывает ГВ>>... запросто создаётся перекос в сторону "программирования на форме". Впрочем, это ещё с Delphi и VB пошло... M>И правильно пошло.
Ну, вообще-то, это азы ОО-проектирования: не писать бизнес-код непосредственно в обработчиках событий UI.
ГВ>>Но только всё равно контекст его применения ограничивается пользовательским интерфейсом к Web-приложениям. Интересно, для desktop-варианта тоже нужно интерфейс пользователя средствами ASP.NET городить? M>Я думаю не стоит. Ведь .NET предоставляет богатый инсрументарий. Чем тебе WinForms не понравился?
Хорошо, значит, имеем таки две независимых реализации интерфейса пользователя: для web и для desktop. Всё как всегда.
ГВ>>Не знаю. Знаю только, что свято место пусто не бывает, и на него всегда много желающих. M>Перечисляй.
Повторяю: не знаю.
ГВ>>А причём тут remoting? Это, кстати, тоже сугубо коммуникационная приблуда. Необходимость в нём "резко уничтожается", если на обоих машинах установлены одни и те же версии софта. M>Опа, а это то тут при чем?
Это я у тебя хотел спросить — с чего ты remoting вспомнил?
ГВ>>Вопрос, собственно не в том, чтобы найти "наилучший" способ передать объект или его интерфейс на другую машину. Проблема в том, чтобы допустить все приколы линий связи в той или иной точке обработки, т.е. — определить концепцию "разнесения" объектов. А remoting у нас в качестве реализации или просто проинсталлированы соответствующие библиотеки на обоих машинах, или что-то ещё — это уж дело тридесятое.
M>Ну приколы связи, это вообшем то проблема прошлого века. Вероятно, тебе она кажется до сих пор весомой только по тому, что ты не используешь стандатрные вещи. Я уже даже не говорю про .NET. А вот насчет логики обработки... Тут все зависит от ее необходимости, и как ты ее собираешься решить.
Кхм. Акстись. Я даже волшебное слово знаю — пожалуйста. Приколы связи как были, так и останутся навечно, пока её принципы каким-нибудь кардинальным образом не изменятся.
ГВ>>Не знаю, как тебе, а мне что-то подсказывает, что совсем не все серверные объекты ездят на клиента. M>Честно говоря, я вообще такую концепцию не применяю. И Remoting кстати это не позволяет, если не настроить обратную связь. Так что ничего на клиента не ездеет. Они оба (клиент, сервер) общаються через сторонние сущности.
Хорошо, ты только подтвердил мои сомнения.
M>>>Я просто часто вижу, как люди не разобравшись в инструменте, категорически его отвергают по каким-то своим внутренним убеждениям. ГВ>>Я тоже такое часто вижу. Но я ведь и не отвергаю .Net Зачем? M>Ты его просто игнорируешь
А это с чего ты взял?
M>>>Давай тогда решим, какие ты типы программ имеешь ввиду, подрузомевая в них "не коммуникативные" ГВ>>Как ни странно, но в первую очередь — бизнес-софт, M>А что значит "бизнес-софт"? Мы обсуждаем, где конкретно место .NET. И я просил привести реальные места, а не абстрактное название. Или ты считаешь, что на .NET нельзя написать бизнес-софт?
Нет, я этого не считаю и не раз прямо об этом говорил.
ГВ>>который по моим наблюдениям часто делается с допуском "отмеряй микрометром — отрубай топором". M>Ну это твои личные наблюдения. Предлагаю их не рассматривать
А у меня других нет, уж извини.
ГВ>>>>Только объясни, плз., кого, "её" на клиенте реализоывать? M>>>Indigo ГВ>>Зачем? Если клиент предоставляет пользователю исключительно UI, то ему весь букет Indigo даром не нужен. M>Хм. Не понял. А зачем весь. Только то, что позволяет куда то подключаться.
А зачем тогда Indigo?
ГВ>>По-любому в таком случае нужен отдельный серверный модуль, который будет раскидывать поток данных от пользователя по программам-получателям. M>К чему ты это сказал?
К архитектуре.
ГВ>>Нужно обеспечить переносимость серверной части: Sparc-Wintel-Linux-FreeBSD. Клиенты могут сидеть на Linux, MacOS и Wintel. Переносимость серверной части — для того, чтобы можно было продать подороже/подешевле при случае. Переносимость клиентской части — вполне реальная потребность, например, для издательского дома. Ну правда, для них, скорее MacOS + Wintel. Ну... ещё присовокупим сюда необходимость интеграции всего этого хозяйства с... ну, например 1С и почтовыми шлюзами.
M>Тут скорее всего подойдет Ява. Переносимость у Нет в другой сфере (архитектура процессора и КПК). Хотя, может и Моно поможет, но правда там ф-ть очень мизерная
Хорошо, значит-таки, не всегда правильно писать на .Net?
M>>>Более того, я докажу тебе, что ты плохо подходишь к решению проблемы при выборе нужного инструмента для реализации того или иного программмного продукта. Как пример, описанное тобою ниже. ГВ>>Если ты думаешь, что это я писал эту АБС, то крупно ошибаешься. Если думаешь, что я тебя буду однозначно агитировать "за C++" во всех случаях, то тоже крупно ошибаешься. M>Еще бы. Я уже вижу к чему ты клонишь В наших рядах пополнение
Ась? В каких рядах?
ГВ>>К тому, что многое на многом можно написать. "вопрос в том, для чего они лучше всего годятся". M>многое. Вот клучевое слово. Если у тебя есть время, для того чтобы создать систему с различными подходами и разными языками, то вообщем-то, и спор дальше не имеет вести смысл. За бесконечность я смогу сделать все что угодно.
Аналогично. Вопрос в выборе адекватного решения. Да и "разные языки" по большому счёту — фикция, если уж они должны быть CLR-compliant.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mihailik, Вы писали:
ГВ>>Ну, Mika... "Возможности у него самые большие." Самые большие по сравнению с чем?
M>На дотнете разработка быстрее происходит. По сравнению со "старыми" языками, конечно. Из-за того, что управляемость+метаданные приносят существенные преимущества.
А структура разрабатываемых сущностей? Оптимизация без изменения алгоритма вобщем-то всегда имеет свои пределы.
M>Ну и плюс библиотеки, если уж не только теорию рассматривать.
Библиотеки — они везде библиотеки.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mihailik, Вы писали:
M>>>В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений. ГВ>>ИМХО, если для приложения требуется unsafe, то ему его всё равно дадут. Вопрос на самом деле в том, насколько легко потребовать unsafe. M>Это примерно как потребовать прав на NTFS-файл. Кому положено, тому легко потребовать. Кому неположено — не то что нелегко. Просто никак
Не, ты меня не понял. Я имел ввиду лёгкость перехода от safe к unsafe (platform invoke). И лёгкость этого перехода именно для разработчика.
ГВ>> Собственно, его применение как раз накрывает медным тазом всю переносимость и для Java и для .Net. M>Нет, unsafe не связан напрямую с переносимостью. Unsafe в .NET — это, грубо говоря, оперирование с указателями. Само по себе оно не платформозависимо. Просто применяется оно обычно для Platform Invoke (работа с внешними функциями).
Да, ты прав. Я имел ввиду Platform Invoke.
ГВ>>>>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй... M>>>Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит. ГВ>>Пусть стреляет. Но тогда реальной переносимости между процессорными архитектурами совсем не получается. M>Здрасте! IA64 отличается от x86 просто совершенно. Вообще, совсем другой процессор.
Ды на здоровье. А для PowerPC уже есть .Net?
M>Кстати, если говорить именно о переносимости и забыть на время о серверах, то на карманных ПК уже существует .NET Compact Framework.
Экий ты. Ну уж нет, о серверах в первую очередь забывать не будем.
M>>>Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом). ГВ>>Или ASP.ONE. Впрочем, это уже совсем другая история. Главное другое: xxxxx Server Pages — по сути обеспечивают коммуникации (ИМХО), а точнее — коммуникацию пользователя с программой в среде Web. M>Ну нет, я не согласен! Ты с ходу взял смешал слой представления с коммуникациями. ASP/JSP — это однозначно слой представления. Так и Word у тебя будет средством коммуникации.
Просто они работают в коммуникационной среде — всяческие Sessions тому подтверждением.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
DG>>6. Оптимизация (опять много разнородных объектов, частоменяющиеся требования, много вычислений) ГВ>Это — задача компилятора. Любого. Или .Net уже научился переливать объектный код за границы COM-интерфейсов.
Имелось ввиду не оптимизация на уровне компилятора, а оптимизационные задачи.
найти минимальное, максимальное, лучшее решение задачи стоящей перед пользователем.
например, распределить машины по бензоправкам, или минимизировать расходы на проезд и т.д.
DG>>7. Стыковка с чужими библиотеками. ГВ>Какими? Если с плюсовыми, то лучше на плюсах, если Java, то аналогично.
Про Java-согласен.
Про плюсы совершенно не согласен.
Простыковать C++ — программу с чужой C++ — библиотекой — это очень нетривиальная задача.
На уровне исходников данная задача еще решается (но с большой долей геморроя),
а если библиотека в виде бинарника, то все приплыли.
Типичные проблемы при стыковке на уровне dll-ек:
отсутствие единого менеджера памяти (тот кто память выделил должен ее и освободить),
проблемы с именами (у разных компиляторов свои понятия о том, как должно выглядить имя),
проблемы с исключениями при переходе границ dll-ек
и т.д.
DG>>9. Устойчивость (легко восстанавливается при ошибке, легкая локализация утечек памяти) ГВ>Ерунда. Падает вплоть до выноса W2K вместе с собой.
Не встречал. Вы уверены, что у программиста были прямые руки?
Предложите альтернативу. Какое средство (технология) позволяет меньше падать?
ГВ> С утечками памяти как бороться — так это в форум "проектирование". Восстановление при ошибке — полезная, но не экстраординарная фича: что мне толку как пользователю с того, что Янус вываливал по 5-10 раз сообщения об ошибке? Если бы это была какая-нибудь "автоматическая семантика восстановления", то ещё ладно, а stack trace... Это даже не смешно. А утечки памяти и на плюсах попросту не допускаются при разумном подходе.
Янус некая бесплатная поделка, зачем ее в качестве примера приводить?
Я могу привести сотни более убогих примеров написанных на C++.
Так ты начем предлагаешь писать? На чистых C++?
И как по твоему программа будет восстанавливатся вот после такого кода?:
DG>>10. Безопасность. ГВ>Не понял, какую именно безопасность ты имеешь ввиду? Их две: в смысле ограничения доступа пользователей к функциональности и блокировки доступа к памяти или unmanaged-ресурсам.
И то, и другое. В общем смысле, это одно и тоже, т.к. первое не может быть без второго.
DG>>11. Версионность. ГВ>Хм. А это большая проблема? Вроде как Object Factory + Version Select Policy + ещё совсем немного составляют достойную альтернативу .Net-овскому встроенному механизму, да и реализуется несложно, если, конечно, не считать std::vector объектом версионирования, что было бы приятно, но по большей части — совершенно ни к чему.
Да, очень большая проблема.
Особенно если требования часто меняются, а в разработке участвует несколько фирм, отделов.
Причем скорость реакции на изменения у всех разная.
DG>>3. Бизнес задачи (много разнородных объектов, частоменяющие требования) ГВ>А если из этого пункта убрать обобщения? Вот такими качествами: "много разнородных объектов, частоменяющие требования" обладает абсолютно любая "живая" программа.
Еще раз повторю, все выше перечисленные пункты относились к одной программе.
И под бизнес-задачами как раз понималась только та часть, которая наиболее меняется, по другому можно назвать бизнес-слой.
DG>>Предложите тогда, пожалуйста, реальную альтернативу .Net-у?
DG>>Перед типичной программой стоят следующие задачи (и проблемы):
[skip]
DG>>С помощью чего будут решаться данные задачи? Что будет фундаментом? ГВ>Голова, конечно. Это единственный фундамент.
А если серьезно?
Еще раз напомню, что это все были задачи, которые встречаются в каждой программе в той или иной мере.
Из предложенных тобой путей решения вырисовывается что-то страшное:
в одной программе ты одновременно используешь:
.Net(UI и коммуникации),
Fortran для вычислительных задач,
C++,
как все это стыкуется ты так и не сказал,
так же не сказал, на чем ты пишешь:
бизнес-логику,
оптимизационные задачи
и т.д.
DG>>ps DG>>На данный момент, .Net выглядит хорошим кандидатом в качестве фундамента для решения всех вышеперечисленных задач.
ГВ>Технология не может быть фундаментом решения всех данных задач, увы.
.Net — это не только технология, это еще и среда, и как среда, она как раз может предоставлять фундамент для решения данных задач
Здравствуйте, mikа, Вы писали:
M>Ну, если сразу подходить с таким желанием узнать про новую для тебя функциональность, то конечно. Зачем вообще MS существует?
Для зарабатывания денег, есессно. Себе лично на нас в том числе. А ты думал, для чего? "Нести свет истины", что ли?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
M>>Ну, если сразу подходить с таким желанием узнать про новую для тебя функциональность, то конечно. Зачем вообще MS существует?
ГВ>Для зарабатывания денег, есессно. Себе лично на нас в том числе. А ты думал, для чего? "Нести свет истины", что ли?
на самом деле , мне кажется, что в майкросовт программисты нормальные чуваки, они занимаются тем, что интересно. есть задача — разработать крутой совт. они услышали что есть xml и решили — нормал давайте мочканем крутое. (про то что есть уже наработки спецификации и т.д. никто не думает) все с нуля и т.д. т.е. изучать и разработывать академические спецификации скучно и не интересно поэтому они делают свои и называют их по своему. за исключением веб-броузера.
а маркетинг уже продивигает потом нормально так. WDSL то се, гы. (это все, конечно, шутка )
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, dad, Вы писали:
M>>Cледующие подобные вопросы в соответствующий форум.
M>>Генерация кода нужна для того, чтобы работать не с Xml (SOAP) а с какими-то классами (прокси-объектами). Адаптер и конвертер нужен для того, чтобы процесс генерации был управляемым. Допустим, для разлиицных типов клиентов строиться разные типы проксей, добавляються сущности, с которые работают эти прокси-обекты.
dad>так я и думал, rpc только в текстовом формате (xml) а терминов то ..
Ты думаешь, что RPC и кодогенерация это одно и тоже? Тогда самое время начать рассуждать преимущества Ява над .NET
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, mikа, Вы писали:
M>>Ну, если сразу подходить с таким желанием узнать про новую для тебя функциональность, то конечно. Зачем вообще MS существует?
ГВ>Для зарабатывания денег, есессно. Себе лично на нас в том числе. А ты думал, для чего? "Нести свет истины", что ли?
Ага. Пытаемся в другую русло повернуть течение обсуждения. Теперь уже грязные деньги MS не даю нам покоя. Совет. Не думай о них. Живи проще
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, DarkGray, Вы писали:
DG>>Вот Вы говорите: .Net — это только коммуникации и точка. DG>>Предложите тогда, пожалуйста, реальную альтернативу .Net-у?
DG>>Перед типичной программой стоят следующие задачи (и проблемы): DG>>1. Пользовательский интерфейс ГВ>Допускаю, что для UI .Net подходит неплохо, с учётом той горы библиотек, что уже есть.
DG>>2. Доступ к БД ГВ>Ты и сам знаешь, сколько API существует. AFAIK, самый универсальный пока что — ODBC (что жаль, но такова селяви). А дальше всё зависит от БД.
Опять же нет. В .NET 2.0 Sql станет в разу богаче, чем Odbc (сейчас же Sql самый быстрый провайдер, если он соединятьеся с Sql Server). К тому же, ты так и не привел достойного аналога Object Spaces.
DG>>5. Вычислительные задачи (числа, числа и еще раз числа) ГВ>C++ с native-библиотеками или Fortran. C каких это пор .Net стал лучшей системой, ориентированной именно на вычисления? Он на UI и коммуникации ориентирован.
Вот тут я бы выбрал MС++
DG>>7. Стыковка с чужими библиотеками. ГВ>Какими? Если с плюсовыми, то лучше на плюсах, если Java, то аналогично.
Стыковка C++ с C++ довольно таки не просто. Ява с Явой? А если мне не подходит Ява? Нужен вот мне скрипт? Что, снова на Яве писать? А что если у меня уже туева куча на PHP написана? Снова все на Яву переписывать? Ты издеваешься или просто шутишь так?
Ладно, вот что интересно, ты как Фортран с С++ будешь скрешивать?
DG>>9. Устойчивость (легко восстанавливается при ошибке, легкая локализация утечек памяти) ГВ>Ерунда. Падает вплоть до выноса W2K вместе с собой. С утечками памяти как бороться — так это в форум "проектирование". Восстановление при ошибке — полезная, но не экстраординарная фича: что мне толку как пользователю с того, что Янус вываливал по 5-10 раз сообщения об ошибке? Если бы это была какая-нибудь "автоматическая семантика восстановления", то ещё ладно, а stack trace... Это даже не смешно. А утечки памяти и на плюсах попросту не допускаются при разумном подходе.
Где утечка памяти? На Нете? Утечка или перерасходывание памяти? Это два разных понятия — ты не путай. А что локализировать, так это ты чушь говоришь. Знаю я С++. С его чудо исключениями, которые еще не все перехватываються. Мне же даже не надо нигде ставить Try Catch по отлавливанию неотловимого. Я могу лишь в одном месте написать
Application.ThreadException += new ThreadExceptionEventHandler(OnThreadException) и все. А что Янус валиться, так это не из-за .NET. Не надо все сваливать в одну кучу. Выглядит как то не солидно.
DG>>10. Безопасность. ГВ>Не понял, какую именно безопасность ты имеешь ввиду? Их две: в смысле ограничения доступа пользователей к функциональности и блокировки доступа к памяти или unmanaged-ресурсам.
Безопасность unmanaged-ресурсов и .NET не совместимые понятия по определнию.
DG>>11. Версионность. ГВ>Хм. А это большая проблема? Вроде как Object Factory + Version Select Policy + ещё совсем немного составляют достойную альтернативу .Net-овскому встроенному механизму, да и реализуется несложно, если, конечно, не считать std::vector объектом версионирования, что было бы приятно, но по большей части — совершенно ни к чему.
Понятно. DLL Hell тебя не коснулась. Что ж тебе повезло.
DG>>С помощью чего будут решаться данные задачи? Что будет фундаментом? ГВ>Голова, конечно. Это единственный фундамент.
DG>>ps DG>>На данный момент, .Net выглядит хорошим кандидатом в качестве фундамента для решения всех вышеперечисленных задач.
ГВ>Технология не может быть фундаментом решения всех данных задач, увы.
.NET не абстрактен. Он реален. Поверь. И он многое решает
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>На самом деле, "геморрный код", о котором ты говоришь, появляется, только тогда, когда архитектура перекошена в пользу презентационного слоя и никто не думает о возможной мутации софта.
M>>А где я про это писал?
ГВ>Здесь
M>>>А кто сказал что это data-layer? Вот допустим я написал веб сервис. Он мне возвращает список товаров. Потом создал DataGrid и прибиндил к нему этот сервис. Я разве что то соединил? Нет. Я решил проблему без лишнего гемморного кода. При этом, веб сервис это не уровень доступа данных Это Business уровень, его фасад.
И что тут из того, что ты назваешь "перекошена в пользу презентационного слоя". Или у нас клиент уже не от веб сервиса данные получает?
ГВ>>>А байндинг — это вообще мелочи. Приятные, конечно, но мелочи. M>>Так так. А ты вообще с сервера как собираешься данные получать? Через святой дух?
ГВ>Я имею ввиду — мелочи в смысле сложности их реализации.
Из мелочей складываються блоки, из блоков — программы. Вместо готового реализуешь одно, потом другое, и не заметишь, как время, отведенное на разработку ПО, закончилось, а программа запускается через раз. Вот твой принцип?
ГВ>>>Э... "за морем телушка — полушка, да рупь перевоз". Знаешь такую пословицу? По мне, так лучше за неделю сделать простенький CRUD теми средствами, которые под рукой, чем тащить весь .Net и ещё интерфейс к нему. M>>Если все изначально писать правильно — на Нете, то ничего тащить не надо.
ГВ>Не доказано.
А что тебе нужно доказать? .NET он и есть .NET, что автономен. Ему ничего лишнего не надо.
ГВ>>>Личные проблемы Sun. Хорошо , но дело не в этом. ИМХО, использование XML на уровне коммуникаций вообще... кхм, не очень хорошая практика. M>>Почему? Из за большого размера? Ну дык это только сейчас кажеться.
ГВ>Это будет всегда так. Если бы это было не так, то мы бы сейчас поголовно писали с использованием интерпретируемого, а не компилируемого кода.
К нему стремимся. Напомнить тебе где должна лежать бизнес-логика?
M>>Если клиенты долго ожидают ответа, купить выделенку. Даже в нашей глухомани это обычное явление. M>>Если долго сервер обрабатывает запросы, заапгрейдить проц. M>>Если вы являетесь рьяным приверженцем LISP-а, сделайте общение клиента с сервером на нем.
M>>В чем проблема?
ГВ>В принципиально неверном подходе: "высока у стула ножка — подпилю её немножко". Только вместо стула подпиливается пол, на котором он стоит.
Отлично ответил. Только было бы не плохо аргументировать свои ответ.
ГВ>>>>>Да, но назначение ASP — работа в коммуникационной среде. Каких бы прибамбасов там ни было, "среда" для ASP всё равно — коммуникационная. Ну, плюс ещё презентативная логика в определённом смысле. M>>>>Честно говоря, если взглянуть глубже, то ASP это не только коммуникация. Что то мне подсказывает ГВ>>>... запросто создаётся перекос в сторону "программирования на форме". Впрочем, это ещё с Delphi и VB пошло... M>>И правильно пошло.
ГВ> Ну, вообще-то, это азы ОО-проектирования: не писать бизнес-код непосредственно в обработчиках событий UI.
А что тут то сложного? Бери с сайта microsoft.com их App Block, базирующийся на модель Doc-View-Controller. Или вас от готового нос воротит.
Тут как то dad заавлял, что MS выпустила свои продукту только потому, что парни (из MS) решили поднатареть в новых технологиях... К чему это я? Ах, да. Может он с адресацией обшибся?
ГВ>>>Но только всё равно контекст его применения ограничивается пользовательским интерфейсом к Web-приложениям. Интересно, для desktop-варианта тоже нужно интерфейс пользователя средствами ASP.NET городить? M>>Я думаю не стоит. Ведь .NET предоставляет богатый инсрументарий. Чем тебе WinForms не понравился?
ГВ>Хорошо, значит, имеем таки две независимых реализации интерфейса пользователя: для web и для desktop. Всё как всегда.
А что, есть какое-то средство разработки, позволяющее на один и тот же код (абстрактный) генерировать win и web приложения? По моему к такому только MS стремиться.
ГВ>>>А причём тут remoting? Это, кстати, тоже сугубо коммуникационная приблуда. Необходимость в нём "резко уничтожается", если на обоих машинах установлены одни и те же версии софта. M>>Опа, а это то тут при чем?
ГВ>Это я у тебя хотел спросить — с чего ты remoting вспомнил?
Дал для примера, что люди, совершенно не знающие предметную область начинают ее наять. Поговорка (запиши в свою коллекцию ) "Врага надо знать в лицо" тут явно не в почете
M>>Ну приколы связи, это вообшем то проблема прошлого века. Вероятно, тебе она кажется до сих пор весомой только по тому, что ты не используешь стандатрные вещи. Я уже даже не говорю про .NET. А вот насчет логики обработки... Тут все зависит от ее необходимости, и как ты ее собираешься решить.
ГВ>Кхм. Акстись. Я даже волшебное слово знаю — пожалуйста. Приколы связи как были, так и останутся навечно, пока её принципы каким-нибудь кардинальным образом не изменятся.
Если такие компоненты MSMQ. Позволяют пересылать на неустойчивом участке звязи данные со 100 гарантией. Расширяються за счет написания триггеров, связью с СУБД и прочей приблуды. Или тебе и это уже не нравиться, подавай самописное?
ГВ>>>Не знаю, как тебе, а мне что-то подсказывает, что совсем не все серверные объекты ездят на клиента. M>>Честно говоря, я вообще такую концепцию не применяю. И Remoting кстати это не позволяет, если не настроить обратную связь. Так что ничего на клиента не ездеет. Они оба (клиент, сервер) общаються через сторонние сущности.
ГВ>Хорошо, ты только подтвердил мои сомнения.
Какие если не секрет?
M>>>>Я просто часто вижу, как люди не разобравшись в инструменте, категорически его отвергают по каким-то своим внутренним убеждениям. ГВ>>>Я тоже такое часто вижу. Но я ведь и не отвергаю .Net Зачем? M>>Ты его просто игнорируешь
ГВ>А это с чего ты взял?
Неужто боишься?
M>>>>Давай тогда решим, какие ты типы программ имеешь ввиду, подрузомевая в них "не коммуникативные" ГВ>>>Как ни странно, но в первую очередь — бизнес-софт, M>>А что значит "бизнес-софт"? Мы обсуждаем, где конкретно место .NET. И я просил привести реальные места, а не абстрактное название. Или ты считаешь, что на .NET нельзя написать бизнес-софт?
ГВ>Нет, я этого не считаю и не раз прямо об этом говорил.
Тогда к чему ты привел словообразование "бизнес-софт"? Что и тут место Нету, это то понятно. Или ты что то тайное, с умыслом скрытым имел ввиду?
ГВ>>>>>Только объясни, плз., кого, "её" на клиенте реализоывать? M>>>>Indigo ГВ>>>Зачем? Если клиент предоставляет пользователю исключительно UI, то ему весь букет Indigo даром не нужен. M>>Хм. Не понял. А зачем весь. Только то, что позволяет куда то подключаться.
ГВ>А зачем тогда Indigo?
Логично. Мы ж велики любим. Салют, урал, школьник. Зачем на Indigo?
M>>К чему ты это сказал?
ГВ>К архитектуре.
А она тут к чему?
M>>Тут скорее всего подойдет Ява. Переносимость у Нет в другой сфере (архитектура процессора и КПК). Хотя, может и Моно поможет, но правда там ф-ть очень мизерная
ГВ>Хорошо, значит-таки, не всегда правильно писать на .Net?
Честно говоря, я считаю, что вин-серверные системы сейчас стали довольно-таки на высоком уровне. Но уж что захотел заказчик Заказчик всегда прав, даже если это расходится с логикой.
Что касается клиента. Лично я ни разу не видел требования к лиенту кроссплтаформенность. Это уж какие клиенты должны быть Может меня просто пронесло?
ГВ>>>К тому, что многое на многом можно написать. "вопрос в том, для чего они лучше всего годятся". M>>многое. Вот клучевое слово. Если у тебя есть время, для того чтобы создать систему с различными подходами и разными языками, то вообщем-то, и спор дальше не имеет вести смысл. За бесконечность я смогу сделать все что угодно.
ГВ>Аналогично. Вопрос в выборе адекватного решения. Да и "разные языки" по большому счёту — фикция, если уж они должны быть CLR-compliant.
Во-первых, CLS-compliant. Это как разработчику, знающему внутренности .NET Во-вторых, это не фикция. Это удобство. Думаю понятно В третьих, если ты имеешь ввиду, что есть какие то ограничения, накладываемые CLS-сompliant, то это раздутый слон из мухи. Использование вместо int Int32 решат практически всю проблему. Это для шарпа. Для других это вообще не надо, ибо они несколько обделены.
Так что тут стоит вопрос в другом, как ты будешь соединять солянку из Фортран, С++, Dephi?
M>>>Честно говоря, я вообще такую концепцию не применяю. И Remoting кстати это не позволяет, если не настроить обратную связь. Так что ничего на клиента не ездеет. Они оба (клиент, сервер) общаються через сторонние сущности.
Почему это серверные объекты не "ездят" на клиента?
Здравствуйте, mikа, Вы писали:
M> Есть. Но альтернатива состоит из совокупности. А .NET один. Тоесть, лучше использовать один язык программирования, к которому ты привык за долгие годы, и которые сможет так же легко реализовать задачу, как альтернативное средство во всех сферах, чем питаться сборной солянкой. Геннадий предлагаем нам супчик
Супчик этот заварен давно и не нами.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>>>6. Оптимизация (опять много разнородных объектов, частоменяющиеся требования, много вычислений) ГВ>>Это — задача компилятора. Любого. Или .Net уже научился переливать объектный код за границы COM-интерфейсов.
DG>Имелось ввиду не оптимизация на уровне компилятора, а оптимизационные задачи. DG>найти минимальное, максимальное, лучшее решение задачи стоящей перед пользователем.
DG>например, распределить машины по бензоправкам, или минимизировать расходы на проезд и т.д.
Хм... А чем здесь .Net лучше чем, к примеру, C++? Действительно, интересно.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
DG>>>Перед типичной программой стоят следующие задачи (и проблемы): DG>>>1. Пользовательский интерфейс ГВ>>Допускаю, что для UI .Net подходит неплохо, с учётом той горы библиотек, что уже есть. DG>>>2. Доступ к БД ГВ>>Ты и сам знаешь, сколько API существует. AFAIK, самый универсальный пока что — ODBC (что жаль, но такова селяви). А дальше всё зависит от БД. M>Опять же нет. В .NET 2.0 Sql станет в разу богаче, чем Odbc (сейчас же Sql самый быстрый провайдер, если он соединятьеся с Sql Server). К тому же, ты так и не привел достойного аналога Object Spaces.
Ну, не видел я пока .Net 2.0, даже пресс-релизы не все читал. Да и с Object Spaces ещё не разобрался основательно, а потому тебя о них и переспросил.
DG>>>5. Вычислительные задачи (числа, числа и еще раз числа) ГВ>>C++ с native-библиотеками или Fortran. C каких это пор .Net стал лучшей системой, ориентированной именно на вычисления? Он на UI и коммуникации ориентирован. M>Вот тут я бы выбрал MС++
Ну, если нужно связать ещё и с .Net, то можно и MC++, но вычислительную часть я бы лично на его C++-й части делал (шаблоны, всё-таки, хорошая вещь), а интерфейс к .Net — через managed-прибамбасы.
DG>>>7. Стыковка с чужими библиотеками. ГВ>>Какими? Если с плюсовыми, то лучше на плюсах, если Java, то аналогично. M>Стыковка C++ с C++ довольно таки не просто. Ява с Явой? А если мне не подходит Ява? Нужен вот мне скрипт? Что, снова на Яве писать? А что если у меня уже туева куча на PHP написана? Снова все на Яву переписывать? Ты издеваешься или просто шутишь так?
Ну, скажем так. C++ с C++ таки стыкуется, особливо, если компиляторы не слишком разные и библиотека не неизвестно откуда взялась.
M>Ладно, вот что интересно, ты как Фортран с С++ будешь скрешивать?
Смотря какой фортран. Нужно взять, да посмотреть конкретный компилер. У фортрана интерфейс к C должен быть.
DG>>>9. Устойчивость (легко восстанавливается при ошибке, легкая локализация утечек памяти) ГВ>>Ерунда. Падает вплоть до выноса W2K вместе с собой. С утечками памяти как бороться — так это в форум "проектирование". Восстановление при ошибке — полезная, но не экстраординарная фича: что мне толку как пользователю с того, что Янус вываливал по 5-10 раз сообщения об ошибке? Если бы это была какая-нибудь "автоматическая семантика восстановления", то ещё ладно, а stack trace... Это даже не смешно. А утечки памяти и на плюсах попросту не допускаются при разумном подходе.
M>Где утечка памяти? На Нете? Утечка или перерасходывание памяти? Это два разных понятия — ты не путай.
Я про утечки памяти в .Net не говорил, это к DarkGray вопросы. И на перерасход не жаловался.
M>А что локализировать, так это ты чушь говоришь. Знаю я С++. С его чудо исключениями, которые еще не все перехватываються.
Ну, видимо, не так уж и хорошо знаешь. Впрочем, это не беда, да и не важно по большому счёту. Вариантов решения проблем обычно не много, а очень много.
M>Мне же даже не надо нигде ставить Try Catch по отлавливанию неотловимого. Я могу лишь в одном месте написать M>Application.ThreadException += new ThreadExceptionEventHandler(OnThreadException) и все. А что Янус валиться, так это не из-за .NET. Не надо все сваливать в одну кучу. Выглядит как то не солидно.
Ладно, ладно, уболтал. Десйствительно — Янус это одно, а фреймворк — совсем другое. Просто мне как-то непонятно, как же он умудряется blue screen из W2K выколачивать? Там же всё насквозь управляется и контролируется. Впрочем, конечно, в пользу того, что это именно Янус с .Net говорит только наблюдение: если Януса больше суток не перезапускать, то blue screen появляется, если перезапускать периодически — всё в порядке. Может, Jet глючит, чёрт его знает.
DG>>>10. Безопасность. ГВ>>Не понял, какую именно безопасность ты имеешь ввиду? Их две: в смысле ограничения доступа пользователей к функциональности и блокировки доступа к памяти или unmanaged-ресурсам.
M>Безопасность unmanaged-ресурсов и .NET не совместимые понятия по определнию.
Тогда о чём там речь?
DG>>>11. Версионность. ГВ>>Хм. А это большая проблема? Вроде как Object Factory + Version Select Policy + ещё совсем немного составляют достойную альтернативу .Net-овскому встроенному механизму, да и реализуется несложно, если, конечно, не считать std::vector объектом версионирования, что было бы приятно, но по большей части — совершенно ни к чему.
M>Понятно. DLL Hell тебя не коснулась. Что ж тебе повезло.
Почему же? Касалась. Просто я не любитель искать велосипеды, я их как-то сам по необходимости делаю и... ничего, ездят.
DG>>>С помощью чего будут решаться данные задачи? Что будет фундаментом? ГВ>>Голова, конечно. Это единственный фундамент.
DG>>>ps DG>>>На данный момент, .Net выглядит хорошим кандидатом в качестве фундамента для решения всех вышеперечисленных задач. ГВ>>Технология не может быть фундаментом решения всех данных задач, увы.
M>.NET не абстрактен. Он реален. Поверь. И он многое решает
Знаешь, у меня как-то не возникало проблем с тем, чтобы доказать себе реальность существования .Net Так что, извини, но мимо кассы. А насчёт многая решений, так я в этом и не сомневаюсь — комуникации + UI.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>>>Предложите тогда, пожалуйста, реальную альтернативу .Net-у? DG>>>Перед типичной программой стоят следующие задачи (и проблемы):
DG>[skip]
DG>>>С помощью чего будут решаться данные задачи? Что будет фундаментом? ГВ>>Голова, конечно. Это единственный фундамент.
DG>А если серьезно?
Это и есть — серьёзно. Голова — единственный фундамент решения интеллектуальных задач.
DG>Еще раз напомню, что это все были задачи, которые встречаются в каждой программе в той или иной мере.
Угу. Особенно вычисления на высокой скорости. Почему-то мне чаще приходилось сталкиваться с оптимизациями памяти и SQL-запросов.
DG>Из предложенных тобой путей решения вырисовывается что-то страшное: DG>в одной программе ты одновременно используешь: DG>.Net(UI и коммуникации),
Угу, хотя с UI всё не так просто, как с коммуникациями, там внутренняя логика посложнее.
DG>Fortran для вычислительных задач,
Ну, это я для примера привёл, не цепляйся.
DG>C++,
DG>как все это стыкуется ты так и не сказал, DG>так же не сказал, на чем ты пишешь: DG>бизнес-логику,
Я бы лично предпочёл её писать на языке своей собственной среды или на том же самом C++. Или на прологе, или на лиспе. Но повторюсь — понятие "бизнес-логика" для меня не включает в себя ни в какой мере сеансы связи, коммуникации и т.п.
DG>оптимизационные задачи
Оптимизацию чего? Ты имеешь ввиду симплексы всяческие? Я бы её на плюсах написал, разумеется. Хотя, вполне возможно, что и на прологе.
DG>и т.д.
Что-то я не вижу здесь ничего страшного.
DG>>>ps DG>>>На данный момент, .Net выглядит хорошим кандидатом в качестве фундамента для решения всех вышеперечисленных задач. ГВ>>Технология не может быть фундаментом решения всех данных задач, увы. DG>.Net — это не только технология, это еще и среда, и как среда, она как раз может предоставлять фундамент для решения данных задач
Хорошо, не технология, а среда. Хоть груздь. Она предоставляет только инструмент для решения тех или иных элементов описанных тобой задач, а не задач в целом. Просто элементы эти меня всё ещё не впечатляют, как не впечатляли и пару лет назад. Может быть, ещё через пару лет моё мнение кардинально изменится, хотя мне что-то подсказывает, что этого не произойдёт, во всяком случае — так скоро.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>>>7. Стыковка с чужими библиотеками. ГВ>>Какими? Если с плюсовыми, то лучше на плюсах, если Java, то аналогично.
DG>Про Java-согласен. DG>Про плюсы совершенно не согласен. DG>Простыковать C++ — программу с чужой C++ — библиотекой — это очень нетривиальная задача.
Угу, значит к MC++ только MC++ стыкуем. Согласен. Ну как иначе стыковать имеющиеся плюсовые либы с .Net?
DG>На уровне исходников данная задача еще решается (но с большой долей геморроя), DG>а если библиотека в виде бинарника, то все приплыли. DG>Типичные проблемы при стыковке на уровне dll-ек: DG> отсутствие единого менеджера памяти (тот кто память выделил должен ее и освободить),
Вот это действительно траблой может оказаться.
DG> проблемы с именами (у разных компиляторов свои понятия о том, как должно выглядить имя), DG> проблемы с исключениями при переходе границ dll-ек DG> и т.д.
Добавь сюда ещё возможные конфликты имён. Тем не менее, эта проблема в принципе решаема методом отказа от поиска велосипедов.
Но в принципе не спорю — не всегда от их поиска можно отказаться. На крайний случай я бы сделал врапперы тем же компилятором, что и оригинальная dll, и там бы перехватил исключения, если они не ловятся в библиотеке, сделанной "основным" компилером. Можно найти решения, если захотеть их поискать.
DG>>>9. Устойчивость (легко восстанавливается при ошибке, легкая локализация утечек памяти) ГВ>>Ерунда. Падает вплоть до выноса W2K вместе с собой. DG>Не встречал. Вы уверены, что у программиста были прямые руки?
Не знаю.
DG>Предложите альтернативу. Какое средство (технология) позволяет меньше падать?
Прямые руки и не затуманенная голова. Надёжнейшее средство, рекомендую. Притом спасает не только в C++.
ГВ>> С утечками памяти как бороться — так это в форум "проектирование". Восстановление при ошибке — полезная, но не экстраординарная фича: что мне толку как пользователю с того, что Янус вываливал по 5-10 раз сообщения об ошибке? Если бы это была какая-нибудь "автоматическая семантика восстановления", то ещё ладно, а stack trace... Это даже не смешно. А утечки памяти и на плюсах попросту не допускаются при разумном подходе. DG>Янус некая бесплатная поделка, зачем ее в качестве примера приводить?
Ну а почему нет? Он вываливает stack trace, всё как положено по канону. А я, как канонический пользователь, нажимаю на continue.
DG>Я могу привести сотни более убогих примеров написанных на C++.
Я тоже. Но это как-то слабо вяжется с тезисами о защищённости и устойчивости .Net. Хотя, конечно, я был бы рад найти реальную причину. Тут и Jet может глючить и IE и ещё невесть что.
DG>Так ты начем предлагаешь писать? На чистых C++?
Подожди, я пока говорил не о том, "на чём надо писать", а о том "где место .Net"? Не чуешь разницы? Мне лично удобнее писать на C++, нежели на C# со-товарищи MSIL, но тем не менее — вопросы мои были о другом. Вообще забавно получается — я о том, что через .Net лучше всего коммуникации обслуживать (да и то — не всегда), а мне с оттенком испуга: "А остальное на чём?" А про остальное я как-то и не спрашивал.
DG>И как по твоему программа будет восстанавливатся вот после такого кода?: DG>
По-моему, такой код просто не надо писать, особенно первую часть. Или это труднообъяснимо?
DG>>>10. Безопасность. ГВ>>Не понял, какую именно безопасность ты имеешь ввиду? Их две: в смысле ограничения доступа пользователей к функциональности и блокировки доступа к памяти или unmanaged-ресурсам. DG>И то, и другое. В общем смысле, это одно и тоже, т.к. первое не может быть без второго.
В общем смысле это далеко не одно и тоже, да и нету тут никакого общего смысла. Тем не менее и что? Для первого случая — пишется очень простая система согласования прав и уровней допуска (только делать её надо ближе к началу работы, а не к концу, когда об этом вспоминают пользователи), а для второго — ну, блин... море информации по этому поводу, а если ещё и подумать, то вообще проблемы нет.
DG>>>11. Версионность. ГВ>>Хм. А это большая проблема? Вроде как Object Factory + Version Select Policy + ещё совсем немного составляют достойную альтернативу .Net-овскому встроенному механизму, да и реализуется несложно, если, конечно, не считать std::vector объектом версионирования, что было бы приятно, но по большей части — совершенно ни к чему. DG>Да, очень большая проблема. DG>Особенно если требования часто меняются, а в разработке участвует несколько фирм, отделов. DG>Причем скорость реакции на изменения у всех разная.
Хм. А если сначала разобраться с системным сегментом, то может, потом и несколько фирм и отделов привлекать не понадобится? А если и привлечь, то вообще-то можно и требования к исходным кодам выставить. Не пробовал? Ну там, единый компилятор, общий API, общее ядро... Я ж тебе говорю — с головы начинается фундамент, а не со среды программирования.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
M>Здравствуйте, dad, Вы писали:
M>>>Cледующие подобные вопросы в соответствующий форум.
M>>>Генерация кода нужна для того, чтобы работать не с Xml (SOAP) а с какими-то классами (прокси-объектами). Адаптер и конвертер нужен для того, чтобы процесс генерации был управляемым. Допустим, для разлиицных типов клиентов строиться разные типы проксей, добавляються сущности, с которые работают эти прокси-обекты.
dad>>так я и думал, rpc только в текстовом формате (xml) а терминов то ..
M>Ты думаешь, что RPC и кодогенерация это одно и тоже? Тогда самое время начать рассуждать преимущества Ява над .NET
Кстати, dad прав в том смысле, что RPC в принципе заменяет SOAP. Просто RPC "раскручен" меньше. А кодогенерация решает проблему, созданную SOAP-ом же. Короче, ещё один уровень проксей у нас получается.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, dad, Вы писали:
M>>>Ну, если сразу подходить с таким желанием узнать про новую для тебя функциональность, то конечно. Зачем вообще MS существует?
ГВ>>Для зарабатывания денег, есессно. Себе лично на нас в том числе. А ты думал, для чего? "Нести свет истины", что ли?
dad>на самом деле , мне кажется, что в майкросовт программисты нормальные чуваки, они занимаются тем, что интересно.есть задача — разработать крутой совт. они услышали что есть xml и решили — нормал давайте мочканем крутое. (про то что есть уже наработки спецификации и т.д. никто не думает) все с нуля и т.д. т.е. изучать и разработывать академические спецификации скучно и не интересно поэтому они делают свои и называют их по своему. за исключением веб-броузера.
Похоже на то, только у таких "исследований" один недостаток имеется — всюду один и тот же клин раздувания мелких мух в огромных слонов.
dad>а маркетинг уже продивигает потом нормально так. WDSL то се, гы. (это все, конечно, шутка )
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
M>>>Ну, если сразу подходить с таким желанием узнать про новую для тебя функциональность, то конечно. Зачем вообще MS существует?
ГВ>>Для зарабатывания денег, есессно. Себе лично на нас в том числе. А ты думал, для чего? "Нести свет истины", что ли?
M>Ага. Пытаемся в другую русло повернуть течение обсуждения. Теперь уже грязные деньги MS не даю нам покоя. Совет. Не думай о них. Живи проще
Я вроде как, деньги MS "грязными" не называл и не собираюсь. Обычная компания, обычные для компании цели. Или называть вещи своими именами уже моветон?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
M>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>>На самом деле, "геморрный код", о котором ты говоришь, появляется, только тогда, когда архитектура перекошена в пользу презентационного слоя и никто не думает о возможной мутации софта.
[...] M>И что тут из того, что ты назваешь "перекошена в пользу презентационного слоя". Или у нас клиент уже не от веб сервиса данные получает?
Я к тому, что оценка "геморный код" появляется тогда, когда сам этот код оказывается чем-то неожиданным и крайне нежелательным. Такие ситуации возникают, если имеется сильный перекос в сторону той или иной специфической семантики. Например — в пользу презентационной. Тогда необходимость написать какой-то сугубо системный код вызывает вполне естественное психологическое отторжение.
ГВ>>>>А байндинг — это вообще мелочи. Приятные, конечно, но мелочи. M>>>Так так. А ты вообще с сервера как собираешься данные получать? Через святой дух? ГВ>>Я имею ввиду — мелочи в смысле сложности их реализации. M>Из мелочей складываються блоки, из блоков — программы. Вместо готового реализуешь одно, потом другое, и не заметишь, как время, отведенное на разработку ПО, закончилось, а программа запускается через раз. Вот твой принцип?
Это очень наивное изложение, к тому же оно полностью отключает мозги, что досадно. У меня как-то и программы работают, и поисками велосипедов не озабочиваюсь. Хотя не спорю, по первому времени прохлопы по времени случались, пока смелости не хватало реализовывать то, что я считаю нужным так, как я это считаю нужным делать.
ГВ>>>>Э... "за морем телушка — полушка, да рупь перевоз". Знаешь такую пословицу? По мне, так лучше за неделю сделать простенький CRUD теми средствами, которые под рукой, чем тащить весь .Net и ещё интерфейс к нему. M>>>Если все изначально писать правильно — на Нете, то ничего тащить не надо. ГВ>>Не доказано. M>А что тебе нужно доказать? .NET он и есть .NET, что автономен. Ему ничего лишнего не надо.
mika, ну не скатывайся до банальной демагогии. "Это велико, потому что оно большое, а большое оно потому, что велико".
ГВ>>>>Личные проблемы Sun. Хорошо , но дело не в этом. ИМХО, использование XML на уровне коммуникаций вообще... кхм, не очень хорошая практика. M>>>Почему? Из за большого размера? Ну дык это только сейчас кажеться. ГВ>>Это будет всегда так. Если бы это было не так, то мы бы сейчас поголовно писали с использованием интерпретируемого, а не компилируемого кода. M>К нему стремимся. Напомнить тебе где должна лежать бизнес-логика?
Интересно, напомни. Неужели на уровне коммуникаций?
M>>>Если клиенты долго ожидают ответа, купить выделенку. Даже в нашей глухомани это обычное явление. M>>>Если долго сервер обрабатывает запросы, заапгрейдить проц. M>>>Если вы являетесь рьяным приверженцем LISP-а, сделайте общение клиента с сервером на нем. M>>>В чем проблема? ГВ>>В принципиально неверном подходе: "высока у стула ножка — подпилю её немножко". Только вместо стула подпиливается пол, на котором он стоит. M>Отлично ответил. Только было бы не плохо аргументировать свои ответ.
Аргументация очень простая и ты сам её привёл на самом деле. Если слегка перефразировать твою реплику, то получится, что если программы провоцируют перегрузку линий, то не программы оптимизируются, что было бы, ИМХО, логично, а линии апгрейдятся, что, ИМХО, без особой необходимости — неверно. Хотя спору нет — таким образом создаётся рынок для линий связи.
ГВ>>>>>>Да, но назначение ASP — работа в коммуникационной среде. Каких бы прибамбасов там ни было, "среда" для ASP всё равно — коммуникационная. Ну, плюс ещё презентативная логика в определённом смысле. M>>>>>Честно говоря, если взглянуть глубже, то ASP это не только коммуникация. Что то мне подсказывает ГВ>>>>... запросто создаётся перекос в сторону "программирования на форме". Впрочем, это ещё с Delphi и VB пошло... M>>>И правильно пошло. ГВ>> Ну, вообще-то, это азы ОО-проектирования: не писать бизнес-код непосредственно в обработчиках событий UI. M>А что тут то сложного? Бери с сайта microsoft.com их App Block, базирующийся на модель Doc-View-Controller. Или вас от готового нос воротит.
Не воротит, не переживай. Только как это относится к моей реплике?
M>Тут как то dad заавлял, что MS выпустила свои продукту только потому, что парни (из MS) решили поднатареть в новых технологиях... К чему это я? Ах, да. Может он с адресацией обшибся?
К чему это ты?
ГВ>>>>Но только всё равно контекст его применения ограничивается пользовательским интерфейсом к Web-приложениям. Интересно, для desktop-варианта тоже нужно интерфейс пользователя средствами ASP.NET городить? M>>>Я думаю не стоит. Ведь .NET предоставляет богатый инсрументарий. Чем тебе WinForms не понравился? ГВ>>Хорошо, значит, имеем таки две независимых реализации интерфейса пользователя: для web и для desktop. Всё как всегда. M> А что, есть какое-то средство разработки, позволяющее на один и тот же код (абстрактный) генерировать win и web приложения? По моему к такому только MS стремиться.
Не надо обобщать. Код Win-приложений и Web-приложений — не одно и тоже, тогда как обобщить интерфейсы пользователя в Win и Web — вполне можно.
ГВ>>>>А причём тут remoting? Это, кстати, тоже сугубо коммуникационная приблуда. Необходимость в нём "резко уничтожается", если на обоих машинах установлены одни и те же версии софта. M>>>Опа, а это то тут при чем? ГВ>>Это я у тебя хотел спросить — с чего ты remoting вспомнил? M>Дал для примера, что люди, совершенно не знающие предметную область начинают ее наять. Поговорка (запиши в свою коллекцию ) "Врага надо знать в лицо" тут явно не в почете
mika, у меня к тебе личный вопрос. А почему сразу "хаять"? Вроде как я .Net не ругаю, а просто выношу некоторые свои соображения для оспаривания. Ну уж извини за несколько пренебрежительный слог, я его считаю сленговым и вполне допустимым в профессиональном общении.
M>>>Ну приколы связи, это вообшем то проблема прошлого века. Вероятно, тебе она кажется до сих пор весомой только по тому, что ты не используешь стандатрные вещи. Я уже даже не говорю про .NET. А вот насчет логики обработки... Тут все зависит от ее необходимости, и как ты ее собираешься решить. ГВ>>Кхм. Акстись. Я даже волшебное слово знаю — пожалуйста. Приколы связи как были, так и останутся навечно, пока её принципы каким-нибудь кардинальным образом не изменятся. M>Если такие компоненты MSMQ. Позволяют пересылать на неустойчивом участке звязи данные со 100 гарантией. Расширяються за счет написания триггеров, связью с СУБД и прочей приблуды. Или тебе и это уже не нравиться, подавай самописное?
Стоп-стоп-стоп. MSMQ — это способ решения проблемы доставки, но на такие приколы, как выпадение по таймауту его использование ну никак не повлияет. А особенно, если один объект посылает сообщение (сиречь — вызывает метод) и... упс... оно уходит по MSMQ, а в это время на линии возникает перегрузка... а MSMQ она ж с гарантированной доставкой — она хоть месяц ждать будет, только вот что объекту-то делать? Месяц висеть?
ГВ>>>>Не знаю, как тебе, а мне что-то подсказывает, что совсем не все серверные объекты ездят на клиента. M>>>Честно говоря, я вообще такую концепцию не применяю. И Remoting кстати это не позволяет, если не настроить обратную связь. Так что ничего на клиента не ездеет. Они оба (клиент, сервер) общаються через сторонние сущности. ГВ>>Хорошо, ты только подтвердил мои сомнения. M>Какие если не секрет?
Что remoting что-то кардинально меняет.
M>>>>>Я просто часто вижу, как люди не разобравшись в инструменте, категорически его отвергают по каким-то своим внутренним убеждениям. ГВ>>>>Я тоже такое часто вижу. Но я ведь и не отвергаю .Net Зачем? M>>>Ты его просто игнорируешь ГВ>>А это с чего ты взял? M>Неужто боишься?
Смешно.
M>>>>>Давай тогда решим, какие ты типы программ имеешь ввиду, подрузомевая в них "не коммуникативные" ГВ>>>>Как ни странно, но в первую очередь — бизнес-софт, M>>>А что значит "бизнес-софт"? Мы обсуждаем, где конкретно место .NET. И я просил привести реальные места, а не абстрактное название. Или ты считаешь, что на .NET нельзя написать бизнес-софт? ГВ>>Нет, я этого не считаю и не раз прямо об этом говорил. M>Тогда к чему ты привел словообразование "бизнес-софт"? Что и тут место Нету, это то понятно. Или ты что то тайное, с умыслом скрытым имел ввиду?
Бизнес-софт всё-таки разный бывает, не находишь? Поисковики — тоже бизнес софт и высокопроизводительные вычисления — тоже, однако.
ГВ>>>>>>Только объясни, плз., кого, "её" на клиенте реализоывать? M>>>>>Indigo ГВ>>>>Зачем? Если клиент предоставляет пользователю исключительно UI, то ему весь букет Indigo даром не нужен. M>>>Хм. Не понял. А зачем весь. Только то, что позволяет куда то подключаться. ГВ>>А зачем тогда Indigo? M>Логично. Мы ж велики любим. Салют, урал, школьник. Зачем на Indigo?
Мда.
M>>>К чему ты это сказал? ГВ>>К архитектуре. M>А она тут к чему?
А с неё всё начинается. ИМХО, хорошая архитектура просто и однозначно делит семантику системы по доменам (в терминологии Буча) в одной группе — только отображение, в другой — только прикладнуха, в третьей — только БД и т.д. и т.п. Переверни архитектуру с ног на голову (здесь — бухгалтерия, здесь — склад, здесь — отчёты) и сопровождаемость в первую очередь усложняется в разы. Ну, разумеется, эта проблема не так остро стоит перед простенькими приложениями.
M>>>Тут скорее всего подойдет Ява. Переносимость у Нет в другой сфере (архитектура процессора и КПК). Хотя, может и Моно поможет, но правда там ф-ть очень мизерная ГВ>>Хорошо, значит-таки, не всегда правильно писать на .Net? M>Честно говоря, я считаю, что вин-серверные системы сейчас стали довольно-таки на высоком уровне. Но уж что захотел заказчик Заказчик всегда прав, даже если это расходится с логикой.
Хорошо, пусть так. Не будем начинать holy war.
M>Что касается клиента. Лично я ни разу не видел требования к лиенту кроссплтаформенность. Это уж какие клиенты должны быть Может меня просто пронесло?
Простейший пример кросплатформенного интерфейса пользователя: desktop + web.
ГВ>>>>К тому, что многое на многом можно написать. "вопрос в том, для чего они лучше всего годятся". M>>>многое. Вот клучевое слово. Если у тебя есть время, для того чтобы создать систему с различными подходами и разными языками, то вообщем-то, и спор дальше не имеет вести смысл. За бесконечность я смогу сделать все что угодно. ГВ>>Аналогично. Вопрос в выборе адекватного решения. Да и "разные языки" по большому счёту — фикция, если уж они должны быть CLR-compliant.
M>Во-первых, CLS-compliant. Это как разработчику, знающему внутренности .NET
Спасибо за замечание — я аббревиатуры часто путаю, а проблемы CLS у меня на языке не крутятся.
M>Во-вторых, это не фикция. Это удобство. Думаю понятно
Для кого?
M>В третьих, если ты имеешь ввиду, что есть какие то ограничения, накладываемые CLS-сompliant, то это раздутый слон из мухи. Использование вместо int Int32 решат практически всю проблему. Это для шарпа. Для других это вообще не надо, ибо они несколько обделены.
Мика, это всё к делу не относится. Достаточно требования отображения на объектную среду. Хотя, пожалуй, то здесь я погорячился — вроде как проблема не настолько уж и велика, раз уж даже C++ появиться должен.
M>Так что тут стоит вопрос в другом, как ты будешь соединять солянку из Фортран, С++, Dephi?
А у них, вроде как C-интерфейсы есть. Хотя, если честно, то от Delphi я бы постарался избавиться.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>>>7. Стыковка с чужими библиотеками. ГВ>>Какими? Если с плюсовыми, то лучше на плюсах, если Java, то аналогично.
DG>О! Т.е. ты себя сразу ограничиваешь рамками того языка, на котором пишешь.
DG>А как ты предлагаешь, например, стыковатся с библиотекой написанной на Delphi, на фортране, на скрипте каком-то, на прологе?
Нет, просто мне нечасто приходилось сталкиваться с необходимостью интеграции скриптовых библиотек. Так что, про скрипты что-то определённое сказать не могу, кроме того, что, вероятно, закручу интерфейсы через COM или что-то в это роде. А что до фортрана и пролога, так с ними через C-интерфейсы связаться можно.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Кстати, dad прав в том смысле, что RPC в принципе заменяет SOAP. Просто RPC "раскручен" меньше. А кодогенерация решает проблему, созданную SOAP-ом же.
А мне так показалось, что кодогенерация никак не привязана к SOAP. Это просто вопрос эффективного маршалинга. Какой бы транспорт ты ни использовал, тебе надо делать маршалинг. Вариантов всего три с половиной:
1. Вручную. Читаешь спецификацию транспорта и делаешь прокси и стуб. Материшься, отлаживаешь, но зато имеешь максимум перформанса и трюки типа "не передавать дефолтные значения".
2. Reflection если есть. Минимум усилий. Прокладка между объектом и транспортом нудно допрашивает его о всех подробностях. Минимум эффективности.
3. Статическая кодогенерация по метаданным. Например MIDL.
3.5. Динамическая кодогенерация по метаданным. Ее и обсуждаем. Позволяет получить эффективность сравнимую с 2, а то и 1 (если дать возможность управлять кодогенерацией), при усилиях сравнимых с 2.
... << RSDN@Home 1.1.2 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
M>>>>Честно говоря, я вообще такую концепцию не применяю. И Remoting кстати это не позволяет, если не настроить обратную связь. Так что ничего на клиента не ездеет. Они оба (клиент, сервер) общаються через сторонние сущности.
DG>Почему это серверные объекты не "ездят" на клиента? DG>а как же аттрибут [Serializable]? DG>и при чем здесь обратная связь?
Короче всместо того что бы делать раздельно простые и понятные вещи, такие как:
— кроссплатформенная и двочнонезависимая сериализация
— прозрачная и понятная сетевая коммуникация в том числе и поверх http (для веб)
— кроссплатформенная управляемая билиоткека
— кроссплатформенный язык программирования
они опять все нарезали в один батон. местами получилось лучше явы, но что толку?
виндовс тоже местами лучше других ос, но рабтают то на нем персоналки.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
M>>>Генерация кода нужна для того, чтобы работать не с Xml (SOAP) а с какими-то классами (прокси-объектами). Адаптер и конвертер нужен для того, чтобы процесс генерации был управляемым. Допустим, для разлиицных типов клиентов строиться разные типы проксей, добавляються сущности, с которые работают эти прокси-обекты.
dad>>так я и думал, rpc только в текстовом формате (xml) а терминов то ..
M>Ты думаешь, что RPC и кодогенерация это одно и тоже? Тогда самое время начать рассуждать преимущества Ява над .NET
нет я думаю что soap это оо аналог rpc в формате xml. веб сервисы это наворот поверх http, которые к тому же требуют веб сервера который это поддрживал бы.
wdsl это метаязык описания севиса, на манер idl.
или я ошибаюсь?
кодогенерация это что? компиляция во время выполнения что ли?
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
ГВ>Кстати, dad прав в том смысле, что RPC в принципе заменяет SOAP. Просто RPC "раскручен" меньше. А кодогенерация решает проблему, созданную SOAP-ом же. Короче, ещё один уровень проксей у нас получается.
кстати есть xml-rpc, и куча интерфесов ко всем языкам от явы до перло..
чем не .net
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
DG>>>>7. Стыковка с чужими библиотеками. ГВ>>>Какими? Если с плюсовыми, то лучше на плюсах, если Java, то аналогично.
DG>>О! Т.е. ты себя сразу ограничиваешь рамками того языка, на котором пишешь.
DG>>А как ты предлагаешь, например, стыковатся с библиотекой написанной на Delphi, на фортране, на скрипте каком-то, на прологе?
можно подумать до появления .net никто никогда не связывал программы на фортране и php
ГВ>Нет, просто мне нечасто приходилось сталкиваться с необходимостью интеграции скриптовых библиотек. Так что, про скрипты что-то определённое сказать не могу, кроме того, что, вероятно, закручу интерфейсы через COM или что-то в это роде. А что до фортрана и пролога, так с ними через C-интерфейсы связаться можно.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
DG>>>А как ты предлагаешь, например, стыковатся с библиотекой написанной на Delphi, на фортране, на скрипте каком-то, на прологе?
dad>можно подумать до появления .net никто никогда не связывал программы на фортране и php
Конечно, стыковались. Но редко, геморройно и дорого.
А когда заказчик узнает стоимость такой стыковки, то у него волосы начинают шевелиться.
DG>>например, распределить машины по бензоправкам, или минимизировать расходы на проезд и т.д.
ГВ>Хм... А чем здесь .Net лучше чем, к примеру, C++? Действительно, интересно.
Тем, что я могу прозрачно и дешево зацепить Fortran.Net, Prolog.Net или какой-нибудь FuzzyLogic.Net для решения данной задачи.
И мне не надо будет решать тонну проблем связанную со стыковкой разных языков, разных dll-ек и т.д.
ГВ>Добавь сюда ещё возможные конфликты имён. Тем не менее, эта проблема в принципе решаема методом отказа от поиска велосипедов.
Т.е. всё пишем сами? А заказчик стоимость разработки велосипедов готов оплачивать?
Или ему уже посоветовали соседнюю фирму, в которой стоимость разработки будет меньше, потому что они не изобретают велосипеды?
DG>>Я могу привести сотни более убогих примеров написанных на C++.
ГВ>Я тоже. Но это как-то слабо вяжется с тезисами о защищённости и устойчивости .Net.
.Net только гарантирует устойчивость, когда использует managed-код; как только появляется unsafe или unmanaged код, то вся устойчивость лежит на совести разработчика.
.Net — не серебрянная пуля, это просто технология, которая позволяет ряд вещей сделать проще.
DG>>Так ты начем предлагаешь писать? На чистых C++?
ГВ>Подожди, я пока говорил не о том, "на чём надо писать", а о том "где место .Net"? Не чуешь разницы?
Не чую. .Net предоставляет более дешевый способ решения многих проблем, и пока ты не предложишь такой же по дешевизне способ для решения этих задач, то те разработчики, которые используют .Net, будут в более выигрышном положении, чем ты.
А значит и заказчики пойдут не к тебе.
ГВ> Мне лично удобнее писать на C++, нежели на C# со-товарищи MSIL, но тем не менее — вопросы мои были о другом. Вообще забавно получается — я о том, что через .Net лучше всего коммуникации обслуживать (да и то — не всегда), а мне с оттенком испуга: "А остальное на чём?" А про остальное я как-то и не спрашивал.
Задам вопрос по другому: почему ты считаешь, что на C++ писать проще, чем на C# на пример?
DG>>И как по твоему программа будет восстанавливатся вот после такого кода?: DG>>
ГВ>По-моему, такой код просто не надо писать, особенно первую часть. Или это труднообъяснимо?
Предложи реальный способ, который будет не допускать появлении такого кода.
throw ведь могут быть и не явными. Могут быть из-за каких-то ошибок программиста, но пользователю-то будет от этого не легче.
ГВ>Хм. А если сначала разобраться с системным сегментом, то может, потом и несколько фирм и отделов привлекать не понадобится? А если и привлечь, то вообще-то можно и требования к исходным кодам выставить. Не пробовал? Ну там, единый компилятор, общий API, общее ядро... Я ж тебе говорю — с головы начинается фундамент, а не со среды программирования.
Например, тебе нужно простыковатся с банковской системой, или с товарной системой твоего партнера.
И то, и другое уже написано, вложена куча денег, и если ты будешь пытатся навязывать жесткие ограничения на используемый компилятор, на используемый язык, то тебя просто пошлют.
DG>>и т.д. ГВ>Что-то я не вижу здесь ничего страшного.
Реальная задачка:
Есть бензино-разливочная компания, они хотят автоматизироватся:
В рамках данной задачи надо сделать следующее:
1. Простыковатся с банковской системой
а) для проверки пришли ли платежи
b) для оплаты поставок от "нефтяной компании".
2. Простыковатся с "нефтяной компании" для осуществленняя автоматического заказа новых партий бензина
3. упростить написание правил расчета цен за товар (есть много разных скидок, различных партнерских договоров и т.д.)
4. оптимизировать стоимость хранения бензина (хранить только столько, сколько необходимо)
5. разработать удобный пользовательский интерфейс для всего этого
6. сформировать толпу отчетов
Вопрос: на чем все это будет написано?
И что ты, кроме xml-я, предлагаешь использовать для стыковки с партнерами и банком?
ГВ>>По-моему, такой код просто не надо писать, особенно первую часть. Или это труднообъяснимо?
DG>Предложи реальный способ, который будет не допускать появлении такого кода. DG>throw ведь могут быть и не явными. Могут быть из-за каких-то ошибок программиста, но пользователю-то будет от этого не легче.
Бить морду программиста и высмеивать его на доске почета.
хорошая альтерантива твоему предложению:
"Купите совт под дот нет и вам станет легче от ошибок программиста"
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
DG>В рамках данной задачи надо сделать следующее: DG>1. Простыковатся с банковской системой
кому простыковаться?
DG> а) для проверки пришли ли платежи
обычно банки предоставляют свой совт для доступа к данным
DG> b) для оплаты поставок от "нефтяной компании".
тот же совт от банка для оформления платежек.
причем у каждого банка все по разному видел даже в лотус нотес
и даже если ты захочешь зделать све клиентское ПО, на кой ляд тебе дот нет?
DG>2. Простыковатся с "нефтяной компании" для осуществленняя автоматического заказа новых партий бензина
кому простыковаться? попросить нефтяную компанию написать свое по на дот нет?
DG>3. упростить написание правил расчета цен за товар (есть много разных скидок, различных партнерских договоров и т.д.) DG>4. оптимизировать стоимость хранения бензина (хранить только столько, сколько необходимо)
а причем тут дот нет?
DG>5. разработать удобный пользовательский интерфейс для всего этого
html либо текст в зависимости от рабочего места
DG>6. сформировать толпу отчетов
ок
DG>Вопрос: на чем все это будет написано?
как мы увидели — три совта — банковский, совт "нефтяной камании", и твой учетный совт.
твой учетный софт может быть написан на чем угодно, никаких примуществ дот нет я не вижу.
DG>И что ты, кроме xml-я, предлагаешь использовать для стыковки с партнерами и банком?
хмл вполне подходит для данной задачи обмена данными.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, mikа, Вы писали:
M>> Есть. Но альтернатива состоит из совокупности. А .NET один. Тоесть, лучше использовать один язык программирования, к которому ты привык за долгие годы, и которые сможет так же легко реализовать задачу, как альтернативное средство во всех сферах, чем питаться сборной солянкой. Геннадий предлагаем нам супчик
ГВ>Супчик этот заварен давно и не нами.
Раз давно и не нами, значит правильно? Великолепная логика!
DG>Реальная задачка: DG>Есть бензино-разливочная компания, они хотят автоматизироватся:
DG>В рамках данной задачи надо сделать следующее: DG>1. Простыковатся с банковской системой DG> а) для проверки пришли ли платежи DG> b) для оплаты поставок от "нефтяной компании". DG>2. Простыковатся с "нефтяной компании" для осуществленняя автоматического заказа новых партий бензина DG>3. упростить написание правил расчета цен за товар (есть много разных скидок, различных партнерских договоров и т.д.) DG>4. оптимизировать стоимость хранения бензина (хранить только столько, сколько необходимо) DG>5. разработать удобный пользовательский интерфейс для всего этого DG>6. сформировать толпу отчетов
1 и 2. Какие интерфейсы предоставляют банковская система и ИС нефтяной компании, допустим они поддерживают SOAP.
3 и 4. IMHO, если я правильно понял это бизнес-задачи, будем решать их на уровне бизнес-логики.
5. Какая платформа предполагается для клиентов, допустим windows и *nix.
6. Надо уточнить в каком формате должны быть отчеты, например HTML,XSL,PDF, RTF, XML:FO.
Отдельный вопрос если требуется OLAP.
DG>Вопрос: на чем все это будет написано? DG>И что ты, кроме xml-я, предлагаешь использовать для стыковки с партнерами и банком?
1. В качестве протокола взаимодействия использовать будем SOAP, (спецификация на http://www.w3.org/TR/SOAP).
2. Для управления работой бизнес-логики используем app server, например jboss, не подходит jboss на http://www.theserverside.com/reviews/matrix.jsp можно подобрать другой, соответственно для реализации бизнес-логики используем EJB.
3. С клиентами интереснее. Первый вариант кросплатформенный web клиент — с ним будем работать из IE (windows) и, например Mozilla (*nix). Динамику в HTML делаем через DOM (http://www.w3c.org/DOM/). Серверная часть реализуется на jsp/servlets под управлением app-сервера.
Второй вариант клиент только для windows — используем Delphi, быстро дешево, красиво, функционально.
Клиент естественно тонкий, только GUI.
4. Для построения оперативных отчетов используем, например jasperreport (http://jasperreports.sourceforge.net/) — это только report engine и к ней желательно приобрести построитель отчетов. Далее придется немного поработать руками, что бы вставить его в app server. В результате получим генерацию отчетов на сервере. На клиента их можно отдавать по http или SOAP, что больше нравится.
5. Далее что бы связать все это вместе на app server ставим axis (http://ws.apache.org/axis/) — он обеспечит нам SOAP между клиент<->бизнес-логика, бизнес-логика<->банк, бизнес-логика<->нефтянники.
6. Для хранения данных используем Firebird SQL server (www.ibase.ru) — IMHO очень хороший версионник, если объем данных и нагрузка очень большая — IMHO придется потратиться на Oracle. Он же пригодится и для OLAP (если OLAP конечно нужен).
7. С ростом числа пользователей можно поднять еще один app-сервер и соединить их в кластер. Реально этого не делал, но многие производители app-серверов такие вещи декларируют.
Далее какие средства используем:
1. CVS.
2. Какой нибудь bugtracker — Bugzilla, Mantis и тд.
3. Eclipse + XDoclets — разработка, отладка, кодогенерация и тд.
4. JUnit для прогона unit-тестов.
5. ant — для управления компиляцией, сборки приложения, запуска тестов, размещения приложения на сервере и тд. — общем аналог make
6. Для работы с БД — структуру посмотреть, скриптик запустить и тд, ну например dbVisualizer.
7. Для проектирования базы данных — PowerDesigner.
8. Для проектирования приложения..... Together или PowerDesigner. К Together есть ряд вопросов, после того как его перекупила Borland.
9. Операционная система — Linux (ALT, ASP, RH .....). Ставится ОС, средства разработки и коммуникации, настраивается один раз и закатывается image на болванку.
Если есть вопросы, замечания и конструктивные предложения — буду рад их услышать.
Здравствуйте, DarkGray, Вы писали:
M>>>>Честно говоря, я вообще такую концепцию не применяю. И Remoting кстати это не позволяет, если не настроить обратную связь. Так что ничего на клиента не ездеет. Они оба (клиент, сервер) общаються через сторонние сущности.
DG>Почему это серверные объекты не "ездят" на клиента?
DG>а как же аттрибут [Serializable]?
DG>и при чем здесь обратная связь?
Честно говоря, я подумал что Геннадий разбирается в remoting. Поэтому, я его понял так, что обекты серверные передаються ссылкой на клиент. Здесь нужна как бы обратная связь.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Кстати, dad прав в том смысле, что RPC в принципе заменяет SOAP. Просто RPC "раскручен" меньше. А кодогенерация решает проблему, созданную SOAP-ом же. Короче, ещё один уровень проксей у нас получается.
Вот ты мне скажи как профессионал, где тут прав dad? В том, что он не знает что такое RPC? RCP — это протокол общения (AKA транспортный). SOAP — это протокол форматирования. Обычно SOAP передаеться в HTTP. Сравнивать SOAP и RPC все равно, что самолет с унитазом. Это раз. Во-вторых, кодогенерация — вообще никаким боком не подходит к RCP ибо появлась тогда, когда еще и сетевого общения в помине не было.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Похоже на то, только у таких "исследований" один недостаток имеется — всюду один и тот же клин раздувания мелких мух в огромных слонов.
Это конечно красивые слова, но не более. С чего ты это взял? Где доказательства, кроме твоих субективных рассуждений?
Здравствуйте, mikа, Вы писали:
M>Опять же нет. В .NET 2.0 Sql станет в разу богаче, чем Odbc (сейчас же Sql самый быстрый провайдер, если он соединятьеся с Sql Server). К тому же, ты так и не привел достойного аналога Object Spaces.
JDO. И в отличие от OS давно есть уже зарелизиные реализации.
M>Где утечка памяти? На Нете?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Впрочем, конечно, в пользу того, что это именно Янус с .Net говорит только наблюдение: если Януса больше суток не перезапускать, то blue screen появляется, если перезапускать периодически — всё в порядке. Может, Jet глючит, чёрт его знает.
Скорее твое железо. У меня янус не перезапускается все 5 рабочих дней, BSOD пока ни разу не видел.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ> Я вроде как, деньги MS "грязными" не называл и не собираюсь. Обычная компания, обычные для компании цели. Или называть вещи своими именами уже моветон?
А зачем тогда речь о деньгах? Или ты хочешь что и там место для .NET? Согласен, для банковских операций тенхология вписывается лучше не куда.
AVM>2. Для управления работой бизнес-логики используем app server, например jboss, не подходит jboss на http://www.theserverside.com/reviews/matrix.jsp можно подобрать другой, соответственно для реализации бизнес-логики используем EJB.
tomcat
AVM>3. С клиентами интереснее. Первый вариант кросплатформенный web клиент — с ним будем работать из IE (windows) и, например Mozilla (*nix). Динамику в HTML делаем через DOM (http://www.w3c.org/DOM/). Серверная часть реализуется на jsp/servlets под управлением app-сервера.
or xforms engine
AVM>Второй вариант клиент только для windows — используем Delphi, быстро дешево, красиво, функционально.
and dcom/corba gateaway
AVM>5. Далее что бы связать все это вместе на app server ставим axis (http://ws.apache.org/axis/) — он обеспечит нам SOAP между клиент<->бизнес-логика, бизнес-логика<->банк, бизнес-логика<->нефтянники.
там и покруче есть вещи (если уж ява )
AVM>6. Для хранения данных используем Firebird SQL server (www.ibase.ru) — IMHO очень хороший версионник, если объем данных и нагрузка очень большая — IMHO придется потратиться на Oracle. Он же пригодится и для OLAP (если OLAP конечно нужен).
можнои и sql lite ибо клиент все равно один
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, dad, Вы писали:
dad>они опять все нарезали в один батон. местами получилось лучше явы, но что толку?
По моему, это ты все в одну кашу для себя намешал. Путаешь элементарные понятия. Как же тогда ты можешь с легкостью утвержать, что для данной задачи наиболее актуален Java, если ты не знаешь возможности конкурентных средств?
M> Вот ты мне скажи как профессионал, где тут прав dad? В том, что он не знает что такое RPC? RCP — это протокол общения (AKA транспортный). SOAP — это протокол форматирования. Обычно SOAP передаеться в HTTP. Сравнивать SOAP и RPC все равно, что самолет с унитазом. Это раз. Во-вторых, кодогенерация — вообще никаким боком не подходит к RCP ибо появлась тогда, когда еще и сетевого общения в помине не было.
нормально так, меня обвиняет в том что я не сведущь в элементарных понятиях, а сам налево инаправо терминами сыплешь.
соап это действиетельно спецификация разработанная для обмена структурированной информацией между распределенноыми объектами. я к тому, что технологически это не несет ничего нового и огружать это громкой терминологией нет никакиго смысла.
это как паттерны преподносить как новый подход к программированию, хотя это всего лишь использование ООП.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну, если нужно связать ещё и с .Net, то можно и MC++, но вычислительную часть я бы лично на его C++-й части делал (шаблоны, всё-таки, хорошая вещь), а интерфейс к .Net — через managed-прибамбасы.
Вот видишь, как твой подход плох. Твои вычисления надо еще с внешним миром связать, а у меня это по умолчанию. Особоенно, тот факт, что тебе еще ни разу со скриптами не удалось связываться, то совсем грустно. Кстати, раз скрипты, то значит COM. Интересно, как ты считаешь, custom marshaller тривиальна задача? Или ты ограничишься строчками?
ГВ>Ну, скажем так. C++ с C++ таки стыкуется, особливо, если компиляторы не слишком разные и библиотека не неизвестно откуда взялась.
Ах, тут еще и компиляторы одинаковые? Совсем великолепно. Это с учетом того, что нам нужна кроссплатформенность. Пр6едставляю, библиотека написанная на Sun великолепно стыкуеться с интел компиллерной программой.
M>>Ладно, вот что интересно, ты как Фортран с С++ будешь скрешивать?
ГВ>Смотря какой фортран. Нужно взять, да посмотреть конкретный компилер. У фортрана интерфейс к C должен быть.
Ох Сразу ностальгия по прологу. Я им как то интерфейс расширял по созданию Win32 приложений. Мда. Вот оно бездонетное детство
M>>Где утечка памяти? На Нете? Утечка или перерасходывание памяти? Это два разных понятия — ты не путай.
ГВ>Я про утечки памяти в .Net не говорил, это к DarkGray вопросы. И на перерасход не жаловался.
А как с этим справляется C++? (ответ не нужен. Я знаю примено какой он. Используйте умные указатели, кодируйте правильно и толку от этого не будет )
M>>А что локализировать, так это ты чушь говоришь. Знаю я С++. С его чудо исключениями, которые еще не все перехватываються.
ГВ>Ну, видимо, не так уж и хорошо знаешь. Впрочем, это не беда, да и не важно по большому счёту. Вариантов решения проблем обычно не много, а очень много.
Ух ты? Да ну. А запись в память, которая еще не занято, но уже не используется? Там есть чудо менеджер памяти или как?
Так, мы еще и C++ плоховато знаем. Щас, дойдем до пролога и потом и до фортрана. И выясниться, что беседовал я тут сам с собою
ГВ>Ладно, ладно, уболтал. Десйствительно — Янус это одно, а фреймворк — совсем другое. Просто мне как-то непонятно, как же он умудряется blue screen из W2K выколачивать? Там же всё насквозь управляется и контролируется. Впрочем, конечно, в пользу того, что это именно Янус с .Net говорит только наблюдение: если Януса больше суток не перезапускать, то blue screen появляется, если перезапускать периодически — всё в порядке. Может, Jet глючит, чёрт его знает.
Или винда. Не управляемая ведь
ГВ>Тогда о чём там речь?
CAS (code access security)
M>>Понятно. DLL Hell тебя не коснулась. Что ж тебе повезло. ГВ>Почему же? Касалась. Просто я не любитель искать велосипеды, я их как-то сам по необходимости делаю и... ничего, ездят.
Видно, что человек с COM не особо работал. Зато С++ со скриптом использовал
M>>.NET не абстрактен. Он реален. Поверь. И он многое решает ГВ>Знаешь, у меня как-то не возникало проблем с тем, чтобы доказать себе реальность существования .Net Так что, извини, но мимо кассы. А насчёт многая решений, так я в этом и не сомневаюсь — комуникации + UI.
Я тебя еще раз прошу привести мне все аспекты, для которых ты считатешь что Нет к ним не подойдет. Пока что от своих "бизнес-задач" ты отказался.
dad>>они опять все нарезали в один батон. местами получилось лучше явы, но что толку?
M>По моему, это ты все в одну кашу для себя намешал. Путаешь элементарные понятия. Как же тогда ты можешь с легкостью утвержать, что для данной задачи наиболее актуален Java, если ты не знаешь возможности конкурентных средств?
для какой "данной задачи" ?
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, mikа, Вы писали:
M>А что тебе нужно доказать? .NET он и есть .NET, что автономен. Ему ничего лишнего не надо.
Кхм . Мягко говоря это не так. Ты думаешь в янусе Jet и IE от хорошей жизни используются?
ГВ>>А зачем тогда Indigo?
M>Логично. Мы ж велики любим. Салют, урал, школьник. Зачем на Indigo?
Ты бы все таки ответил, а то похоже ГВ просто не совсем представляет себе что это такое и для чего оно нужно.
M>Что касается клиента. Лично я ни разу не видел требования к лиенту кроссплтаформенность.
ГВ>>Кстати, dad прав в том смысле, что RPC в принципе заменяет SOAP. Просто RPC "раскручен" меньше. А кодогенерация решает проблему, созданную SOAP-ом же. Короче, ещё один уровень проксей у нас получается.
M> Вот ты мне скажи как профессионал,
более того могу заметить, что соглашение о вызове должно оставаться соглашением о вызове.
опять же не надо soap как таковой относить к заслугам майкросовт и .net
конечно soap это более фундаментальная спецификация (рекоммендация) более обширно использует xml и т.д.
но ведь, чем проще, тем лучше, тем быстрее и надежней.. сремление "все в одном" никому не приносило еще большйо пользы.
модульность на первом месте. поэтому, мы выделяем проблему коммуникации поверх http, и называем ее xml-rpc, некое соглашение по вызову процедур. а уж эти процедуры могут как угодно интерепертировать передаваемые параметры. создавать заместители и заглушки и т.д. а упаковка распаковка (сериализация) объектов — делом самих объектов (или другого механизма) вот это все надо делать РАЗДЕЛЬНО, тогда это будет всеми восприниматься на ура! а когда мне надо поверх шттп
создать коммуникацию а вынужден использовать для этого /net это называется выкручиваение рук. вот так!
Здравствуйте, AVM, Вы писали:
DG>>4. оптимизировать стоимость хранения бензина (хранить только столько, сколько необходимо)
AVM>3 и 4. IMHO, если я правильно понял это бизнес-задачи, будем решать их на уровне бизнес-логики.
Совсем согласен, кроме 4 пункта.
4 пункта — это не бизнес логига, это вычислительная задача: необходимо перебрать варианты, найти оптимум и т.д.
и на скриптах такая задача не сделается.
Здравствуйте, dad, Вы писали:
dad>>>они опять все нарезали в один батон. местами получилось лучше явы, но что толку?
M>>По моему, это ты все в одну кашу для себя намешал. Путаешь элементарные понятия. Как же тогда ты можешь с легкостью утвержать, что для данной задачи наиболее актуален Java, если ты не знаешь возможности конкурентных средств?
Здравствуйте, mihailik, Вы писали:
M>На самом деле, конечно, это несколько праздный вопрос. Дотнетовский ремотинг как раз сейчас полностью перестраивается (Indigo),
В индиго сам ремоутинг, как это ни странно, сильно не изменится, изменится транспортный уровень и появится нормальный хост, не более того.
Здравствуйте, dad, Вы писали:
AVM>>2. Для управления работой бизнес-логики используем app server, например jboss, не подходит jboss на http://www.theserverside.com/reviews/matrix.jsp можно подобрать другой, соответственно для реализации бизнес-логики используем EJB.
dad>tomcat
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Я к тому, что оценка "геморный код" появляется тогда, когда сам этот код оказывается чем-то неожиданным и крайне нежелательным. Такие ситуации возникают, если имеется сильный перекос в сторону той или иной специфической семантики. Например — в пользу презентационной. Тогда необходимость написать какой-то сугубо системный код вызывает вполне естественное психологическое отторжение.
Я а понимаю под "гемморны кодом" код, которых нужна писать и отлаживать. Видно у нас разные подходы при планировании и анализе проблемы
M>>Из мелочей складываються блоки, из блоков — программы. Вместо готового реализуешь одно, потом другое, и не заметишь, как время, отведенное на разработку ПО, закончилось, а программа запускается через раз. Вот твой принцип?
ГВ>Это очень наивное изложение, к тому же оно полностью отключает мозги, что досадно. У меня как-то и программы работают, и поисками велосипедов не озабочиваюсь. Хотя не спорю, по первому времени прохлопы по времени случались, пока смелости не хватало реализовывать то, что я считаю нужным так, как я это считаю нужным делать.
Мозги не отключаються ибо концентрируешься на реальное задачи, а не на той, которую сам себе выдумал. Чем то мне это напоминает "Дон Кихот". Согласись
M>>А что тебе нужно доказать? .NET он и есть .NET, что автономен. Ему ничего лишнего не надо.
ГВ>mika, ну не скатывайся до банальной демагогии. "Это велико, потому что оно большое, а большое оно потому, что велико".
Геннадий, ты сам начсинаешь уже утвержать нечто третье. Мы вообще о чем разговаривает? Что тебе не доказано и кто тебе это должен доказать?
ГВ>Интересно, напомни. Неужели на уровне коммуникаций?
А у тебя коммуникация на скриптах написана. Тогда не удивительно что ты все на АБС писал. С такими тормозами передачи данных можно на сервак хоть тройку поставить
ГВ>>>В принципиально неверном подходе: "высока у стула ножка — подпилю её немножко". Только вместо стула подпиливается пол, на котором он стоит. M>>Отлично ответил. Только было бы не плохо аргументировать свои ответ.
ГВ>Аргументация очень простая и ты сам её привёл на самом деле. Если слегка перефразировать твою реплику, то получится, что если программы провоцируют перегрузку линий, то не программы оптимизируются, что было бы, ИМХО, логично, а линии апгрейдятся, что, ИМХО, без особой необходимости — неверно. Хотя спору нет — таким образом создаётся рынок для линий связи.
Хм. Чем тебе третий вариант не понравился? Или ты уже не читаешь, а только споришь?
ГВ>>>>>>>Да, но назначение ASP — работа в коммуникационной среде. Каких бы прибамбасов там ни было, "среда" для ASP всё равно — коммуникационная. Ну, плюс ещё презентативная логика в определённом смысле. M>>>>>>Честно говоря, если взглянуть глубже, то ASP это не только коммуникация. Что то мне подсказывает ГВ>>>>>... запросто создаётся перекос в сторону "программирования на форме". Впрочем, это ещё с Delphi и VB пошло... M>>>>И правильно пошло. ГВ>>> Ну, вообще-то, это азы ОО-проектирования: не писать бизнес-код непосредственно в обработчиках событий UI. M>>А что тут то сложного? Бери с сайта microsoft.com их App Block, базирующийся на модель Doc-View-Controller. Или вас от готового нос воротит.
ГВ>Не воротит, не переживай. Только как это относится к моей реплике?
К тому, что ты утверждаешь, что у MS подхода неправильное представление о создании UI приложений. Вот тебе мой ответ, показывающий где ты ошибаешься
ГВ>>>>>Но только всё равно контекст его применения ограничивается пользовательским интерфейсом к Web-приложениям. Интересно, для desktop-варианта тоже нужно интерфейс пользователя средствами ASP.NET городить? M>>>>Я думаю не стоит. Ведь .NET предоставляет богатый инсрументарий. Чем тебе WinForms не понравился? ГВ>>>Хорошо, значит, имеем таки две независимых реализации интерфейса пользователя: для web и для desktop. Всё как всегда. M>> А что, есть какое-то средство разработки, позволяющее на один и тот же код (абстрактный) генерировать win и web приложения? По моему к такому только MS стремиться.
ГВ>Не надо обобщать. Код Win-приложений и Web-приложений — не одно и тоже, тогда как обобщить интерфейсы пользователя в Win и Web — вполне можно.
Во-первых, тут я не пойму в чем проблема и почему это нельзя создать в Нете. Во-вторых, скоро (или уже) выйдет статья Михаила Чащина. Советую почитать.
M>>Дал для примера, что люди, совершенно не знающие предметную область начинают ее наять. Поговорка (запиши в свою коллекцию ) "Врага надо знать в лицо" тут явно не в почете
ГВ>mika, у меня к тебе личный вопрос. А почему сразу "хаять"? Вроде как я .Net не ругаю, а просто выношу некоторые свои соображения для оспаривания.
Просто у меня сложилось впечатления, что любые доводы тебе, как горох об стену. Возможно, я ошибся.
M>>>>Ну приколы связи, это вообшем то проблема прошлого века. Вероятно, тебе она кажется до сих пор весомой только по тому, что ты не используешь стандатрные вещи. Я уже даже не говорю про .NET. А вот насчет логики обработки... Тут все зависит от ее необходимости, и как ты ее собираешься решить. ГВ>>>Кхм. Акстись. Я даже волшебное слово знаю — пожалуйста. Приколы связи как были, так и останутся навечно, пока её принципы каким-нибудь кардинальным образом не изменятся. M>>Если такие компоненты MSMQ. Позволяют пересылать на неустойчивом участке звязи данные со 100 гарантией. Расширяються за счет написания триггеров, связью с СУБД и прочей приблуды. Или тебе и это уже не нравиться, подавай самописное?
ГВ>Стоп-стоп-стоп. MSMQ — это способ решения проблемы доставки, но на такие приколы, как выпадение по таймауту его использование ну никак не повлияет. А особенно, если один объект посылает сообщение (сиречь — вызывает метод) и... упс... оно уходит по MSMQ, а в это время на линии возникает перегрузка... а MSMQ она ж с гарантированной доставкой — она хоть месяц ждать будет, только вот что объекту-то делать? Месяц висеть?
А ты как реализуешь. Хитрый способ доставки? Или канал какой нить вирт отктроешь, который решит всю проблему?
ГВ>Что remoting что-то кардинально меняет.
По сравнению с чем? Может я тебе еще не все рассказал про него?
ГВ>Бизнес-софт всё-таки разный бывает, не находишь? Поисковики — тоже бизнес софт и высокопроизводительные вычисления — тоже, однако.
Вот вот. И почему тут Нет не подходит?
ГВ>Мда.
Не нравиться. Вот и я не люблю велосипеды
M>>>>К чему ты это сказал? ГВ>>>К архитектуре. M>>А она тут к чему?
ГВ>А с неё всё начинается. ИМХО, хорошая архитектура просто и однозначно делит семантику системы по доменам (в терминологии Буча) в одной группе — только отображение, в другой — только прикладнуха, в третьей — только БД и т.д. и т.п. Переверни архитектуру с ног на голову (здесь — бухгалтерия, здесь — склад, здесь — отчёты) и сопровождаемость в первую очередь усложняется в разы. Ну, разумеется, эта проблема не так остро стоит перед простенькими приложениями.
Во-первых, начинаеться все не с проектирования. Во-вторых, при чем здесь Нет. Тут я так представляю нужен UML.
M>>Что касается клиента. Лично я ни разу не видел требования к лиенту кроссплтаформенность. Это уж какие клиенты должны быть Может меня просто пронесло?
ГВ>Простейший пример кросплатформенного интерфейса пользователя: desktop + web.
И?
M>>Во-вторых, это не фикция. Это удобство. Думаю понятно ГВ>Для кого?
В Нет. Я это уже сказал для dad, повторю и для тебя. Все следующие вопросы по тематике .NET в соот форум.
ГВ>Мика, это всё к делу не относится. Достаточно требования отображения на объектную среду. Хотя, пожалуй, то здесь я погорячился — вроде как проблема не настолько уж и велика, раз уж даже C++ появиться должен.
А какую ты проблему видел, если не секрет?
M>>Так что тут стоит вопрос в другом, как ты будешь соединять солянку из Фортран, С++, Dephi? ГВ>А у них, вроде как C-интерфейсы есть. Хотя, если честно, то от Delphi я бы постарался избавиться.
dad>>>>они опять все нарезали в один батон. местами получилось лучше явы, но что толку?
M>>>По моему, это ты все в одну кашу для себя намешал. Путаешь элементарные понятия. Как же тогда ты можешь с легкостью утвержать, что для данной задачи наиболее актуален Java, если ты не знаешь возможности конкурентных средств?
Мика! Я диспутирую на тему "где место .net" и пытаюсь вместе с вами найти ответ на этот вопрос.
собственно "пощщу" я сюда для поддержания диспута ибо мне интеренсна эта "священная война " ..
Что касается "данной задачи":
Коллеги, добрый день!
Передо мной встала сейчас вот какая задача — в ближайшем будущем начнется разработка коробочного продукта, который планируется во 2й версии сделать кроссплатформенным.
1я версия будет под Windows.
Продукт нацеливается на средних и крупных иностранных заказчиков и его клиентская часть должна быть установлена на большом кол-ве компов. Также должна быть возможность зайдя на сайт, скачать и установить клиента (следовательно, он должен быть "легким").
Я бы заменил там на
Коллеги, улыбнитесь!
Передо мной встала сейчас вот какая задача —
в ближайшем будущем начнется разработка коробочного продукта,
требования:
— совт должен быть крутым и в коробке
— во 2й версии кроссплатформенным.
— 1я версия будет под Windows.
— должна быть возможность зайдя на сайт, скачать и установить клиента
и на эту тему вы флеймите уже на 20 страницах??
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, mihailik, Вы писали:
M>>На самом деле, конечно, это несколько праздный вопрос. Дотнетовский ремотинг как раз сейчас полностью перестраивается (Indigo),
AVK>В индиго сам ремоутинг, как это ни странно, сильно не изменится, изменится транспортный уровень и появится нормальный хост, не более того.
Здравствуйте, dad, Вы писали:
dad>соап это действиетельно спецификация разработанная для обмена структурированной информацией между распределенноыми объектами. я к тому, что технологически это не несет ничего нового и огружать это громкой терминологией нет никакиго смысла.
Мда. Уж не знаю как тебе еще обяснить. Мы говорили про кодогенерацию, не soap. SOAP — это одно, RCP — это другое, кодогенерация — это третье. Не нужно это рассматривать это как одно. Оно никогда не будет вместе.
dad>>они опять все нарезали в один батон. местами получилось лучше явы, но что толку?
M>По моему, это ты все в одну кашу для себя намешал. Путаешь элементарные понятия. Как же тогда ты можешь с легкостью утвержать, что для данной задачи наиболее актуален Java, если ты не знаешь возможности конкурентных средств?
да нееет! наоброт!
есть спецификации (скажем так — теретичекое обоснование) есть конкретные реализации и механизмы для тех или иных платформ, с помощью тех или иных средств. microsoft впереди планеты всей — реализавало _САМО_ средство, а если завтра опять появятся новые спецификации? новое средство?
консерватизма не хватает товарищам из ресёча в ms.. простого академического консерватизма
я лично на .net перейду когда он будет везде. и уверен, что не сильно остану.
НО! прошу запротоклировать я _ОЧЕНЬ_ увужаю майкросовт, и отдельных персон которые практически на 50% составляют все боле не менее уважаемые комитеты по разработке спецификаций (буть то soap, xml-rpc, wsdl, и иже сними)
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
ГВ>>>ИМХО, если для приложения требуется unsafe, то ему его всё равно дадут. Вопрос на самом деле в том, насколько легко потребовать unsafe. M>>Это примерно как потребовать прав на NTFS-файл. Кому положено, тому легко потребовать. Кому неположено — не то что нелегко. Просто никак
ГВ>Не, ты меня не понял. Я имел ввиду лёгкость перехода от safe к unsafe (platform invoke). И лёгкость этого перехода именно для разработчика.
Ну не знаю, вроде написано было явно, "для приложения". А для разработчика конечно легко. Но, как я уже говорил, неудобства JNI вряд ли можно считать преимуществом.
M>>>>Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит. ГВ>>>Пусть стреляет. Но тогда реальной переносимости между процессорными архитектурами совсем не получается. M>>Здрасте! IA64 отличается от x86 просто совершенно. Вообще, совсем другой процессор.
ГВ>Ды на здоровье.
Значит всё-таки есть переносимость?
ГВ> А для PowerPC уже есть .Net?
Коммерческого, серверного нет. Есть Mono (Open Source) и Shared Source aka Rotor (некоммерческий пример реализации от Микрософт с исходными кодами). Оба работают под PPC.
Я думаю, .NET вряд ли скоро будет портирован на эту платформу в достаточном для серверов, коммерческом качестве. Это достаточно большой объём работы.
Насколько я понимаю стратегию Микрософта, они стремятся коммерчески поддерживать .NET на своей платформе. Им выгоднее выдавливать Юникс целиком, как операционку, а не зарабатывать на устоявшемся поделенном рынке. Есть MS SQL для Юникса? Нету. Вот и .NET Framework потому же не портируют.
ГВ>>>Или ASP.ONE. Впрочем, это уже совсем другая история. Главное другое: xxxxx Server Pages — по сути обеспечивают коммуникации (ИМХО), а точнее — коммуникацию пользователя с программой в среде Web. M>>Ну нет, я не согласен! Ты с ходу взял смешал слой представления с коммуникациями. ASP/JSP — это однозначно слой представления. Так и Word у тебя будет средством коммуникации.
ГВ>Просто они работают в коммуникационной среде — всяческие Sessions тому подтверждением.
Ну так это же разные вещи! SQL Server тоже работает в комуникационной среде. Но SQL Server — это слой данных, как ни крути.
ГВ>>>Ну, Mika... "Возможности у него самые большие." Самые большие по сравнению с чем?
M>>На дотнете разработка быстрее происходит. По сравнению со "старыми" языками, конечно. Из-за того, что управляемость+метаданные приносят существенные преимущества.
ГВ> А структура разрабатываемых сущностей? Оптимизация без изменения алгоритма вобщем-то всегда имеет свои пределы.
Не совсем понимаю мысль. Ты намекаешь, что в управляемых средах типа Java/.NET возможны дополнительные опитмизации по сравнению со "старым", ассемблерным кодом?
dad>нет я думаю что soap это оо аналог rpc в формате xml. dad>wdsl это метаязык описания севиса, на манер idl.
Очень близко.
dad> веб сервисы это наворот поверх http, которые к тому же требуют веб сервера который это поддрживал бы.
Совсем неверно.
dad>кодогенерация это что? компиляция во время выполнения что ли?
Нет, создание исходников по wsdl. Это в RPC тоже, вроде было.
Я не очень знаком с RPC. Наверное, веб-сервисы позволяют большее.
Были ли в RPC возможности посылки дополнительной информации при вызове методов? Была ли там поддержка аутентификации и каких типов? Была ли поддержка сессий? Что насчёт load-balancing?
DG>>6. Оптимизация (опять много разнородных объектов, частоменяющиеся требования, много вычислений) ГВ>Это — задача компилятора. Любого. Или .Net уже научился переливать объектный код за границы COM-интерфейсов.
Угу. JIT-компилятор даже inline делает, даже из чужой библиотеки функцию может поинлайнить.
M>>>>Я думаю не стоит. Ведь .NET предоставляет богатый инсрументарий. Чем тебе WinForms не понравился? ГВ>>>Хорошо, значит, имеем таки две независимых реализации интерфейса пользователя: для web и для desktop. Всё как всегда. M>> А что, есть какое-то средство разработки, позволяющее на один и тот же код (абстрактный) генерировать win и web приложения? По моему к такому только MS стремиться.
ГВ>Не надо обобщать. Код Win-приложений и Web-приложений — не одно и тоже, тогда как обобщить интерфейсы пользователя в Win и Web — вполне можно.
Погодите, товарищ!
Обобщить любые интерфейсы можно, но всё равно их реализовывать пока приходится раздельно (пока не вышел Windows Longhorn и XAML).
Или есть ещё какие-то наработки по существу вопроса?
ГВ>>>>>А причём тут remoting? Это, кстати, тоже сугубо коммуникационная приблуда. Необходимость в нём "резко уничтожается", если на обоих машинах установлены одни и те же версии софта. M>>>>Опа, а это то тут при чем? ГВ>>>Это я у тебя хотел спросить — с чего ты remoting вспомнил? M>>Дал для примера, что люди, совершенно не знающие предметную область начинают ее наять. Поговорка (запиши в свою коллекцию ) "Врага надо знать в лицо" тут явно не в почете
ГВ>mika, у меня к тебе личный вопрос. А почему сразу "хаять"? Вроде как я .Net не ругаю, а просто выношу некоторые свои соображения для оспаривания. Ну уж извини за несколько пренебрежительный слог, я его считаю сленговым и вполне допустимым в профессиональном общении.
M>>>>Ну приколы связи, это вообшем то проблема прошлого века. Вероятно, тебе она кажется до сих пор весомой только по тому, что ты не используешь стандатрные вещи. Я уже даже не говорю про .NET. А вот насчет логики обработки... Тут все зависит от ее необходимости, и как ты ее собираешься решить. ГВ>>>Кхм. Акстись. Я даже волшебное слово знаю — пожалуйста. Приколы связи как были, так и останутся навечно, пока её принципы каким-нибудь кардинальным образом не изменятся. M>>Если такие компоненты MSMQ. Позволяют пересылать на неустойчивом участке звязи данные со 100 гарантией. Расширяються за счет написания триггеров, связью с СУБД и прочей приблуды. Или тебе и это уже не нравиться, подавай самописное?
ГВ>Стоп-стоп-стоп. MSMQ — это способ решения проблемы доставки, но на такие приколы, как выпадение по таймауту его использование ну никак не повлияет. А особенно, если один объект посылает сообщение (сиречь — вызывает метод) и... упс... оно уходит по MSMQ, а в это время на линии возникает перегрузка... а MSMQ она ж с гарантированной доставкой — она хоть месяц ждать будет, только вот что объекту-то делать? Месяц висеть?
ГВ>>>>>Не знаю, как тебе, а мне что-то подсказывает, что совсем не все серверные объекты ездят на клиента. M>>>>Честно говоря, я вообще такую концепцию не применяю. И Remoting кстати это не позволяет, если не настроить обратную связь. Так что ничего на клиента не ездеет. Они оба (клиент, сервер) общаються через сторонние сущности. ГВ>>>Хорошо, ты только подтвердил мои сомнения. M>>Какие если не секрет?
ГВ>Что remoting что-то кардинально меняет.
M>>>>>>Я просто часто вижу, как люди не разобравшись в инструменте, категорически его отвергают по каким-то своим внутренним убеждениям. ГВ>>>>>Я тоже такое часто вижу. Но я ведь и не отвергаю .Net Зачем? M>>>>Ты его просто игнорируешь ГВ>>>А это с чего ты взял? M>>Неужто боишься?
ГВ>Смешно.
M>>>>>>Давай тогда решим, какие ты типы программ имеешь ввиду, подрузомевая в них "не коммуникативные" ГВ>>>>>Как ни странно, но в первую очередь — бизнес-софт, M>>>>А что значит "бизнес-софт"? Мы обсуждаем, где конкретно место .NET. И я просил привести реальные места, а не абстрактное название. Или ты считаешь, что на .NET нельзя написать бизнес-софт? ГВ>>>Нет, я этого не считаю и не раз прямо об этом говорил. M>>Тогда к чему ты привел словообразование "бизнес-софт"? Что и тут место Нету, это то понятно. Или ты что то тайное, с умыслом скрытым имел ввиду?
ГВ>Бизнес-софт всё-таки разный бывает, не находишь? Поисковики — тоже бизнес софт и высокопроизводительные вычисления — тоже, однако.
ГВ>>>>>>>Только объясни, плз., кого, "её" на клиенте реализоывать? M>>>>>>Indigo ГВ>>>>>Зачем? Если клиент предоставляет пользователю исключительно UI, то ему весь букет Indigo даром не нужен. M>>>>Хм. Не понял. А зачем весь. Только то, что позволяет куда то подключаться. ГВ>>>А зачем тогда Indigo? M>>Логично. Мы ж велики любим. Салют, урал, школьник. Зачем на Indigo?
ГВ>Мда.
M>>>>К чему ты это сказал? ГВ>>>К архитектуре. M>>А она тут к чему?
ГВ>А с неё всё начинается. ИМХО, хорошая архитектура просто и однозначно делит семантику системы по доменам (в терминологии Буча) в одной группе — только отображение, в другой — только прикладнуха, в третьей — только БД и т.д. и т.п. Переверни архитектуру с ног на голову (здесь — бухгалтерия, здесь — склад, здесь — отчёты) и сопровождаемость в первую очередь усложняется в разы. Ну, разумеется, эта проблема не так остро стоит перед простенькими приложениями.
M>>>>Тут скорее всего подойдет Ява. Переносимость у Нет в другой сфере (архитектура процессора и КПК). Хотя, может и Моно поможет, но правда там ф-ть очень мизерная ГВ>>>Хорошо, значит-таки, не всегда правильно писать на .Net? M>>Честно говоря, я считаю, что вин-серверные системы сейчас стали довольно-таки на высоком уровне. Но уж что захотел заказчик Заказчик всегда прав, даже если это расходится с логикой.
ГВ>Хорошо, пусть так. Не будем начинать holy war.
M>>Что касается клиента. Лично я ни разу не видел требования к лиенту кроссплтаформенность. Это уж какие клиенты должны быть Может меня просто пронесло?
ГВ>Простейший пример кросплатформенного интерфейса пользователя: desktop + web.
ГВ>>>>>К тому, что многое на многом можно написать. "вопрос в том, для чего они лучше всего годятся". M>>>>многое. Вот клучевое слово. Если у тебя есть время, для того чтобы создать систему с различными подходами и разными языками, то вообщем-то, и спор дальше не имеет вести смысл. За бесконечность я смогу сделать все что угодно. ГВ>>>Аналогично. Вопрос в выборе адекватного решения. Да и "разные языки" по большому счёту — фикция, если уж они должны быть CLR-compliant.
M>>Во-первых, CLS-compliant. Это как разработчику, знающему внутренности .NET ГВ>Спасибо за замечание — я аббревиатуры часто путаю, а проблемы CLS у меня на языке не крутятся.
M>>Во-вторых, это не фикция. Это удобство. Думаю понятно ГВ>Для кого?
M>>В третьих, если ты имеешь ввиду, что есть какие то ограничения, накладываемые CLS-сompliant, то это раздутый слон из мухи. Использование вместо int Int32 решат практически всю проблему. Это для шарпа. Для других это вообще не надо, ибо они несколько обделены. ГВ>Мика, это всё к делу не относится. Достаточно требования отображения на объектную среду. Хотя, пожалуй, то здесь я погорячился — вроде как проблема не настолько уж и велика, раз уж даже C++ появиться должен.
M>>Так что тут стоит вопрос в другом, как ты будешь соединять солянку из Фортран, С++, Dephi? ГВ>А у них, вроде как C-интерфейсы есть. Хотя, если честно, то от Delphi я бы постарался избавиться.
dad>Короче всместо того что бы делать раздельно простые и понятные вещи, такие как: dad>- кроссплатформенная и двочнонезависимая сериализация dad>- прозрачная и понятная сетевая коммуникация в том числе и поверх http (для веб) dad>- кроссплатформенная управляемая билиоткека dad>- кроссплатформенный язык программирования
dad>они опять все нарезали в один батон.
А что, ты предлагаешь? Сделать эти вещи по отдельности?
Отдельно управляемая библиотека, отдельно язык программирования, отдельно сериализация?
1. Как будет работать кроссплатформенный управляемый язык программирования без библиотеки?
2. На чём писать кросплатформенную библиотеку без языка?
3. Кто будет делать сериализацию, если не библиотека?
4. Кто будет делать коммуникацию без библиотеки?
Всё взаимосвязано, и по отдельности рассыпается.
dad> местами получилось лучше явы, но что толку?
А ты хотел гениального прозрения и царства добра на всей планете? .NET Framework — это всего лишь удобный инструмент.
dad>виндовс тоже местами лучше других ос, но рабтают то на нем персоналки.
В чём проблема если пероналки раотают на хорошей ос?
dad>>соап это действиетельно спецификация разработанная для обмена структурированной информацией между распределенноыми объектами. я к тому, что технологически это не несет ничего нового и огружать это громкой терминологией нет никакиго смысла.
M>Мда. Уж не знаю как тебе еще обяснить. Мы говорили про кодогенерацию, не soap. SOAP — это одно, RCP — это другое, кодогенерация — это третье. Не нужно это рассматривать это как одно. Оно никогда не будет вместе.
поясню:
под rpc я понимал механзм удаленного взаимодействия, пропустив DCOM/corba я сразу заговорил о web (поверх http) реализации теперь думаю понятна моя логика ?
про кодогенерацию не понял. что в данном случае ты имеешь ввиду? по xml описанию сервиса генерится код для него или что?
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
ГВ>>>ИМХО, если для приложения требуется unsafe, то ему его всё равно дадут. Вопрос на самом деле в том, насколько легко потребовать unsafe. M>>Это примерно как потребовать прав на NTFS-файл. Кому положено, тому легко потребовать. Кому неположено — не то что нелегко. Просто никак
ГВ>Не, ты меня не понял. Я имел ввиду лёгкость перехода от safe к unsafe (platform invoke). И лёгкость этого перехода именно для разработчика.
Ну не знаю, вроде написано было явно, "для приложения". А для разработчика конечно легко. Но, как я уже говорил, неудобства JNI вряд ли можно считать преимуществом.
M>>>>Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит. ГВ>>>Пусть стреляет. Но тогда реальной переносимости между процессорными архитектурами совсем не получается. M>>Здрасте! IA64 отличается от x86 просто совершенно. Вообще, совсем другой процессор.
ГВ>Ды на здоровье.
Значит всё-таки есть переносимость?
ГВ> А для PowerPC уже есть .Net?
Коммерческого, серверного нет. Есть Mono (Open Source) и Shared Source aka Rotor (некоммерческий пример реализации от Микрософт с исходными кодами). Оба работают под PPC.
Я думаю, .NET вряд ли скоро будет портирован на эту платформу в достаточном для серверов, коммерческом качестве. Это достаточно большой объём работы.
Насколько я понимаю стратегию Микрософта, они стремятся коммерчески поддерживать .NET на своей платформе. Им выгоднее выдавливать Юникс целиком, как операционку, а не зарабатывать на устоявшемся поделенном рынке. Есть MS SQL для Юникса? Нету. Вот и .NET Framework потому же не портируют.
ГВ>>>Или ASP.ONE. Впрочем, это уже совсем другая история. Главное другое: xxxxx Server Pages — по сути обеспечивают коммуникации (ИМХО), а точнее — коммуникацию пользователя с программой в среде Web. M>>Ну нет, я не согласен! Ты с ходу взял смешал слой представления с коммуникациями. ASP/JSP — это однозначно слой представления. Так и Word у тебя будет средством коммуникации.
ГВ>Просто они работают в коммуникационной среде — всяческие Sessions тому подтверждением.
Ну так это же разные вещи! SQL Server тоже работает в комуникационной среде. Но SQL Server — это слой данных, как ни крути.
ГВ>>>Ну, Mika... "Возможности у него самые большие." Самые большие по сравнению с чем?
M>>На дотнете разработка быстрее происходит. По сравнению со "старыми" языками, конечно. Из-за того, что управляемость+метаданные приносят существенные преимущества.
ГВ> А структура разрабатываемых сущностей? Оптимизация без изменения алгоритма вобщем-то всегда имеет свои пределы.
Не совсем понимаю мысль. Ты намекаешь, что в управляемых средах типа Java/.NET возможны дополнительные опитмизации по сравнению со "старым", ассемблерным кодом?
dad>нет я думаю что soap это оо аналог rpc в формате xml. dad>wdsl это метаязык описания севиса, на манер idl.
Очень близко.
dad> веб сервисы это наворот поверх http, которые к тому же требуют веб сервера который это поддрживал бы.
Совсем неверно.
dad>кодогенерация это что? компиляция во время выполнения что ли?
Нет, создание исходников по wsdl. Это в RPC тоже, вроде было.
Я не очень знаком с RPC. Наверное, веб-сервисы позволяют большее.
Были ли в RPC возможности посылки дополнительной информации при вызове методов? Была ли там поддержка аутентификации и каких типов? Была ли поддержка сессий? Что насчёт load-balancing?
DG>>6. Оптимизация (опять много разнородных объектов, частоменяющиеся требования, много вычислений) ГВ>Это — задача компилятора. Любого. Или .Net уже научился переливать объектный код за границы COM-интерфейсов.
Угу. JIT-компилятор даже inline делает, даже из чужой библиотеки функцию может поинлайнить.
M>>>>Я думаю не стоит. Ведь .NET предоставляет богатый инсрументарий. Чем тебе WinForms не понравился? ГВ>>>Хорошо, значит, имеем таки две независимых реализации интерфейса пользователя: для web и для desktop. Всё как всегда. M>> А что, есть какое-то средство разработки, позволяющее на один и тот же код (абстрактный) генерировать win и web приложения? По моему к такому только MS стремиться.
ГВ>Не надо обобщать. Код Win-приложений и Web-приложений — не одно и тоже, тогда как обобщить интерфейсы пользователя в Win и Web — вполне можно.
Погодите, товарищ!
Обобщить любые интерфейсы можно, но всё равно их реализовывать пока приходится раздельно (пока не вышел Windows Longhorn и XAML).
Или есть ещё какие-то наработки по существу вопроса?
ГВ>>>>>А причём тут remoting? Это, кстати, тоже сугубо коммуникационная приблуда. Необходимость в нём "резко уничтожается", если на обоих машинах установлены одни и те же версии софта. M>>>>Опа, а это то тут при чем? ГВ>>>Это я у тебя хотел спросить — с чего ты remoting вспомнил? M>>Дал для примера, что люди, совершенно не знающие предметную область начинают ее наять. Поговорка (запиши в свою коллекцию ) "Врага надо знать в лицо" тут явно не в почете
ГВ>mika, у меня к тебе личный вопрос. А почему сразу "хаять"? Вроде как я .Net не ругаю, а просто выношу некоторые свои соображения для оспаривания. Ну уж извини за несколько пренебрежительный слог, я его считаю сленговым и вполне допустимым в профессиональном общении.
M>>>>Ну приколы связи, это вообшем то проблема прошлого века. Вероятно, тебе она кажется до сих пор весомой только по тому, что ты не используешь стандатрные вещи. Я уже даже не говорю про .NET. А вот насчет логики обработки... Тут все зависит от ее необходимости, и как ты ее собираешься решить. ГВ>>>Кхм. Акстись. Я даже волшебное слово знаю — пожалуйста. Приколы связи как были, так и останутся навечно, пока её принципы каким-нибудь кардинальным образом не изменятся. M>>Если такие компоненты MSMQ. Позволяют пересылать на неустойчивом участке звязи данные со 100 гарантией. Расширяються за счет написания триггеров, связью с СУБД и прочей приблуды. Или тебе и это уже не нравиться, подавай самописное?
ГВ>Стоп-стоп-стоп. MSMQ — это способ решения проблемы доставки, но на такие приколы, как выпадение по таймауту его использование ну никак не повлияет. А особенно, если один объект посылает сообщение (сиречь — вызывает метод) и... упс... оно уходит по MSMQ, а в это время на линии возникает перегрузка... а MSMQ она ж с гарантированной доставкой — она хоть месяц ждать будет, только вот что объекту-то делать? Месяц висеть?
ГВ>>>>>Не знаю, как тебе, а мне что-то подсказывает, что совсем не все серверные объекты ездят на клиента. M>>>>Честно говоря, я вообще такую концепцию не применяю. И Remoting кстати это не позволяет, если не настроить обратную связь. Так что ничего на клиента не ездеет. Они оба (клиент, сервер) общаються через сторонние сущности. ГВ>>>Хорошо, ты только подтвердил мои сомнения. M>>Какие если не секрет?
ГВ>Что remoting что-то кардинально меняет.
M>>>>>>Я просто часто вижу, как люди не разобравшись в инструменте, категорически его отвергают по каким-то своим внутренним убеждениям. ГВ>>>>>Я тоже такое часто вижу. Но я ведь и не отвергаю .Net Зачем? M>>>>Ты его просто игнорируешь ГВ>>>А это с чего ты взял? M>>Неужто боишься?
ГВ>Смешно.
M>>>>>>Давай тогда решим, какие ты типы программ имеешь ввиду, подрузомевая в них "не коммуникативные" ГВ>>>>>Как ни странно, но в первую очередь — бизнес-софт, M>>>>А что значит "бизнес-софт"? Мы обсуждаем, где конкретно место .NET. И я просил привести реальные места, а не абстрактное название. Или ты считаешь, что на .NET нельзя написать бизнес-софт? ГВ>>>Нет, я этого не считаю и не раз прямо об этом говорил. M>>Тогда к чему ты привел словообразование "бизнес-софт"? Что и тут место Нету, это то понятно. Или ты что то тайное, с умыслом скрытым имел ввиду?
ГВ>Бизнес-софт всё-таки разный бывает, не находишь? Поисковики — тоже бизнес софт и высокопроизводительные вычисления — тоже, однако.
ГВ>>>>>>>Только объясни, плз., кого, "её" на клиенте реализоывать? M>>>>>>Indigo ГВ>>>>>Зачем? Если клиент предоставляет пользователю исключительно UI, то ему весь букет Indigo даром не нужен. M>>>>Хм. Не понял. А зачем весь. Только то, что позволяет куда то подключаться. ГВ>>>А зачем тогда Indigo? M>>Логично. Мы ж велики любим. Салют, урал, школьник. Зачем на Indigo?
ГВ>Мда.
M>>>>К чему ты это сказал? ГВ>>>К архитектуре. M>>А она тут к чему?
ГВ>А с неё всё начинается. ИМХО, хорошая архитектура просто и однозначно делит семантику системы по доменам (в терминологии Буча) в одной группе — только отображение, в другой — только прикладнуха, в третьей — только БД и т.д. и т.п. Переверни архитектуру с ног на голову (здесь — бухгалтерия, здесь — склад, здесь — отчёты) и сопровождаемость в первую очередь усложняется в разы. Ну, разумеется, эта проблема не так остро стоит перед простенькими приложениями.
M>>>>Тут скорее всего подойдет Ява. Переносимость у Нет в другой сфере (архитектура процессора и КПК). Хотя, может и Моно поможет, но правда там ф-ть очень мизерная ГВ>>>Хорошо, значит-таки, не всегда правильно писать на .Net? M>>Честно говоря, я считаю, что вин-серверные системы сейчас стали довольно-таки на высоком уровне. Но уж что захотел заказчик Заказчик всегда прав, даже если это расходится с логикой.
ГВ>Хорошо, пусть так. Не будем начинать holy war.
M>>Что касается клиента. Лично я ни разу не видел требования к лиенту кроссплтаформенность. Это уж какие клиенты должны быть Может меня просто пронесло?
ГВ>Простейший пример кросплатформенного интерфейса пользователя: desktop + web.
ГВ>>>>>К тому, что многое на многом можно написать. "вопрос в том, для чего они лучше всего годятся". M>>>>многое. Вот клучевое слово. Если у тебя есть время, для того чтобы создать систему с различными подходами и разными языками, то вообщем-то, и спор дальше не имеет вести смысл. За бесконечность я смогу сделать все что угодно. ГВ>>>Аналогично. Вопрос в выборе адекватного решения. Да и "разные языки" по большому счёту — фикция, если уж они должны быть CLR-compliant.
M>>Во-первых, CLS-compliant. Это как разработчику, знающему внутренности .NET ГВ>Спасибо за замечание — я аббревиатуры часто путаю, а проблемы CLS у меня на языке не крутятся.
M>>Во-вторых, это не фикция. Это удобство. Думаю понятно ГВ>Для кого?
M>>В третьих, если ты имеешь ввиду, что есть какие то ограничения, накладываемые CLS-сompliant, то это раздутый слон из мухи. Использование вместо int Int32 решат практически всю проблему. Это для шарпа. Для других это вообще не надо, ибо они несколько обделены. ГВ>Мика, это всё к делу не относится. Достаточно требования отображения на объектную среду. Хотя, пожалуй, то здесь я погорячился — вроде как проблема не настолько уж и велика, раз уж даже C++ появиться должен.
M>>Так что тут стоит вопрос в другом, как ты будешь соединять солянку из Фортран, С++, Dephi? ГВ>А у них, вроде как C-интерфейсы есть. Хотя, если честно, то от Delphi я бы постарался избавиться.
dad>Короче всместо того что бы делать раздельно простые и понятные вещи, такие как: dad>- кроссплатформенная и двочнонезависимая сериализация dad>- прозрачная и понятная сетевая коммуникация в том числе и поверх http (для веб) dad>- кроссплатформенная управляемая билиоткека dad>- кроссплатформенный язык программирования
dad>они опять все нарезали в один батон.
А что, ты предлагаешь? Сделать эти вещи по отдельности?
Отдельно управляемая библиотека, отдельно язык программирования, отдельно сериализация?
1. Как будет работать кроссплатформенный управляемый язык программирования без библиотеки?
2. На чём писать кросплатформенную библиотеку без языка?
3. Кто будет делать сериализацию, если не библиотека?
4. Кто будет делать коммуникацию без библиотеки?
Всё взаимосвязано, и по отдельности рассыпается.
dad> местами получилось лучше явы, но что толку?
А ты хотел гениального прозрения и царства добра на всей планете? .NET Framework — это всего лишь удобный инструмент.
dad>виндовс тоже местами лучше других ос, но рабтают то на нем персоналки.
В чём проблема если пероналки раотают на хорошей ос?
dad>>кстати есть xml-rpc, и куча интерфесов ко всем языкам от явы до перло.. dad>>чем не .net
M>Какой нафиг .NET? Ты бы ещё сказал "чем не Windows?"
M>.NET к веб-сервисам имеет косвенное отношение.
нормально так .. давай сначала начнем?
а к сему же .net имеет ПРЯМОЕ отношение?
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
ГВ>>>ИМХО, если для приложения требуется unsafe, то ему его всё равно дадут. Вопрос на самом деле в том, насколько легко потребовать unsafe. M>>Это примерно как потребовать прав на NTFS-файл. Кому положено, тому легко потребовать. Кому неположено — не то что нелегко. Просто никак
ГВ>Не, ты меня не понял. Я имел ввиду лёгкость перехода от safe к unsafe (platform invoke). И лёгкость этого перехода именно для разработчика.
Ну не знаю, вроде написано было явно, "для приложения". А для разработчика конечно легко. Но, как я уже говорил, неудобства JNI вряд ли можно считать преимуществом.
M>>>>Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит. ГВ>>>Пусть стреляет. Но тогда реальной переносимости между процессорными архитектурами совсем не получается. M>>Здрасте! IA64 отличается от x86 просто совершенно. Вообще, совсем другой процессор.
ГВ>Ды на здоровье.
Значит всё-таки есть переносимость?
ГВ> А для PowerPC уже есть .Net?
Коммерческого, серверного нет. Есть Mono (Open Source) и Shared Source aka Rotor (некоммерческий пример реализации от Микрософт с исходными кодами). Оба работают под PPC.
Я думаю, .NET вряд ли скоро будет портирован на эту платформу в достаточном для серверов, коммерческом качестве. Это достаточно большой объём работы.
Насколько я понимаю стратегию Микрософта, они стремятся коммерчески поддерживать .NET на своей платформе. Им выгоднее выдавливать Юникс целиком, как операционку, а не зарабатывать на устоявшемся поделенном рынке. Есть MS SQL для Юникса? Нету. Вот и .NET Framework потому же не портируют.
ГВ>>>Или ASP.ONE. Впрочем, это уже совсем другая история. Главное другое: xxxxx Server Pages — по сути обеспечивают коммуникации (ИМХО), а точнее — коммуникацию пользователя с программой в среде Web. M>>Ну нет, я не согласен! Ты с ходу взял смешал слой представления с коммуникациями. ASP/JSP — это однозначно слой представления. Так и Word у тебя будет средством коммуникации.
ГВ>Просто они работают в коммуникационной среде — всяческие Sessions тому подтверждением.
Ну так это же разные вещи! SQL Server тоже работает в комуникационной среде. Но SQL Server — это слой данных, как ни крути.
ГВ>>>Ну, Mika... "Возможности у него самые большие." Самые большие по сравнению с чем?
M>>На дотнете разработка быстрее происходит. По сравнению со "старыми" языками, конечно. Из-за того, что управляемость+метаданные приносят существенные преимущества.
ГВ> А структура разрабатываемых сущностей? Оптимизация без изменения алгоритма вобщем-то всегда имеет свои пределы.
Не совсем понимаю мысль. Ты намекаешь, что в управляемых средах типа Java/.NET возможны дополнительные опитмизации по сравнению со "старым", ассемблерным кодом?
dad>нет я думаю что soap это оо аналог rpc в формате xml. dad>wdsl это метаязык описания севиса, на манер idl.
Очень близко.
dad> веб сервисы это наворот поверх http, которые к тому же требуют веб сервера который это поддрживал бы.
Совсем неверно.
dad>кодогенерация это что? компиляция во время выполнения что ли?
Нет, создание исходников по wsdl. Это в RPC тоже, вроде было.
Я не очень знаком с RPC. Наверное, веб-сервисы позволяют большее.
Были ли в RPC возможности посылки дополнительной информации при вызове методов? Была ли там поддержка аутентификации и каких типов? Была ли поддержка сессий? Что насчёт load-balancing?
DG>>6. Оптимизация (опять много разнородных объектов, частоменяющиеся требования, много вычислений) ГВ>Это — задача компилятора. Любого. Или .Net уже научился переливать объектный код за границы COM-интерфейсов.
Угу. JIT-компилятор даже inline делает, даже из чужой библиотеки функцию может поинлайнить.
M>>>>Я думаю не стоит. Ведь .NET предоставляет богатый инсрументарий. Чем тебе WinForms не понравился? ГВ>>>Хорошо, значит, имеем таки две независимых реализации интерфейса пользователя: для web и для desktop. Всё как всегда. M>> А что, есть какое-то средство разработки, позволяющее на один и тот же код (абстрактный) генерировать win и web приложения? По моему к такому только MS стремиться.
ГВ>Не надо обобщать. Код Win-приложений и Web-приложений — не одно и тоже, тогда как обобщить интерфейсы пользователя в Win и Web — вполне можно.
Погодите, товарищ!
Обобщить любые интерфейсы можно, но всё равно их реализовывать пока приходится раздельно (пока не вышел Windows Longhorn и XAML).
Или есть ещё какие-то наработки по существу вопроса?
ГВ>>>>>А причём тут remoting? Это, кстати, тоже сугубо коммуникационная приблуда. Необходимость в нём "резко уничтожается", если на обоих машинах установлены одни и те же версии софта. M>>>>Опа, а это то тут при чем? ГВ>>>Это я у тебя хотел спросить — с чего ты remoting вспомнил? M>>Дал для примера, что люди, совершенно не знающие предметную область начинают ее наять. Поговорка (запиши в свою коллекцию ) "Врага надо знать в лицо" тут явно не в почете
ГВ>mika, у меня к тебе личный вопрос. А почему сразу "хаять"? Вроде как я .Net не ругаю, а просто выношу некоторые свои соображения для оспаривания. Ну уж извини за несколько пренебрежительный слог, я его считаю сленговым и вполне допустимым в профессиональном общении.
M>>>>Ну приколы связи, это вообшем то проблема прошлого века. Вероятно, тебе она кажется до сих пор весомой только по тому, что ты не используешь стандатрные вещи. Я уже даже не говорю про .NET. А вот насчет логики обработки... Тут все зависит от ее необходимости, и как ты ее собираешься решить. ГВ>>>Кхм. Акстись. Я даже волшебное слово знаю — пожалуйста. Приколы связи как были, так и останутся навечно, пока её принципы каким-нибудь кардинальным образом не изменятся. M>>Если такие компоненты MSMQ. Позволяют пересылать на неустойчивом участке звязи данные со 100 гарантией. Расширяються за счет написания триггеров, связью с СУБД и прочей приблуды. Или тебе и это уже не нравиться, подавай самописное?
ГВ>Стоп-стоп-стоп. MSMQ — это способ решения проблемы доставки, но на такие приколы, как выпадение по таймауту его использование ну никак не повлияет. А особенно, если один объект посылает сообщение (сиречь — вызывает метод) и... упс... оно уходит по MSMQ, а в это время на линии возникает перегрузка... а MSMQ она ж с гарантированной доставкой — она хоть месяц ждать будет, только вот что объекту-то делать? Месяц висеть?
ГВ>>>>>Не знаю, как тебе, а мне что-то подсказывает, что совсем не все серверные объекты ездят на клиента. M>>>>Честно говоря, я вообще такую концепцию не применяю. И Remoting кстати это не позволяет, если не настроить обратную связь. Так что ничего на клиента не ездеет. Они оба (клиент, сервер) общаються через сторонние сущности. ГВ>>>Хорошо, ты только подтвердил мои сомнения. M>>Какие если не секрет?
ГВ>Что remoting что-то кардинально меняет.
M>>>>>>Я просто часто вижу, как люди не разобравшись в инструменте, категорически его отвергают по каким-то своим внутренним убеждениям. ГВ>>>>>Я тоже такое часто вижу. Но я ведь и не отвергаю .Net Зачем? M>>>>Ты его просто игнорируешь ГВ>>>А это с чего ты взял? M>>Неужто боишься?
ГВ>Смешно.
M>>>>>>Давай тогда решим, какие ты типы программ имеешь ввиду, подрузомевая в них "не коммуникативные" ГВ>>>>>Как ни странно, но в первую очередь — бизнес-софт, M>>>>А что значит "бизнес-софт"? Мы обсуждаем, где конкретно место .NET. И я просил привести реальные места, а не абстрактное название. Или ты считаешь, что на .NET нельзя написать бизнес-софт? ГВ>>>Нет, я этого не считаю и не раз прямо об этом говорил. M>>Тогда к чему ты привел словообразование "бизнес-софт"? Что и тут место Нету, это то понятно. Или ты что то тайное, с умыслом скрытым имел ввиду?
ГВ>Бизнес-софт всё-таки разный бывает, не находишь? Поисковики — тоже бизнес софт и высокопроизводительные вычисления — тоже, однако.
ГВ>>>>>>>Только объясни, плз., кого, "её" на клиенте реализоывать? M>>>>>>Indigo ГВ>>>>>Зачем? Если клиент предоставляет пользователю исключительно UI, то ему весь букет Indigo даром не нужен. M>>>>Хм. Не понял. А зачем весь. Только то, что позволяет куда то подключаться. ГВ>>>А зачем тогда Indigo? M>>Логично. Мы ж велики любим. Салют, урал, школьник. Зачем на Indigo?
ГВ>Мда.
M>>>>К чему ты это сказал? ГВ>>>К архитектуре. M>>А она тут к чему?
ГВ>А с неё всё начинается. ИМХО, хорошая архитектура просто и однозначно делит семантику системы по доменам (в терминологии Буча) в одной группе — только отображение, в другой — только прикладнуха, в третьей — только БД и т.д. и т.п. Переверни архитектуру с ног на голову (здесь — бухгалтерия, здесь — склад, здесь — отчёты) и сопровождаемость в первую очередь усложняется в разы. Ну, разумеется, эта проблема не так остро стоит перед простенькими приложениями.
M>>>>Тут скорее всего подойдет Ява. Переносимость у Нет в другой сфере (архитектура процессора и КПК). Хотя, может и Моно поможет, но правда там ф-ть очень мизерная ГВ>>>Хорошо, значит-таки, не всегда правильно писать на .Net? M>>Честно говоря, я считаю, что вин-серверные системы сейчас стали довольно-таки на высоком уровне. Но уж что захотел заказчик Заказчик всегда прав, даже если это расходится с логикой.
ГВ>Хорошо, пусть так. Не будем начинать holy war.
M>>Что касается клиента. Лично я ни разу не видел требования к лиенту кроссплтаформенность. Это уж какие клиенты должны быть Может меня просто пронесло?
ГВ>Простейший пример кросплатформенного интерфейса пользователя: desktop + web.
ГВ>>>>>К тому, что многое на многом можно написать. "вопрос в том, для чего они лучше всего годятся". M>>>>многое. Вот клучевое слово. Если у тебя есть время, для того чтобы создать систему с различными подходами и разными языками, то вообщем-то, и спор дальше не имеет вести смысл. За бесконечность я смогу сделать все что угодно. ГВ>>>Аналогично. Вопрос в выборе адекватного решения. Да и "разные языки" по большому счёту — фикция, если уж они должны быть CLR-compliant.
M>>Во-первых, CLS-compliant. Это как разработчику, знающему внутренности .NET ГВ>Спасибо за замечание — я аббревиатуры часто путаю, а проблемы CLS у меня на языке не крутятся.
M>>Во-вторых, это не фикция. Это удобство. Думаю понятно ГВ>Для кого?
M>>В третьих, если ты имеешь ввиду, что есть какие то ограничения, накладываемые CLS-сompliant, то это раздутый слон из мухи. Использование вместо int Int32 решат практически всю проблему. Это для шарпа. Для других это вообще не надо, ибо они несколько обделены. ГВ>Мика, это всё к делу не относится. Достаточно требования отображения на объектную среду. Хотя, пожалуй, то здесь я погорячился — вроде как проблема не настолько уж и велика, раз уж даже C++ появиться должен.
M>>Так что тут стоит вопрос в другом, как ты будешь соединять солянку из Фортран, С++, Dephi? ГВ>А у них, вроде как C-интерфейсы есть. Хотя, если честно, то от Delphi я бы постарался избавиться.
dad>Короче всместо того что бы делать раздельно простые и понятные вещи, такие как: dad>- кроссплатформенная и двочнонезависимая сериализация dad>- прозрачная и понятная сетевая коммуникация в том числе и поверх http (для веб) dad>- кроссплатформенная управляемая билиоткека dad>- кроссплатформенный язык программирования
dad>они опять все нарезали в один батон.
А что, ты предлагаешь? Сделать эти вещи по отдельности?
Отдельно управляемая библиотека, отдельно язык программирования, отдельно сериализация?
1. Как будет работать кроссплатформенный управляемый язык программирования без библиотеки?
2. На чём писать кросплатформенную библиотеку без языка?
3. Кто будет делать сериализацию, если не библиотека?
4. Кто будет делать коммуникацию без библиотеки?
Всё взаимосвязано, и по отдельности рассыпается.
dad> местами получилось лучше явы, но что толку?
А ты хотел гениального прозрения и царства добра на всей планете? .NET Framework — это всего лишь удобный инструмент.
dad>виндовс тоже местами лучше других ос, но рабтают то на нем персоналки.
В чём проблема если пероналки раотают на хорошей ос?
Здравствуйте, dad, Вы писали:
dad>>>кстати есть xml-rpc, и куча интерфесов ко всем языкам от явы до перло.. dad>>>чем не .net
M>>Какой нафиг .NET? Ты бы ещё сказал "чем не Windows?"
M>>.NET к веб-сервисам имеет косвенное отношение.
dad>нормально так .. давай сначала начнем?
dad>а к сему же .net имеет ПРЯМОЕ отношение?
Ко всему. В Нете реализация, идея не обязательно ему принадлечит. Понятие Веб сервис появилось раньше понятия ASP.NET Web Service.
dad>> веб сервисы это наворот поверх http, которые к тому же требуют веб сервера который это поддрживал бы.
M>Совсем неверно.
как же так? разве веб сервис не должен работать независимо от клиента? разве не для этого предназначен wsdl ?
или ты предлагаешь в каждыйвеб сервис встраивать вебсервер?
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>если Януса больше суток не перезапускать, то blue screen появляется, если перезапускать периодически — всё в порядке.
Blue screen в w2k, в отличие от w9x, означает проблемы ядра или драйвера, а не приложения.
M>1. Как будет работать кроссплатформенный управляемый язык программирования без библиотеки? M>2. На чём писать кросплатформенную библиотеку без языка?
как ява (может когда сделают .net на все платформы будет и .net)
dad>>виндовс тоже местами лучше других ос, но рабтают то на нем персоналки. M>В чём проблема если пероналки раотают на хорошей ос?
мы же говорим о сетевых коммуникациях
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, mihailik, Вы писали:
M>>Где утечка памяти? На Нете? Утечка или перерасходывание памяти? Это два разных понятия — ты не путай. M>Утечки памяти на дотнете вполне реальны. Если программу писать с извратом, могут быть утечки
И без изврата тоже. Подписался на SystemEvents.UserPreferenceChanged (или у любого другого статика), забыл отписаться (или у тебя не вызвали Dispose) — и объект завис в памяти навечно. У сборки мусора по сравнению с явным delete свои проблемы.
S>3. Статическая кодогенерация по метаданным. Например MIDL. S>3.5. Динамическая кодогенерация по метаданным. Ее и обсуждаем. Позволяет получить эффективность сравнимую с 2, а то и 1 (если дать возможность управлять кодогенерацией), при усилиях сравнимых с 2.
кстати, причем тут .net? можно годогенирировать и для явы и для c++ и т.д. например — коммуникационная либа, и кодогенератор к ней. все "пуляет" никаких .net не требует.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
M>А что тебе нужно доказать? .NET он и есть .NET, что автономен. Ему ничего лишнего не надо.
а он , мне кажется, пытается тебе доказать что .net сам по себе лишний ..
открываю msdn .net programming выбрасываю
"все лишнее", чтое сть в яве
остается:
— разные языки
— смешивание управляемогои не управляемогок кода (что скорее всего для разнык платформ будет ен реализуемо)
— remoting который на поверку оказывается смесью:
транспорта (tcp/http/rpc + soap)
— кодогенерация и прочие навороты (которые можно отенсти скорее к тулзам)
и все это удовльствие обязывает:
клиента иметь установленую .net framework
любые решения , реализующие раширенную функциональность вроде быстрого gui и т.д
писать на смешанном коде, что сразу убирает это преимущество перед явой, ибо там тоже клиенты пишутся, как правило, на других языках (и пропадает многоязыковое преимущество)
остается "прозрачный" ремоутинг
и "кодогенерация" .. и .net сразу превращается в обузу..
почему не сделать нормальрные бибилотеки отдельно транспорт, отдельно кодогенератор,
отдельно бриджи на языки и web протколы ?
Здравствуйте, dad, Вы писали:
dad>кстати, причем тут .net? можно годогенирировать и для явы и для c++ и т.д. например — коммуникационная либа, и кодогенератор к ней. все "пуляет" никаких .net не требует.
На нете это можно делать в рантайме, как используя компиляторы (которые штатно входят в состав редиста) так и напрямую в IL.
Ну вобще то в джаве есть RMI, хотя он конечно попримитивнее.
dad> который на поверку оказывается смесью: dad> транспорта (tcp/http/rpc + soap)
Нет, ремотинг это намного больше. К примеру для междоменного взаимодействия используется ремоутинг, а там, как ты понимаешь, никаких tcp/http/rpc. СОМ-интероп так же работает через ремоутинг.
dad>- кодогенерация и прочие навороты (которые можно отенсти скорее к тулзам)
Эмит это уже ядро CLR, ничего похожего в джаве нет, хотя при желании конечно через класс-лоадер можно извратиться.
dad>и все это удовльствие обязывает:
dad>клиента иметь установленую .net framework
А минусы ты чего джавовские не выкидываешь? JRE надо тоже устанавливать. Выкидываем.
dad>любые решения , реализующие раширенную функциональность вроде быстрого gui и т.д dad>писать на смешанном коде, что сразу убирает это преимущество перед явой, ибо там тоже клиенты пишутся, как правило, на других языках (и пропадает многоязыковое преимущество)
DX9 и джава оказывается далеко. Кроме того у джавы ее графика вполне сопоставима по скорости с GDI+. Выкидываем.
dad>остается "прозрачный" ремоутинг dad>и "кодогенерация" .. и .net сразу превращается в обузу..
Пока ничего не осталось. На самом деле у джавы есть парочка серьезных преимуществ, но ты их даже не назвал
dad>короче , реально .net начнет рулить когда он будет повсюду. "написано один раз — работает везде" dad>знакомый слоган?
Здравствуйте, DarkGray, Вы писали:
DG>>>например, распределить машины по бензоправкам, или минимизировать расходы на проезд и т.д.
ГВ>>Хм... А чем здесь .Net лучше чем, к примеру, C++? Действительно, интересно.
DG>Тем, что я могу прозрачно и дешево зацепить Fortran.Net, Prolog.Net или какой-нибудь FuzzyLogic.Net для решения данной задачи. DG>И мне не надо будет решать тонну проблем связанную со стыковкой разных языков, разных dll-ек и т.д.
Да фиг с ним, с фортраном. А каков выбор среди, например, Prolog.Net? С обычным C-интерфейсом их вобщем-то есть... Есть ли компилирующий Prolog?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>Реальная задачка: DG>Есть бензино-разливочная компания, они хотят автоматизироватся: DG>В рамках данной задачи надо сделать следующее:
DG>1. Простыковатся с банковской системой DG> а) для проверки пришли ли платежи
Надо выяснить, что представляет их интерфейс. Спецификации, явки, пароли и т.п.
DG> b) для оплаты поставок от "нефтяной компании".
Аналогично.
DG>2. Простыковатся с "нефтяной компании" для осуществленняя автоматического заказа новых партий бензина
Способ связи? Вот навскидку:
— отправить e-mail;
— SOAP;
— связаться непосредственно с системой с шифрованием трафика;
— сделать свой XLS-ник и отправить компании... тоже по e-mail.
DG>3. упростить написание правил расчета цен за товар (есть много разных скидок, различных партнерских договоров и т.д.)
Раскрой, плз., поподроднее. Что подразумевается по упрощением?
DG>4. оптимизировать стоимость хранения бензина (хранить только столько, сколько необходимо)
Это — расчёты. Не смертельно сложные, алгоритмика вполне доступна непуганому технологиями студенту 3-4 курса. Язык — скорее всего C++ из-за развитых шаблонов. Собственно, с моей стороны это только предположения — какими выполняется оценка?
DG>5. разработать удобный пользовательский интерфейс для всего этого
Разумеется, а как же без него? Для каких клиентов? Сколько пользователей у системы?
DG>6. сформировать толпу отчетов
Три вагона генераторов, плюc свои собственные средства. Да и, собственно, какие отчёты.
DG>Вопрос: на чем все это будет написано?
Ответь на дополнительные вопросы.
Предварительно можно сказать, что больше всего времени и сил уйдёт на постановку задачи и анализ пп. 3-5. пп. 1 и 2 — жду ответов, п. 6 — принципиально неоканчиваемая штука, можно остановиться на согласовании набора "первого этапа".
А в какие сроки ты оцениваешь сию разработку? Я допускаю, что это может быть закрытой информацией, так что если не хочешь — не отвечай. Можешь сказать просто порядок сроков.
DG>И что ты, кроме xml-я, предлагаешь использовать для стыковки с партнерами и банком?
Забавно. А если ни у партнёров ни у банка нет XML-связи? Бум навязывать им именно XML?
Вобщем-то, что XML, что бинарная спецификация — один хрен, основая сложность не в формате, а в том, чтобы связать прикладную составляющую этих интерфейсов с прикладной же функциональностью основной программы. Ну, это, впрочем, с моей личной колокольни.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
ГВ>>Добавь сюда ещё возможные конфликты имён. Тем не менее, эта проблема в принципе решаема методом отказа от поиска велосипедов. DG>Т.е. всё пишем сами? А заказчик стоимость разработки велосипедов готов оплачивать? DG>Или ему уже посоветовали соседнюю фирму, в которой стоимость разработки будет меньше, потому что они не изобретают велосипеды?
Ничего фатального — обычно заказчика интересует всё-таки конечная функциональность, а не инструменты, которыми я для её реализации пользуюсь. Может, мне повезло, но встречаться с теми, кто будет ковыряться во внутренностях откомпилированной программы мне пока не доводилось. Максимум — в базе данных копаются.
[...]
DG>>>Так ты начем предлагаешь писать? На чистых C++? ГВ>>Подожди, я пока говорил не о том, "на чём надо писать", а о том "где место .Net"? Не чуешь разницы? DG>Не чую. .Net предоставляет более дешевый способ решения многих проблем, и пока ты не предложишь такой же по дешевизне способ для решения этих задач, то те разработчики, которые используют .Net, будут в более выигрышном положении, чем ты. DG>А значит и заказчики пойдут не к тебе.
Ты забегаешь вперёд, не спеши.
ГВ>> Мне лично удобнее писать на C++, нежели на C# со-товарищи MSIL, но тем не менее — вопросы мои были о другом. Вообще забавно получается — я о том, что через .Net лучше всего коммуникации обслуживать (да и то — не всегда), а мне с оттенком испуга: "А остальное на чём?" А про остальное я как-то и не спрашивал. DG>Задам вопрос по другому: почему ты считаешь, что на C++ писать проще, чем на C# на пример?
Templates + МН + переносимость + почва для развития мышления = достаточный аргумент? Для меня — да.
DG>>>И как по твоему программа будет восстанавливатся вот после такого кода?:
[...] ГВ>>По-моему, такой код просто не надо писать, особенно первую часть. Или это труднообъяснимо?
DG>Предложи реальный способ, который будет не допускать появлении такого кода.
Э... ну да, извини, кроме как голову на плечах... а это — "несерьёзный аргумент". Звиняй.
DG>throw ведь могут быть и не явными. Могут быть из-за каких-то ошибок программиста, но пользователю-то будет от этого не легче.
А не вызывать в деструкторе потенциально опасный код — это из области фантастики?
ГВ>>Хм. А если сначала разобраться с системным сегментом, то может, потом и несколько фирм и отделов привлекать не понадобится? А если и привлечь, то вообще-то можно и требования к исходным кодам выставить. Не пробовал? Ну там, единый компилятор, общий API, общее ядро... Я ж тебе говорю — с головы начинается фундамент, а не со среды программирования. DG>Например, тебе нужно простыковатся с банковской системой, или с товарной системой твоего партнера.
Что за интерфейсы? И у той и у той системы. Какова их сложность? Какая прикладная структура отображается интерфейсами?
DG>И то, и другое уже написано, вложена куча денег, и если ты будешь пытатся навязывать жесткие ограничения на используемый компилятор, на используемый язык, то тебя просто пошлют.
Странно, если это отделы — то как это "пошлют"? А если сторонние фирмы — то это моё дело, соглашаться на их "пошлют" или менять условия.
Ладно, понял, похоже, что вы ещё не вошли в стадию, когда желание развития своих идей превалирует над внешними условиями.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, desperado_gmbh, Вы писали:
ГВ>>если Януса больше суток не перезапускать, то blue screen появляется, если перезапускать периодически — всё в порядке. _>Blue screen в w2k, в отличие от w9x, означает проблемы ядра или драйвера, а не приложения.
Ладно, чтобы не флеймить по этому поводу — может быть и так, просто какая-то на самом деле странная зависимость — елси янус болтается около суток кряду — привет BS, если нет, то всё в порядке. В принципе, сразу на .Net валить, конечно, резковато получилось.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mihailik, Вы писали:
DG>>>6. Оптимизация (опять много разнородных объектов, частоменяющиеся требования, много вычислений) ГВ>>Это — задача компилятора. Любого. Или .Net уже научился переливать объектный код за границы COM-интерфейсов.
M>Угу. JIT-компилятор даже inline делает, даже из чужой библиотеки функцию может поинлайнить.
Даже нативную? Теоретически это возможно, хотя и рисковано.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
DG>>Т.е. всё пишем сами? А заказчик стоимость разработки велосипедов готов оплачивать? DG>>Или ему уже посоветовали соседнюю фирму, в которой стоимость разработки будет меньше, потому что они не изобретают велосипеды?
ГВ>Ничего фатального — обычно заказчика интересует всё-таки конечная функциональность, а не инструменты, которыми я для её реализации пользуюсь. Может, мне повезло, но встречаться с теми, кто будет ковыряться во внутренностях откомпилированной программы мне пока не доводилось. Максимум — в базе данных копаются.
Какая разница ковыряются или нет в коде.
Главное что ты, изобретая велосипед, теряешь время, тратишь дополнительные деньги заказчика и т.д.
DG>>>>Так ты начем предлагаешь писать? На чистых C++? ГВ>>>Подожди, я пока говорил не о том, "на чём надо писать", а о том "где место .Net"? Не чуешь разницы? DG>>Не чую. .Net предоставляет более дешевый способ решения многих проблем, и пока ты не предложишь такой же по дешевизне способ для решения этих задач, то те разработчики, которые используют .Net, будут в более выигрышном положении, чем ты. DG>>А значит и заказчики пойдут не к тебе.
ГВ>Ты забегаешь вперёд, не спеши.
А когда уже будет пора?
ГВ>>> Мне лично удобнее писать на C++, нежели на C# со-товарищи MSIL, но тем не менее — вопросы мои были о другом. Вообще забавно получается — я о том, что через .Net лучше всего коммуникации обслуживать (да и то — не всегда), а мне с оттенком испуга: "А остальное на чём?" А про остальное я как-то и не спрашивал. DG>>Задам вопрос по другому: почему ты считаешь, что на C++ писать проще, чем на C# на пример?
ГВ>Templates
Да, вот это действительно не хватает, в первую очередь для создания типизированных коллекций.
Но опять же, как только ты начинаешься стыковатся в C++ на уровне бинарников, а не на уровне исходников, то шаблоны уходят в никуда.
ГВ> + МН
фиг его знает. МН действительно приносит не только плюсы, но и минусы.
ГВ> + переносимость
AFAIK, у C++ очень низкая переносимость. Чтобы перенести реальное приложение, необходимо вбухать кучу денег.
ГВ> + почва для развития мышления
довод из области демагогии. Ассемблер тоже предлагает отличные возможности для развития мышления, но это не значит, что на нам стоит писать большие системы.
ГВ> = достаточный аргумент? Для меня — да.
DG>>throw ведь могут быть и не явными. Могут быть из-за каких-то ошибок программиста, но пользователю-то будет от этого не легче. ГВ>А не вызывать в деструкторе потенциально опасный код — это из области фантастики?
В некотором смысле — да, это из области фантастики. В деструкторах обычно идет зачистка ресурсов, например, закрываем соединения, файлы и т.д.
И кто сказал, что это соединение, например, не было уже убито кет-то снаружи — сеть например отвалилась.
В конце концов, может просто кончится память или из-за глубокой ошибки программиста, произойти обращение по нулевому указателю. В любой программе есть некий процент ошибок.
Или ты предлагаешь в любой деструктор обязательно дописывать try/catch?
DG>>Например, тебе нужно простыковатся с банковской системой, или с товарной системой твоего партнера.
ГВ>Что за интерфейсы? И у той и у той системы. Какова их сложность? Какая прикладная структура отображается интерфейсами?
У одних честный Web services, у других некий свой протокол, но они готовы дать исходники клиента, написанного на Java.
DG>>И то, и другое уже написано, вложена куча денег, и если ты будешь пытатся навязывать жесткие ограничения на используемый компилятор, на используемый язык, то тебя просто пошлют.
ГВ>Странно, если это отделы — то как это "пошлют"?
Это реальная жизнь. У них свои мысли, идеи и т.д. Не хватит духу послать открыто, будут посылать скрытно, вставляя палки в колеса.
ГВ> А если сторонние фирмы — то это моё дело, соглашаться на их "пошлют" или менять условия.
Сторонних фирм же тоже конечное число.
Тем более можно вспомнить один из законов кибернетики: системой управляет самый гибкий ее элемент.
.Net, в отличии от C++, предоставляет большую гибкость: развязка между языками, развязка на уровне бинарников, развязка на уровне менеджера памяти, развяка на уровне метаданных о коде и т.д.
ГВ>Ладно, понял, похоже, что вы ещё не вошли в стадию, когда желание развития своих идей превалирует над внешними условиями.
Здравствуйте, mikа, Вы писали:
M>>>>>Честно говоря, я вообще такую концепцию не применяю. И Remoting кстати это не позволяет, если не настроить обратную связь. Так что ничего на клиента не ездеет. Они оба (клиент, сервер) общаються через сторонние сущности. DG>>Почему это серверные объекты не "ездят" на клиента? DG>>а как же аттрибут [Serializable]? DG>>и при чем здесь обратная связь? M>Честно говоря, я подумал что Геннадий разбирается в remoting. Поэтому, я его понял так, что обекты серверные передаються ссылкой на клиент. Здесь нужна как бы обратная связь.
А я тебя понял так, что серверные объекты ездят полностью (есессно, с утаскиванием всех своих связей, проксей и т.п.). Объясню свой комментарий. Если объект создан в одном адресном пространстве, а появился в другом, то в любом случае определённая информация о нём сначала должна быть в этом самом другом АП. Её можно передать remoting-ом, а можно просто скопировать (загрузить и т.п.) соответствующую библиотеку и передать ей команду создания объекта нужного типа и нужные данные для загрузки. Это как раз то, о чём я говорил: "одни и те же версии софта".
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Ну ты и разволновался — аж занадпереоверквотил.
ГВ>>Не надо обобщать. Код Win-приложений и Web-приложений — не одно и тоже, тогда как обобщить интерфейсы пользователя в Win и Web — вполне можно. M>Погодите, товарищ! M>Обобщить любые интерфейсы можно, но всё равно их реализовывать пока приходится раздельно (пока не вышел Windows Longhorn и XAML). M>Или есть ещё какие-то наработки по существу вопроса?
Ну есть кое-какие. Ещё AVK эту тему копал, AFAIK. Естественно, обобщению поддаётся не всё, но не всё и не всегда нужно обобщать.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
DG>>3. упростить написание правил расчета цен за товар (есть много разных скидок, различных партнерских договоров и т.д.) ГВ>Раскрой, плз., поподроднее. Что подразумевается по упрощением?
Предложить какие-то настройки, скрипты и т.д.
DG>>4. оптимизировать стоимость хранения бензина (хранить только столько, сколько необходимо) ГВ>Это — расчёты. Не смертельно сложные, алгоритмика вполне доступна непуганому технологиями студенту 3-4 курса. Язык — скорее всего C++ из-за развитых шаблонов. Собственно, с моей стороны это только предположения — какими выполняется оценка?
Т.е. опять велосипед изобретается?
DG>>5. разработать удобный пользовательский интерфейс для всего этого ГВ>Разумеется, а как же без него? Для каких клиентов? Сколько пользователей у системы?
GUI + Web. 50 рабочих мест.
DG>>И что ты, кроме xml-я, предлагаешь использовать для стыковки с партнерами и банком?
ГВ>Забавно. А если ни у партнёров ни у банка нет XML-связи? Бум навязывать им именно XML?
Если будет возможность, то навяжем, т.к. при использовании xml-я сразу уходят проблемы с версиями, проксами, firewall-ами и т.д.
Если навязать не получится, то тогда поверх их формата реализуем IXmlReader или IXPathNavigator, и будем работать как с обычным xml-ем.
ГВ>Вобщем-то, что XML, что бинарная спецификация — один хрен, основая сложность не в формате, а в том, чтобы связать прикладную составляющую этих интерфейсов с прикладной же функциональностью основной программы. Ну, это, впрочем, с моей личной колокольни.
Как раз прикладная составляющая примерно похожа.
А конвертить один xml в другой-xml намного проще (где-то можно заюзать xslt, где-то универсальный конвертер, где-то в конце концов руками сконвертировать), чем конвертить один бинарный формат в другой.
Здравствуйте, mihailik, Вы писали:
M>Ну не знаю, вроде написано было явно, "для приложения". А для разработчика конечно легко. Но, как я уже говорил, неудобства JNI вряд ли можно считать преимуществом.
Да, очень условно.
M>>>>>Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит. ГВ>>>>Пусть стреляет. Но тогда реальной переносимости между процессорными архитектурами совсем не получается. M>>>Здрасте! IA64 отличается от x86 просто совершенно. Вообще, совсем другой процессор. ГВ>>Ды на здоровье. M>Значит всё-таки есть переносимость?
Нет, есть неправомерное обобщение.
ГВ>> А для PowerPC уже есть .Net? M>Коммерческого, серверного нет. Есть Mono (Open Source) и Shared Source aka Rotor (некоммерческий пример реализации от Микрософт с исходными кодами). Оба работают под PPC.
OK, значит, я был не прав.
M>Я думаю, .NET вряд ли скоро будет портирован на эту платформу в достаточном для серверов, коммерческом качестве. Это достаточно большой объём работы.
А может быть и прав...
M>Насколько я понимаю стратегию Микрософта, они стремятся коммерчески поддерживать .NET на своей платформе. Им выгоднее выдавливать Юникс целиком, как операционку, а не зарабатывать на устоявшемся поделенном рынке. Есть MS SQL для Юникса? Нету. Вот и .NET Framework потому же не портируют.
Но для Юникса есть Оракул и другие базы. Что-то мне всё время пдсказывает, что не очень уж .Net на Unix приживётся. Хотя кто его знает...
[offtopic]
Вот ну не думаю я, что IBM возьмёт да и бросит свои разработки в области серверов и ОС. Да и Linux тоже не хрен собачий. Потом возьми ещё всяческие иные факторы вплоть до политических... Нет уж... "единой ОС на всех" в обозримом будущем не предвидится. Как и единого средства разработки.
[/offtopic]
ГВ>>>>Или ASP.ONE. Впрочем, это уже совсем другая история. Главное другое: xxxxx Server Pages — по сути обеспечивают коммуникации (ИМХО), а точнее — коммуникацию пользователя с программой в среде Web. M>>>Ну нет, я не согласен! Ты с ходу взял смешал слой представления с коммуникациями. ASP/JSP — это однозначно слой представления. Так и Word у тебя будет средством коммуникации.
ГВ>>Просто они работают в коммуникационной среде — всяческие Sessions тому подтверждением.
M>Ну так это же разные вещи! SQL Server тоже работает в комуникационной среде. Но SQL Server — это слой данных, как ни крути.
Ну... это ты загнул, ИМХО. Я бы сказал, что интерфейсы SQL-сервера работают в коммуникационной среде.
M>Так и ASP/JSP — слой представления.
Да, вобщем-то верно. Коммуникации и представление в смысле организации взаимодействия с пользователем — структурно очень похожи. А смешал я их потому, что ASP/JSP генерируют HTML/DHTML/xxxML для Web-браузеров. Семантику прикладной задачи нередко одними только средствами ASP/JSP описать невозможно без привлечения сторонних средств (COM, EJB-серевры, SQL-серверы и т.п.). Точно также, как нельзя, например, поточечено рисовать на экране. Хотя алгоритмы, конечно, записать можно. Т.е., остаётся только примитивная в сущности функциональность генерации текстовой размеки в ответ на Http-request. Оговорюсь, что "примитивная" не значит — плохая, а значит — простая и понятная.
С другой стороны, SQL-сервер скорее уж в основном создан ради реализации семантик теории отношений и долговременного существования информации. А вот его интерфейсы — это да, они коммуникационные. Они просто ради коммуникаций созданы. Но при этом нельзя говорить, что SQL-сервер работает совсем уж "в коммуникационной среде". Уловил мысль?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
ГВ>>Похоже на то, только у таких "исследований" один недостаток имеется — всюду один и тот же клин раздувания мелких мух в огромных слонов. M>Это конечно красивые слова, но не более. С чего ты это взял? Где доказательства, кроме твоих субективных рассуждений?
Если кратко, то у меня упорное и нехорошее ощущение, что всё время (за последние эдак лет 10-15) пытаются средства реализации прикладной семантики растащить по второстепенным службам: вывалить на SQL-сервер, спихнуть в коммуникационные слои, переложить в презентационный слой и т.п. А когда добавляется элементарный императивный язычок, то тут уже воплей выши крыши. Вопли-то понятно откуда — маркетинг подсуечивается, вот только комбинаторные возможности этих язычков... кхм. Ну, для задач типа "слабать что-то по-бырому" — да, а вот чего посложнее описать, так либо полк программистов собирать нужно, либо невозможно вообще.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
M>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>> Я вроде как, деньги MS "грязными" не называл и не собираюсь. Обычная компания, обычные для компании цели. Или называть вещи своими именами уже моветон?
M>А зачем тогда речь о деньгах? Или ты хочешь что и там место для .NET? Согласен, для банковских операций тенхология вписывается лучше не куда.
Нет, я о том, что не на все вопросы программирования ответ должен начинаться со слов "А вот у MS есть...". Понятно?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>>>Т.е. всё пишем сами? А заказчик стоимость разработки велосипедов готов оплачивать? DG>>>Или ему уже посоветовали соседнюю фирму, в которой стоимость разработки будет меньше, потому что они не изобретают велосипеды?
ГВ>>Ничего фатального — обычно заказчика интересует всё-таки конечная функциональность, а не инструменты, которыми я для её реализации пользуюсь. Может, мне повезло, но встречаться с теми, кто будет ковыряться во внутренностях откомпилированной программы мне пока не доводилось. Максимум — в базе данных копаются.
DG>Какая разница ковыряются или нет в коде.
Большая. В первом случае они могут потребовать от меня тех или иных средств реализации, во втором — нет.
DG>Главное что ты, изобретая велосипед, теряешь время, тратишь дополнительные деньги заказчика и т.д.
Ну, это тоже демагогия. Здесь всё определяется готовностью команды к "изобретению" или изучению очередного велосипеда.
ГВ>>>> Мне лично удобнее писать на C++, нежели на C# со-товарищи MSIL, но тем не менее — вопросы мои были о другом. Вообще забавно получается — я о том, что через .Net лучше всего коммуникации обслуживать (да и то — не всегда), а мне с оттенком испуга: "А остальное на чём?" А про остальное я как-то и не спрашивал. DG>>>Задам вопрос по другому: почему ты считаешь, что на C++ писать проще, чем на C# на пример?
ГВ>>Templates DG>Да, вот это действительно не хватает, в первую очередь для создания типизированных коллекций.
Если бы только коллекций...
DG>Но опять же, как только ты начинаешься стыковатся в C++ на уровне бинарников, а не на уровне исходников, то шаблоны уходят в никуда.
Не всегда и не обязательно.
ГВ>> + МН DG>фиг его знает. МН действительно приносит не только плюсы, но и минусы.
Ну... вобщем — да, это как "автомат в руках обезяны". Нравится мне это сравнение.
ГВ>> + переносимость DG>AFAIK, у C++ очень низкая переносимость. Чтобы перенести реальное приложение, необходимо вбухать кучу денег.
Ну, если оно сразу написано, например в терминах MFC, то — да. А если переносимость предполагается изначально — то не совсем так. Хотя ты прав в то смысле, что с компиляторами до недавненго времени всё было совсем не так гладко, как хотелось бы.
ГВ>> + почва для развития мышления DG>довод из области демагогии. Ассемблер тоже предлагает отличные возможности для развития мышления, но это не значит, что на нам стоит писать большие системы.
Не совсем так. Ассемблер всё-таки чисто императивный язык, у C++ в плане выражения моделей возможностей поболе будет.
ГВ>> = достаточный аргумент? Для меня — да.
DG>>>throw ведь могут быть и не явными. Могут быть из-за каких-то ошибок программиста, но пользователю-то будет от этого не легче. ГВ>>А не вызывать в деструкторе потенциально опасный код — это из области фантастики?
DG>В некотором смысле — да, это из области фантастики. В деструкторах обычно идет зачистка ресурсов, например, закрываем соединения, файлы и т.д.
DG>И кто сказал, что это соединение, например, не было уже убито кет-то снаружи — сеть например отвалилась.
DG>В конце концов, может просто кончится память или из-за глубокой ошибки программиста, произойти обращение по нулевому указателю. В любой программе есть некий процент ошибок.
DG>Или ты предлагаешь в любой деструктор обязательно дописывать try/catch?
DG>>>Например, тебе нужно простыковатся с банковской системой, или с товарной системой твоего партнера.
ГВ>>Что за интерфейсы? И у той и у той системы. Какова их сложность? Какая прикладная структура отображается интерфейсами?
DG>У одних честный Web services, у других некий свой протокол, но они готовы дать исходники клиента, написанного на Java.
DG>>>И то, и другое уже написано, вложена куча денег, и если ты будешь пытатся навязывать жесткие ограничения на используемый компилятор, на используемый язык, то тебя просто пошлют.
ГВ>>Странно, если это отделы — то как это "пошлют"?
DG>Это реальная жизнь. У них свои мысли, идеи и т.д. Не хватит духу послать открыто, будут посылать скрытно, вставляя палки в колеса.
ГВ>> А если сторонние фирмы — то это моё дело, соглашаться на их "пошлют" или менять условия.
DG>Сторонних фирм же тоже конечное число.
DG>Тем более можно вспомнить один из законов кибернетики: системой управляет самый гибкий ее элемент.
DG>.Net, в отличии от C++, предоставляет большую гибкость: развязка между языками, развязка на уровне бинарников, развязка на уровне менеджера памяти, развяка на уровне метаданных о коде и т.д.
ГВ>>Ладно, понял, похоже, что вы ещё не вошли в стадию, когда желание развития своих идей превалирует над внешними условиями.
DG>Не понял данную ремарку.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
ГВ>>Кстати, dad прав в том смысле, что RPC в принципе заменяет SOAP. Просто RPC "раскручен" меньше. А кодогенерация решает проблему, созданную SOAP-ом же. Короче, ещё один уровень проксей у нас получается. M> Вот ты мне скажи как профессионал, где тут прав dad? В том, что он не знает что такое RPC? RCP — это протокол общения (AKA транспортный). SOAP — это протокол форматирования.
Хм. А я-то думал, что SOAP — протокол доступа к объектам. А RPC — совсем не транспортный протокол.
M>Обычно SOAP передаеться в HTTP.
Не "в", а "через".
M>Сравнивать SOAP и RPC все равно, что самолет с унитазом.
Смотря с какого уровня абстракции. Хотя, пожалуй, что лучше сравнивать с Object RPC. В сущности. и то и другое и третье — метода удалённых вызовов.
M>Это раз. Во-вторых, кодогенерация — вообще никаким боком не подходит к RCP ибо появлась тогда, когда еще и сетевого общения в помине не было.
Точно также, как кодогенерация никакого отношения к SOAP самому по себе не имеет. Она нужна только для упрощения работы с SOAP.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
M>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Я к тому, что оценка "геморный код" появляется тогда, когда сам этот код оказывается чем-то неожиданным и крайне нежелательным. Такие ситуации возникают, если имеется сильный перекос в сторону той или иной специфической семантики. Например — в пользу презентационной. Тогда необходимость написать какой-то сугубо системный код вызывает вполне естественное психологическое отторжение. M>Я а понимаю под "гемморны кодом" код, которых нужна писать и отлаживать. Видно у нас разные подходы при планировании и анализе проблемы
Да нет, похоже. Я стремлюсь писать такой код один раз и забывать о нём.
M>>>Из мелочей складываються блоки, из блоков — программы. Вместо готового реализуешь одно, потом другое, и не заметишь, как время, отведенное на разработку ПО, закончилось, а программа запускается через раз. Вот твой принцип? ГВ>>Это очень наивное изложение, к тому же оно полностью отключает мозги, что досадно. У меня как-то и программы работают, и поисками велосипедов не озабочиваюсь. Хотя не спорю, по первому времени прохлопы по времени случались, пока смелости не хватало реализовывать то, что я считаю нужным так, как я это считаю нужным делать. M>Мозги не отключаються ибо концентрируешься на реальное задачи, а не на той, которую сам себе выдумал. Чем то мне это напоминает "Дон Кихот". Согласись
Ну, не знаю, что кому оно напоминает, мне оно напоминает желание отвязаться от бестолковых "всеобщих новшеств". Ради того, чтобы опять таки сконцентрироваться на прикладной задаче.
M>>>А что тебе нужно доказать? .NET он и есть .NET, что автономен. Ему ничего лишнего не надо. ГВ>>mika, ну не скатывайся до банальной демагогии. "Это велико, потому что оно большое, а большое оно потому, что велико". M>Геннадий, ты сам начсинаешь уже утвержать нечто третье. Мы вообще о чем разговаривает? Что тебе не доказано и кто тебе это должен доказать?
Зря я обратил внимание на эту фразу, на да ладно.
ГВ>>Интересно, напомни. Неужели на уровне коммуникаций? M>А у тебя коммуникация на скриптах написана. Тогда не удивительно что ты все на АБС писал. С такими тормозами передачи данных можно на сервак хоть тройку поставить
На чём, на чём?
ГВ>>>>В принципиально неверном подходе: "высока у стула ножка — подпилю её немножко". Только вместо стула подпиливается пол, на котором он стоит. M>>>Отлично ответил. Только было бы не плохо аргументировать свои ответ. ГВ>>Аргументация очень простая и ты сам её привёл на самом деле. Если слегка перефразировать твою реплику, то получится, что если программы провоцируют перегрузку линий, то не программы оптимизируются, что было бы, ИМХО, логично, а линии апгрейдятся, что, ИМХО, без особой необходимости — неверно. Хотя спору нет — таким образом создаётся рынок для линий связи. M>Хм. Чем тебе третий вариант не понравился? Или ты уже не читаешь, а только споришь?
Нет, конечно.
ГВ>>>>>>>>Да, но назначение ASP — работа в коммуникационной среде. Каких бы прибамбасов там ни было, "среда" для ASP всё равно — коммуникационная. Ну, плюс ещё презентативная логика в определённом смысле. M>>>>>>>Честно говоря, если взглянуть глубже, то ASP это не только коммуникация. Что то мне подсказывает ГВ>>>>>>... запросто создаётся перекос в сторону "программирования на форме". Впрочем, это ещё с Delphi и VB пошло... M>>>>>И правильно пошло. ГВ>>>> Ну, вообще-то, это азы ОО-проектирования: не писать бизнес-код непосредственно в обработчиках событий UI. M>>>А что тут то сложного? Бери с сайта microsoft.com их App Block, базирующийся на модель Doc-View-Controller. Или вас от готового нос воротит. ГВ>>Не воротит, не переживай. Только как это относится к моей реплике? M>К тому, что ты утверждаешь, что у MS подхода неправильное представление о создании UI приложений. Вот тебе мой ответ, показывающий где ты ошибаешься
По-моему, это тебя носит из стороны в сторону.
ГВ>>Не надо обобщать. Код Win-приложений и Web-приложений — не одно и тоже, тогда как обобщить интерфейсы пользователя в Win и Web — вполне можно. M>Во-первых, тут я не пойму в чем проблема и почему это нельзя создать в Нете. Во-вторых, скоро (или уже) выйдет статья Михаила Чащина. Советую почитать.
Хм, спасибо за рекомендацию.
M>>>Дал для примера, что люди, совершенно не знающие предметную область начинают ее наять. Поговорка (запиши в свою коллекцию ) "Врага надо знать в лицо" тут явно не в почете ГВ>>mika, у меня к тебе личный вопрос. А почему сразу "хаять"? Вроде как я .Net не ругаю, а просто выношу некоторые свои соображения для оспаривания. M>Просто у меня сложилось впечатления, что любые доводы тебе, как горох об стену. Возможно, я ошибся.
Совсем нет, просто они пока не того порядка, которого я жду.
[оставил здесь пока все цитаты] M>>>>>Ну приколы связи, это вообшем то проблема прошлого века. Вероятно, тебе она кажется до сих пор весомой только по тому, что ты не используешь стандатрные вещи. Я уже даже не говорю про .NET. А вот насчет логики обработки... Тут все зависит от ее необходимости, и как ты ее собираешься решить. ГВ>>>>Кхм. Акстись. Я даже волшебное слово знаю — пожалуйста. Приколы связи как были, так и останутся навечно, пока её принципы каким-нибудь кардинальным образом не изменятся. M>>>Если такие компоненты MSMQ. Позволяют пересылать на неустойчивом участке звязи данные со 100 гарантией. Расширяються за счет написания триггеров, связью с СУБД и прочей приблуды. Или тебе и это уже не нравиться, подавай самописное? ГВ>>Стоп-стоп-стоп. MSMQ — это способ решения проблемы доставки, но на такие приколы, как выпадение по таймауту его использование ну никак не повлияет. А особенно, если один объект посылает сообщение (сиречь — вызывает метод) и... упс... оно уходит по MSMQ, а в это время на линии возникает перегрузка... а MSMQ она ж с гарантированной доставкой — она хоть месяц ждать будет, только вот что объекту-то делать? Месяц висеть? M>А ты как реализуешь. Хитрый способ доставки? Или канал какой нить вирт отктроешь, который решит всю проблему?
Не в этом дело. Дело в том, что наличие ремутинга не отменяет необходимости деления программы на куски, между которыми то или иное ремутничанье допустимо, а внутри — нет. А следовательно, это только сугубо техническая полумера.
ГВ>>Что remoting что-то кардинально меняет. M>По сравнению с чем? Может я тебе еще не все рассказал про него?
ГВ>>Бизнес-софт всё-таки разный бывает, не находишь? Поисковики — тоже бизнес софт и высокопроизводительные вычисления — тоже, однако. M>Вот вот. И почему тут Нет не подходит?
Где-то подходит, где-то нет.
Я всё думаю-думаю, но что-то мне подсказывает, что, например, App-серверы для поддержки stateful-модели на .Net писать пока что будет сложнее, чем на C++.
ГВ>>Мда. M>Не нравиться. Вот и я не люблю велосипеды
Не люби на здоровье. Но
M>>>>>К чему ты это сказал? ГВ>>>>К архитектуре. M>>>А она тут к чему? ГВ>>А с неё всё начинается. ИМХО, хорошая архитектура просто и однозначно делит семантику системы по доменам (в терминологии Буча) в одной группе — только отображение, в другой — только прикладнуха, в третьей — только БД и т.д. и т.п. Переверни архитектуру с ног на голову (здесь — бухгалтерия, здесь — склад, здесь — отчёты) и сопровождаемость в первую очередь усложняется в разы. Ну, разумеется, эта проблема не так остро стоит перед простенькими приложениями. M>Во-первых, начинаеться все не с проектирования.
Беда. Хотя на самом деле ты прав — бывает всяко. Кроме того, понятно, что любая программа начинается с желания её написать.
M>Во-вторых, при чем здесь Нет. Тут я так представляю нужен UML.
Поверь, ни UML, ни .Net ни даже C++ этой проблемы сами по себе не решают. UML только слегка поможет документировать решение и сделать предварительный анализ.
M>>>Что касается клиента. Лично я ни разу не видел требования к лиенту кроссплтаформенность. Это уж какие клиенты должны быть Может меня просто пронесло? ГВ>>Простейший пример кросплатформенного интерфейса пользователя: desktop + web. M>И?
И почти всегда делают две независимые реализации, блин.
M>>>Во-вторых, это не фикция. Это удобство. Думаю понятно ГВ>>Для кого? M>Все следующие вопросы по тематике .NET в соот форум.
OK, только у меня вопросы философского характера, так что я здесь побуду.
ГВ>>Мика, это всё к делу не относится. Достаточно требования отображения на объектную среду. Хотя, пожалуй, то здесь я погорячился — вроде как проблема не настолько уж и велика, раз уж даже C++ появиться должен. M>А какую ты проблему видел, если не секрет?
Я не знаю как её назвать, но проблема может выражаться в том, что на уровне самого языка будут торчать уши .Net.
M>>>Так что тут стоит вопрос в другом, как ты будешь соединять солянку из Фортран, С++, Dephi? ГВ>>А у них, вроде как C-интерфейсы есть. Хотя, если честно, то от Delphi я бы постарался избавиться. M>А у Prolog.NET тоже есть интерфейсы. Что лучше?
Я тебе ответил на твой вопрос, а "просто так" ничего лучше другого не бывает.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
M>>> Есть. Но альтернатива состоит из совокупности. А .NET один. Тоесть, лучше использовать один язык программирования, к которому ты привык за долгие годы, и которые сможет так же легко реализовать задачу, как альтернативное средство во всех сферах, чем питаться сборной солянкой. Геннадий предлагаем нам супчик
ГВ>>Супчик этот заварен давно и не нами.
M>Раз давно и не нами, значит правильно? Великолепная логика!
Нет, это ты меня не совсем правильно понял. Раз "давно и не нами" и до сих пор есть — значит тому есть много-много причин. (c) Мировинген.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>>>3. упростить написание правил расчета цен за товар (есть много разных скидок, различных партнерских договоров и т.д.) ГВ>>Раскрой, плз., поподроднее. Что подразумевается по упрощением? DG>Предложить какие-то настройки, скрипты и т.д.
Понятно. Делали, предагали, работает. Усё на С++. Проблемно-ориентированный язык отдельно взятой системы пишется не просто быстро, а весьма быстро. Не плюсы, конечно, но и не невесть что. Главное — это понять, куда его нужно поставить.
DG>>>4. оптимизировать стоимость хранения бензина (хранить только столько, сколько необходимо) ГВ>>Это — расчёты. Не смертельно сложные, алгоритмика вполне доступна непуганому технологиями студенту 3-4 курса. Язык — скорее всего C++ из-за развитых шаблонов. Собственно, с моей стороны это только предположения — какими выполняется оценка? DG>Т.е. опять велосипед изобретается?
А где гарантия, что я найду в обозримый срок нужные мне библиотеки?
DG>>>5. разработать удобный пользовательский интерфейс для всего этого ГВ>>Разумеется, а как же без него? Для каких клиентов? Сколько пользователей у системы? DG>GUI + Web. 50 рабочих мест.
Ну что же, бум с генератором интерфейсов работать.
DG>>>И что ты, кроме xml-я, предлагаешь использовать для стыковки с партнерами и банком? ГВ>>Забавно. А если ни у партнёров ни у банка нет XML-связи? Бум навязывать им именно XML? DG>Если будет возможность, то навяжем, т.к. при использовании xml-я сразу уходят проблемы с версиями, проксами, firewall-ами и т.д.
Да, это хорошо, но ты забыл, что кроме интернет, могут быть и совершенно другие каналы связи, вплоть до своих программно-аппаратных комплексов. Ладно, проехали.
DG>Если навязать не получится, то тогда поверх их формата реализуем IXmlReader или IXPathNavigator, и будем работать как с обычным xml-ем.
А это уже на данном этапе не важно. Я не сомневаюсь, что трансформировать XML несложно.
ГВ>>Вобщем-то, что XML, что бинарная спецификация — один хрен, основая сложность не в формате, а в том, чтобы связать прикладную составляющую этих интерфейсов с прикладной же функциональностью основной программы. Ну, это, впрочем, с моей личной колокольни. DG>Как раз прикладная составляющая примерно похожа.
Вот-вот, вся проблема именно в этом "примерно".
DG>А конвертить один xml в другой-xml намного проще (где-то можно заюзать xslt, где-то универсальный конвертер, где-то в конце концов руками сконвертировать), чем конвертить один бинарный формат в другой.
Это уже детали. Ты обратил внимание, о чём я говорил? Конвертнуть "формат"-"формат" не проблема почти всегда. Проблема в том, чтобы разобраться в порядке взаимодействия двух систем.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, dad, Вы писали:
ГВ>>Кстати, dad прав в том смысле, что RPC в принципе заменяет SOAP. Просто RPC "раскручен" меньше. А кодогенерация решает проблему, созданную SOAP-ом же. Короче, ещё один уровень проксей у нас получается.
dad>кстати есть xml-rpc, и куча интерфесов ко всем языкам от явы до перло.. dad>чем не .net
Погоди, ща разберёмся где же место .Net, тогда и сравнивать будем.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Не совсем так. Ассемблер всё-таки чисто императивный язык, у C++ в плане выражения моделей возможностей поболе будет.
Согласись с тем, что .Net еще более декларативная система, чем C++, благодаря аттрибутам и метаданным.
Хотя до нормальной декларативной системы еще расти и расти.
ГВ>Я всё думаю-думаю, но что-то мне подсказывает, что, например, App-серверы для поддержки stateful-модели на .Net писать пока что будет сложнее, чем на C++.
Причина?
На первый взгляд плюсов у .Net-а больше, чем минусов, по сравнению с тем же C++.
С Java-ой паритет, но java рулит в основном только на nix-ах.
Здравствуйте, DarkGray, Вы писали:
ГВ>>Не совсем так. Ассемблер всё-таки чисто императивный язык, у C++ в плане выражения моделей возможностей поболе будет.
DG>Согласись с тем, что .Net еще более декларативная система, чем C++, благодаря аттрибутам и метаданным.
Нет, с этим не соглашусь.
DG>Хотя до нормальной декларативной системы еще расти и расти.
Это — да.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>>Я всё думаю-думаю, но что-то мне подсказывает, что, например, App-серверы для поддержки stateful-модели на .Net писать пока что будет сложнее, чем на C++.
DG>Причина?
DG>На первый взгляд плюсов у .Net-а больше, чем минусов, по сравнению с тем же C++. DG>С Java-ой паритет, но java рулит в основном только на nix-ах.
Пока я и сам не определился с этим однозначно. В основном — из-за пресловутого недетерминированного удаления и отсутсвия шаблонов, а мне они ох как нужны. МН тоже не хватает — весьма полезная штука на системном уровне. Так что, вот так вот...
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
DG>AFAIK, у C++ очень низкая переносимость. Чтобы перенести реальное приложение, необходимо вбухать кучу денег.
наджо нормально писать совт потому что, тог8да бует все нормально переноситься, а не писать соединение с mssql в обработчке WM_MESSAGE тогда все будет переноситься нормально. "вбухать кучу денег" такое абстрактное выражение как и "реальное приложение"
ГВ>> + почва для развития мышления DG>довод из области демагогии. Ассемблер тоже предлагает отличные возможности для развития мышления, но это не значит, что на нам стоит писать большие системы.
Нуда, а зачем писать на ассмебле ели есть компилируемый язык? (И то в серьезных командах второй вопрос после вирт. деструктора — можешь ли ты отлаживаться в дизасме , так что ниуда он ен ушел асм. и не уйдет, на текущей архитекутре)
DG>.Net, в отличии от C++, предоставляет большую гибкость: развязка между языками, развязка на уровне бинарников, развязка на уровне менеджера памяти, развяка на уровне метаданных о коде и т.д.
Что такое "развязка на уровне" ?
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
dad>>кстати, причем тут .net? можно годогенирировать и для явы и для c++ и т.д. например — коммуникационная либа, и кодогенератор к ней. все "пуляет" никаких .net не требует.
AVK>На нете это можно делать в рантайме, как используя компиляторы (которые штатно входят в состав редиста) так и напрямую в IL.
хм.. т.е. il на самом деле с явой надо сравнивать а не c# ?
что касается рантайма. объясни плз.
есть описание вебсервиса публикующего скажем котировки, я хочу написать совт который эти котировки рендерит,
мне надо изучить описание веб сервиса (wsdl), если он имеет описание объектов данных (soap) я беру либу
и коннкчучь напрямую к сервису выполняя сериализацию через soap так ? (используя при это тот транспорт который
использует сервис) (пустть это будет не веб сервис, а просто сетевой сервис поверх tcp, скажем )
т.е. пишу клиента у себя который работает с сервсиов, который создает заместителя для меня у себя и мы там посредством сообщенйи общаемся у меня все прозрачно я создаю объхект
channel.open("www.rbc.ru/8080");
Quote q = new Quote(channel);
чота типо этого да?
если не так поправь плз. а теперь объясни мне что такое "делать это в рантайме", что имеено?
(спасибо)
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
M>>Я думаю, .NET вряд ли скоро будет портирован на эту платформу в достаточном для серверов, коммерческом качестве. Это достаточно большой объём работы. ГВ>А может быть и прав...
M>>Насколько я понимаю стратегию Микрософта, они стремятся коммерчески поддерживать .NET на своей платформе. Им выгоднее выдавливать Юникс целиком, как операционку, а не зарабатывать на устоявшемся поделенном рынке. Есть MS SQL для Юникса? Нету. Вот и .NET Framework потому же не портируют.
ГВ>[offtopic] ГВ>Вот ну не думаю я, что IBM возьмёт да и бросит свои разработки в области серверов и ОС. Да и Linux тоже не хрен собачий. Потом возьми ещё всяческие иные факторы вплоть до политических... Нет уж... "единой ОС на всех" в обозримом будущем не предвидится. Как и единого средства разработки. ГВ>[/offtopic]
Я видел текст (года два назад) в ктором всерьез утверждалось, что в скором времени вся инфраструктура Internet (интернет) будет функционаировать на .Net!!!
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, dad, Вы писали:
dad>>>кстати, причем тут .net? можно годогенирировать и для явы и для c++ и т.д. например — коммуникационная либа, и кодогенератор к ней. все "пуляет" никаких .net не требует.
AVK>>На нете это можно делать в рантайме, как используя компиляторы (которые штатно входят в состав редиста) так и напрямую в IL.
dad>хм.. т.е. il на самом деле с явой надо сравнивать а не c# ?
Не понял логики.
dad>т.е. пишу клиента у себя который работает с сервсиов, который создает заместителя для меня у себя и мы там посредством сообщенйи общаемся у меня все прозрачно я создаю объхект
Наверное я плохо с утра соображаю, но нифига не понял что ты этой фразой хотел сказать.
dad>channel.open("www.rbc.ru/8080"); dad>Quote q = new Quote(channel);
dad>чота типо этого да?
dad>если не так поправь плз. а теперь объясни мне что такое "делать это в рантайме", что имеено?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Пока я и сам не определился с этим однозначно. В основном — из-за пресловутого недетерминированного удаления
Вот как раз детерминированное удаление очень часто в серверах приложений зло.
ГВ> и отсутсвия шаблонов,
Это не цель, это всего лишь средство.
ГВ> а мне они ох как нужны. МН тоже не хватает — весьма полезная штука на системном уровне.
dad>>хм.. т.е. il на самом деле с явой надо сравнивать а не c# ? AVK>Не понял логики.
il на самом деле язык переносимый, а не c#(and brothers)
dad>>т.е. пишу клиента у себя который работает с сервсиов, который создает заместителя для меня у себя и мы там посредством сообщенйи общаемся у меня все прозрачно я создаю объхект
AVK>Наверное я плохо с утра соображаю, но нифига не понял что ты этой фразой хотел сказать.
Два варианта распределенного ПО:
— вариант один когда серверная и клиенская часть это одно приложение посути с распределенной логикой
(празрабатывается одним разработчиком для конкретных нужд)
— сервис, который ничего не знает о клиенте
первый вариант понятно, тут мы вообще можем что уогодно использовать для связи, можем использровать какие тос пецификации а можем и нет, можем свою среиалихзацию сделать и т.д. .net тут как вспомогательный инстурмент вроде,
выступает. причем совсем неоптимально. а если оптимально (на сколькоя понял балансировки там какие то и т.д)
то обязывает иметь .net на обоих концах
второй вариант — мы пишем некий сервис, который предположительно будет использован кем угодно. тут необходим
некоторый регламентированный интерфейс, протокол общения, и обмена данными — вперед выступает wsdl & soap,
причем, мне , как клиенту даже _неположено_ знать на чем реализован сервер,
как в таком случае использовать .net на серверной стороне (не знаю е ничего о клиенте) и на клиенской? (не знаю ничего о сервере) ?
dad>>channel.open("www.rbc.ru/8080"); dad>>Quote q = new Quote(channel);
dad>>чота типо этого да?
dad>>если не так поправь плз. а теперь объясни мне что такое "делать это в рантайме", что имеено? AVK>Создавать класс Quote.
поясни пожалуйста в свете подробного комментария выше.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
dad>>>хм.. т.е. il на самом деле с явой надо сравнивать а не c# ? AVK>>Не понял логики.
dad>il на самом деле язык переносимый, а не c#(and brothers)
Ну таким манером и байткод джавы тоже переносим, а не сама джава. Я вот не пойму к чему это.
dad>как в таком случае использовать .net на серверной стороне (не знаю е ничего о клиенте) и на клиенской? (не знаю ничего о сервере) ?
На серверной просто публикуется объект, на клиентской создается прокси серверного объекта + классы, представляющие все непростые типы параметров и возвращаемых значений. По wsdl естественно. Дальше работа прозрачная — в коде ты просто вызваешь метод.
dad>поясни пожалуйста в свете подробного комментария выше.
dad>>>>хм.. т.е. il на самом деле с явой надо сравнивать а не c# ? AVK>>>Не понял логики.
dad>>il на самом деле язык переносимый, а не c#(and brothers)
AVK>Ну таким манером и байткод джавы тоже переносим, а не сама джава. Я вот не пойму к чему это.
Наверно, в этом отличие как раз java и .net, потому что все остальное в .net это упаковка "все в одном"
т.е. фича .net не в c# а в il. все остальнео — это бибилотека.
занчит, при определении "места дот нет" надо исходя только из перимуществ обеспециаваемых этим свойством платформы,
все остальное может превратиться в бесконечное сравнивание библиотек и спецификаций.
поэтому смотри вопрос ниже:
dad>>как в таком случае использовать .net на серверной стороне (не знаю е ничего о клиенте) и на клиенской? (не знаю ничего о сервере) ?
AVK>На серверной просто публикуется объект, на клиентской создается прокси серверного объекта + классы, представляющие все непростые типы параметров и возвращаемых значений. По wsdl естественно. Дальше работа прозрачная — в коде ты просто вызваешь метод.
dad>>поясни пожалуйста в свете подробного комментария выше.
AVK>Я все таки не могу понят что ты от меня хочешь.
т.е. при таком подходе тут преимущество .net в том, что оно позволяет быстро и удобно разрабатывать клиента и/или сервера (т.е. преимущества как удобной библиотеки в ущерб некотрой производительности).
а какие преимущества она дает при разработке распределенных систем .net<->.net ?
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, dad, Вы писали:
dad>Наверно, в этом отличие как раз java и .net, потому что все остальное в .net это упаковка "все в одном" dad>т.е. фича .net не в c# а в il. все остальнео — это бибилотека.
Нету там такого различия, системные библиотеки и рантайм тесно интегрированы. Почему то все плюсовые программеры делают одну и ту же ошибку — пытаются зачем то рассматривать языки, рантайм и системные библиотеки поотдельности. Каждая из них, будучи оторвана от остального выглядит действительно убого, но рассматривать нужно исключительно в комплексе.
dad>занчит, при определении "места дот нет" надо исходя только из перимуществ обеспециаваемых этим свойством платформы, dad>все остальное может превратиться в бесконечное сравнивание библиотек и спецификаций.
Неверная предпосылка. Невозможно к примеру оценить прелесть наличия transparent proxy без рассмотрения ремоутинга, рефлекшена или автоматической сериализации без соответствующих кусков рантайма.
AVK>>Я все таки не могу понят что ты от меня хочешь.
dad>т.е. при таком подходе тут преимущество .net в том, что оно позволяет быстро и удобно разрабатывать клиента и/или сервера
И это тоже.
dad> (т.е. преимущества как удобной библиотеки в ущерб некотрой производительности).
Почему в ущерб производительности?
dad>а какие преимущества она дает при разработке распределенных систем .net<->.net ?
Это очень общий вопрос — ответ на него это большая статья
Здравствуйте, dad, Вы писали:
AVM>>2. Для управления работой бизнес-логики используем app server, например jboss, не подходит jboss на http://www.theserverside.com/reviews/matrix.jsp можно подобрать другой, соответственно для реализации бизнес-логики используем EJB.
dad>tomcat
Tomcat это jsp/servlet container, кстати он входит в JBoss 3.2.2.
Можно отказатся от использования EJB и реализовать бизнес-логику под управлением Tomcat. Остальные части системы при этом не будут значительно измененены.
AVM>>3. С клиентами интереснее. Первый вариант кросплатформенный web клиент — с ним будем работать из IE (windows) и, например Mozilla (*nix). Динамику в HTML делаем через DOM (http://www.w3c.org/DOM/). Серверная часть реализуется на jsp/servlets под управлением app-сервера.
dad>or xforms engine
конечно, а еще можно Java server faces, MVC на Struts и многое другое.....
Если кому то нравится на php или perl писать — нет проблем.
У тебя всегда есть свобода выбора.
AVM>>Второй вариант клиент только для windows — используем Delphi, быстро дешево, красиво, функционально.
dad>and dcom/corba gateaway
IMHO corba тяжеловата будет, а с dcom в свое время навозился и теперь стараюсь его не использовать.
AVM>>6. Для хранения данных используем Firebird SQL server (www.ibase.ru) — IMHO очень хороший версионник, если объем данных и нагрузка очень большая — IMHO придется потратиться на Oracle. Он же пригодится и для OLAP (если OLAP конечно нужен).
dad>можнои и sql lite ибо клиент все равно один
sql lite = MS SQL ?
Здравствуйте, DarkGray, Вы писали:
DG>Здравствуйте, AVM, Вы писали:
DG>>>4. оптимизировать стоимость хранения бензина (хранить только столько, сколько необходимо)
AVM>>3 и 4. IMHO, если я правильно понял это бизнес-задачи, будем решать их на уровне бизнес-логики.
DG>Совсем согласен, кроме 4 пункта. DG>4 пункта — это не бизнес логига, это вычислительная задача: необходимо перебрать варианты, найти оптимум и т.д. DG>и на скриптах такая задача не сделается.
ОК, если это вычислительная задача и ее никто до нас не решал, пишем на C/C++, и подключим ее к серверу через JNI.
AVM>>>Второй вариант клиент только для windows — используем Delphi, быстро дешево, красиво, функционально.
dad>>and dcom/corba gateaway AVM>IMHO corba тяжеловата будет, а с dcom в свое время навозился и теперь стараюсь его не использовать.
для коннекта к серверу я имел ввиду в связке дельфи-ява dcom -> corba мост
dad>>можнои и sql lite ибо клиент все равно один AVM>sql lite = MS SQL ?
нет, в зависимости от задач sqllite — просто быстре , меньше, и проще
короче сутьв том, что ты все едлаешь своими руками и собираешь из того что есть и доступно использую лучшие стороны того или иного продукта, а не "все в одном"
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, dad, Вы писали:
AVM>>>2. Для управления работой бизнес-логики используем app server, например jboss, не подходит jboss на http://www.theserverside.com/reviews/matrix.jsp можно подобрать другой, соответственно для реализации бизнес-логики используем EJB.
dad>>tomcat
AVK>Это не EJB-сервер, а всего лишь JSP.
Если быть точнее он поддерживает Servlet 2.3 and JSP 1.2 specifications (их можно найти на java.sun.com)
C уважением,
AVM
PS: JSP/Servlet это несколько большее чем ASP на IIS.
dad>короче сутьв том, что ты все едлаешь своими руками и собираешь из того что есть и доступно использую лучшие стороны того или иного продукта, а не "все в одном"
все делать руками — не эффективно.
если есть вещи, которые уже написаны я с удовольствием их использую
естественно стараюсь выбирать то, что позволяет решить поставленную задачу эффективно
при этом я хочу иметь свободу выбора,
IMHO вполне хватает того, что требует заказчик, и мне не всегда бывают понятны некоторые требования одного из производителей средств разработки.
Если сможешь, объясни мне почему для того что бы почитать MSDN 2003 мне необходимо поставить IE 6 ?, почему я не могу тоже самое делать с IE 5.x ?
Здравствуйте, AVM, Вы писали:
AVK>>Это не EJB-сервер, а всего лишь JSP. AVM>Если быть точнее он поддерживает Servlet 2.3 and JSP 1.2 specifications (их можно найти на java.sun.com)
А если быть совсем точным. то надо бы и версию сервера указать.
AVM>C уважением, AVM>AVM AVM>PS: JSP/Servlet это несколько большее чем ASP на IIS.
M>>>>Здрасте! IA64 отличается от x86 просто совершенно. Вообще, совсем другой процессор. ГВ>>>Ды на здоровье. M>>Значит всё-таки есть переносимость? ГВ>Нет, есть неправомерное обобщение.
Это наезд или раскаяние?
Я, кажется, не утверждал, что есть какая-то существенная переносимость.
ГВ>OK, значит, я был не прав.
M>>Я думаю, .NET вряд ли скоро будет портирован на эту платформу в достаточном для серверов, коммерческом качестве. Это достаточно большой объём работы. ГВ>А может быть и прав...
Ты был неправ, если считал дотнет игрушкой. Но, конечно, на серверном рынке это ещё не ровня Яве.
ГВ>Но для Юникса есть Оракул и другие базы. Что-то мне всё время пдсказывает, что не очень уж .Net на Unix приживётся. Хотя кто его знает...
Я тоже так думаю. Микрософту он там не особо нужен, а Open Source любит заниматься фигнёй и затягивать сроки.
ГВ> Нет уж... "единой ОС на всех" в обозримом будущем не предвидится. Как и единого средства разработки.
Микрософт лезет на серверный рынок, потихоньку но лезет. За дальнее будующее бесполезно гадать, а в ближайшие несколько лет, конечно, всё останется как есть. Юникс будет однозначно править в своей парафии.
ГВ>>>Просто они работают в коммуникационной среде — всяческие Sessions тому подтверждением.
M>>Ну так это же разные вещи! SQL Server тоже работает в комуникационной среде. Но SQL Server — это слой данных, как ни крути. ГВ>Ну... это ты загнул, ИМХО. Я бы сказал, что интерфейсы SQL-сервера работают в коммуникационной среде.
Точно! И у ASP/JSP есть интерфейсы в коммуникационной среде.
Кстати о сессиях. Ты наверное заметил, что сессии есть и в SQL и в ASP/JSP.
M>>Так и ASP/JSP — слой представления. ГВ>Да, вобщем-то верно.
ГВ>Т.е., остаётся только примитивная в сущности функциональность генерации текстовой размеки в ответ на Http-request. Оговорюсь, что "примитивная" не значит — плохая, а значит — простая и понятная.
Ну это уже начинает напоминать тот флейм про plaintext. Текст это ведь не синоним простоты, да?
Конечно, HTML не содержит непечатных символов и кракозябр. Но сделать толковую страничку от этого не намного проще, чем в Windows Forms или что там в Яве вместо этого используется. Сдаётся мне, ты слишком свысока смотришь на программистов из чужих отраслей.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, AVM, Вы писали:
AVK>>>Это не EJB-сервер, а всего лишь JSP. AVM>>Если быть точнее он поддерживает Servlet 2.3 and JSP 1.2 specifications (их можно найти на java.sun.com)
L>А если быть совсем точным. то надо бы и версию сервера указать.
Извини, исправлюсь
For the impatient, current Tomcat production quality releases vs. Servlet/JSP specifications:
Servlet/JSP Spec Tomcat version
2.4/2.0 5.0.16
2.3/1.2 4.1.29
2.2/1.1 3.3.1a
AVM>все делать руками — не эффективно. AVM>если есть вещи, которые уже написаны я с удовольствием их использую AVM>естественно стараюсь выбирать то, что позволяет решить поставленную задачу эффективно
руками я имею виду увязывать. когда делаешь руками — понимаешь что делаешь.
AVM>Если сможешь, объясни мне почему для того что бы почитать MSDN 2003 мне необходимо поставить IE 6 ?, почему я не могу тоже самое делать с IE 5.x ?
мне тоже не понятно, как и не понятноп очему теряются все настройки при переустановки ие, почему виндовс все время просит перезагружаться, почему я не могу настройки взять файл просто и пенести на другую машину (на рабоут например)
и т.д. и т.п. объясни мне почему что бы использовать янус мне нужно поставить framework 1.1.
потому что подход такой к разработке программ "все в одном"
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, AVM, Вы писали:
AVM>>PS: JSP/Servlet это несколько большее чем ASP на IIS.
AVK>Это несколько меньше.
Андрей, если ты опубликуешь ссылку по которой широкая общественность сможет ознакомится со спецификацией на Active Server Pages и назовешь 10 различных производителей, которые реализовали эту спецификацию в своих продуктах, я безоговорочно соглашусь с тобой без обсуждения технических деталей
Здравствуйте, AVM, Вы писали:
AVK>>Это несколько меньше.
AVM>Андрей, если ты опубликуешь ссылку по которой широкая общественность сможет ознакомится со спецификацией на Active Server Pages и назовешь 10 различных производителей, которые реализовали эту спецификацию в своих продуктах, я безоговорочно соглашусь с тобой без обсуждения технических деталей
Гы. Следуя такой логике несложно придти к выводу, что Oracle -- полное г., а вот dbf -- это руль полнейший, т.к. библиотек доступа тьма-тьмущая.
Так что-ли?
ГВ>А я тебя понял так, что серверные объекты ездят полностью
Серверные объекты ездят в виде ObjRef. Грубо говоря, текстовый id, в котором сохранёно название класса и библиотеки.
По приезду на клиент, для такого объекта создаётся прокси. Прокси — это внутренняя системная сущность, которая "прикидывается" каким-то существующим на клиенте типом. То есть, на самом деле этот объект методы все делегирует на сервер, но для клиентов выглядит как объект некоторого конкретного типа (не интерфеса!).
Причём, тип на сервере и на клиенте может не совпадать.
При вызове любого метода этого объекта, начинает работать прокси. Код из "маскировочного" типа не выполняется аж нiяк.
Есть ещё другой вариант, передача by value. При этом объект передаётся без всякой связи с сервером. Вот как есть, все его поля сериализуются и в XML или в бинарном виде уходят к клиенту.
Если среди полей есть MarshalByRef, значение этого поля уже передаётся по ссылке.
Здравствуйте, AVM, Вы писали:
AVK>>Это несколько меньше.
AVM>Андрей, если ты опубликуешь ссылку по которой широкая общественность сможет ознакомится со спецификацией на Active Server Pages и назовешь 10 различных производителей, которые реализовали эту спецификацию в своих продуктах, я безоговорочно соглашусь с тобой без обсуждения технических деталей
ASP.NET. А при чем здесь количество производителей? Речь то о томкете.
DG>>>>4. оптимизировать стоимость хранения бензина (хранить только столько, сколько необходимо) ГВ>>>Это — расчёты. Не смертельно сложные, алгоритмика вполне доступна непуганому технологиями студенту 3-4 курса. Язык — скорее всего C++ из-за развитых шаблонов. Собственно, с моей стороны это только предположения — какими выполняется оценка? DG>>Т.е. опять велосипед изобретается? ГВ>А где гарантия, что я найду в обозримый срок нужные мне библиотеки?
Задачи делятся на стандартные и нестандартные. Причем стандартных задач в программе обычно процентов 80.
Стандартные задачи сделаны уже кем-то с очень высокой долей вероятности, и есть вероятность, что эта стандартная задача уже была оформлена в виде библиотеки.
Это справедливо и для .Net-а, и для C++, но C++ — библиотеки намного сложнее redistribute-итировать, их намного сложнее подключать.
Поэтому и вероятность того, что разработчики все-таки оформили уже сделанную задачу в виде библиотеки — много ниже. Поэтому в целом, Native-ных библиотек много меньше, чем .Net-ных. Причем — C++ лет 20 уже, а .Net-у — 3 года.
DG>>>>4. оптимизировать стоимость хранения бензина (хранить только столько, сколько необходимо) ГВ>>>Это — расчёты. Не смертельно сложные, алгоритмика вполне доступна непуганому технологиями студенту 3-4 курса. Язык — скорее всего C++ из-за развитых шаблонов. Собственно, с моей стороны это только предположения — какими выполняется оценка? DG>>Т.е. опять велосипед изобретается? ГВ>А где гарантия, что я найду в обозримый срок нужные мне библиотеки?
Поискал день, поискал два — не нашел, сел и сам написал за месяц велосипед.
Или поискал день, поискал два — нашел, и с экономил месяц.
1. У тебя появляется гибкость: для каких-то задач ты можешь использовать чужие библиотеки, для каких-то задач свои и т.д.
2. Причем что хорошо с чужой библиотекой, это то, что ты освобождаешься от ее сопровождения.
Пример: Gui-библиотека. Одно дело ты ее сам написал, и теперь вынужден постоянно поддерживать ее в актуальном состоянии с новыми версиями WIndows-а, другое дело ты ее купил, и теперь она сама обновляется.
3. Что еще хорошо с библиотеками, это то, что есть большая вероятность, что они уже оттестированы, и большая половина багов и проблем уже вылизана. Со своим велосипедом тебе еще предстоит все это сделать.
DG>>Какая разница ковыряются или нет в коде. ГВ>Большая. В первом случае они могут потребовать от меня тех или иных средств реализации, во втором — нет.
DG>>Главное что ты, изобретая велосипед, теряешь время, тратишь дополнительные деньги заказчика и т.д. ГВ>Ну, это тоже демагогия. Здесь всё определяется готовностью команды к "изобретению" или изучению очередного велосипеда.
Другими словами: ты не уверен, что твоя команда готова к изучению и интегрированию в программу чужих библиотек?
И поэтому вам проще написать свой велосипед?
ps
Команда — это понятие большое. Какая разница для отдельного разработчика: изучать либу из соседнего отдела или от другой фирмы?
pps
Хотя разница есть... Все упирается в "культуру": культура построения библиотек, культура наименования и т.д.
Но вот как раз .Net предоставляет более однородную культуру, поэтому проще интегрировать чужие библиотеки в свой продукт.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, AVM, Вы писали:
AVK>>>Это несколько меньше.
AVM>>Андрей, если ты опубликуешь ссылку по которой широкая общественность сможет ознакомится со спецификацией на Active Server Pages и назовешь 10 различных производителей, которые реализовали эту спецификацию в своих продуктах, я безоговорочно соглашусь с тобой без обсуждения технических деталей
L>Гы. Следуя такой логике несложно придти к выводу, что Oracle -- полное г., а вот dbf -- это руль полнейший, т.к. библиотек доступа тьма-тьмущая. L>Так что-ли?
Нет конечно же не так
Что бы понять логику посмотри с другой точки зрения — есть RDBMS (в том числе и Oracle) — все они в той или иной степени удовлетворяют SQL-92 плюс у каждого производителя есть свои расширения и надстройки.
Если по каким то причинам понадобится я могу перенести хранение данных с Oracle, ну например на DB2 или Caсhe. Придется конечно повозится, но принципиально это возможно.
AVM>>все делать руками — не эффективно. AVM>>если есть вещи, которые уже написаны я с удовольствием их использую AVM>>естественно стараюсь выбирать то, что позволяет решить поставленную задачу эффективно
dad>руками я имею виду увязывать. когда делаешь руками — понимаешь что делаешь.
да именно так, абсолютно согласен
плюс можно посмотреть исходники для более глубокого понимания
AVM>>Если сможешь, объясни мне почему для того что бы почитать MSDN 2003 мне необходимо поставить IE 6 ?, почему я не могу тоже самое делать с IE 5.x ?
dad>мне тоже не понятно, как и не понятноп очему теряются все настройки при переустановки ие, почему виндовс все время просит перезагружаться, почему я не могу настройки взять файл просто и пенести на другую машину (на рабоут например) и т.д. и т.п. объясни мне почему что бы использовать янус мне нужно поставить framework 1.1.
framework 1.1 — это в Net аналог jre ?
честно признаюсь — с Net дела не имел... думаю через полгодика восполнить этот пробел
dad>потому что подход такой к разработке программ "все в одном"
"все в одном" — IMHO это нормальный подход только в том случае если из этого "всего" можно выделить какую то часть и заменить на известный аналог, сохраняя при этом работоспособность "всего",
вообще хорошо если это "все" имеет аналоги других производителей, ну а если спецификации на это "все" открыты — это просто замечательно
С уважением,
AVM
PS: на прошлой неделе ставил IE 6 на win 98 — так в процессе установки он раз 5-6 ломился в инет — что ему там надо было и почему он мне ничего не сказал, если ему что то надо ?
похоже что умный он слишком — пользователь ему не нужен
хъ
AVM>Нет конечно же не так AVM>Что бы понять логику посмотри с другой точки зрения — есть RDBMS (в том числе и Oracle) — все они в той или иной степени удовлетворяют SQL-92 плюс у каждого производителя есть свои расширения и надстройки. AVM>Если по каким то причинам понадобится я могу перенести хранение данных с Oracle, ну например на DB2 или Caсhe. Придется конечно повозится, но принципиально это возможно.
dad>>руками я имею виду увязывать. когда делаешь руками — понимаешь что делаешь. AVM>да именно так, абсолютно согласен AVM>плюс можно посмотреть исходники для более глубокого понимания
а я изначально с тобйо соглашался ты недопонял меня просто.
dad>>мне тоже не понятно, как и не понятноп очему теряются все настройки при переустановки ие, почему виндовс все время просит перезагружаться, почему я не могу настройки взять файл просто и пенести на другую машину (на рабоут например) и т.д. и т.п. объясни мне почему что бы использовать янус мне нужно поставить framework 1.1. AVM>framework 1.1 — это в Net аналог jre ? AVM>честно признаюсь — с Net дела не имел... думаю через полгодика восполнить этот пробел
да нет это я вот к этому:
AVM>PS: на прошлой неделе ставил IE 6 на win 98 — так в процессе установки он раз 5-6 ломился в инет — что ему там надо было и почему он мне ничего не сказал, если ему что то надо ? AVM>похоже что умный он слишком — пользователь ему не нужен
дело в том, что сама стилистика программирования windows такова. все к этому располагает — и продвижение таких продуктов как vb, и создание интерфеса мышкой, и даже vcl все способствует написанию программ в которых вставка в БД происходит в обработчике нажатия кнопки. почему такое происходит отдельная тема. ябы не доускал до разработки gui пока весь севт не будет делать все что задумано в коммандной строке и с помощью конф. файлов. тогда мы будем иметь продкты вроде миранды или мозилы (скопировал и работай)
dad>>потому что подход такой к разработке программ "все в одном" AVM>"все в одном" — IMHO это нормальный подход только в том случае если из этого "всего" можно выделить какую то часть и заменить на известный аналог, сохраняя при этом работоспособность "всего",
да. это нормальный академический подход — отдельно спецификация отдельно реализация. но похоже именно в .net все с этим в порядке (в функционале который он реализует)
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
DG>>>А как связываетесь? Голые сокеты?
dad>>голые сокеты ну ты дал. сначала были голые сокеты а потом пригло .net!
DG>Ты не ерничай, а пальцем покажи. Ерничать мы все умеем, а как что-то полезное сказать, так в кусты.
а куда ты смотрел когда мы обсуждали soap|wdsl/xml-rpc ? dcom-corba bridge и еще там что то
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, mikа, Вы писали:
M>Я не говорю, что все нужно писать на Нете. Низкоуровневое, как заметил Геннадий, нужно писать на Нете. К сожалению, я не по этой части. Но тут с ним согласен. В остальном же, .NET — это реальный выигрыш. Тат что тут криминального, если я хочу упростить решение задачи?
Согласен
is>>Разъясни, пожалуйста, если я чего-то не понимаю. .NET — это самая прогрессивная технология на данный момент, которой в большинстве случаев, нет альтернативы?
M> Есть. Но альтернатива состоит из совокупности. А .NET один. Тоесть, лучше использовать один язык программирования, к которому ты привык за долгие годы, и которые сможет так же легко реализовать задачу, как альтернативное средство во всех сферах, чем питаться сборной солянкой.
Ну, шарп пока не претендует на язык, к "которому ты привык за долгие коды". В остальном же согласен.
M>Геннадий предлагаем нам супчик
Иногда просто не может быть по-другому, когда часть системы уже написана и нормально функционирует. Трудно объяснить заказчику, зачем он должен платить свои деньги за переписывание этих частей (не важно с использованием чего они реализованы, важно — что они работают). Придется варить супчик.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, dad, Вы писали:
dad>А это похоже на академический консерватизм
Не знаю, допускаю, что похоже. Но я пока задаю вопросы. А в .net мне, прежде всего, не нравится жесткий маркетинг (т.е. это не сам .нет, а то, что ему сопутствует) — это настораживает.
Кстати, интересно узнать список продуктов Майкрософт, которые уже выпущены, с использованием платформы .net.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, mikа, Вы писали:
is>>Похоже на юношеский максимализм, не находишь?
M>Полегче на поворотах.
Извини, если обидел. Целью моего высказывания было подчеркнуть лишь бросившуюся мне в глаза и, возможно, кажущуюся категоричность твоих заявлений.
M>Если тебе не нравиться дискуссия — не читай ее.
Естественно
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, is, Вы писали:
is>Не знаю, допускаю, что похоже. Но я пока задаю вопросы. А в .net мне, прежде всего, не нравится жесткий маркетинг (т.е. это не сам .нет, а то, что ему сопутствует) — это настораживает.
is>Кстати, интересно узнать список продуктов Майкрософт, которые уже выпущены, с использованием платформы .net.
Кстати как-то где-то прочитал один интересный факт, что sun не выпустила ни одного коммерческого продукта, написанного на java.
DG>>Ты не ерничай, а пальцем покажи. Ерничать мы все умеем, а как что-то полезное сказать, так в кусты.
dad>а куда ты смотрел когда мы обсуждали soap|wdsl/xml-rpc ? dcom-corba bridge и еще там что то
Одно дело что-то обсуждать, вообще. Другое дело — что предлагается использовать в данном конкретном случае: Java Server <-> Delphi client.
DG>>>Ты не ерничай, а пальцем покажи. Ерничать мы все умеем, а как что-то полезное сказать, так в кусты.
dad>>а куда ты смотрел когда мы обсуждали soap|wdsl/xml-rpc ? dcom-corba bridge и еще там что то
DG>Одно дело что-то обсуждать, вообще. Другое дело — что предлагается использовать в данном конкретном случае: Java Server <-> Delphi client.
А мы, разве, говорим о каком то конкретном проекте? тогда извини. (голые сокеты не подходят скорее всего, согласен)
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
dad>Я видел текст (года два назад) в ктором всерьез утверждалось, что в скором времени вся инфраструктура Internet (интернет) будет функционаировать на .Net!!!
ГВ>1. .Net более всего подходит для построения коммуникационных инфраструктур.
ГВ>2. Не всякая программа (в т.ч. и серверная) лучше всего реализуется средствами, ориентированными на построение коммуникаций.
Итак, после добавления в пункт 1 ещё и User Interface, ситуация сильно накренилась.
Много ли программ, которые занимаются и не коммуникациями и не UI? Видимо, в основном — сервера БД и бизнес логика.
Хотя с той же бизнес-логикой тоже не всё чисто. Чем плох дотнет на уровне бизнес-логики? Ява вон катит.
Ну а насчёт всего остального моря разливанного — законная вотчина дотнета.
Клепаете формочки для клиентов? Дотнет.
Хитроумные интерактивные отчёты для анализа? Дотнет.
Пишете какой-нибудь сервис сбора биржевых котировок? Дотнет.
Браузер/майлер — явный дотнет.
Офисный пакет — опять дотнет, куда ж без него.
Здравствуйте, Lloyd, Вы писали:
L>Кстати как-то где-то прочитал один интересный факт, что sun не выпустила ни одного коммерческого продукта, написанного на java.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Пока я и сам не определился с этим однозначно. В основном — из-за пресловутого недетерминированного удаления AVK>Вот как раз детерминированное удаление очень часто в серверах приложений зло.
Э... я уже давно тут предлагал форум по App-серверам сделать. Там бы и пободались.
ГВ>> и отсутсвия шаблонов, AVK>Это не цель, это всего лишь средство. ГВ>> а мне они ох как нужны. МН тоже не хватает — весьма полезная штука на системном уровне. AVK>То же самое.
Да, конечно не цель, но от этих средств очень не хочется отказываться.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, dad, Вы писали:
dad>Я видел текст (года два назад) в ктором всерьез утверждалось, что в скором времени вся инфраструктура Internet (интернет) будет функционаировать на .Net!!!
Маркетинг, друже, маркетинг. "Огонь и движение".
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
DG>>>Согласись с тем, что .Net еще более декларативная система, чем C++, благодаря аттрибутам и метаданным. ГВ>>Нет, с этим не соглашусь.
DG>Приведи, плиз, пример, из которого видно, что с++ более декларативная система, чем .Net
Я понял, что ты меня сбил с толку, но не сразу просёк — когда именно. Извии, исправляюсь.
Давай, сначала определимся с критериями оценок "более" и "менее" относительно декларативности. Что значит "более декларативная"?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mihailik, Вы писали:
M>>>>>Здрасте! IA64 отличается от x86 просто совершенно. Вообще, совсем другой процессор. ГВ>>>>Ды на здоровье. M>>>Значит всё-таки есть переносимость? ГВ>>Нет, есть неправомерное обобщение. M>Это наезд или раскаяние?
Это — констатация.
M>Я, кажется, не утверждал, что есть какая-то существенная переносимость.
А... ну извини. Так бы сразу и сказал, что существенной переносимости нет и закрыли бы тему сразу.
ГВ>>OK, значит, я был не прав. M>>>Я думаю, .NET вряд ли скоро будет портирован на эту платформу в достаточном для серверов, коммерческом качестве. Это достаточно большой объём работы. ГВ>>А может быть и прав... M>Ты был неправ, если считал дотнет игрушкой. Но, конечно, на серверном рынке это ещё не ровня Яве.
А с чего ты взял, что я считаю его игрушкой?
ГВ>> Нет уж... "единой ОС на всех" в обозримом будущем не предвидится. Как и единого средства разработки. M>Микрософт лезет на серверный рынок, потихоньку но лезет. За дальнее будующее бесполезно гадать, а в ближайшие несколько лет, конечно, всё останется как есть. Юникс будет однозначно править в своей парафии.
А куда он денется? Всё, ладно, давай завяжем с этой темой.
ГВ>>>>Просто они работают в коммуникационной среде — всяческие Sessions тому подтверждением. M>>>Ну так это же разные вещи! SQL Server тоже работает в комуникационной среде. Но SQL Server — это слой данных, как ни крути. ГВ>>Ну... это ты загнул, ИМХО. Я бы сказал, что интерфейсы SQL-сервера работают в коммуникационной среде. M>Точно! И у ASP/JSP есть интерфейсы в коммуникационной среде.
Угу. И только для них они и предназначены.
M>Кстати о сессиях. Ты наверное заметил, что сессии есть и в SQL и в ASP/JSP.
Верно, только замечу, что правильный перевод этого слова — "сеанс". Конечно, в коммуникациях это обычное понятие: сеанс связи, интерактивный сеанс и т.п.
M>>>Так и ASP/JSP — слой представления. ГВ>>Да, вобщем-то верно. ГВ>>Т.е., остаётся только примитивная в сущности функциональность генерации текстовой размеки в ответ на Http-request. Оговорюсь, что "примитивная" не значит — плохая, а значит — простая и понятная. M>Ну это уже начинает напоминать тот флейм про plaintext. Текст это ведь не синоним простоты, да? M>Конечно, HTML не содержит непечатных символов и кракозябр. Но сделать толковую страничку от этого не намного проще, чем в Windows Forms или что там в Яве вместо этого используется.
Нет, вовсе даже без "свысока". Я вроде бы ничего не говорил, например, о сложностях адекватного дизайна HTML-страниц.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mihailik, Вы писали:
ГВ>>1. .Net более всего подходит для построения коммуникационных инфраструктур. ГВ>>2. Не всякая программа (в т.ч. и серверная) лучше всего реализуется средствами, ориентированными на построение коммуникаций. M>Итак, после добавления в пункт 1 ещё и User Interface, ситуация сильно накренилась.
User Interface бывает разным, так что, ИМХО, здесь обобщать не стоит. Вроде бы .Net могучих обобщённых графических библиотек как-то не содержит.
M>Много ли программ, которые занимаются и не коммуникациями и не UI? Видимо, в основном — сервера БД и бизнес логика.
Мда... любопытное обобщение.
M>Хотя с той же бизнес-логикой тоже не всё чисто. Чем плох дотнет на уровне бизнес-логики? Ява вон катит.
Допустим... Пока что.
M>Ну а насчёт всего остального моря разливанного — законная вотчина дотнета.
Что-то у тебя мелковато море-то получилось.
M>Клепаете формочки для клиентов? Дотнет.
С этим вобщем-то согласен.
M>Хитроумные интерактивные отчёты для анализа? Дотнет.
Да ну? Хотя чего это я? Их ведь иногда можно и на ASP делать. Проверено. И тоже — аналитические.
M>Пишете какой-нибудь сервис сбора биржевых котировок? Дотнет.
Хммм... ты себе представляшь, какими бывают интерфейсы бирж? Я ведь неслучайно DarkGray зацепил по этому поводу относительно бинарных форматов.
M>Браузер/майлер — явный дотнет.
Здрасьте — приехали. Неужто и браузер на .Net уже написали?
M>Офисный пакет — опять дотнет, куда ж без него.
А что, Office'2003 на .Net?
M>Правильно!
Ну, что до "", то оно всегда правильно.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>>>Какая разница ковыряются или нет в коде. ГВ>>Большая. В первом случае они могут потребовать от меня тех или иных средств реализации, во втором — нет. DG>>>Главное что ты, изобретая велосипед, теряешь время, тратишь дополнительные деньги заказчика и т.д. ГВ>>Ну, это тоже демагогия. Здесь всё определяется готовностью команды к "изобретению" или изучению очередного велосипеда.
DG>Другими словами: ты не уверен, что твоя команда готова к изучению и интегрированию в программу чужих библиотек?
Я уверен в том, что для того, чтобы понять, подходит ли найденная библиотека к задаче, нужно проделать работу, сопоставимую с разработкой той части библиотеки, которая содержит нужную мне функциональность. Естественно, что я не имею ввиду библиотеки для well-known tasks, например, библиотеки контролов.
DG>И поэтому вам проще написать свой велосипед?
А если так, то что? Если во многих случаях так поступить — действительно проще?
DG>ps DG>Команда — это понятие большое. Какая разница для отдельного разработчика: изучать либу из соседнего отдела или от другой фирмы?
Вот именно. И если написать библиотеку проще, чем её найти, то...
DG>pps DG>Хотя разница есть... Все упирается в "культуру": культура построения библиотек, культура наименования и т.д. DG>Но вот как раз .Net предоставляет более однородную культуру, поэтому проще интегрировать чужие библиотеки в свой продукт.
И ты хочешь сказать, что если плюсовая библиотека не стыкуется по тем или иным причинам с MC++, то её будет проще подоткнуть к .Net? Самому не смешно? Хотя ты прав в одном — если эти библиотеки будут написаны исключительно средствами .Net то их сопряжение, действительно, должно быть проще.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
ГВ>>Пока я и сам не определился с этим однозначно. ГВ>> В основном — из-за пресловутого недетерминированного удаления DG>Зачем тебе детерминированное удаление? Для удаления ресурсов есть Dispose. Зачем мне Dispose, который неизвестно когда сработает? Мне нужна уверенность в происходящем. А вставлять очистки в блоках finally — нетушки, лучше уж в деструкторах.
ГВ>> и отсутсвия шаблонов, а мне они ох как нужны. DG>А что у вас сейчас делается на шаблонах?
Всё не перечислить. Управление памятью, API, системные структуры (отдельная сага), связь (пока — немного), частично — UI, разные контроллеры ресурсов и т.п. Задач хватает, одним словом. Это очень удобное композиционное средство. И почему только им редко пользуются?
DG>альтернатива: интерфейсы, делегаты.
Да, не спорю. Если бы ещё вычесть отсюда неизбежные оверхеды от такого подхода — цены бы им не было.
ГВ>> МН тоже не хватает — весьма полезная штука на системном уровне. DG>Альтернатива: DG>дробление классов, вынос части функционала в подклассы. DG>подключение реализаций.
Оверхеды, оверхеды, оверхеды... А потом удивляемся, почему .Net-овские программы порой медленно работают. Вот она — причина.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AVM, Вы писали:
AVM>>>PS: JSP/Servlet это несколько большее чем ASP на IIS. AVK>>Это несколько меньше. AVM>Андрей, если ты опубликуешь ссылку по которой широкая общественность сможет ознакомится со спецификацией на Active Server Pages и назовешь 10 различных производителей, которые реализовали эту спецификацию в своих продуктах, я безоговорочно соглашусь с тобой без обсуждения технических деталей
Коллеги! Вобщем-то тема, конечно, интересная, только давайте завязывать потихоньку с обсуждением "Java vs .Net", а то топик читать становится трудновато.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>>>Т.е. опять велосипед изобретается? ГВ>>А где гарантия, что я найду в обозримый срок нужные мне библиотеки? DG>Это справедливо и для .Net-а, и для C++, но C++ — библиотеки намного сложнее redistribute-итировать, их намного сложнее подключать.
Да, сложнее в чём-то, наверное. Хотя главная проблема это не "просто подцепить", а не нарваться в ближайшей перспективе на какие-нить ошибки дизайна библиотеки.
DG>Поэтому и вероятность того, что разработчики все-таки оформили уже сделанную задачу в виде библиотеки — много ниже. Поэтому в целом, Native-ных библиотек много меньше, чем .Net-ных.
Так... "много" это сколько? Я просто не владею статистикой по библиотекам "в целом" по C++ и .Net. Не представишь доказательств своих суждений?
DG>Причем — C++ лет 20 уже, а .Net-у — 3 года.
Стандарту C++ всего-то около 6 лет, а компиляторы подтянулись только-только.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>>>>>4. оптимизировать стоимость хранения бензина (хранить только столько, сколько необходимо) ГВ>>>>Это — расчёты. Не смертельно сложные, алгоритмика вполне доступна непуганому технологиями студенту 3-4 курса. Язык — скорее всего C++ из-за развитых шаблонов. Собственно, с моей стороны это только предположения — какими выполняется оценка? DG>>>Т.е. опять велосипед изобретается? ГВ>>А где гарантия, что я найду в обозримый срок нужные мне библиотеки?
DG>Поискал день, поискал два — не нашел, сел и сам написал за месяц велосипед. DG>Или поискал день, поискал два — нашел, и с экономил месяц.
Или поискал неделю, потом два дня подключал, потом спустя месяц выяснил, что не хватает чего-то очень важного. Аргумент?
DG>1. У тебя появляется гибкость: для каких-то задач ты можешь использовать чужие библиотеки, для каких-то задач свои и т.д.
Ага. Верю. Особенно если и те и те с похожим интерфейсом. Притом под "интерфейсом" я понимаю как API, так и, например, порядок вызовов инициализации, основные схемы работы с библиотеками и т.п.
DG>2. Причем что хорошо с чужой библиотекой, это то, что ты освобождаешься от ее сопровождения.
Угу, т.е., практически не управляю её глюкавостью (если она не OpenSource), тогда как со своей я могу делать ровно всё что хочу.
DG>Пример: Gui-библиотека. Одно дело ты ее сам написал, и теперь вынужден постоянно поддерживать ее в актуальном состоянии с новыми версиями WIndows-а, другое дело ты ее купил,
Да, поддерживать в актуальном состоянии относительно Windows в принципе, нужно. Но гораздо важнее, чтобы поддерживалась актуальность библиотек относительно решаемых мною задач и моего их понимания.
DG> и теперь она сама обновляется.
Такой большой, а в сказки веришь. Извини. Это — мечты. Фирма-поставщик может точно также, как и любая другая просто бросить поддержку или развалиться нафиг.
DG>3. Что еще хорошо с библиотеками, это то, что есть большая вероятность, что они уже оттестированы, и большая половина багов и проблем уже вылизана. Со своим велосипедом тебе еще предстоит все это сделать.
Демагогия, разумеется. Опять — что значит "большая"? "Некоторая" — соглашусь. Но не факт, что они оттестированы в необходимой мне степени.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Извини, только сейчас заметил, что не ответил на сообщение полностью.
[skip то, на что уже ответил]
DG>>>throw ведь могут быть и не явными. Могут быть из-за каких-то ошибок программиста, но пользователю-то будет от этого не легче. ГВ>>А не вызывать в деструкторе потенциально опасный код — это из области фантастики? DG>В некотором смысле — да, это из области фантастики. В деструкторах обычно идет зачистка ресурсов, например, закрываем соединения, файлы и т.д.
И да и нет — смотря в деструкторах чего.
DG>И кто сказал, что это соединение, например, не было уже убито кет-то снаружи — сеть например отвалилась.
Да, но ресурсы, связанные с этим соединением, должны быть детерминированно освобождены, когда удаляем зависший сеанс.
DG>В конце концов, может просто кончится память или из-за глубокой ошибки программиста, произойти обращение по нулевому указателю. В любой программе есть некий процент ошибок.
Это на сегодняшний день везде возможно.
DG>Или ты предлагаешь в любой деструктор обязательно дописывать try/catch? Неплохо бы, но можно обойтись и без такого экстрима.
DG>>>Например, тебе нужно простыковатся с банковской системой, или с товарной системой твоего партнера. ГВ>>Что за интерфейсы? И у той и у той системы. Какова их сложность? Какая прикладная структура отображается интерфейсами? DG>У одних честный Web services, у других некий свой протокол, но они готовы дать исходники клиента, написанного на Java.
Там видно будет — может быть, лучше спецификацию протокола запросить.
DG>>>И то, и другое уже написано, вложена куча денег, и если ты будешь пытатся навязывать жесткие ограничения на используемый компилятор, на используемый язык, то тебя просто пошлют. ГВ>>Странно, если это отделы — то как это "пошлют"? DG>Это реальная жизнь. У них свои мысли, идеи и т.д. Не хватит духу послать открыто, будут посылать скрытно, вставляя палки в колеса.
Странно немного. Может, мне просто не приходилось сталкиваться с таким явлением. Компромисс, как-то обычно обнаруживался...
ГВ>> А если сторонние фирмы — то это моё дело, соглашаться на их "пошлют" или менять условия. DG>Сторонних фирм же тоже конечное число.
Но и ресурсы команды тоже не резиновые.
DG>Тем более можно вспомнить один из законов кибернетики: системой управляет самый гибкий ее элемент.
Интересно... На C (даже не C++) можно связаться с кем угодно, включая .Net и ещё невесть что. Вывод?
DG>.Net, в отличии от C++, предоставляет большую гибкость: развязка между языками, развязка на уровне бинарников, развязка на уровне менеджера памяти, развяка на уровне метаданных о коде и т.д.
Бррр... сколько "развязок". Присоединюсь к dad: а что это такое? ИМХО, только общие метаданные и всё, вобщем-то.
ГВ>>Ладно, понял, похоже, что вы ещё не вошли в стадию, когда желание развития своих идей превалирует над внешними условиями. DG>Не понял данную ремарку.
Ну и ладно.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
is>>Кстати, интересно узнать список продуктов Майкрософт, которые уже выпущены, с использованием платформы .net.
AVK>VS.NET. Какие то части вроде есть в BizTalk 2004. В следующем году будет Юкон. Ну и конечно лонгхорн.
А Юкон разве с использованием .Net написан? AFAIK, он просто с ним интегрирован.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
dad>>дело в том, что сама стилистика программирования windows такова
M>Это уже чистой воды религиозные войны. Ни уму ни сердцу
M>Можно обсуждать какие-то конкретные свойства, можно учиться друг у друга. Но всякие бестолковые наезды на идеологию вообще... На фиг оно нужно
нет — это форум "философия программирования" я вот о философии и говорю — мощный маркетинг и "все в одном" стимулирует именно такое программирование "все в одном" . + различные "автокодогенераторы" "консруткотры" "визарды" и языки
привлекают самоучек. лучше не знать всех особенностей (больешй части) инстурмента и использовать минимум но _грамотно_
я даже попозже голосовало сделаю.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Здравствуйте, AVM, Вы писали:
AS>хъ
AVM>>Нет конечно же не так AVM>>Что бы понять логику посмотри с другой точки зрения — есть RDBMS (в том числе и Oracle) — все они в той или иной степени удовлетворяют SQL-92 плюс у каждого производителя есть свои расширения и надстройки. AVM>>Если по каким то причинам понадобится я могу перенести хранение данных с Oracle, ну например на DB2 или Caсhe. Придется конечно повозится, но принципиально это возможно.
AS>Ты лучше скажи прямо, делал ли ты такое или нет?
Делал IB->Oracle. Если в БД изначально не закладывалась реализация бизнес-логики — переносится с пол пинка, DDL и DML в известных мне RDBMS почти совпадает. Есть небольшие ньюансы с переносом constraints и тп.
Если бизнес-логика закладывалась в БД — тут дело намного сложнее и переход на другую RDBMS/ORDBMS может себя не оправдать, но повторюсь — принципиально это возможно.
Еще заметь такую вещь, при переходе с одной субд на другую (если это не mssql), я могу оставить ту же программно/аппаратную платформу. Ведь кроме wintel — есть и много других платформ.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, AVM, Вы писали:
AVK>>>Это несколько меньше.
AVM>>Андрей, если ты опубликуешь ссылку по которой широкая общественность сможет ознакомится со спецификацией на Active Server Pages и назовешь 10 различных производителей, которые реализовали эту спецификацию в своих продуктах, я безоговорочно соглашусь с тобой без обсуждения технических деталей
AVK>ASP.NET. А при чем здесь количество производителей? Речь то о томкете.
Когда я писал
PS: JSP/Servlet это несколько большее чем ASP на IIS.
имелись ввиду технологии а не конкретные продукты
IIS назван потому что, я например себе не представляю, кто кроме IIS поддерживает ASP в полном объеме и в какой еще OS, кроме windows, это может работать
Здравствуйте, dad, Вы писали:
DG>>>>Ты не ерничай, а пальцем покажи. Ерничать мы все умеем, а как что-то полезное сказать, так в кусты.
dad>>>а куда ты смотрел когда мы обсуждали soap|wdsl/xml-rpc ? dcom-corba bridge и еще там что то
DG>>Одно дело что-то обсуждать, вообще. Другое дело — что предлагается использовать в данном конкретном случае: Java Server <-> Delphi client.
dad>А мы, разве, говорим о каком то конкретном проекте? тогда извини. (голые сокеты не подходят скорее всего, согласен)
Как говорил один известный персонаж, Ребята давайте жить дружно
В конце концов HTTP тоже ходит по голым сокетам и нам от них никуда не дется.
А если серьезно в Delphi 7 (на счет 6 не уверен) есть класс THTTPRIO, который позволяет работать с удаленным объектом через протокол SOAP.
Так же в Delphi есть простенький wizard, который позволяет по wsdl сгенерировать delphi-клиента для web-сервиса.
Большие объемы данных не гоняли, несовместимостей со спецификацией SOAP не нашел.
На стороне сервера стоит Axis 1.1, который работает под управлением JBoss 3.2.2
dad>>>руками я имею виду увязывать. когда делаешь руками — понимаешь что делаешь. AVM>>да именно так, абсолютно согласен AVM>>плюс можно посмотреть исходники для более глубокого понимания
dad>а я изначально с тобйо соглашался ты недопонял меня просто.
да наверное не допонял, зато теперь нашли взаимопонимание
dad>>>мне тоже не понятно, как и не понятноп очему теряются все настройки при переустановки ие, почему виндовс все время просит перезагружаться, почему я не могу настройки взять файл просто и пенести на другую машину (на рабоут например) и т.д. и т.п. объясни мне почему что бы использовать янус мне нужно поставить framework 1.1. AVM>>framework 1.1 — это в Net аналог jre ? AVM>>честно признаюсь — с Net дела не имел... думаю через полгодика восполнить этот пробел
dad>да нет это я вот к этому:
AVM>>PS: на прошлой неделе ставил IE 6 на win 98 — так в процессе установки он раз 5-6 ломился в инет — что ему там надо было и почему он мне ничего не сказал, если ему что то надо ? AVM>>похоже что умный он слишком — пользователь ему не нужен
dad>дело в том, что сама стилистика программирования windows такова. все к этому располагает — и продвижение таких продуктов как vb, и создание интерфеса мышкой, и даже vcl все способствует написанию программ в которых вставка в БД происходит в обработчике нажатия кнопки. почему такое происходит отдельная тема. ябы не доускал до разработки gui пока весь севт не будет делать все что задумано в коммандной строке и с помощью конф. файлов. тогда мы будем иметь продкты вроде миранды или мозилы (скопировал и работай)
dad>>>потому что подход такой к разработке программ "все в одном" AVM>>"все в одном" — IMHO это нормальный подход только в том случае если из этого "всего" можно выделить какую то часть и заменить на известный аналог, сохраняя при этом работоспособность "всего",
dad>да. это нормальный академический подход — отдельно спецификация отдельно реализация. но похоже именно в .net все с этим в порядке (в функционале который он реализует)
Так это же хорошо.
Если на net будут открытые спецификации (не только на C# но и на API);
будет организация которая будет управлять изменениями этих спецификаций и следить за их соблюдением;
MS, как прородитель Net сделает реализации framework для 5-6 различных операционок, а тем кто захочет сам реализовать FW — раздаст исходники, своих реализаций, чтобы другие могли поучится, как правильно писать;
выступит спонсором в паре-тройке OpenSource проектов
NET тогда цены не будет.
Здравствуйте, mihailik, Вы писали:
AVM>>Если сможешь, объясни мне почему для того что бы почитать MSDN 2003 мне необходимо поставить IE 6 ?, почему я не могу тоже самое делать с IE 5.x ?
M>Вот уж действительно серьёзная проблема!
Здравствуйте, mihailik, Вы писали:
dad>>дело в том, что сама стилистика программирования windows такова
M>Это уже чистой воды религиозные войны. Ни уму ни сердцу
О, где ты увидел религиозных фанатиков — без них как известно ни одна война не начинается?
M>Можно обсуждать какие-то конкретные свойства, можно учиться друг у друга. Но всякие бестолковые наезды на идеологию вообще... На фиг оно нужно
Тут IMHO дело вот в чем:
например берем Delphi(или JBuilder), сажаем "студента", показываем ему основные моменты/компоненты и студент начинает ваять программы, причем обрати внимание не "hello world", а клиент-серверные или многозвенные приложения. Супер!!! При этом студент даже не догадывается, что есть design patterns, MVC и "прочая ерунда".
Если же "студент" попробует написать Swing приложение с нуля, не используя JBuilder и его компоненты, то он практически сразу обнаружит загадочный ActionListener, потом найдет другие DP, а если очень любознателен, то докопается и до GRASP-шаблонов. В процессе он обнаружит что есть UML (без него просто с паттернами не разобратся). После этого, ему как и любому нормальному человеку, надоест все писать руками и он конечно же подберет себе удобную среду разработки (с кодогенерацией, отладчиком, возможно дизайнером UI), но к этому моменту он уже будет понимать как это работает.
Как думаешь более качественный софт получится в первом случае или во втором ?
Насколько я знаю, оба версионники. Если на них еще и ничего кроме голого data storage не висело — задача решаема.
AVM>Если в БД изначально не закладывалась реализация бизнес-логики — переносится с пол пинка, DDL и DML в известных мне RDBMS почти совпадает.
Да? А у меня вот простецкая базенка с 10 таблицами и парой триггеров есть на Оракле. Ты знаешь, меня такая тоска охватывает, при мысли о переносе ее на MSSQL.
У каждой СУБД свой синтаксис, и что намного хуже — семантика.
AVM>Есть небольшие ньюансы с переносом constraints и тп.
А вот это абсолютная не правда. Наоборот, с констрейнтами все класно. Например, fk, pk, check constraint везде имеют обинаковый синтаксис. Например,
--MSSQLcreate table test(i int identity primary key,j int check(j > 10))
AVM>Если бизнес-логика закладывалась в БД — тут дело намного сложнее и переход на другую RDBMS/ORDBMS может себя не оправдать, но повторюсь — принципиально это возможно.
Да нихрена это не возможно!
AVM>Еще заметь такую вещь, при переходе с одной субд на другую (если это не mssql), я могу оставить ту же программно/аппаратную платформу. Ведь кроме wintel — есть и много других платформ.
Про это речь пока не ведется.
AVM>Ты со мной не согласен ?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>User Interface бывает разным, так что, ИМХО, здесь обобщать не стоит. Вроде бы .Net могучих обобщённых графических библиотек как-то не содержит.
Будет содержать. См. Avalon.
M>>Браузер/майлер — явный дотнет. ГВ>Здрасьте — приехали. Неужто и браузер на .Net уже написали?
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>VS.NET. Какие то части вроде есть в BizTalk 2004. В следующем году будет Юкон. Ну и конечно лонгхорн.
ГВ>А Юкон разве с использованием .Net написан?
Да
ГВ> AFAIK, он просто с ним интегрирован.
Нет. На дотнете написан основной тул, дотнет же обеспечивает работу юкона через SOAP.
DG>>>Одно дело что-то обсуждать, вообще. Другое дело — что предлагается использовать в данном конкретном случае: Java Server <-> Delphi client.
dad>>А мы, разве, говорим о каком то конкретном проекте? тогда извини. (голые сокеты не подходят скорее всего, согласен)
AVM>Как говорил один известный персонаж, Ребята давайте жить дружно AVM>В конце концов HTTP тоже ходит по голым сокетам и нам от них никуда не дется.
AVM>А если серьезно в Delphi 7 (на счет 6 не уверен) есть класс THTTPRIO, который позволяет работать с удаленным объектом через протокол SOAP.
Я спросил посему они юзают dcom/corba bridge — на момент создания системы (банковский совт) не было внятной реализации corba для delphi и + тогдащний архитектор не очень то шарил. потом серверная часть была переделана на яву и появился corba bridge (примерно так с чужих слов)
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, Геннадий Васильев, Вы писали:
DG>>Зачем тебе детерминированное удаление? Для удаления ресурсов есть Dispose. ГВ> Зачем мне Dispose, который неизвестно когда сработает? Мне нужна уверенность в происходящем. А вставлять очистки в блоках finally — нетушки, лучше уж в деструкторах.
Гм. Странное заявление. Dispose сработает ровно тогда, когда его вызовут. Ни позже и не раньше.
Да и finally использовать необязательно. Для этого есть using.
M>>Ну а насчёт всего остального моря разливанного — законная вотчина дотнета. M>>Клепаете формочки для клиентов? Дотнет.
dad>это почему?
Потому что клиенты под Windows. Вернее, бывают и не-Windows клиенты, но процент таких мизерный.
А под Windows на чём удобнее всего формы клепать? На Дельфи и на дотнете. Но Дельфи хуже во всём остальном кроме формочек.
M>>Пишете какой-нибудь сервис сбора биржевых котировок? Дотнет. dad>это почему ???
Ну как, это же коммуникации. Геннадий вон тоже говорил, что дотнет для коммуникаций в самый раз подходит.
dad>а это, например:
Да примеров-то много можно на чём сделать. Вопрос в том, на чём дешевле разработка.
M>>Браузер/майлер — явный дотнет.
dad>ого!!
Ну, майлер это ж однозначно коммуникации + UI.
M>>Офисный пакет — опять дотнет, куда ж без него.
dad>что за офисный пакет? (два года использую openoffice)
ГВ>Вроде бы .Net могучих обобщённых графических библиотек как-то не содержит.
Согласен. Но мы же в перспективе смотрим, для чего .NET может пригодится.
M>>Много ли программ, которые занимаются и не коммуникациями и не UI? Видимо, в основном — сервера БД и бизнес логика. ГВ>Мда... любопытное обобщение.
Угу. Какие будут мнения, комментарии?
M>>Пишете какой-нибудь сервис сбора биржевых котировок? Дотнет. ГВ>Хммм... ты себе представляшь, какими бывают интерфейсы бирж? Я ведь неслучайно DarkGray зацепил по этому поводу относительно бинарных форматов.
Ну, бинарные конвертилки не большая проблема вроде бы. Их на чём хочешь можно делать, разве что на VBScript неудобно.
ГВ>Неужто и браузер на .Net уже написали? ГВ>А что, Office'2003 на .Net?
Ну, это ж теоретически. На C++ тоже не за один день софт переписывали.
M>>Я, кажется, не утверждал, что есть какая-то существенная переносимость. ГВ>А... ну извини. Так бы сразу и сказал, что существенной переносимости нет и закрыли бы тему сразу.
Нужно было спросить, я б сказал.
M>>Ты был неправ, если считал дотнет игрушкой. Но, конечно, на серверном рынке это ещё не ровня Яве. ГВ>А с чего ты взял, что я считаю его игрушкой?
AVM>Как думаешь более качественный софт получится в первом случае или во втором ?
Я думаю, что если в среде могут работать домохозяйки — это плюс а не минус. И создавать искуственные трудности — это не годится как общий приём в обучении.
dad>лучше не знать всех особенностей (больешй части) инстурмента и использовать минимум но _грамотно_
Лучше — это всегда "лучше для чего". Для клиента, для программиста для начальника отдела разработки?
По-моему, просто так, в воздух, без конкретики такие разговоры как раз и попахивают маркетингом.
Ты скажи: "разрабатывая оконное приложение, начинайте всегда с бизнес-объектов". И мы начнём конструктивное обсуждение. Или давай обсуждать необходимость UML при проектировании. Это действительно может принести кому-то интерестные мысли.
Но что с того, что ты обвинишь Микрософт в иедологии? Чтоб делать такие выводы нужно по крайней мере привести серьёзный анализ Микрософтовской идеологии.
M>>Выходит, в одну сторону ремотин в другую уже нет.
AVK>Ну и что? В другую сторону ремоутинг не нужен, там уже СОМ.
Нужен не нужен. Я и говорю, что там не чистый ремотинг.
При общении с внешними веб-сервисами другая ситуация. Поступающие в AppDomain вызовы обрабатываются ремотингом. Уходящие из AppDomain вызовы обрабатываются ремотингом.
Здравствуйте, mihailik, Вы писали:
AVK>>Ну и что? В другую сторону ремоутинг не нужен, там уже СОМ.
M>Нужен не нужен. Я и говорю, что там не чистый ремотинг.
Что то у тебя опять с терсинологией. Что значит не чистый? Что такое грязный? Понятно что помимо ремоутинга там используются другие технологии, но ремоутинг там неотемлемая часть.
M>При общении с внешними веб-сервисами другая ситуация.
Опять ты что то мудрить начинаешь. При общении с веб-сервисами ремоутинг не используется.
Здравствуйте, mihailik, Вы писали:
AVK>>Понятно что помимо ремоутинга там используются другие технологии, но ремоутинг там неотемлемая часть.
M>Это не совсем то, что было вот тут:
M>
M>СОМ-интероп так же работает через ремоутинг.
По-моему, все верно.
M>>>При общении с внешними веб-сервисами другая ситуация.
AVK>>Опять ты что то мудрить начинаешь. При общении с веб-сервисами ремоутинг не используется.
M>Кгм. MarshalByRefObject, TransparentProxy — это не считается ремотингом? Странная терминология, а?
AVK>>>Понятно что помимо ремоутинга там используются другие технологии, но ремоутинг там неотемлемая часть.
M>>Это не совсем то, что было вот тут:
M>>
M>>СОМ-интероп так же работает через ремоутинг.
M>По-моему, все верно.
По второму кругу?
Там не чистый ремотинг. COM встроен в CLR, а не просто отдельный пристёгнутый канал. Некоторые части COM-Interop используют ремотинг, это было бы точнее.
Нет, ну дотнетовцы это и так поймут. Но тут же идёт объяснение для неспециалистов. Нечего людей путать.
M>>Кгм. MarshalByRefObject, TransparentProxy — это не считается ремотингом? Странная терминология, а?
M>Значит ты мой клиент
Ну, надеюсь только, что ты не психиатром работаешь
ГВ>> Зачем мне Dispose, который неизвестно когда сработает? Мне нужна уверенность в происходящем. А вставлять очистки в блоках finally — нетушки, лучше уж в деструкторах.
L>Dispose сработает ровно тогда, когда его вызовут.
Поясняю для тех, кто не в курсе. Интерфейс IDisposable и его метод Dispose — это отдельный, не связанный с финализацией/деструкцией способ очистки ресурсов. Язык C# умеет обрабатывать этот интерфейс при помощи слова using.
К примеру, в классе Stream реализован IDisposable. Вот так получается детерминированное закрытие ресурсов:
В конце блока using для объекта fs будет детерминировано вызван метод Dispose. Таким образом, детерминированное освобождение возможно, но для этого нужно явно использовать using.
При компиляции using преобразовывается в try/finally.
Вообщем, особого противоречия нет. Хотя если вам хочеться до истины докопаться
M>Нет, ну дотнетовцы это и так поймут. Но тут же идёт объяснение для неспециалистов. Нечего людей путать.
Думаешь им интересны такие тонкости?
M>Ну, надеюсь только, что ты не психиатром работаешь
M>>И CCW тоже? S> А можно, чуть чуть подробнее об CCW.
COM Callable Wrapper. Со стороны COM дотнетовский объект выглядит в виде COM-объекта, правильно?
CCW создаётся когда в COM нужно передать дотнетовский объект. Этот объект в бинарном виде реализует нужные COM-интерфейсы, плюс содержит ссылку на дотнетовский родной объект.
В результате, вызов дотнета из COM практически никак не затрагивает ремотинг.
В обратную сторону по другому. RCW, вроде бы, является TransparentProxy, то есть существует какой-то специальный channel для маршалинга вызова из дотнет в COM.
AVM>MS, как прородитель Net сделает реализации framework для 5-6 различных операционок
А зачем это Микрософту?
AVM> а тем кто захочет сам реализовать FW — раздаст исходники, своих реализаций, чтобы другие могли поучится, как правильно писать
Примерно это Микрософт уже делает. Shared Source CLI доступна любому желающему, в нём поддерживается Windows, FreeBSD, MacOS X.
AVM>выступит спонсором в паре-тройке OpenSource проектов
Микрософт коммерческая организация. Ты не перепутал её случайно с какими-нибудь уличными христианами?
Здравствуйте, mihailik, Вы писали:
AVK>>Опять ты что то мудрить начинаешь. При общении с веб-сервисами ремоутинг не используется.
M>Кгм. MarshalByRefObject, TransparentProxy — это не считается ремотингом? Странная терминология, а?
AVM>IIS назван потому что, я например себе не представляю, кто кроме IIS поддерживает ASP в полном объеме и в какой еще OS, кроме windows, это может работать
Ну это просто ты не в курсе. ASP.NET можно с полпинка хостить в любой программе.
Mono включает реализацию ASP.NET. Пару недель назад (Mono 0.29) они уже объявили, что вся функциональность ASP.NET полностью реализована. А Моно работает под разными операционками. Под Линуксом, например.
M>>Нет, ну дотнетовцы это и так поймут. Но тут же идёт объяснение для неспециалистов. Нечего людей путать.
M>Думаешь им интересны такие тонкости?
Если сразу правильно сформулировать, это не будет тонкостями. Я думаю, нужно ценить наших уважаемых оппонентов и давать им как можно более точную информацию.
AVK>>>Опять ты что то мудрить начинаешь. При общении с веб-сервисами ремоутинг не используется.
M>>Кгм. MarshalByRefObject, TransparentProxy — это не считается ремотингом? Странная терминология, а?
AVK>Считается, но в веб-сервисах не используется.
С клиентской стороны доступ к любому веб-сервису идёт через ремотинг. Будь это ASP.NET веб-сервисы, ремотинговые веб-сервисы или Java-веб-сервисы.
AVM>> а тем кто захочет сам реализовать FW — раздаст исходники, своих реализаций, чтобы другие могли поучится, как правильно писать
M>Примерно это Микрософт уже делает. Shared Source CLI доступна любому желающему, в нём поддерживается Windows, FreeBSD, MacOS X.
AVM>>выступит спонсором в паре-тройке OpenSource проектов
M>Микрософт коммерческая организация. Ты не перепутал её случайно с какими-нибудь уличными христианами?
странно ты в одном посте сам себю противоречишь.. то оно выпускает shared source то тебя веселит идея спонсирования open source ..
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
AVM>>>выступит спонсором в паре-тройке OpenSource проектов
M>>Микрософт коммерческая организация. Ты не перепутал её случайно с какими-нибудь уличными христианами?
dad>странно ты в одном посте сам себю противоречишь.. то оно выпускает shared source то тебя веселит идея спонсирования open source ..
Здравствуйте, mihailik, Вы писали:
AVK>>>>Опять ты что то мудрить начинаешь. При общении с веб-сервисами ремоутинг не используется.
M>>>Кгм. MarshalByRefObject, TransparentProxy — это не считается ремотингом? Странная терминология, а?
AVK>>Считается, но в веб-сервисах не используется.
M>С клиентской стороны доступ к любому веб-сервису идёт через ремотинг. Будь это ASP.NET веб-сервисы, ремотинговые веб-сервисы или Java-веб-сервисы.
сокет — пайп — ремотинг. Тоесть, ты ошибаешься так же, как АВК с твоих слов про СОМ интероп
Здравствуйте, AVM, Вы писали:
dad>>да. это нормальный академический подход — отдельно спецификация отдельно реализация. но похоже именно в .net все с этим в порядке (в функционале который он реализует) AVM>Так это же хорошо. AVM>Если на net будут открытые спецификации (не только на C# но и на API); AVM>будет организация которая будет управлять изменениями этих спецификаций и следить за их соблюдением; AVM>MS, как прородитель Net сделает реализации framework для 5-6 различных операционок, а тем кто захочет сам реализовать FW — раздаст исходники, своих реализаций, чтобы другие могли поучится, как правильно писать; AVM>выступит спонсором в паре-тройке OpenSource проектов AVM>NET тогда цены не будет.
AVM>PS: Только не надо — с губой у меня все в порядке
Правильно мыслишь. Именно так и делает MS. Явный пример куча статей по технологиям, не обфусцированные сборки, дополнительные блоки, которая она выпускает с исходниками, MSDN, и, наконец, Ротор.
Здравствуйте, mihailik, Вы писали:
AVM>>>>выступит спонсором в паре-тройке OpenSource проектов
M>>>Микрософт коммерческая организация. Ты не перепутал её случайно с какими-нибудь уличными христианами?
dad>>странно ты в одном посте сам себю противоречишь.. то оно выпускает shared source то тебя веселит идея спонсирования open source ..
M>И где же здесь противоречие?
в том что оно спонсирует ресеч свой который выпускает совт с открытым кодом (раздает его),
что еще круче чем проекты open source ориентированные на прямой доход. так что ничего такого не вижу в финансировании ms какого нибудь комьюнити. учавтсвует же оно во всех комитетах по спецификациям и рекоммендациям (платит людям зп).
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, mihailik, Вы писали:
M>Поясняю для тех, кто не в курсе. Интерфейс IDisposable и его метод Dispose — это отдельный, не связанный с финализацией/деструкцией способ очистки ресурсов. Язык C# умеет обрабатывать этот интерфейс при помощи слова using.
M>>И где же здесь противоречие?
dad>в том что оно спонсирует ресеч свой который выпускает совт с открытым кодом (раздает его), что еще круче чем проекты open source ориентированные на прямой доход.
Ну, если с позиции крутизны рассматривать, тогда можно к странным выводам прийти. Но для Микрософта это вопрос денег, а не крутизны.
dad> так что ничего такого не вижу в финансировании ms какого нибудь комьюнити. учавтсвует же оно во всех комитетах по спецификациям и рекоммендациям (платит людям зп).
Когда это выгодно, участвует. Финансировать Shared Source CLI Микрософту выгодно. Это помогает остальным программистам лучше разобраться в дотнете. В конечном счёте, это помогает успешном выходу дотнета на рынок.
Однозначно, если появится выгодное Микрософту комьюнити, они его будут поддерживать. Да, в этом смысле согласен с тобой.
M>>>>Кгм. MarshalByRefObject, TransparentProxy — это не считается ремотингом? Странная терминология, а?
AVK>>>Считается, но в веб-сервисах не используется.
M>>С клиентской стороны доступ к любому веб-сервису идёт через ремотинг. Будь это ASP.NET веб-сервисы, ремотинговые веб-сервисы или Java-веб-сервисы.
M>сокет — пайп — ремотинг. Тоесть, ты ошибаешься так же, как АВК с твоих слов про СОМ интероп
Не понял. Работа клиента с веб-сервисом идёт только через ремотинг, т.е. через TransparentProxy. В чём ошибка?
AVM>>Как думаешь более качественный софт получится в первом случае или во втором ?
M>Я думаю, что если в среде могут работать домохозяйки — это плюс а не минус. И создавать искуственные трудности — это не годится как общий приём в обучении.
а эти трудности не искуственныек они естественные, и наиболее естественным путем их преодоления (создание естесвенной легкости, а не искуственной ) это декомпозиция и модульность. где каждая часть может быть использована отдельно, хорошо докумментирована и прозрачна.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, mihailik, Вы писали:
M>>>И CCW тоже? S>> А можно, чуть чуть подробнее об CCW.
M>COM Callable Wrapper. Со стороны COM дотнетовский объект выглядит в виде COM-объекта, правильно?
M>CCW создаётся когда в COM нужно передать дотнетовский объект. Этот объект в бинарном виде реализует нужные COM-интерфейсы, плюс содержит ссылку на дотнетовский родной объект.
M>В результате, вызов дотнета из COM практически никак не затрагивает ремотинг.
M>В обратную сторону по другому. RCW, вроде бы, является TransparentProxy, то есть существует какой-то специальный channel для маршалинга вызова из дотнет в COM.
mihailik, с Новым Годом!!! От чистого Сердца. Ты чего сегодня раздухарился. Маршалинг, и унмаршалинг понятно, интересно механизм передачи как раньше RPC или уже забыл. Суть то все таже.
А Remoting просто опирается на множество других протоколов. Теже Сообщения чегото Data хорошо проходили. Напридумают словей.
Всего хорошего в новом Году.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, mihailik, Вы писали:
M>>>>>Кгм. MarshalByRefObject, TransparentProxy — это не считается ремотингом? Странная терминология, а?
AVK>>>>Считается, но в веб-сервисах не используется.
M>>>С клиентской стороны доступ к любому веб-сервису идёт через ремотинг. Будь это ASP.NET веб-сервисы, ремотинговые веб-сервисы или Java-веб-сервисы.
M>>сокет — пайп — ремотинг. Тоесть, ты ошибаешься так же, как АВК с твоих слов про СОМ интероп
M>Не понял. Работа клиента с веб-сервисом идёт только через ремотинг, т.е. через TransparentProxy. В чём ошибка?
Может ты имеешь ввиду не System.Web.Services.WebService? Если его, то ты не прав. Там нет никакого ремотинга (кроме того места, что я указал, но это специфичное место и его можно даже не рассматривать).
dad>а эти трудности не искуственныек они естественные, и наиболее естественным путем их преодоления (создание естесвенной легкости, а не искуственной ) это декомпозиция и модульность. где каждая часть может быть использована отдельно, хорошо докумментирована и прозрачна.
Я не против декомпозиции или модульности "вообще". Но не везде она нужна.
Если я делаю складскую программу, лучше будет начинать её проектирование с GUI и основных действий пользователя. И под GUI, отчёты придумывать уже структуру базы. Причём для мелкой складской программы бесполезна серьёзная декомпозиция, сложная объектная иерархия, UML.
Берёшь форму, рисуешь так, как удобнее клиенту работать. Вставляешь код, выполняющий всякие там проводки, суммы. Добавляешь пару отчётов. Всё, готово. Следующий!
Поэтому, для разработки складской программы, удобнее тот инструмент, который позволит быстро рисовать формочки и цеплять к ним код.
M>Лучше — это всегда "лучше для чего". Для клиента, для программиста для начальника отдела разработки?
для качества результата труда
M>По-моему, просто так, в воздух, без конкретики такие разговоры как раз и попахивают маркетингом. M>Ты скажи: "разрабатывая оконное приложение, начинайте всегда с бизнес-объектов". И мы начнём конструктивное обсуждение. Или давай обсуждать необходимость UML при проектировании. Это действительно может принести кому-то интерестные мысли.
оконным бывает интерфес а не приложение, это раз, использование юмл при проектировании звучит как то не в тему
к тому, о чем говорю я — это два.
M>Но что с того, что ты обвинишь Микрософт в иедологии? Чтоб делать такие выводы нужно по крайней мере привести серьёзный анализ Микрософтовской идеологии.
Я не обвиняю МС в идеологии я говорю о вреде сочетания:
"Все в одном" + "Теперь делать ПО сможет и домохозяйка"
понимаешь вот вы сидидите знатоки .net и между собой догвооиться не можете используется ли ремоутинг или нет при общении с веб сервисами, переспрашиваете друг друга. а вот если бы ты писал совт вот так:
Начало программы.
Загрузить соап бибилотеку.
Включить ремоутинг.
Ремутинг.Сделай мне что то.
Соапбиблиотека. сделай тото.
Выгрузить соап бибилотек.
Выключить ремоутинг.
Сообщить: Рапира форева.
КонецПрограммы
ты бы точно знал используется ли ремоутинг или не используется
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
M>Если я делаю складскую программу, лучше будет начинать её проектирование с GUI и основных действий пользователя. И под GUI, отчёты придумывать уже структуру базы. Причём для мелкой складской программы бесполезна серьёзная декомпозиция, сложная объектная иерархия, UML.
M>Берёшь форму, рисуешь так, как удобнее клиенту работать. Вставляешь код, выполняющий всякие там проводки, суммы. Добавляешь пару отчётов. Всё, готово. Следующий!
во первых, хорошо что топик масивный надеюсь этот твой подход останится для всех втайне, во вторых — че ты через каждое слово вставляешь UML ? в третих — одно дело халтурить другое дело работать.
M>Поэтому, для разработки складской программы, удобнее тот инструмент, который позволит быстро рисовать формочки и цеплять к ним код.
пректирование gui сразу начинать делать надо, согласен, но ни оно должно тебе диктовать архитекутру совта.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
И тебе С Новым Годом!
С наступающим, так сказать.
S>Маршалинг, и унмаршалинг понятно, интересно механизм передачи как раньше RPC или уже забыл. Суть то все таже.
Дальше куда? Внутри процесса никаких особых маршалингов. А между процессами вообще говоря там есть проблемы. Особенно, если CCW попадёт опять в дотнет, но в чужой AppDomain. Работать с таким будет трудно или невозможно — в зависимости от везения.
Но передаётся CCW между процессами/машинами обычным DCOM'ом.
Говорят, если использовать EnterpiseServices, наследовать там от ServicedComponent, всё будет передаваться хорошо. Но я с COM+ не знаком как следует, поэтому понять этого не могу.
M>>Не понял. Работа клиента с веб-сервисом идёт только через ремотинг, т.е. через TransparentProxy. В чём ошибка?
M>Может ты имеешь ввиду не System.Web.Services.WebService? Если его, то ты не прав.
Это серверная сторона. А для обычного клиента никаких System.Web.WebService, ага? Там же по WSDL генерируется сборка с пустыми методами. Кто их вызывает? TransparentProxy очевидно.
Или я что-то неверно описал? Будь другом, наставь на путь истинный, если так. Тебе это там где-нибудь зачтётся, наверное
M>>Берёшь форму, рисуешь так, как удобнее клиенту работать. Вставляешь код, выполняющий всякие там проводки, суммы. Добавляешь пару отчётов. Всё, готово. Следующий!
dad>во первых, хорошо что топик масивный надеюсь этот твой подход останится для всех втайне,
dad> во вторых — че ты через каждое слово вставляешь UML ?
UML один раз, а слов вона сколько. Что-то не сходится арифметика
dad> в третих — одно дело халтурить другое дело работать.
Да. И ещё.
Одно дело работать, другое творить. В некоторых случаях лучше не творить, а быстро поработать. И людям поможешь, и себе копейку в карман положишь.
M>>Поэтому, для разработки складской программы, удобнее тот инструмент, который позволит быстро рисовать формочки и цеплять к ним код.
dad>пректирование gui сразу начинать делать надо, согласен, но ни оно должно тебе диктовать архитекутру совта.
Здравствуйте, mihailik, Вы писали:
S>>mihailik, с Новым Годом!!! От чистого Сердца.
M>И тебе С Новым Годом! M>С наступающим, так сказать.
S>>Маршалинг, и унмаршалинг понятно, интересно механизм передачи как раньше RPC или уже забыл. Суть то все таже.
M>Дальше куда? Внутри процесса никаких особых маршалингов. А между процессами вообще говоря там есть проблемы. Особенно, если CCW попадёт опять в дотнет, но в чужой AppDomain. Работать с таким будет трудно или невозможно — в зависимости от везения.
Ну обижаешь. А как домены в Net одного процесса??? M>Но передаётся CCW между процессами/машинами обычным DCOM'ом.
M>Говорят, если использовать EnterpiseServices, наследовать там от ServicedComponent, всё будет передаваться хорошо. Но я с COM+ не знаком как следует, поэтому понять этого не могу.
Во Вспомнил CopyData. Да какая хрен разница, передается либо сериализованные данные либо некий Хэндл. А понятие Remoting просто подразумевает несколько протоколов передачи. Кроме DCOM , с ни легко уживается и TCP/IP и HTTP и раньше, TSocketConnection и THTTPConnection в Delphi. А организация хранения и передачи данных все таже, только с применением других объектов.
С Наступающем. Только Сегодня почувствовал Его Наступление.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, mihailik, Вы писали:
M>>>Не понял. Работа клиента с веб-сервисом идёт только через ремотинг, т.е. через TransparentProxy. В чём ошибка?
M>>Может ты имеешь ввиду не System.Web.Services.WebService? Если его, то ты не прав.
M>Это серверная сторона. А для обычного клиента никаких System.Web.WebService, ага? Там же по WSDL генерируется сборка с пустыми методами. Кто их вызывает? TransparentProxy очевидно.
Во-первых, что ты подрузомеваешь под словом "обычный" если родной веб сервис клиент (а еще можно с веб сервисом через ремотинг общаться, когда клиент через Soap форматер гонит данные), то никакого там нет ремотинга. Генерируяеться сборка по WSDL. Можешь генерировать ее в любое время (обычно вызывают до компиляции программы клиента). Теперь в сборке находиться класс, наследник от SoapHttpClientProtocol. Его метод Invoke (или BeginInvoke) получает данные ввиде object[] и сериализует в соап вид. Далее открываеться сокет по адресу SoapHttpClientProtocol.Url. По этому сокету посылается бассив байт (соап запрос) на IIS сервера (или можно без него). IIS получает данные, .... ну и далее как в моей статье
Тоесть на клиенте такой есть класс
public class MyWebService : SoapHttpClientProtocol
{
public void Method(string hello)
{
return base.Invoke("Method", new object[]{ hello })[0];
}
}
M>>Лучше — это всегда "лучше для чего". Для клиента, для программиста для начальника отдела разработки? dad>для качества результата труда
А качество само по себе — компетенция искусствоведов. Мы же не для искусства работаем, а для людей. Людям нужно получить свою складскую программу, чтоб она работала и поменьше глючила. А boost или regexp им по барабану.
dad>оконным бывает интерфес а не приложение, это раз
Серьёзно? А консольным тоже?
dad>Я не обвиняю МС в идеологии я говорю о вреде сочетания: dad>"Все в одном" + "Теперь делать ПО сможет и домохозяйка"
Чем это отличается от "Всё в одном" + "Теперь автомобилем может управлять и домохозяйка"?
dad>понимаешь вот вы сидидите знатоки .net и между собой догвооиться не можете
Мы можем договориться, на то и форум. Но вот что ты имел ввиду этой вот рапирой я не пойму. Что нужно в явном виде ремотинг включать/выключать? Или что нужно по русски методы называть?
M>А качество само по себе — компетенция искусствоведов. Мы же не для искусства работаем, а для людей. Людям нужно получить свою складскую программу, чтоб она работала и поменьше глючила. А boost или regexp им по барабану.
не согласен — качество по — вещь техническая инженерная, поддается анализу, формулировке и оценке.
dad>>оконным бывает интерфес а не приложение, это раз M>Серьёзно? А консольным тоже?
консоль — это текстовый интерфейс. под оконным понимается многооконный графический интерфейс.
dad>>Я не обвиняю МС в идеологии я говорю о вреде сочетания: dad>>"Все в одном" + "Теперь делать ПО сможет и домохозяйка"
M>Чем это отличается от "Всё в одном" + "Теперь автомобилем может управлять и домохозяйка"?
если бы я занимался строительством автомобилей под нужды конкретного заказчика я бы тоже опровергал это сочетание.
dad>>понимаешь вот вы сидидите знатоки .net и между собой догвооиться не можете
M>Мы можем договориться, на то и форум. Но вот что ты имел ввиду этой вот рапирой я не пойму. Что нужно в явном виде ремотинг включать/выключать? Или что нужно по русски методы называть?
нет просто я начал писать по русски (поскольку не знаю .net) пока писал вспомнил Рапиру , такой язык был (пошутил так)
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
dad>>>оконным бывает интерфес а не приложение, это раз M>>Серьёзно? А консольным тоже?
dad>консоль — это текстовый интерфейс
Ну не знаю, чего тут спорить. Спроси у кого хочешь, format.com — консольная программа?
Если тебе хоть кто-нибудь ответит: "Нет, это программа с консольным интерфейсом," — тогда я больше спорить не буду.
dad>>>Я не обвиняю МС в идеологии я говорю о вреде сочетания: dad>>>"Все в одном" + "Теперь делать ПО сможет и домохозяйка"
M>>Чем это отличается от "Всё в одном" + "Теперь автомобилем может управлять и домохозяйка"?
dad>если бы я занимался строительством автомобилей под нужды конкретного заказчика я бы тоже опровергал это сочетание.
То есть строительством Ролс-Ройсов да болидов Формулы-1?
Ну так Микрософт себя так и не позиционирует. Микрософт это скорее вроде концерна BMW на автомобильном рынке. Массовый производитель для массового рынка.
dad> пока писал вспомнил Рапиру , такой язык был (пошутил так)
M>>Дальше куда? Внутри процесса никаких особых маршалингов. А между процессами вообще говоря там есть проблемы. Особенно, если CCW попадёт опять в дотнет, но в чужой AppDomain. Работать с таким будет трудно или невозможно — в зависимости от везения.
S> Ну обижаешь. А как домены в Net одного процесса???
Если без "захода" в COM, то это ремотинг. Там есть какой-то незаметный глазу channel, который между доменами ходит.
M>>Говорят, если использовать EnterpiseServices, наследовать там от ServicedComponent, всё будет передаваться хорошо. Но я с COM+ не знаком как следует, поэтому понять этого не могу. S> Во Вспомнил CopyData. Да какая хрен разница, передается либо сериализованные данные либо некий Хэндл.
Пока по хендлу можно что-нибудь восстановить, угу.
S> А понятие Remoting просто подразумевает несколько протоколов передачи. Кроме DCOM ,
Ну вот как раз для DCOM у ремотинга нет channel'а. DCOM возможен только посредством COM Interop, то есть руками COM'а и EnterpriseSerivces (COM+).
S> С Наступающем. Только Сегодня почувствовал Его Наступление.
Здравствуйте, mihailik, Вы писали:
S>> Во Вспомнил CopyData. Да какая хрен разница, передается либо сериализованные данные либо некий Хэндл.
M>Пока по хендлу можно что-нибудь восстановить, угу.
S>> А понятие Remoting просто подразумевает несколько протоколов передачи. Кроме DCOM ,
M>Ну вот как раз для DCOM у ремотинга нет channel'а. DCOM возможен только посредством COM Interop, то есть руками COM'а и EnterpriseSerivces (COM+).
Ага а как пресловутый RPC. Так или иначе существую Прокси и Стаб, а их общения зависит от реализации.
В Любом случае ВСЕ ТО ЖЕ САМОЕ.
С Наступающем. Только Сегодня почувствовал Его Наступление.
Ну, будем последовательны. С наступающим.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, is, Вы писали:
is>[...] "которому ты привык за долгие коды". [...]
Тьфу ты — опечаточка по Фрейду. Конечно же, за годы.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, AndrewVK, Вы писали:
AVK>VS.NET. Какие то части вроде есть в BizTalk 2004. В следующем году будет Юкон.
ОК, по этому ты написал — ясно.
AVK>Ну и конечно лонгхорн.
Т.е. он именно писан на нем, а не включает в составе? Я правильно понял?
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, mihailik, Вы писали:
M>К тому, что назвал AVK добавлю ещё TabletPC. Программная часть платформы реализована на .NET
А какая там ОС? Едишн специальный?
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, mihailik, Вы писали:
is>>Кстати, интересно узнать список продуктов Майкрософт, которые уже выпущены, с использованием платформы .net.
M>К тому, что назвал AVK добавлю ещё TabletPC. Программная часть платформы реализована на .NET
Это всего лишь XP со специальными драйверами. .NET используется на том же уровне, что и в XP.
Здравствуйте, mihailik, Вы писали:
M>С клиентской стороны доступ к любому веб-сервису идёт через ремотинг. Будь это ASP.NET веб-сервисы, ремотинговые веб-сервисы или Java-веб-сервисы.
Нет там никакого ремоутинга, ну да Мика тебе вроде уже объяснил. Самое смешное что с сервисами действительно можно общаться через ремоутинг, но студия так не делает, поскольку прямая кодогенерация в итоге быстрее.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>VS.NET. Какие то части вроде есть в BizTalk 2004. В следующем году будет Юкон. Ну и конечно лонгхорн. ГВ>>А Юкон разве с использованием .Net написан? AVK>Да
Сам сервер или только "обвязка"?
ГВ>> AFAIK, он просто с ним интегрирован. AVK>Нет. На дотнете написан основной тул,
В смысле, что-то вроде query analyzer?
AVK>дотнет же обеспечивает работу юкона через SOAP.
угу
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mihailik, Вы писали:
ГВ>>Вроде бы .Net могучих обобщённых графических библиотек как-то не содержит. M>Согласен. Но мы же в перспективе смотрим, для чего .NET может пригодится.
Так, понял. AndrewVK уже напомнил про авалон.
M>>>Много ли программ, которые занимаются и не коммуникациями и не UI? Видимо, в основном — сервера БД и бизнес логика. ГВ>>Мда... любопытное обобщение. M>Угу. Какие будут мнения, комментарии?
Мне кажется, ты упускаешь ещё расчётные программы как минимум. Впрочем, это неважно. Кажется, я для себя уже некоторые выводы сделал.
M>>>Пишете какой-нибудь сервис сбора биржевых котировок? Дотнет. ГВ>>Хммм... ты себе представляшь, какими бывают интерфейсы бирж? Я ведь неслучайно DarkGray зацепил по этому поводу относительно бинарных форматов. M>Ну, бинарные конвертилки не большая проблема вроде бы. Их на чём хочешь можно делать, разве что на VBScript неудобно.
На самом деле там и собственные девайсы могут быть.
ГВ>>Неужто и браузер на .Net уже написали? ГВ>>А что, Office'2003 на .Net? M>Ну, это ж теоретически. На C++ тоже не за один день софт переписывали.
Теоретически, на .Net можно писать почти любой софт кроме драйверов. Языки достаточно полные, библиотеки развитые... Вопрос в том — что на нём лучше всего писать.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
dad>>консоль — это текстовый интерфейс
M>Ну не знаю, чего тут спорить. Спроси у кого хочешь, format.com — консольная программа?
M>Если тебе хоть кто-нибудь ответит: "Нет, это программа с консольным интерфейсом," — тогда я больше спорить не буду.
ответил "нет это прокрамма без интерфейса вообще", холтя я считаю что консоль то такаяже парадигма интерфеса (ориентирована на стандарный ввод-вывод), как и например цикл сообщений в оконном режиме. т.е. по сути консоль — это разновидность интерфейса в текстовом режиме, предоставляемая платформой.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
dad>>в том что оно спонсирует ресеч свой который выпускает совт с открытым кодом (раздает его), что еще круче чем проекты open source ориентированные на прямой доход.
M>Ну, если с позиции крутизны рассматривать, тогда можно к странным выводам прийти. Но для Микрософта это вопрос денег, а не крутизны.
dad>> так что ничего такого не вижу в финансировании ms какого нибудь комьюнити. учавтсвует же оно во всех комитетах по спецификациям и рекоммендациям (платит людям зп).
M>Когда это выгодно, участвует. Финансировать Shared Source CLI Микрософту выгодно. Это помогает остальным программистам лучше разобраться в дотнете. В конечном счёте, это помогает успешном выходу дотнета на рынок.
а я тебе о чем? или по твоему open souce проекты невыгодны? помимо пиара еще и доход.
(вообще я параноически подозреваю что многие разработки и порты под винды да и вообще многие мекие фирмы стартапятся или спонсируются ms)
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Теоретически, на .Net можно писать почти любой софт кроме драйверов.
Вообщем-то, MS сама утверждает, что С++ теперь остался только для того, чтобы на нем драйвера писать. Тоесть, Нет тут не особый помошник. Да и DDK носит WinAPI характерный стиль. Будет слишком большой оверхед при маршалинге.
ГВ>Языки достаточно полные, библиотеки развитые...
Самое главное, что они постоянное пополняются. Сама MS пишет новое ( ), туча сторонних библиотек. Да дело в том, что на Нете приятно кодить. Поэтому, раз есть желание, то будет и результат.
ГВ>Вопрос в том — что на нём лучше всего писать.
ToAll: Вот на этом я предлагаю закончить все дебаты (в том числе о Яве, о которой вообще не было упоминания. Напомню, говорим о .NET). Все там Веб сервисы, COM Interop, remoting и кодогенерация к делу не относится.
Вот тут хотелось бы увидеть спиков всех тех задач, которые ты знаешь и считаешь, что на них нельзя писать на Нете. Мы будем дальше приводить плюсы и минусы. Их, соответственно, тоже оспаривать. Таким образом, мы поймем причину недопонимания.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Геннадий Васильев, Вы писали:
DG>>>Зачем тебе детерминированное удаление? Для удаления ресурсов есть Dispose. ГВ>> Зачем мне Dispose, который неизвестно когда сработает? Мне нужна уверенность в происходящем. А вставлять очистки в блоках finally — нетушки, лучше уж в деструкторах.
L>Гм. Странное заявление. Dispose сработает ровно тогда, когда его вызовут. Ни позже и не раньше. L>Да и finally использовать необязательно. Для этого есть using.
Мда. Тебе и mihailik спасибо, что напомнили.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>А Юкон разве с использованием .Net написан? AVK>>Да ГВ>Сам сервер или только "обвязка"?
Что значит сам сервер? Ядро разумеется нативное, никто такую гору кода переписывать не будет. А вот службы частично на нете.
ГВ>>> AFAIK, он просто с ним интегрирован. AVK>>Нет. На дотнете написан основной тул,
ГВ>В смысле, что-то вроде query analyzer?
Круче. QA и Enterprise Manager в одном флаконе + отладчик. За основу взята обычная студия, но вся начинка менеджед.
Здравствуйте, dad, Вы писали:
dad>а я тебе о чем? или по твоему open souce проекты невыгодны? помимо пиара еще и доход. dad>(вообще я параноически подозреваю что многие разработки и порты под винды да и вообще многие мекие фирмы стартапятся или спонсируются ms)
Точно паранойя. Тут кто то помнится утверждал что янус написан на дотнете потому что МС нам заплатила
dad>>а я тебе о чем? или по твоему open souce проекты невыгодны? помимо пиара еще и доход. dad>>(вообще я параноически подозреваю что многие разработки и порты под винды да и вообще многие мекие фирмы стартапятся или спонсируются ms)
AVK>Точно паранойя. Тут кто то помнится утверждал что янус написан на дотнете потому что МС нам заплатила
не знаю на счет януса, но я еще до его появления кажется шутил, что сайт поддерживается майкросовт фирмой.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, dad, Вы писали:
AVK>>Точно паранойя. Тут кто то помнится утверждал что янус написан на дотнете потому что МС нам заплатила
dad>не знаю на счет януса, но я еще до его появления кажется шутил, что сайт поддерживается майкросовт фирмой.
Геннадий тоже на самом деле не Геннадий. А групен фюрер фон Геннус, специальное подставное лицо, чтобы создавать иллюзию о равноправии
Здравствуйте, Геннадий Васильев, Вы писали:
M>>Я, кажется, не утверждал, что есть какая-то существенная переносимость. ГВ>А... ну извини. Так бы сразу и сказал, что существенной переносимости нет и закрыли бы тему сразу.
Друзья, а что такое "существенная переносимость"? Это что-то типа осетрины второй свежести или я туплю?
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Но для Юникса есть Оракул и другие базы. Что-то мне всё время пдсказывает, что не очень уж .Net на Unix приживётся. Хотя кто его знает...
Угу, вроде как у DB2 позиции не так плохи.
ГВ>[offtopic] ГВ>Вот ну не думаю я, что IBM возьмёт да и бросит свои разработки в области серверов и ОС. Да и Linux тоже не хрен собачий.
IBM её двигает, к тому же AIX никто не отменял.
ГВ> Потом возьми ещё всяческие иные факторы вплоть до политических... Нет уж... "единой ОС на всех" в обозримом будущем не предвидится. Как и единого средства разработки.
По-моему, это и хорошо.
ГВ>[/offtopic]
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, is, Вы писали:
is>Здравствуйте, Геннадий Васильев, Вы писали:
M>>>Я, кажется, не утверждал, что есть какая-то существенная переносимость. ГВ>>А... ну извини. Так бы сразу и сказал, что существенной переносимости нет и закрыли бы тему сразу.
is>Друзья, а что такое "существенная переносимость"? Это что-то типа осетрины второй свежести или я туплю?
В перспективе. Тоесть интерфейс есть, а реализовать некому.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Здравствуйте, AVM, Вы писали:
AVM>>Делал IB->Oracle.
AS>Насколько я знаю, оба версионники. Если на них еще и ничего кроме голого data storage не висело — задача решаема.
Oracle не "чистый" версионник
AVM>>Есть небольшие ньюансы с переносом constraints и тп.
AS>А вот это абсолютная не правда. Наоборот, с констрейнтами все класно. Например, fk, pk, check constraint везде имеют обинаковый синтаксис. Например,
[skip]
Другой пример в TSQL CREATE RULE и в PostgreSQL CREATE RULE — используются для раличных целей.
AVM>>Если бизнес-логика закладывалась в БД — тут дело намного сложнее и переход на другую RDBMS/ORDBMS может себя не оправдать, но повторюсь — принципиально это возможно.
AS>Да нихрена это не возможно!
Если тебе интересно, то через 3-4 недели могу поделится опытом переноса БД Oracle на PostgreSQL.
AVM>>Если в БД изначально не закладывалась реализация бизнес-логики — переносится с пол пинка, DDL и DML в известных мне RDBMS почти совпадает.
AS>Да? А у меня вот простецкая базенка с 10 таблицами и парой триггеров есть на Оракле. Ты знаешь, меня такая тоска охватывает, при мысли о переносе ее на MSSQL. AS>У каждой СУБД свой синтаксис, и что намного хуже — семантика.
Тоска это неверное потому, что настроение предпраздничное, отдохнуть хочется а не базы туда сюда переносить.
С Новым годом!
PS: Приношу извинения владельцу топика, что обсуждение немного в другую сторону пошло. Если есть желание продолжить тему про открытые технологии и RDBMS пишите в приват или в новую ветку форума.
Всех с Новым годом!
AS>А вот это абсолютная не правда. Наоборот, с констрейнтами все класно. Например, fk, pk, check constraint везде имеют обинаковый синтаксис. Например,
Уверен? Как насчет каскадных обновлений/уделений? Как насчет оракловкого deferrable?
Здравствуйте, Igor Trofimov, Вы писали:
AS>>А вот это абсолютная не правда. Наоборот, с констрейнтами все класно. Например, fk, pk, check constraint везде имеют обинаковый синтаксис. Например,
iT>Уверен? Как насчет каскадных обновлений/уделений? Как насчет оракловкого deferrable?
Ну положим, в восьмерке еще и set default и set null нету и что? Перечисленные констрейнты то все-равно одинаковые. Кстати, где-то в форуме по БД была мысль как сделать в MSSQL констрейнт откладываемым.
M>Вообщем-то, MS сама утверждает, что С++ теперь остался только для того, чтобы на нем драйвера писать. Тоесть, Нет тут не особый помошник. Да и DDK носит WinAPI характерный стиль. Будет слишком большой оверхед при маршалинге.
Да ладно бы оверхед. Дотнет везде использует отложенную загрузку, отложенную компиляцию и т.д. Для драйверов такая модель как правило просто никак не годится.
Здравствуйте, Геннадий Васильев, Вы писали:
DG>>Зачем тебе детерминированное удаление? Для удаления ресурсов есть Dispose. ГВ> Зачем мне Dispose, который неизвестно когда сработает? Мне нужна уверенность в происходящем. А вставлять очистки в блоках finally — нетушки, лучше уж в деструкторах.
Для этого есть конструкция using
using (StreamReader reader = new StreamReader("test.txt"))
{
string text = reader.ReadToEnd();
}
Текст кода получается таким же чистым, как в C++.
ГВ>>> и отсутсвия шаблонов, а мне они ох как нужны. DG>>А что у вас сейчас делается на шаблонах? ГВ>Всё не перечислить. Управление памятью, API, системные структуры (отдельная сага), связь (пока — немного), частично — UI, разные контроллеры ресурсов и т.п. Задач хватает, одним словом.
DGЭто очень удобное композиционное средство. И почему только им редко пользуются?
Можно пример? Именно как композиционного средства.
DG>>альтернатива: интерфейсы, делегаты. ГВ>Да, не спорю. Если бы ещё вычесть отсюда неизбежные оверхеды от такого подхода — цены бы им не было.
Если программа большая, то лишний косвенный вызов не скажется на производительности в целом.
ГВ>>> МН тоже не хватает — весьма полезная штука на системном уровне. DG>>Альтернатива: DG>>дробление классов, вынос части функционала в подклассы. DG>>подключение реализаций. ГВ>Оверхеды, оверхеды, оверхеды...
Откуда оверхеды? В худшем случае — один дополнительный косвенный вызов?
ГВ> А потом удивляемся, почему .Net-овские программы порой медленно работают. Вот она — причина.
Причина в другом. .Net позволяет быстро разработать некий функционал, который могут напрямую использовать пользователи программы.
Но не у всех разработчиков есть желание, времени и денег на вылизывание кода — особенно этим страдают бесплатные программы, которые делаются программистами без участия "маркетологов".
Hello, "alexkro"
> DG>Для этого есть конструкция using > DG>Текст кода получается таким же чистым, как в C++. > > Давай сравним это с: > Где чище?
Да все просто. Добавляем небольшой Sleep();
using (StreamReader reader = new StreamReader("test.txt"))
{
string text = reader.ReadToEnd();
}
Thread.CurrentThread.Sleep(10000);
StreamReader reader( "test.txt" );
String ^ text = reader.ReadToEnd();
Thread.CurrentThread.Sleep(10000);
И после этого — какой код более нагляден? C#, где ресурс занимается на минимальное время и этот блок явно очерчен или на C++ где время нецелевого использования ресурса просто не нормированно?
Posted via RSDN NNTP Server 1.8 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>И после этого — какой код более нагляден? C#, где ресурс занимается на минимальное время и этот блок явно очерчен или на C++ где время нецелевого использования ресурса просто не нормированно?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, TK, Вы писали:
TK>>И после этого — какой код более нагляден? C#, где ресурс занимается на минимальное время и этот блок явно очерчен или на C++ где время нецелевого использования ресурса просто не нормированно?
IT>Тоже самое не хуже делается и на плюсах
IT>
M>>>Я думаю комментарии излишни T>>Ну да, в плюсах компактнее и читабельнее. ;-в
IT>Читабельнее было бы, если бы String был с маленькой буквы и не было бы вот этой '^' козябры.
Насчёт кракозябры — это да, согласен — нафиг не нужна. ;-в
Здравствуйте, Tonal-, Вы писали:
M>>>>Я думаю комментарии излишни T>>>Ну да, в плюсах компактнее и читабельнее. ;-в
IT>>Читабельнее было бы, если бы String был с маленькой буквы и не было бы вот этой '^' козябры. T>Насчёт кракозябры — это да, согласен — нафиг не нужна. ;-в
А как же ты без нее поймешь, managed это тип или native?
Здравствуйте, DarkGray, Вы писали:
DG>Здравствуйте, Геннадий Васильев, Вы писали:
DG>>>Зачем тебе детерминированное удаление? Для удаления ресурсов есть Dispose. ГВ>> Зачем мне Dispose, который неизвестно когда сработает? Мне нужна уверенность в происходящем. А вставлять очистки в блоках finally — нетушки, лучше уж в деструкторах.
DG>Для этого есть конструкция using DG>
DG>using (StreamReader reader = new StreamReader("test.txt"))
DG>{
DG> string text = reader.ReadToEnd();
DG>}
DG>
DG>Текст кода получается таким же чистым, как в C++.
{
StreamReader reader("test.txt");
CString s = reader.ReadToEnd(); // Это не хэндл, а MFC::CString
}
Или ещё компактнее:
{
CString s = StreamReader("test.txt").ReadToEnd();
}
ГВ>>>> и отсутсвия шаблонов, а мне они ох как нужны. DG>>>А что у вас сейчас делается на шаблонах? ГВ>>Всё не перечислить. Управление памятью, API, системные структуры (отдельная сага), связь (пока — немного), частично — UI, разные контроллеры ресурсов и т.п. Задач хватает, одним словом. DG>DGЭто очень удобное композиционное средство. И почему только им редко пользуются? DG>Можно пример? Именно как композиционного средства.
{
CString s = StreamReader<IOSafePolicy_UseDefault>("test.txt").ReadToEnd();
CString s1 = StreamReader<IOSafePolicy_ThrowException>("test1.txt").ReadToEnd();
}
DG>>>альтернатива: интерфейсы, делегаты. ГВ>>Да, не спорю. Если бы ещё вычесть отсюда неизбежные оверхеды от такого подхода — цены бы им не было. DG>Если программа большая, то лишний косвенный вызов не скажется на производительности в целом.
Гы. Если бы один.
ГВ>>>> МН тоже не хватает — весьма полезная штука на системном уровне. DG>>>Альтернатива: DG>>>дробление классов, вынос части функционала в подклассы. DG>>>подключение реализаций. ГВ>>Оверхеды, оверхеды, оверхеды... DG>Откуда оверхеды? В худшем случае — один дополнительный косвенный вызов?
Птичка по зёрнышку...
ГВ>> А потом удивляемся, почему .Net-овские программы порой медленно работают. Вот она — причина. DG>Причина в другом. .Net позволяет быстро разработать некий функционал, который могут напрямую использовать пользователи программы.
Э... а другой функционал они используют не напрямую? Может быть, ты имеешь ввиду функционал, выраженный в символах пользователей?
DG>Но не у всех разработчиков есть желание, времени и денег на вылизывание кода — особенно этим страдают бесплатные программы, которые делаются программистами без участия "маркетологов".
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>И в чью пользу?
Конечно в пользу C#
Ты сравниваешь идеализированный код на C++ с обычной практикой программирования на C#. Такого кода на C++ как ты привёл в реальных проектах не бывает. Каша из STL, ATL, MFC, RTL, VCL, WIN API — это да, обычное дело. Сейчас ещё добавится .NET Framework, но боюсь, что лучше от этого не станет.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
ГВ>>И в чью пользу? IT>Конечно в пользу C#
Ага, там скобок больше.
IT>Ты сравниваешь идеализированный код на C++ с обычной практикой программирования на C#. Такого кода на C++ как ты привёл в реальных проектах не бывает. Каша из STL, ATL, MFC, RTL, VCL, WIN API — это да, обычное дело. Сейчас ещё добавится .NET Framework, но боюсь, что лучше от этого не станет.
Да, существенное замечание, спору нет. Ну так... враппировать надо. И ещё — рефакторить.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
ГВ>>Да, существенное замечание, спору нет. Ну так... враппировать надо. И ещё — рефакторить. IT>Что рефакторить? MFC, ATL и STL? Безусловно надо, но только это не про нас с тобой
Да нет. Свои проекты.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
IT>Конечно в пользу C#
IT>Ты сравниваешь идеализированный код на C++ с обычной практикой программирования на C#. Такого кода на C++ как ты привёл в реальных проектах не бывает. Каша из STL, ATL, MFC, RTL, VCL, WIN API — это да, обычное дело. Сейчас ещё добавится .NET Framework, но боюсь, что лучше от этого не станет.
а как вообще работает .net. сама платформа. бибилотеку классов я не беру в расчет.
вот есть программа скомпонованная в il. а потом он сибирается в машинный код (JIT) так чтоли? а какую роль здесь выполняет ОС? сама бибилотека не использует ос?
если уж нато пошло то суть .net — новая ОС, без поддержки старого кода, а если просто надсройка над os, то цена ей совсем другая. какие механизмы есть для связи с приложениями выполняющимися под текущей ос?
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Tonal-, Вы писали:
M>>>Я думаю комментарии излишни T>>Ну да, в плюсах компактнее и читабельнее. ;-в
IT>Читабельнее было бы, если бы String был с маленькой буквы и не было бы вот этой '^' козябры.
Да нет, Игорь. Ты посчитай количесво строчек. Да и сам стиль обрамления круглыми скобками отвратителен. Студия так и норовит их форматнуть через пень колоду.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, IT, Вы писали:
ГВ>>>Да, существенное замечание, спору нет. Ну так... враппировать надо. И ещё — рефакторить. IT>>Что рефакторить? MFC, ATL и STL? Безусловно надо, но только это не про нас с тобой
ГВ>Да нет. Свои проекты.
Свои проекты? Кстати, в С# есть тулза стандартная. Есть ли такое для С++?
И еще. Ты когда-нибудь видел проекты, сложеннные из программ, написанных на MFC, ANSI C++, WIN API, STL, ATL? Это ж ужас какой-то. CString, char*, LPTSTR, string, BSTR.
Толи дело на С#
ГВ>>>>> и отсутсвия шаблонов, а мне они ох как нужны. DG>>>>А что у вас сейчас делается на шаблонах? ГВ>>>Всё не перечислить. Управление памятью, API, системные структуры (отдельная сага), связь (пока — немного), частично — UI, разные контроллеры ресурсов и т.п. Задач хватает, одним словом. DG>>DGЭто очень удобное композиционное средство. И почему только им редко пользуются? DG>>Можно пример? Именно как композиционного средства.
ГВ> ГВ>
И что? Да я это на шарпе лучше напишу. Хех. (кстати у тебя в коде ошибка )
namespace Test
{
public interface ISafePolicy
{
T GetOnErrorValue<T>();
}
class StreamReader<SafePolicy>
where SafePolicy : ISafePolicy, new()
{
public StreamReader(string fileName)
{
}
public string ReadToEnd()
{
return new SafePolicy().GetOnErrorValue<string>();
}
}
class IOSafePolicy_UseDefault : ISafePolicy
{
public T GetOnErrorValue<T>()
{
return T.default;
}
}
class IOSafePolicy_ThrowException : ISafePolicy
{
public T GetOnErrorValue<T>()
{
throw new System.IO.IOException();
}
}
public class Launcher
{
public static void Main()
{
string s1 = new StreamReader<IOSafePolicy_UseDefault>("test1.txt").ReadToEnd();
string s2 = new StreamReader<IOSafePolicy_ThrowException>("test2.txt").ReadToEnd();
}
}
}
Или что еще проще
class StreamReader
{
public StreamReader(string fileName)
{
}
[PrincipalPermissionAttribute(SecurityAction.Demand, Role="IOUser")]
public string ReadToEnd()
{
return string.default;
}
}
DG>>Откуда оверхеды? В худшем случае — один дополнительный косвенный вызов? ГВ>Птичка по зёрнышку...
Не верно. Главные тормоза из-за неправильной архитектуры. Возможно у вас там что-то напортачено.
зы Честно говоря, зря ты начал сравнивать С++ с С#. Последний тут неоспоримый победитель
IT>>>Читабельнее было бы, если бы String был с маленькой буквы и не было бы вот этой '^' козябры. T>>Насчёт кракозябры — это да, согласен — нафиг не нужна. ;-в
A>А как же ты без нее поймешь, managed это тип или native?
Понять 100%-но можно только прямым запросом rtti, вот так, например:
if (dynamic_cast<void*>(obj))
Console::WriteLine("Это обычный указатель");
else if (dynamic_cast<System::Object^>(obj))
Console::WriteLine("Это managed объект");
else
Console::WriteLine("Это обячный объект, или обычная ссылка");
Или статически (вроде должно работать):
if (static_cast<void*>(obj))
Console::WriteLine("Это обычный указатель");
else if (static_cast<System::Object^>(obj)) //Или здесь будет боксинг?
Console::WriteLine("Это managed объект");
else
Console::WriteLine("Это обычный объект, или обычная ссылка");
Веть где то выше может быть такая сторка:
#define MyString String^
//Илиtypedef String^ MyString;
//Или вообше ты пишеш шаблон, и тип у него - параметр.template <class T>
voud MyCoolFunc(T t);
Здравствуйте, Tonal-, Вы писали:
IT>>>>Читабельнее было бы, если бы String был с маленькой буквы и не было бы вот этой '^' козябры. T>>>Насчёт кракозябры — это да, согласен — нафиг не нужна. ;-в
A>>А как же ты без нее поймешь, managed это тип или native?
T>Понять 100%-но можно только прямым запросом rtti, вот так, например:
Я про то, что нужно это видеть с первого взгляда. Смотришь на использование класса и сразу можешь сказать, managed это или native, нужно delete писать или нет, и т.д. Между прочим, это была одна из проблем в managed extensions — все типы выглядят одинаково.
Потом, опять-же перегружка операторов. Для указателей не работает, для handle'ов — без проблем.
Здравствуйте, alexkro, Вы писали:
A>Здравствуйте, mikа, Вы писали:
M>> public string ReadToEnd() M>> { M>> return new SafePolicy().GetOnErrorValue<string>(); M>> } M>> }
A>Создавать новый объект только для того, чтобы вызвать единственный метод, — это криво.
Согласен. Поэтому самый лучший способ — декларативно. И ведь все без шаблонов, прям чудеса какие-то
Здравствуйте, mikа, Вы писали:
DG>>>Откуда оверхеды? В худшем случае — один дополнительный косвенный вызов? ГВ>>Птичка по зёрнышку...
M>Не верно. Главные тормоза из-за неправильной архитектуры. Возможно у вас там что-то напортачено.
M>зы Честно говоря, зря ты начал сравнивать С++ с С#. Последний тут неоспоримый победитель
Ладно, это пока не важно. Кстати, не раскроешь тайну: partial specialization в шарповых женериках есть али нет? И шаблонные параметры шаблонов допустимы? Это не в порядке спора, а мне для информации.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
M>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Здравствуйте, IT, Вы писали:
ГВ>>>>Да, существенное замечание, спору нет. Ну так... враппировать надо. И ещё — рефакторить. IT>>>Что рефакторить? MFC, ATL и STL? Безусловно надо, но только это не про нас с тобой
ГВ>>Да нет. Свои проекты.
M>Свои проекты? Кстати, в С# есть тулза стандартная. Есть ли такое для С++? M>И еще. Ты когда-нибудь видел проекты, сложеннные из программ, написанных на MFC, ANSI C++, WIN API, STL, ATL? Это ж ужас какой-то. CString, char*, LPTSTR, string, BSTR. M>Толи дело на С#
Mika, это уже бесполезный флейм начнётся. Давай в приват по этому поводу, моё мыло — в профайле.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
A>>>А как же ты без нее поймешь, managed это тип или native?
T>>Понять 100%-но можно только прямым запросом rtti, вот так, например:
A>Я про то, что нужно это видеть с первого взгляда. Смотришь на использование класса и сразу можешь сказать, managed это или native, нужно delete писать или нет, и т.д. Между прочим, это была одна из проблем в managed extensions — все типы выглядят одинаково. A>Потом, опять-же перегружка операторов. Для указателей не работает, для handle'ов — без проблем.
А я привёл несколько примеров на плюсе, которые показывают, что всегда это "видеть" невозможно. Для этого надо вносить существенные ограничения в существующий язык, после чего он стане не плюсом а скажем диезом. ;-в
Ситуация с MS C++ под .NET мне кажется очень похожей на ситуацию с Borland C++ Builder. Много рекламной шелухи, но делать серьёзные проекты не рекомендуется. А использовать для обучения С++ — бессмысленно.
Тут пол дела в том, что Borland не смог добиться стабильной работы компилятора и rtl.
Вторая половина в том, что для того чтобы уяснить когда надо/можно/лучше использовать одни фичи, а когда другие, требуется изрядная квалификация.
Поэтому, после "быстрого старта" следует полный ступпор и застой. ;-в
Я конечно верю что MS рано или поздно добъётся стабильной работы, а вот по поводу сложности...
Боюсь что C++.NET — это действительно только для облегчения портирования...
Здравствуйте, Геннадий Васильев, Вы писали:
M>>Свои проекты? Кстати, в С# есть тулза стандартная. Есть ли такое для С++? M>>И еще. Ты когда-нибудь видел проекты, сложеннные из программ, написанных на MFC, ANSI C++, WIN API, STL, ATL? Это ж ужас какой-то. CString, char*, LPTSTR, string, BSTR. M>>Толи дело на С#
ГВ>Mika, это уже бесполезный флейм начнётся. Давай в приват по этому поводу, моё мыло — в профайле.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ладно, это пока не важно. Кстати, не раскроешь тайну: partial specialization в шарповых женериках есть али нет?
Нет. Есть только уточнение типа.
ГВ>И шаблонные параметры шаблонов допустимы?
Нет.
Скоро статья будет на эту тему в RSDN Magazine. Можешь почитать.
Здравствуйте, Tonal-, Вы писали:
T>А я привёл несколько примеров на плюсе, которые показывают, что всегда это "видеть" невозможно. Для этого надо вносить существенные ограничения в существующий язык, после чего он стане не плюсом а скажем диезом. ;-в
Тебя занесло в область умозрительных размышлений. Почитай лучше ECMA C++/CLI spec, развей сомненья .
Здравствуйте, mikа, Вы писали:
M>Здравствуйте, alexkro, Вы писали:
A>>Создавать новый объект только для того, чтобы вызвать единственный метод, — это криво.
M>Согласен.
Значит, ты согласен, что твой пример кривой и не эквивалентен тому, что привел Геннадий?
>Поэтому самый лучший способ — декларативно. И ведь все без шаблонов, прям чудеса какие-то
Здравствуйте, mikа, Вы писали:
ГВ>>Ладно, это пока не важно. Кстати, не раскроешь тайну: partial specialization в шарповых женериках есть али нет? M>Нет. Есть только уточнение типа.
Какого? Сгенерированного?
ГВ>>И шаблонные параметры шаблонов допустимы? M>Нет.
Хм, интересно...
M>Скоро статья будет на эту тему в RSDN Magazine. Можешь почитать.
Хорошо, почитаю. Спасибо.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
T>>А я привёл несколько примеров на плюсе, которые показывают, что всегда это "видеть" невозможно. Для этого надо вносить существенные ограничения в существующий язык, после чего он стане не плюсом а скажем диезом. ;-в
A>Тебя занесло в область умозрительных размышлений. Почитай лучше ECMA C++/CLI spec, развей сомненья .
А что, уже вышел релиз? У меня валяется "C++ CLI Candidate Base Draft.pdf" вот по впечатлению от него и пишу. ;-в
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, mikа, Вы писали:
ГВ>>>Ладно, это пока не важно. Кстати, не раскроешь тайну: partial specialization в шарповых женериках есть али нет? M>>Нет. Есть только уточнение типа. ГВ>Какого? Сгенерированного?
ГВ>>>И шаблонные параметры шаблонов допустимы? M>>Нет. ГВ>Хм, интересно...
Развеваю сомнения.
Вот код на сях
template <class T> class ObsoleteClass
{
public: int ObsoleteMethod()
{
return T::ObsoleteMethod();
}
};
template <int size> class ObsoleteTemplate
{
public: static int ObsoleteMethod()
{
return size;
}
};
void _tmain()
{
const int size = 10;
ObsoleteClass<ObsoleteTemplate<size> > obsObj;
Console::WriteLine(obsObj.ObsoleteMethod());
}
А вот на шарпе.
public class Sizable
{
public int GetSize()
{
return 10;
}
}
public class ObsoleteClass<T> where T: ObsoleteTemplate<Sizable>, new()
{
public int ObsoleteMethod()
{
return new T().ObsoleteMethod();
}
}
public class ObsoleteTemplate<T> where T: Sizable, new()
{
public int ObsoleteMethod()
{
return new T().GetSize();
}
}
static void Main(string[] args)
{
Console.WriteLine(new ObsoleteClass<ObsoleteTemplate<Sizable>>().ObsoleteMethod());
return;
}
Вообщем, шаблоны там придуманы не для того, зачем он на сях.
Здравствуйте, Tonal-, Вы писали:
T>>>А я привёл несколько примеров на плюсе, которые показывают, что всегда это "видеть" невозможно. Для этого надо вносить существенные ограничения в существующий язык, после чего он стане не плюсом а скажем диезом. ;-в
A>>Тебя занесло в область умозрительных размышлений. Почитай лучше ECMA C++/CLI spec, развей сомненья . T>А что, уже вышел релиз? У меня валяется "C++ CLI Candidate Base Draft.pdf" вот по впечатлению от него и пишу. ;-в
T>>>>А я привёл несколько примеров на плюсе, которые показывают, что всегда это "видеть" невозможно. Для этого надо вносить существенные ограничения в существующий язык, после чего он стане не плюсом а скажем диезом. ;-в
A>>>Тебя занесло в область умозрительных размышлений. Почитай лучше ECMA C++/CLI spec, развей сомненья . T>>А что, уже вышел релиз? У меня валяется "C++ CLI Candidate Base Draft.pdf" вот по впечатлению от него и пишу. ;-в
A>Какие-то размытые впечатления. Давай поконкретней.
У меня вполне конкретные впечатления.
Но если не ясно из моих прошлых постов здесь
1) Про C++ CLI:
Я считаю, что язык С++ один из самых сложных и гибких современных языков. Непротиворечиво расширять его, не принося в жертву каких-нибудь сушествующих свойств черезвычайно трудно. По этому поводу см "Дизайн и эволюция С++" Страуструпа. В лучшем случае это получится совсем другой язык с С подобным синтаксисом (например Java, C#), в хучшем — нечто вроде злополучного продукта от borland. В документе "C++ CLI Candidate Base Draft.pdf" описывается достаточно много нововведений, чтобы с уверенностью можно было сказать, что получившейся язык будет очень трудно сбалансировать (до сих пор ведутся небезосновательные споры о нужности типа bool, wchar_t — не стандартизирован, а MS щедро вводит сразу несколько базовых типов в без того перегруженную систему) (вспомни глюки MS с исключениями, шаболнами, приведениями типов).
Обучать же полученному конгламерату (даже при условии устойчивой реализации) будет довольно трудно. Да и смысл это обучение будет иметь только с позиции "Ща быстренько перетащим исходники под .NET, а потом помаленьку на шарпе всё перепишем" ;-в
Т.е. я считаю что "C++ CLI" это в основном маркетинг направленный на завлечение — "иди к нам у нас крутяк!", а далее пришедьший плавно переползает на шарп.
2) Про .NET:
Некоторое количество технических решений + большое количество сервисов + агрессивный маркетинг сделают платформу достаточно привлекательной для большого количества разработчиков под Win. Ничего принципиально нового, или напрочь отсутствующего в других средах пока не видно и вроде не предвидиться. Как замена быстрой разработке на VB или Delphi — вполне нормально.
Поэтому причин для ажиотажа по моему нет.
Здравствуйте, Tonal-, Вы писали:
T>1) Про C++ CLI:
Всё так.
T>2) Про .NET: T>Некоторое количество технических решений + большое количество сервисов + агрессивный маркетинг сделают платформу достаточно привлекательной для большого количества разработчиков под Win. Ничего принципиально нового, или напрочь отсутствующего в других средах пока не видно и вроде не предвидиться. Как замена быстрой разработке на VB или Delphi — вполне нормально.
Для Java разработчиков может и не так уж много, а для VB, VC++ и других Win-девелоперов нового предостаточно.
T>Поэтому причин для ажиотажа по моему нет.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tonal-, Вы писали:
T>Поэтому причин для ажиотажа по моему нет.
Вот именно.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alexkro, Вы писали:
A>>Я про то, что нужно это видеть с первого взгляда.
IT>А нужно ли это?
A>>Смотришь на использование класса и сразу можешь сказать, managed это или native,
IT>Ну посмотрел, сказал и что дальше?
Ты не понимаешь зачем это нужно? Когда проект большой и запутанный, каждый чих на счету.
Здравствуйте, alexkro, Вы писали:
A>>>Смотришь на использование класса и сразу можешь сказать, managed это или native,
IT>>Ну посмотрел, сказал и что дальше?
A>Ты не понимаешь зачем это нужно?
Я понимаю зачем это не нужно.
A>Когда проект большой и запутанный, каждый чих на счету.
Вот как раз когда проэкт большой и запутанный, то такими чихами лучше заниматься компилятору, а не программисту.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alexkro, Вы писали:
A>>Когда проект большой и запутанный, каждый чих на счету.
IT>Вот как раз когда проэкт большой и запутанный, то такими чихами лучше заниматься компилятору, а не программисту.
Для компилятора это не проблема, он любой сложности код разберет. А вот человеку этот код читать и понимать нужно.
Здравствуйте, alexkro, Вы писали:
IT>>Вот как раз когда проэкт большой и запутанный, то такими чихами лучше заниматься компилятору, а не программисту.
A>Для компилятора это не проблема, он любой сложности код разберет. А вот человеку этот код читать и понимать нужно.
Именно поэтому чем проще этот код, тем легче его читать и понимать.
A>PS: Are you playing devil's advocate here?
I'm just trying to keep your poor soul away from troubles.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, alexkro, Вы писали:
A>Извини меня, но это — вода.
Это вполне взвешенное мнение, которому ты пока не в состоянии возразить
То что C++ устарел и нуждается в модернизации давно известный факт. И пока комитет абсолютно не ловит мышей, его улучшениями занимаются всевозможные добровольники. Результат на лицо. Перед нами рождается очередной монстр, на котором будут писать только его создатели и жалкая кучка поклонников-фанатов. Чистота и красота языка (до сих пор уничтожавшаяся грубыми конструкциями всяких WIN API, MFC, ATL и прочая) окончательно утеряна, синтаксис замусорен совершенно бредовыми конструкциями, в язык насильственно имплантирована ещё одна модель памяти (кстати, интересно как она будут стыковаться с классической адресной арифметикой), труды классиков поруганы. И после всего этого ты смеешь утверждать, что это всё вода?!?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alexkro, Вы писали:
A>>Для компилятора это не проблема, он любой сложности код разберет. А вот человеку этот код читать и понимать нужно.
IT>Именно поэтому чем проще этот код, тем легче его читать и понимать.
В данном случае я вижу в твоих словах: чем меньше конструкций в языке, тем проще код.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alexkro, Вы писали:
A>>Извини меня, но это — вода.
IT>Это вполне взвешенное мнение, которому ты пока не в состоянии возразить
IT>Для Java разработчиков может и не так уж много, а для VB, VC++ и других Win-девелоперов нового предостаточно.
А кто же их (разработчиков) заставлял ограничиваться только VB, или Java?
Если-бы народ больше уделял времени образованию, воплей о "передовом шаге вперёд" по поводу .NET или Java просто не было-бы
IT>То что C++ устарел и нуждается в модернизации давно известный факт.
Вы просто не умеете его готовить.
Из всего предложенного MS в "C++ CLI Candidate Base Draft" только generic-и не реализуються напрямую, т.к. для их реализации требуется присутствие компилятора в rtl. Остальное довольно просто реализуется стандартными средствами. И введение частной формы реализации в стандарт я не считаю оправданным.
Плюс содержит достаточно выразительных средств, чтобы разрабатывать на нём достаточно быстрые, большие, гибкие програмные комплексы. Другое дело, что для этого недостаточно только языка, т.к. он не формализует несвойственные языку вещи, как то форматы исполняемых файлов и файлов данных, протоколы межпроцесного и межмашинного взаимодействия, сервисы операционной системы, модели взаимодействия с пользователем, и т.д.
Грубо говоря, любой програмный комплекс (п.к.) кроме языка реализации сильно зависит от применяемого компилятора и библиотек, операционной системы, технологических процессов, средств коммуникации, принятых в отрасли спецификаций и форматов данных. При изменении любой из составляющих приходиться изменять п.к., часто довольно существенно. .NET — это очередная попытка зафиксировать некоторые из этих составляющих. В первую очередь это библиотеки, сервисы операционной системы, средства коммуникаций. Идея вполне здравая, и для Win-ды скорее всего прокатит стараниями MS. Другое дело что не так быстро и не так глобально, как об этом говорят (вспоминается COM который так и не захватил *nix, не вытеснил CORBA, да и в Win-де не всё API на него перевели).
Здравствуйте, Tonal-, Вы писали:
A>>Извини меня, но это — вода. T>Извиняю. А где вода?
Вместо того, чтобы выразить конкретные претензии к C++/CLI, ты разводишь пространный разговор о сложности и противоречивости, пугаешь какими-то глюками и бросаешься необосноваными заявлениями об отсутствии wchar_t в Стандарте. Потом даешь очень странную оценку C++/CLI в целом опять-же с позиций Fear, Uncertainty & Doubt.
Здравствуйте, Tonal-, Вы писали:
IT>>Для Java разработчиков может и не так уж много, а для VB, VC++ и других Win-девелоперов нового предостаточно.
T>А кто же их (разработчиков) заставлял ограничиваться только VB, или Java?
Время. К сожалению в сутках только 24 часа.
T>Если-бы народ больше уделял времени образованию, воплей о "передовом шаге вперёд" по поводу .NET или Java просто не было-бы
Думаю, что образование тут не при чём. По сравнению с C++/COM .NET действительно большой шаг вперёд. Это очень хорошо видно по сокращению сроков разработки и одновременно сокращению затрат на подготовку персонала.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, alexkro, Вы писали:
IT>>Именно поэтому чем проще этот код, тем легче его читать и понимать.
A>В данном случае я вижу в твоих словах: чем меньше конструкций в языке, тем проще код.
Почти так. Чем меньше конструкций используемых в одно одтельно взятом участке кода.
Если нам не помогут, то мы тоже никого не пощадим.
DG>Т.е. всё пишем сами? А заказчик стоимость разработки велосипедов готов оплачивать? DG>Или ему уже посоветовали соседнюю фирму, в которой стоимость разработки будет меньше, потому что они не изобретают велосипеды?
DG>Не чую. .Net предоставляет более дешевый способ решения многих проблем, и пока ты не предложишь такой же по дешевизне способ для решения этих задач, то те разработчики, которые используют .Net, будут в более выигрышном положении, чем ты. DG>А значит и заказчики пойдут не к тебе.
Вы тут дорогой товарищ чтото говорите о том насколько использование НЕТ выгоднее чем С++. Давайте обратимся к фактам. Давай так сказать что нужно народному хозяйству (я подобную тему уже кидал для Делфи вс С++ — результаты оказались неутешительные для Делфи )) )
И так
Заходим на job.ru и делаем поиск
1)
Раздел: Информационные технологии и Интернет
Город: Москва
Образование: Высшее
Опыт работы: 1 год
Заработная плата от $: 1000
График работы: Полный день
Занятость: Полная
Ключевые слова: C#
Все слова
Сортировать по: по зарплате
Тип сортировки: по убыванию
Просматривать на странице: 20 объявлений
2)
Раздел: Информационные технологии и Интернет
Город: Москва
Образование: Высшее
Опыт работы: 1 год
Заработная плата от $: 1000
График работы: Полный день
Занятость: Полная
Ключевые слова: C++
Все слова
Сортировать по: по зарплате
Тип сортировки: по убыванию
Просматривать на странице: 20 объявлений
То есть налицо — рынок нуждается в С++ программерах больше чем в С# программерах в 6 раз сильнее и ценяться в 3 раза больше. То есть готовы товарищи потерпеть и шаблоны, больной непонятный код, и длительную разработку и т.п. А вот за шарп и нет с его скоростью, удобством и тп мало чтото платят. Наверное лохи, как и с делфи нихрена не соображают. (Кстати соотношение объяв С++/Делфи так же бяло приблизительно таким же в 5 раз больше и в 3 раза дороже) Так что "Факты — вещь упрямая" И.В.Сталин.
Здравствуйте, Glоbus, Вы писали:
G>То есть налицо — рынок нуждается в С++ программерах больше чем в С# программерах в 6 раз сильнее и ценяться в 3 раза больше. То есть готовы товарищи потерпеть и шаблоны, больной непонятный код, и длительную разработку и т.п. А вот за шарп и нет с его скоростью, удобством и тп мало чтото платят. Наверное лохи, как и с делфи нихрена не соображают. (Кстати соотношение объяв С++/Делфи так же бяло приблизительно таким же в 5 раз больше и в 3 раза дороже) Так что "Факты — вещь упрямая" И.В.Сталин.
Проблема только в их трактовке. Я вот например трактую так — на С++ ведется море старых проектов, а на шарпе новые только появляются. И при этом шарп вполне адекватен. А еще могу привести другие факты — количество объявлений в форуме на этом сайте по шарпу уж точно никак не меньше чем по С++. Почему то этот факт я ценю больше.
Здравствуйте, mikа, Вы писали:
ГВ>>Mika, это уже бесполезный флейм начнётся. Давай в приват по этому поводу, моё мыло — в профайле.
M>Хочешь отойти побазарить? Давай!
Ты, главное, рекламный щит найди
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Hello, "oRover"
> не флейма ради хочу спросить — есть ли где-нибудь еще Reflection кроме как в НЕТ?
Конечно. Он есть в COM (IProvideClassInfo, ITypeInfo). Правда, в отличии от .NET, поддержка интерфейсов является опциональной, и может отсутсвовать, но в целом — это чистой воды Reflection и отрицать его наличие нельзя.
Posted via RSDN NNTP Server 1.8 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Jenyay, Вы писали:
J>Здравствуйте, Геннадий Васильев, Вы писали:
J>Сегодня понял, что .NET (особенно C#) идеально подходит, если надо по-быстрому набросать программку "для себя" или одноразового использования.
Раньше для этого использовался Васик
Одинаковые ошибки необязательно делать каждый раз, достаточно сделать одну, а затем обращаться к ней по мере необходимости из любого места программы.
A>Вместо того, чтобы выразить конкретные претензии к C++/CLI, ты разводишь пространный разговор о сложности и противоречивости, пугаешь какими-то глюками и бросаешься необосноваными заявлениями об отсутствии wchar_t в Стандарте. Потом даешь очень странную оценку C++/CLI в целом опять-же с позиций Fear, Uncertainty & Doubt.
Извини, про wchar_t — прогнал. Пошел на поводу у компилятора MS (v 7.0), который по умолчанию не считает wchar_t типом.
Могу добавить, что введение в язык "свойств" неоднократно обсуждалось в самых разных местах, постоянно отколенялось комитетом. Достаточно доходчивое описание причин можно найти в "Дизайне и эволюции С++" Страуструпа. Там же очень хорошо описано и аргументировано общее отношение к нововведениям в язык.
Как я уже говорил, всё что описано в предложении, исключая generics, имеет множество реализаций на плюсе:
Сборка мусора — как простые бесплатные библиотеки, так и мощные, идущие в составе с различными ООБД
Хенделы — разнообразные "умные указатели"
Свойства — достаточно просто эмулируются,
Так же как и события и делегаты...
И дело даже не в том, что MS хочет "унифицировать" поведение всех подобных реализаций. В конце концов им же надо как-то представить в языке стандартные .NET-овские фичи. Дело в том, как эти дополнительные сущьности интегрировать в язык?
Например какой тип будет у такого выражения:
struct ttt {
property int x { int get() {return 0;}}
};
&ttt().x
и будет ли он отличатся от
ref struct ttt {
property int x { int get() {return 0;}}
};
&ttt().x
как будет соотноситься с
struct ttt {
int x;
};
&ttt().x
или
struct ttt {
int x();
};
&ttt().x
как "свойства" можно/нельзя использовать с шаблонами, объединениями, статическими инициализаторами...
И такие вопросы возникают по каждому нововведению. А если их (нововведений) несколько, то можешь сам прикинуть сложность нормального интегрирования всего этого в язык. И если не сделать это формально, получится всеми любимый "implementation defined", изменяющийся от версии к версии...
Для справки, MSVC, с версии по моему 5 (хотя могу ощибаться) поддерживает механизм свойств для структур и классов. Правда почему-то не сильно рекламируют.
Да, о попытке борланда расширить язык, я кажется уже говорил. Это, помоему, наиболее близкий пример. Предсказать как будет работать какая-нибудь конструкция в новом релизе, порой просто невозможно, понять почему что-то работает/не работает, без серъёзного изучения исходников rtl + дебаггер + IDA, ну и объяснить молодому коллеге что и почему следует/не следует делать...
Так что, считаю свои выводы о C++/CLI достаточно логичными.
T>>Если-бы народ больше уделял времени образованию, воплей о "передовом шаге вперёд" по поводу .NET или Java просто не было-бы IT>Думаю, что образование тут не при чём. По сравнению с C++/COM .NET действительно большой шаг вперёд. Это очень хорошо видно по сокращению сроков разработки и одновременно сокращению затрат на подготовку персонала.
Подобное наблюдается и при переходе на VB/Delphi. Толко почему-то эти среды многие не воспринимают серьёзно.
А если без приколов, то сокращение сроков разработки и обучения объясняется более развитым framework-ом, интуитивностью техники разработки "тащи и бросай" и большим количеством "визардов".
Вот только часто приходиться наблюдать, как для того, чтобы отсортировать массив, на форму "кидают" конект к БД...
J>Сегодня понял, что .NET (особенно C#) идеально подходит, если надо по-быстрому набросать программку "для себя" или одноразового использования.
Обычно использую для этого Python, C++, Perl, bat/cmd, JavaScript — по обстоятельствам.
Здравствуйте, oRover, Вы писали:
R>не флейма ради хочу спросить — есть ли где-нибудь еще Reflection кроме как в НЕТ?
Кроме того, о чём уже здесь сказали — Lisp.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Tonal-, Вы писали:
T>Подобное наблюдается и при переходе на VB/Delphi. Толко почему-то эти среды многие не воспринимают серьёзно.
Это вражеские языки
T>А если без приколов, то сокращение сроков разработки и обучения объясняется более развитым framework-ом, интуитивностью техники разработки "тащи и бросай" и большим количеством "визардов".
Визардов по сравнению с тем же MFC стало может быть даже меньше. Объясняется ещё простотой языка. Но больше всего простотой отладки и поиска ошибок. Ловля мемори ликов или неинициализированных указателей в релизе — занятие не для слабонервных. А уж за COM я вообще молчу.
T>Вот только часто приходиться наблюдать, как для того, чтобы отсортировать массив, на форму "кидают" конект к БД...
Ну это уж никуда не денется
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Glоbus, Вы писали:
G>То есть налицо — рынок нуждается в С++ программерах больше чем в С# программерах в 6 раз сильнее и ценяться в 3 раза больше. То есть готовы товарищи потерпеть и шаблоны, больной непонятный код, и длительную разработку и т.п. А вот за шарп и нет с его скоростью, удобством и тп мало чтото платят. Наверное лохи, как и с делфи нихрена не соображают. (Кстати соотношение объяв С++/Делфи так же бяло приблизительно таким же в 5 раз больше и в 3 раза дороже) Так что "Факты — вещь упрямая" И.В.Сталин.
Сейчас ситуация такая. В будущем она должна обязательно изменится.
В отчете GG (весна 2003) приводит такой прогноз:
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Glоbus, Вы писали:
G>>То есть налицо — рынок нуждается в С++ программерах больше чем в С# программерах в 6 раз сильнее и ценяться в 3 раза больше. То есть готовы товарищи потерпеть и шаблоны, больной непонятный код, и длительную разработку и т.п. А вот за шарп и нет с его скоростью, удобством и тп мало чтото платят. Наверное лохи, как и с делфи нихрена не соображают. (Кстати соотношение объяв С++/Делфи так же бяло приблизительно таким же в 5 раз больше и в 3 раза дороже) Так что "Факты — вещь упрямая" И.В.Сталин.
AVK>Проблема только в их трактовке. Я вот например трактую так — на С++ ведется море старых проектов, а на шарпе новые только появляются. И при этом шарп вполне адекватен. А еще могу привести другие факты — количество объявлений в форуме на этом сайте по шарпу уж точно никак не меньше чем по С++. Почему то этот факт я ценю больше.
Слабо мне верится, что все эти объявы (сишные) — это суппорт старых прожектов. Тем более где требуются тим-лидеры за 3000 уе. Такое бы объяснение еще пошло для прости господи каких-нибудь лиспов или ада. Просто надо учитывать, что производители ПО инетртны. А .Нет — это еще тема неустоявшаяся, никто не знает толком ее возможностей и внятно не может сказать почему лучше что-то писать на шарпе, чем на плюсах. Есть конечно отрасли (например веб с асп.нет), где все это модное дело клево рулит — там конечно МС убрали всех по скорости и удобству разработки. Но все-же настораживает в НЕТе много вещей. Както необходимость иметь НЕТ Фреймворк на машине для десктопа. Вот жаба например на этом деле погорела. Не хочет никто ставить себе все эти довески и т.п.
Так что возвращаясь к вопросу о том где место НЕТ можно с уверенностью сказать, что никто этого пока не знает — не заняло еще великое и ужасное "Оно" нишу на рынке. Вот лет через пяток можно будет смотреть. А пока это все загибалово пальцев — пацаны в форуме рассказывают друг другу как они много знают из разных областей (и это кстати очень интересно почитать).
А насчет объяв на это форуме — надо сказать что далеко не каждый работодатель знает о его существовании. Спорить готов, что в раздел ИТ на какой-нить жоб.ру или в этом духе приходит в день раз 5 больше объяв, чем сюда. Какая-нибудь Анечка из HR-отдела уж точно не знает о существовании рсдн.ру. То есть опять мы видим что срез объяв на этом сайте (всех — и по плюсам, и по шарпу) весьма ограничен.
Здравствуйте, Glоbus, Вы писали:
G>Слабо мне верится, что все эти объявы (сишные) — это суппорт старых прожектов.
Вопросы веры обсуждать бессмысленно.
G>Вот жаба например на этом деле погорела.
Вряд ли на этом. JVM 1.1 есть почти везде.
G> Так что возвращаясь к вопросу о том где место НЕТ можно с уверенностью сказать, что никто этого пока не знает — не заняло еще великое и ужасное "Оно" нишу на рынке. Вот лет через пяток можно будет смотреть. А пока это все загибалово пальцев — пацаны в форуме рассказывают друг другу как они много знают из разных областей (и это кстати очень интересно почитать).
Ну вобще то я лично не один проект на дотнете написал. И этот сайт включает в себя несколько таких проектов. Так что все таки не только загибалово.
G> А насчет объяв на это форуме — надо сказать что далеко не каждый работодатель знает о его существовании.
Каким образом это может сказаться на процентном отношении требуемых технологий?
G> Спорить готов, что в раздел ИТ на какой-нить жоб.ру или в этом духе приходит в день раз 5 больше объяв, чем сюда. Какая-нибудь Анечка из HR-отдела уж точно не знает о существовании рсдн.ру.
А что, Анечка из HR уже показатель востребованности технологий? Несмотря на то что здесь объявлений разумеется меньше, мусора среди них меньше в разы — предложений от кадровых агенств и анечек нет, поскольку в отличие от job.ru надо отвечать на вопросы.
G> То есть опять мы видим что срез объяв на этом сайте (всех — и по плюсам, и по шарпу) весьма ограничен.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Glоbus, Вы писали:
G>>Слабо мне верится, что все эти объявы (сишные) — это суппорт старых прожектов.
AVK>Вопросы веры обсуждать бессмысленно.
Давай не будем отпускать едких замечаний, мой благородный друг
G>>Вот жаба например на этом деле погорела.
AVK>Вряд ли на этом. JVM 1.1 есть почти везде.
Где везде? И какие десктоп программы ты видел на жабе? жвм 1.1 есть в браузерах ты имеешь в виду? Я чтото не слышал чтобы с поставками ОС шли жвм. И кстати что можно написать с использованием ждк 1.1. Сила жабы начинается с цыфири 1.2 и выше — жсп/сервлеты, ж2ее и т.п. А это уже пардон не десктоп.
G>> Так что возвращаясь к вопросу о том где место НЕТ можно с уверенностью сказать, что никто этого пока не знает — не заняло еще великое и ужасное "Оно" нишу на рынке. Вот лет через пяток можно будет смотреть. А пока это все загибалово пальцев — пацаны в форуме рассказывают друг другу как они много знают из разных областей (и это кстати очень интересно почитать).
AVK>Ну вобще то я лично не один проект на дотнете написал. И этот сайт включает в себя несколько таких проектов. Так что все таки не только загибалово.
Старик, да пиши на здоровье — я только горд буду что поручкался с таким человеком — это не наезд. На аде тоже немало прожектов написали — ну и где они (прожекты). На делфях тоже много прожектов написано пишут и будут написаны — это говорит о том что у делфей есть своя ниша. У шарпа этой ниши еще нет. Понимэ?
G>> А насчет объяв на это форуме — надо сказать что далеко не каждый работодатель знает о его существовании.
AVK>Каким образом это может сказаться на процентном отношении требуемых технологий?
Да, вот каким образом то, что на рсдн.ру соотношение объяв по шарпу и плюсам как ты утверждаешь приблизительно одинаково может сказаться на востребованности технологии. Правильно — никак. Если ты забыл, вопрос не стоял как зависит востребованность технологии от оъяв на сайте а совсем наоборот. Я тебе цифирь привел, ты мне сказал что на рсдн соотношение не такое критичное. Я спросил — сколько объяв по работе ежедневно приходит на рсдн?
G>> Спорить готов, что в раздел ИТ на какой-нить жоб.ру или в этом духе приходит в день раз 5 больше объяв, чем сюда. Какая-нибудь Анечка из HR-отдела уж точно не знает о существовании рсдн.ру.
AVK>А что, Анечка из HR уже показатель востребованности технологий? Несмотря на то что здесь объявлений разумеется меньше, мусора среди них меньше в разы — предложений от кадровых агенств и анечек нет, поскольку в отличие от job.ru надо отвечать на вопросы.
Анечка из HR отдела по указке босса рассылает объявы по сайтилам. Я удивлен что ты не понял этой моей мысли. А мусора среди них столько же. Зайти в раздел работа так там каждое второе объявление или без вилки з/п или с какими-то мутными требованиями от асма до html-а с опытом работы от 430 лет и з/п в 100 уе. Конечно насчет кадровых агенств ты прав, а вот с Анечкой погарячился.
G>> То есть опять мы видим что срез объяв на этом сайте (всех — и по плюсам, и по шарпу) весьма ограничен.
AVK>И что из этого следует?
Из этого следует, что сюда присылают объявы в основном люди которые знают о существовании сайта. Я думаю, для тебя не будет секретом что сайтила этот весьма специфической направленности и хорошо с ним знакомы в основном люди которые сами педалят или педалили. А теперь по каким то причинам (скажем организовалась новая контора) человек переходит в разряд менеджмента и начинает поиск сотрудников. Если предположить что перед был связан именно с организацией новой конторы то этот чел там сам себе и ХР-отдел(Анечка), и дирехтур и бухгалтер и тим-лидер. То есть контора прям скажем средняя. То есть срез ИТ-контор далеко не полный. иожет я че-то пропустил, но ткни мне пальцем в объявы о работе крупных контор в разделе "работа".
А то что как ты сказал на вопросы надо отвечать — не надо. Как ты меня заставишь ))) Я объяву кинул (так же как на жоб.ру) и все — пишите сколько хотите. Кто заинтересуется — привалит, кто захочет — говном польет. На второе крупно положить с прибором. Или мало таких примеров в том же разделе работы? (Кстати может это и плюс жоб.ру что туда нельзя отклики слать — а то там бы поднялся хай — то вилка з/п слишком маленькая, а то слишком большая, а то вместо С/С++ надо писать С++/С — видел я такую ветку в разделе работа ))) )
Здравствуйте, AVM, Вы писали:
AVM>Здравствуйте, Glоbus, Вы писали:
G>>То есть налицо — рынок нуждается в С++ программерах больше чем в С# программерах в 6 раз сильнее и ценяться в 3 раза больше. То есть готовы товарищи потерпеть и шаблоны, больной непонятный код, и длительную разработку и т.п. А вот за шарп и нет с его скоростью, удобством и тп мало чтото платят. Наверное лохи, как и с делфи нихрена не соображают. (Кстати соотношение объяв С++/Делфи так же бяло приблизительно таким же в 5 раз больше и в 3 раза дороже) Так что "Факты — вещь упрямая" И.В.Сталин.
AVM>Сейчас ситуация такая. В будущем она должна обязательно изменится. AVM>В отчете GG (весна 2003) приводит такой прогноз:
AVM>
AVM>Сам отчет находится на: http://www.gartnervoice.com/homepageApril2003/enetvJavaDW.pdf
AVM>С уважением, AVM>AVM
1) А что такое ГГ?
2) Мне интересно как можно делать прогнозы относительно технологии, про которую пока мало что известно. Я там почитал — куча веточек про лонгхорн появилось — всё пишут что там сплошной Нет будет. Но в то же время в ссылке, которую дал один товарищ на сайтиле мс ясно было написано самими же мс-овцами — вин32 никуда не уходит и работа через вин апи всегда будет эффективнее, чем через настройку какую-нить.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Glоbus, Вы писали:
ВВ>Вот почитаешь ваши заявления и диву даешься — как же я еще с голоду не умер?
.
T>Могу добавить, что введение в язык "свойств" неоднократно обсуждалось в самых разных местах, постоянно отколенялось комитетом. Достаточно доходчивое описание причин можно найти в "Дизайне и эволюции С++" Страуструпа. Там же очень хорошо описано и аргументировано общее отношение к нововведениям в язык.
Мне это прекрасно известно. Properties ввести в стандарт языка навряд-ли возможно. Однако в C++/CLI дело в другом: их там нельзя не ввести. Полное объяснение смотри ниже.
T>Как я уже говорил, всё что описано в предложении, исключая generics, имеет множество реализаций на плюсе: T>Сборка мусора — как простые бесплатные библиотеки, так и мощные, идущие в составе с различными ООБД T>Хенделы — разнообразные "умные указатели" T>Свойства — достаточно просто эмулируются, T>Так же как и события и делегаты...
Не спорю. C++ вообще достаточно сбалансированный язык. А generics без отношения к .NET не имеют смысла. А вот на счет GC позволю себе следующее высказывание: C++ не приемлет compacting GC, так как он (GC) любит двигать объекты в памяти и изменять на них указатели. Но в C++ указатели должны быть стабильны — это одна из фундаментальных основ языка. Это, кстати, и послужило толчком к введению хэндлов.
T>И дело даже не в том, что MS хочет "унифицировать" поведение всех подобных реализаций. В конце концов им же надо как-то представить в языке стандартные .NET-овские фичи. Дело в том, как эти дополнительные сущьности интегрировать в язык?
C++/CLI bindings — это расширения языка предназначенные только если ты пишешь под .NET. Никак иначе они не влияют на язык. Одно из следствий это то, что для стандартной структуры нельзя объявить property, например.
T>Например какой тип будет у такого выражения: T>
T>struct ttt {
T> property int x { int get() {return 0;}}
T>};
Нельзя.
T>&ttt().x
T>
T>и будет ли он отличатся от T>
T>ref struct ttt {
T> property int x { int get() {return 0;}}
T>};
T>&ttt().x
T>
ttt::x — это не data member, от него нельзя взять адрес.
T>как будет соотноситься с T>
T>struct ttt {
T> int x;
T>};
T>&ttt().x
T>
T>или T>
T>struct ttt {
T> int x();
T>};
T>&ttt().x
T>
Почему ты автоматически решил, что от property можно взять адрес? Property похож на data member по использованию и только. В остальном никакой связи нет. Это, конечно, является несогласованностью в языке, которая в стандарте, например, не допустима. Но для C++/CLI эта проблема носит разве что академический характер.
T>как "свойства" можно/нельзя использовать с шаблонами, объединениями, статическими инициализаторами...
Поподробнее об этих проблемах можно?
T>И такие вопросы возникают по каждому нововведению. А если их (нововведений) несколько, то можешь сам прикинуть сложность нормального интегрирования всего этого в язык.
Интересно то, что эти "нововведения" и раньше были (на концептуальном уровне) в managed extensions for C++. Большинство из них сейчас только примут человеческое представление. Самым радикальным нововведением является, однако, handles.
> И если не сделать это формально, получится всеми любимый "implementation defined", изменяющийся от версии к версии...
Вот для этого и нужен стандарт ECMA. Как только это там определено, никакие отклонения не допустимы.
T>Для справки, MSVC, с версии по моему 5 (хотя могу ощибаться) поддерживает механизм свойств для структур и классов. Правда почему-то не сильно рекламируют.
От того, что они в стандартном C++ отсутствуют и для нормального программирования на C++ не нужны. Но это не меняет ситуацию с C++/CLI.
T>Да, о попытке борланда расширить язык, я кажется уже говорил. Это, помоему, наиболее близкий пример. Предсказать как будет работать какая-нибудь конструкция в новом релизе, порой просто невозможно, понять почему что-то работает/не работает, без серъёзного изучения исходников rtl + дебаггер + IDA, ну и объяснить молодому коллеге что и почему следует/не следует делать...
Больших проблем, как ты предрекаешь, не будет. Эти расширения же не на пустом месте появились. Они являются всего лишь проекцией .NET'овских понятий на пространство C++. Поэтому common sense will apply. По крайней мере, я о таких проблемах еще не слышал, поэтому для меня было удивительно, что ты сравнил это с борландовскими расширениями.
Молодым коллегам, конечно прийдется туго. Но, в конце концов, для них есть C#. Также, легкость обучения C++/CLI не является приоритетом на данном этапе.
T>Так что, считаю свои выводы о C++/CLI достаточно логичными.
Ты смотришь на C++/CLI с позиций стандартного C++, а это не правильно. C++/CLI создается для того, чтобы на C++ можно было программировать для .NET, причем используя C++ как основной язык, а не дополнение к C# или VB. Это и определяет основные требования к C++/CLI как языку.
Во-первых (1), все понятия CLI должны быть представлены в C++/CLI без исключений.
Во-вторых (2), все широко распостранённые понятия других языков для .NET должны быть представлены в C++/CLI. Сюда входят, например, properties, чего как такового в CLI нет (то бишь это всего лишь методы с соответствующим аттрибутом).
В-третьих (3), нормальная программа на C++/CLI не должна выглядеть кривее нормальной программы на других языках.
В-четвертых (4), основные идиомы C++ должны работать в C++/CLI.
Теперь давай плясать от этих требований.
Properties. Ну просто нельзя не ввести в соответствии с (2) и (3). Здесь C++/CLI идет дальше, чем другие языки .NET, и вводит default properties. Это очень хорошо соответствует намерению сделать С++ одним из основных языков для .NET.
Handles. Многим не понравившиеся. А зря. Очень красивое решение.
Проблема (которую выявили managed extensions): указатели C++ (на хипе) не имеют ничего общего с GC указателями.
Указатель на хипе:
1) стабилен. Ничто извне не может его изменить. Это широко используется в повседневной практике (например, на это полагается реализация set< string * >).
2) работает pointer arithmetics.
3) объект, на который указывает указатель выделяется с помощью new, а уничтожается delete'ом.
GC указатель:
1) может изменяться извне.
2) pointer arithmetics не имеет смысла и просто опасна.
3) GC занимается выделением и освобождением объектов. Никакое влияние или переопределение недопустимо.
В следствие несовместимости основных свойств, C++ указатели и GC указатели не имеют ничего общего. А если сформулировать по другому, то чем оперирует GC не является C++ указателями. Ну, и логично сказать, что в managed extensions синтаксис для работы с GC объектами был притянут к синтаксису C++ указателей за уши.
Это на теоретическом уровне. На практическом, возьмем следующий код:
String * str = new String( "abcd" );
//... много кода
str + 5; // имеет ли это смысл?delete str; // а это?
set< String * > strs; // или это?
В C++ ответ однозначен — имеет. Но с появлением managed extensions все становится как-то неоднозначно. И это плохо.
Поэтому было введено расширение в систему типов C++ — handles.
Насчет, синтаксиса, вопрос отделный. Ясно, что он должен отличаться от синтаксиса указателей. To cut to the chase, ^ является наилучшим решением с точки зрения требования (3). Все, что длиннее чем один символ (например, gc_ptr<>) хуже, так как при программировании для .NET handles будут использоваться повсеместно.
После этого gcnew кажется естественным продолжением основной идей с handles.
Как следствие, настоящее положение дел в C++/CLI позволяет (эффективно) создавать GC объекты и на хипе, и на стеке (как это реализуется, ты, наверное, уже знаешь):
String ^ str = gcnew String(); // System::String on GC heap
String * str = new String(); // System::String on C++ heap
String str; // System::String on C++ stack
Еще интереснее создавать стандартные C++ объекты на GC хипе, чему, как ты понимаешь теперь ничего не мешает. В общем говоря, появляется возможность смешивать C++ и GC классы.
G>Из этого следует, что сюда присылают объявы в основном люди которые знают о существовании сайта.
Согласен. Если сделать без фреймов клоакинг с ключаевыми словами
"Работа вакансия Айти то се", ежеденевно обновляемый, тут целая лавина начнется (айтиперсонел то се), даже стебаться лень будет всем. + в КА рассылочку сделать — постите мол сюда.
G> прибором. Или мало таких примеров в том же разделе работы? (Кстати может это и плюс жоб.ру что туда нельзя отклики слать — а то там бы поднялся хай — то вилка з/п слишком маленькая, а то слишком большая, а то вместо С/С++ надо писать С++/С — видел я такую ветку в разделе работа ))) )
нормально перекрылись две ветки — там про дот нэт, тут про c/c++
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, Glоbus, Вы писали:
G>>>Слабо мне верится, что все эти объявы (сишные) — это суппорт старых прожектов.
AVK>>Вопросы веры обсуждать бессмысленно.
G>Давай не будем отпускать едких замечаний, мой благородный друг
Почему едких? Вопросы веры действительно глупо обсуждать. Ты веришь, я нет. Аргументов никаких.
AVK>>Вряд ли на этом. JVM 1.1 есть почти везде.
G>Где везде?
Если у тебя не ХР то попробуй набери java в консоли.
G> И какие десктоп программы ты видел на жабе?
А какое это имеет отношение к обсуждаемому вопросу?
G> жвм 1.1 есть в браузерах ты имеешь в виду?
Оно либо есть, либо его нету. А в браузерах всего лишь плагин, использующий обычную jvm.
G> Я чтото не слышал чтобы с поставками ОС шли жвм.
Во всех 32-хбитных виндах за исключением ХР.
G> И кстати что можно написать с использованием ждк 1.1.
Много.
G> Сила жабы начинается с цыфири 1.2 и выше — жсп/сервлеты, ж2ее
Ты там помниться про десктоп и проблемы распространения JRE речь заводил. Все что ты перечислил это серверные технологии и у них то как раз проблемы поставить JRE нет никакой.
G> и т.п. А это уже пардон не десктоп.
Вот именно.
AVK>>Ну вобще то я лично не один проект на дотнете написал. И этот сайт включает в себя несколько таких проектов. Так что все таки не только загибалово.
G>На аде тоже немало прожектов написали — ну и где они (прожекты).
Наши посмотреть можно. Работают, куча народа софтом пользуется. Чего тебе еще надо?
G> На делфях тоже много прожектов написано пишут и будут написаны — это говорит о том что у делфей есть своя ниша. У шарпа этой ниши еще нет.
На основании чего сделан вывод?
G>>> А насчет объяв на это форуме — надо сказать что далеко не каждый работодатель знает о его существовании. AVK>>Каким образом это может сказаться на процентном отношении требуемых технологий?
G>Да, вот каким образом то, что на рсдн.ру соотношение объяв по шарпу и плюсам как ты утверждаешь приблизительно одинаково может сказаться на востребованности технологии. Правильно — никак.
Тогда это не аргумент.
G> Если ты забыл, вопрос не стоял как зависит востребованность технологии от оъяв на сайте а совсем наоборот.
Я не забыл — вопрос стоял в соотношении востребованности таких девелоперов. На основании чего я должен доверять job.ru больше чем rsdn.ru?
G> Я тебе цифирь привел, ты мне сказал что на рсдн соотношение не такое критичное. Я спросил — сколько объяв по работе ежедневно приходит на рсдн?
Посчитай сам.
G>>> То есть опять мы видим что срез объяв на этом сайте (всех — и по плюсам, и по шарпу) весьма ограничен. AVK>>И что из этого следует?
G>Из этого следует, что сюда присылают объявы в основном люди которые знают о существовании сайта. Я думаю, для тебя не будет секретом что сайтила этот весьма специфической направленности
Какой? И как эта направленность влияет на соотношение дотнет и С++ разработчиков?
Здравствуйте, alexkro, Вы писали:
A>Во-вторых (2), все широко распостранённые понятия других языков для .NET должны быть представлены в C++/CLI. Сюда входят, например, properties, чего как такового в CLI нет (то бишь это всего лишь методы с соответствующим аттрибутом).
Вобщето в метаданных присутствует понятие именно свойства, так что заявлять о его отсутствии в CLI вобще то некорректно.
A>В следствие несовместимости основных свойств, C++ указатели и GC указатели не имеют ничего общего.
Вопрос только в одном — а нужны ли в дотнете обычные указатели?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Glоbus, Вы писали:
G>>>>Слабо мне верится, что все эти объявы (сишные) — это суппорт старых прожектов.
AVK>>>Вопросы веры обсуждать бессмысленно.
G>>Давай не будем отпускать едких замечаний, мой благородный друг
AVK>Почему едких? Вопросы веры действительно глупо обсуждать. Ты веришь, я нет. Аргументов никаких.
AVK>>>Вряд ли на этом. JVM 1.1 есть почти везде.
G>>Где везде?
AVK>Если у тебя не ХР то попробуй набери java в консоли.
G>> И какие десктоп программы ты видел на жабе?
AVK>А какое это имеет отношение к обсуждаемому вопросу?
Это имеет отношение в твоей фразе что жвм есть почти везде. И само собой напрашивается вопрос — а что на нем пишут тем более на 1.1
G>> жвм 1.1 есть в браузерах ты имеешь в виду?
AVK>Оно либо есть, либо его нету. А в браузерах всего лишь плагин, использующий обычную jvm.
G>> Я чтото не слышал чтобы с поставками ОС шли жвм.
AVK>Во всех 32-хбитных виндах за исключением ХР.
А что ж так ХР сплоховал-то. Я могу конечно ошибаться но тут дело не в виндах а в тех браузерах которые иджут с ними. Просто начиная с ИЕ 6 мс не врубает в него жвм, там нужно его доустанавливать. То есть все опять упирается в то что жвм идет не с виндой а с браузером который идет с виндой. В состав винды жвм не входит.
G>> И кстати что можно написать с использованием ждк 1.1.
AVK>Много.
Например. (Только без отмазок про тчо тебе впадлу перечислять и тп. Нихрена толкового не напишешь на ждк 1.1 — максимум — чат по тср/ир уровня лабораторной работы)
G>> Сила жабы начинается с цыфири 1.2 и выше — жсп/сервлеты, ж2ее
AVK>Ты там помниться про десктоп и проблемы распространения JRE речь заводил. Все что ты перечислил это серверные технологии и у них то как раз проблемы поставить JRE нет никакой.
G>> и т.п. А это уже пардон не десктоп.
AVK>Вот именно.
(Просьба — отвечай на все предложение целиком, а не его части. А тьо ты дал два ответа на первую и вторую половины моей фразы и Я не могу понять что ты хотел сказать — то ты говоришь что "Все что ты перечислил это серверные технологии и у них то как раз проблемы поставить JRE нет никакой" а то когда я говорю что это не десктоп ты поддакиваешь "Вот именно" Давай вести более конструктивный диалог пнимаешь )
AVK>>>Ну вобще то я лично не один проект на дотнете написал. И этот сайт включает в себя несколько таких проектов. Так что все таки не только загибалово.
G>>На аде тоже немало прожектов написали — ну и где они (прожекты).
AVK>Наши посмотреть можно. Работают, куча народа софтом пользуется. Чего тебе еще надо?
Ваши на аде?
G>> На делфях тоже много прожектов написано пишут и будут написаны — это говорит о том что у делфей есть своя ниша. У шарпа этой ниши еще нет.
AVK>На основании чего сделан вывод?
О том что шарп не занял свою нишу? На основе того что есть куча веток, и не только в этом разделе с темами "Зачем нужен НЕТ" и т.п. Вот ты мне скажи зачем нужен НЕТ (и шарп в частности)? Что в них революционного? Какие отрасли они охватывают и подминают под себя, какую нишу займут? Какие приложения будут на них писаться. Вообще какие проблемы, которые раньше были неразрешими, теперь решил НЕТ. То есть например у тебя же не возникает вопросов относительно того, зачемнужно делфи или плюсы.
G>>>> А насчет объяв на это форуме — надо сказать что далеко не каждый работодатель знает о его существовании. AVK>>>Каким образом это может сказаться на процентном отношении требуемых технологий?
G>>Да, вот каким образом то, что на рсдн.ру соотношение объяв по шарпу и плюсам как ты утверждаешь приблизительно одинаково может сказаться на востребованности технологии. Правильно — никак.
AVK>Тогда это не аргумент.
См просьбу выше — приводи цитату целиком и не забывай с чего начался раговор. Это ты сказал что рсдн в статистическом плане по объявам важнее так как тут мол чище и надо еще ан вопросы отвечать. А вообще давай вспомним что говорилось
И так
Ты
Проблема только в их трактовке. Я вот например трактую так — на С++ ведется море старых проектов, а на шарпе новые только появляются. И при этом шарп вполне адекватен. А еще могу привести другие факты — количество объявлений в форуме на этом сайте по шарпу уж точно никак не меньше чем по С++. Почему то этот факт я ценю больше.
Я
А насчет объяв на это форуме — надо сказать что далеко не каждый работодатель знает о его существовании. Спорить готов, что в раздел ИТ на какой-нить жоб.ру или в этом духе приходит в день раз 5 больше объяв, чем сюда. Какая-нибудь Анечка из HR-отдела уж точно не знает о существовании рсдн.ру. То есть опять мы видим что срез объяв на этом сайте (всех — и по плюсам, и по шарпу) весьма ограничен.
Ты
Каким образом это может сказаться на процентном отношении требуемых технологий? (Ты видишь кто задает вопрос про то что сказывеется на процентное отношение требуемых технологий — заметь, до этого нигде в моих постах не было фразы что количество объяв влияет на это. Наоборот — была фраза "То есть опять мы видим что срез объяв.. " Понимаешь, да, что облажался? далее...)
Я
Да, вот каким образом то, что на рсдн.ру соотношение объяв по шарпу и плюсам как ты утверждаешь приблизительно одинаково может сказаться на востребованности технологии. Правильно — никак. Если ты забыл, вопрос не стоял как зависит востребованность технологии от оъяв на сайте а совсем наоборот. Я тебе цифирь привел, ты мне сказал что на рсдн соотношение не такое критичное. Я спросил — сколько объяв по работе ежедневно приходит на рсдн?
Ты
Тогда это не аргумент (Что не аргумент?)
Я
Из этого следует, что сюда присылают объявы в основном люди которые знают о существовании сайта. Я думаю, для тебя не будет секретом что сайтила этот весьма специфической направленности и хорошо с ним знакомы в основном люди которые сами педалят или педалили. А теперь по каким то причинам (скажем организовалась новая контора) человек переходит в разряд менеджмента и начинает поиск сотрудников. Если предположить что перед был связан именно с организацией новой конторы то этот чел там сам себе и ХР-отдел(Анечка), и дирехтур и бухгалтер и тим-лидер. То есть контора прям скажем средняя. То есть срез ИТ-контор далеко не полный. иожет я че-то пропустил, но ткни мне пальцем в объявы о работе крупных контор в разделе "работа".
Ты
Какой? И как эта направленность влияет на соотношение дотнет и С++ разработчиков?
То есть из всего вышесказанного я делаю вывод что ты недочитываешь мои посты до конца а отвечаешь исключительно на уровне эмоций. А насчет специфики сайта — очень просто. Отвечая на вопрос какова специфика сайта — скажу: сайт в большенстве своем предназначен непосредтсвенно для программистов. Не для анечки из ХР-отдела, не для размещения порнухи и не для чего другого. Уж кто-кто а ты как модератор должен знат ьспецифику того, что модеришь.
G>> Если ты забыл, вопрос не стоял как зависит востребованность технологии от оъяв на сайте а совсем наоборот.
AVK>Я не забыл — вопрос стоял в соотношении востребованности таких девелоперов. На основании чего я должен доверять job.ru больше чем rsdn.ru?
G>> Я тебе цифирь привел, ты мне сказал что на рсдн соотношение не такое критичное. Я спросил — сколько объяв по работе ежедневно приходит на рсдн?
AVK>Посчитай сам.
И посчитаю
G>>>> То есть опять мы видим что срез объяв на этом сайте (всех — и по плюсам, и по шарпу) весьма ограничен. AVK>>>И что из этого следует?
См ниже: G>>Из этого следует, что сюда присылают объявы в основном люди которые знают о существовании сайта. Я думаю, для тебя не будет секретом что сайтила этот весьма специфической направленности
AVK>Какой? И как эта направленность влияет на соотношение дотнет и С++ разработчиков?
Никак, белый человек. Это соотношение востребованности дот-нет и С++ влияет на количество объяв (а ваще читай мою длинную тираду выше — там все написано).
Резюме.
1) Ты плохо читаешь посты собеседника — будь менее импульсивен, никто на твой любимый нет грязь не льет. мы тут правду ищем
2) То что ты пишешь на НЕТе и думаешь что поэтому вокруг него все крутится, и что свое мнение относительно востребованности специалистов ты строишь на основе объяв о работе на рсдн говорит лишь о том что ты не хочешь посмотреть правде в глаза. Если помнишь, насчет жабы, делфей и всего всего тоже много говорилось — революция! скорость разработки увеличивается в разы! и т.п. То же самое сейчас говорится и про НЕТ. Поживем увидем. Нишу свою он еще как мне кажется не занял. Вот посмотрим что выйдет.
Здравствуйте, <Аноним>, Вы писали:
G>>> Я чтото не слышал чтобы с поставками ОС шли жвм.
AVK>>Во всех 32-хбитных виндах за исключением ХР.
А>А что ж так ХР сплоховал-то. Я могу конечно ошибаться но тут дело не в виндах а в тех браузерах которые иджут с ними. Просто начиная с ИЕ 6 мс не врубает в него жвм, там нужно его доустанавливать. То есть все опять упирается в то что жвм идет не с виндой а с браузером который идет с виндой. В состав винды жвм не входит.
Здравствуйте, <Аноним>, Вы писали:
G>>> И какие десктоп программы ты видел на жабе?
AVK>>А какое это имеет отношение к обсуждаемому вопросу?
А>Это имеет отношение в твоей фразе что жвм есть почти везде.
Вот и я о том же. Какое имеет отношение то какие из десктоп программ я видел к тому насколько распространен JRE?
А> И само собой напрашивается вопрос — а что на нем пишут тем более на 1.1
Это уже другой вопрос.
G>>> Я чтото не слышал чтобы с поставками ОС шли жвм.
AVK>>Во всех 32-хбитных виндах за исключением ХР.
А>А что ж так ХР сплоховал-то.
МС решил Сан обломать по полной. Маркетинговые игры.
А> Я могу конечно ошибаться но тут дело не в виндах а в тех браузерах которые иджут с ними.
А это не важно, главное что в свое время jvm была почти везде, так что распространенность ее никак не могла быть сдеорживающим фактором.
А> Просто начиная с ИЕ 6 мс не врубает в него жвм, там нужно его доустанавливать. То есть все опять упирается в то что жвм идет не с виндой а с браузером который идет с виндой.
Есть разница?
А> В состав винды жвм не входит.
Входит.
А>Например. (Только без отмазок про тчо тебе впадлу перечислять и тп. Нихрена толкового не напишешь на ждк 1.1 — максимум — чат по тср/ир уровня лабораторной работы)
Ты ошибаешься. Подробности на java.sun.com. Лучше назови чего в Java 2 есть чего нет в 1.1 и мы обсудим насколько оно критично.
А>(Просьба — отвечай на все предложение целиком, а не его части. А тьо ты дал два ответа на первую и вторую половины моей фразы и Я не могу понять что ты хотел сказать — то ты говоришь что "Все что ты перечислил это серверные технологии и у них то как раз проблемы поставить JRE нет никакой" а то когда я говорю что это не десктоп ты поддакиваешь "Вот именно" Давай вести более конструктивный диалог пнимаешь )
Давай. Для начала восстановим логическую цепочку.
G>Както необходимость иметь НЕТ Фреймворк на машине для десктопа. Вот жаба например на этом деле погорела.
AVK>Вряд ли на этом. JVM 1.1 есть почти везде.
G>Сила жабы начинается с цыфири 1.2 и выше — жсп/сервлеты, ж2ее
AVK>Ты там помниться про десктоп и проблемы распространения JRE речь заводил. Все что ты перечислил это серверные технологии и у них то как раз проблемы поставить JRE нет никакой.
А теперь еще раз и поподробнее — какое отношение имеют серверные технологии к обсуждаемому вопросу?
G>>>На аде тоже немало прожектов написали — ну и где они (прожекты).
AVK>>Наши посмотреть можно. Работают, куча народа софтом пользуется. Чего тебе еще надо?
А>Ваши на аде?
На дотнете. Мы ведь о дотнете говорим, не так ли?
G>>> На делфях тоже много прожектов написано пишут и будут написаны — это говорит о том что у делфей есть своя ниша. У шарпа этой ниши еще нет.
AVK>>На основании чего сделан вывод?
А>О том что шарп не занял свою нишу?
Ага
А>На основе того что есть куча веток, и не только в этом разделе с темами "Зачем нужен НЕТ"
Это не показатель. Новая технология естественно вызывает вопросы.
А>Вот ты мне скажи зачем нужен НЕТ (и шарп в частности)?
Чтобы писать программы, как это не банально звучит.
А> Что в них революционного?
Революционного? Почти ничего, так, по мелочи. Transparent proxy в ремоутинге, веб-формсы. А что — технология обязана быть революционной? Фишка в том что самые ценные идеи отрасли были собраны и качественно реализованы в одном продукте.
А> Какие отрасли они охватывают и подминают под себя,
Что такое отрасли?
А> какую нишу займут? Какие приложения будут на них писаться.
Большая часть приложений. В основном серверный и настольный софт.
А> Вообще какие проблемы, которые раньше были неразрешими, теперь решил НЕТ.
Это отдельный разговор. Опять же неразрешимы при помощи каких средств?
А> То есть например у тебя же не возникает вопросов относительно того, зачемнужно делфи или плюсы.
Нет. И насчет нета тоже не возникают.
G>>>Да, вот каким образом то, что на рсдн.ру соотношение объяв по шарпу и плюсам как ты утверждаешь приблизительно одинаково может сказаться на востребованности технологии. Правильно — никак.
AVK>>Тогда это не аргумент.
А>См просьбу выше — приводи цитату целиком и не забывай с чего начался раговор.
Кажется мне что забывает кто то другой
А> Это ты сказал что рсдн в статистическом плане по объявам важнее
Про статистический план я ничего не говорил.
Я тебя постоянно пытаюсь вернуть к начальному вопросу — почему соотношение на job.ru это факт, а на rsdn.ru уже не факт, а ты постоянно уезжаешь куда то не туда.
А>То есть из всего вышесказанного я делаю вывод что ты недочитываешь мои посты до конца а отвечаешь исключительно на уровне эмоций.
Неверный вывод.
А> А насчет специфики сайта — очень просто. Отвечая на вопрос какова специфика сайта — скажу: сайт в большенстве своем предназначен непосредтсвенно для программистов.
А что — программисты на С++ это не программисты?
А>Не для анечки из ХР-отдела, не для размещения порнухи и не для чего другого. Уж кто-кто а ты как модератор должен знат ьспецифику того, что модеришь.
Вот и объясни мне — как эта специфика отражается на процентном соотношении дотнета и С++.
AVK>>Какой? И как эта направленность влияет на соотношение дотнет и С++ разработчиков?
А>Никак, белый человек.
Тогда вспоминаем исходный вопрос.
А>Резюме. А>1) Ты плохо читаешь посты собеседника — будь менее импульсивен, никто на твой любимый нет грязь не льет. мы тут правду ищем
1) Могу переадресовать это к тебе. Кроме того пока что эмоции высказываешь только ты. Заметь — я ни про грязь ни про эмоции не упоминал до сей поры.
А>2) То что ты пишешь на НЕТе и думаешь что поэтому вокруг него все крутится,
Цитату в студию где я такое говорил.
А> и что свое мнение относительно востребованности специалистов ты строишь на основе объяв о работе на рсдн говорит лишь о том что ты не хочешь посмотреть правде в глаза.
А я смотрю правде в глаза, кажный месяц в зарплатный день
А> Если помнишь, насчет жабы, делфей и всего всего тоже много говорилось — революция! скорость разработки увеличивается в разы! и т.п. То же самое сейчас говорится и про НЕТ.
Я такое говорил?
А> Поживем увидем. Нишу свою он еще как мне кажется не занял.
Вот бы еще все таки услышать аргументы, окромя количества объявлений на job.ru .
Здравствуйте, <Аноним>, Вы писали:
G>>> Я чтото не слышал чтобы с поставками ОС шли жвм.
AVK>>Во всех 32-хбитных виндах за исключением ХР.
А>А что ж так ХР сплоховал-то. Я могу конечно ошибаться но тут дело не в виндах а в тех браузерах которые иджут с ними. Просто начиная с ИЕ 6 мс не врубает в него жвм, там нужно его доустанавливать. То есть все опять упирается в то что жвм идет не с виндой а с браузером который идет с виндой. В состав винды жвм не входит.
Здравствуйте, Miem, Вы писали:
M>Здравствуйте, <Аноним>, Вы писали:
G>>>> Я чтото не слышал чтобы с поставками ОС шли жвм.
AVK>>>Во всех 32-хбитных виндах за исключением ХР.
А>>А что ж так ХР сплоховал-то. Я могу конечно ошибаться но тут дело не в виндах а в тех браузерах которые иджут с ними. Просто начиная с ИЕ 6 мс не врубает в него жвм, там нужно его доустанавливать. То есть все опять упирается в то что жвм идет не с виндой а с браузером который идет с виндой. В состав винды жвм не входит.
M>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alexkro, Вы писали:
A>>Во-вторых (2), все широко распостранённые понятия других языков для .NET должны быть представлены в C++/CLI. Сюда входят, например, properties, чего как такового в CLI нет (то бишь это всего лишь методы с соответствующим аттрибутом).
AVK>Вобщето в метаданных присутствует понятие именно свойства, так что заявлять о его отсутствии в CLI вобще то некорректно.
Точно, есть отдельная таблица Property. А я сначала думал, что методы маркируются.
A>>В следствие несовместимости основных свойств, C++ указатели и GC указатели не имеют ничего общего.
AVK>Вопрос только в одном — а нужны ли в дотнете обычные указатели?
Не нужны. Но здесь мы имеем дело с C++. Все его стандартные фичи должны остаться, а то никто не будет его использовать.
R>я вообще машину не перегружаю и янус весит уже наверное месяц (как апгрейт сделал ) и я вообще ни разу не видел синий экран у 2k/XP/2003
Не хочется вас расстраивать, но вчера поставил янус и узрел ЕГО. Винды 2003, а про XP и говорить не хочется. Конечно, я знаю людей у которых и 98 стоит годами. Пасьянс + ворд + винамп
Здравствуйте, Пупырь, Вы писали:
R>>я вообще машину не перегружаю и янус весит уже наверное месяц (как апгрейт сделал ) и я вообще ни разу не видел синий экран у 2k/XP/2003
П>Не хочется вас расстраивать, но вчера поставил янус и узрел ЕГО. Винды 2003, а про XP и говорить не хочется.
Не юзал 2003, а хочется сказать про XP. Видел синий экран только несколько раз (больше чем за год) и то причиной этому был приобретенный второй модуль памяти, который глючил с таймингами, с которыми работал первый. Поменял тайминги и опять все ок.
П>Конечно, я знаю людей у которых и 98 стоит годами. Пасьянс + ворд + винамп
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, <Аноним>, Вы писали:
G>>>> И какие десктоп программы ты видел на жабе?
AVK>>>А какое это имеет отношение к обсуждаемому вопросу?
А>>Это имеет отношение в твоей фразе что жвм есть почти везде.
AVK>Вот и я о том же. Какое имеет отношение то какие из десктоп программ я видел к тому насколько распространен JRE?
Здравствуйте, alexkro, Вы писали:
AVK>>Вопрос только в одном — а нужны ли в дотнете обычные указатели?
A>Не нужны. Но здесь мы имеем дело с C++. Все его стандартные фичи должны остаться, а то никто не будет его использовать.
Здравствуйте, Пупырь, Вы писали:
R>>я вообще машину не перегружаю и янус весит уже наверное месяц (как апгрейт сделал ) и я вообще ни разу не видел синий экран у 2k/XP/2003
П>Не хочется вас расстраивать, но вчера поставил янус и узрел ЕГО. Винды 2003, а про XP и говорить не хочется. Конечно, я знаю людей у которых и 98 стоит годами. Пасьянс + ворд + винамп
у меня VS.NET 2003 2 штуки, MS SQL 2000, янус, ИЕ 5 штук, оутлук эспресс, MMC + кучка мелочи.
Это то, что у меня сейчас. Обычно так всегда.
Здравствуйте, dad, Вы писали:
dad>дело в том, что сама стилистика программирования windows такова. все к этому располагает — и продвижение таких продуктов как vb, и создание интерфеса мышкой, и даже vcl все способствует написанию программ в которых вставка в БД происходит в обработчике нажатия кнопки. почему такое происходит отдельная тема. ябы не доускал до разработки gui пока весь севт не будет делать все что задумано в коммандной строке и с помощью конф. файлов. тогда мы будем иметь продкты вроде миранды или мозилы dad>(скопировал и работай)
dad>мне тоже не понятно, как и не понятноп очему теряются все настройки при переустановки ие, почему виндовс все время просит перезагружаться, почему я не могу настройки взять файл просто и пенести на другую машину (на рабоут например) и т.д. и т.п. объясни мне почему что бы использовать янус мне нужно поставить framework 1.1.
кстати, философия НЕТ как раз такова — "скопировал и работай". Без регистрации в реестре, без перезагрузки. Настройки в хмл-формате.
Здравствуйте, dad, Вы писали:
dad>а я тебе о чем? или по твоему open souce проекты невыгодны? помимо пиара еще и доход. dad>(вообще я параноически подозреваю что многие разработки и порты под винды да и вообще многие мекие фирмы стартапятся или спонсируются ms)
схоже на параною Только даже если и так, то я не вижу в этом ничего плохого
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alexkro, Вы писали:
AVK>>>Вопрос только в одном — а нужны ли в дотнете обычные указатели?
A>>Не нужны. Но здесь мы имеем дело с C++. Все его стандартные фичи должны остаться, а то никто не будет его использовать.
AVK>То есть дело по сути в шашечках?
Здравствуйте, Glоbus, Вы писали:
G>Здравствуйте, AVM, Вы писали:
AVM>>Здравствуйте, Glоbus, Вы писали:
G>>>То есть налицо — рынок нуждается в С++ программерах больше чем в С# программерах в 6 раз сильнее и ценяться в 3 раза больше. То есть готовы товарищи потерпеть и шаблоны, больной непонятный код, и длительную разработку и т.п. А вот за шарп и нет с его скоростью, удобством и тп мало чтото платят. Наверное лохи, как и с делфи нихрена не соображают. (Кстати соотношение объяв С++/Делфи так же бяло приблизительно таким же в 5 раз больше и в 3 раза дороже) Так что "Факты — вещь упрямая" И.В.Сталин.
AVM>>Сейчас ситуация такая. В будущем она должна обязательно изменится. AVM>>В отчете GG (весна 2003) приводит такой прогноз:
AVM>>
AVM>>Сам отчет находится на: http://www.gartnervoice.com/homepageApril2003/enetvJavaDW.pdf
AVM>>С уважением, AVM>>AVM
G>1) А что такое ГГ?
Gartner Group — www.gartnergroup.com G>2) Мне интересно как можно делать прогнозы относительно технологии, про которую пока мало что известно.
Прогнозы делать очень легко , сложно делать "реальные прогнозы", которые сбываются с высокой долей вероятности.
ты сначала на вопросы отвечаешь в стиле "НЕТ фигня С++ рулит", а когда просят конкретику — привести ее не можешь. Даже не можешь сказать, на основе каких предпосылок ты не согласился что НЕТ более декларативная система чем С++
Здравствуйте, mikа, Вы писали:
VK>>Ты, главное, рекламный щит найди
M>Какой-такой щит?
Обыкновенный рекламный... Таких везде много... У дорог обычно стоят... большие такие...
Неужели ни разу не замечал?
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Здравствуйте, oRover, Вы писали:
R>ты сначала на вопросы отвечаешь в стиле "НЕТ фигня С++ рулит", а когда просят конкретику — привести ее не можешь. Даже не можешь сказать, на основе каких предпосылок ты не согласился что НЕТ более декларативная система чем С++
Я же написал чуть выше, что был сбит с толку. В любом случае, ИМХО, лучше не согласиться с непонятным утверждением, чем потом отмазываться.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Это... мастер?! Чё так сложно то?
Не хочется ручками менять все вызовы с ReadToEnd(value) на ReadToEnd(). Кстати, ты не обратил внимания, что default value в моём примере — одно на тип. Для модуля можно определить:
и менять его по мере необходимости.
VD>Может так сойдет:
[поскипано, хотя и сойдёт]
В данном конкретном случае — может и сойдёт. Человек просил иллюстрацию — я и показал.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
AVK>Про статистический план я ничего не говорил.
AVK>Я тебя постоянно пытаюсь вернуть к начальному вопросу — почему соотношение на job.ru это факт, а на rsdn.ru уже не факт, а ты постоянно уезжаешь куда то не туда.
Я как раз туда уежаю. Это ты лепишь тут недопонимание. Давай по существу. Согласен ли ты со мной, что на жоб.ру объяв по работе (именно в ИТ области) скажем на порядок больше чем на рсдн? А так как так оно и есть, то можно с уверенностью сказать что для статистического анализа жоб.ру в смысле среза предложений по работе гараздо более предпочтителен, чем рсдн.
А>> А насчет специфики сайта — очень просто. Отвечая на вопрос какова специфика сайта — скажу: сайт в большенстве своем предназначен непосредтсвенно для программистов.
AVK>А что — программисты на С++ это не программисты?
Ну и к чем ты сказал это. Ты хоть читай на что ответ пишешь.
AVK>Вот бы еще все таки услышать аргументы, окромя количества объявлений на job.ru .
А это самый главный аргумкент — требования рынка. То есть какая-бы клевая технология не была, она нахрен не нужна если за нее не платят. В случае же с НЕТом мне лично кажется что это все есть веяния моды. Надо отдать должное пацанам из Пи-Ар-отдела МС — они как всегда на высоте. Спихнули на рынок неизвестно что. Не знаю, но может ты видел вот это — весьма любопытно и действительно имеет рациональные зерна.
Опять же наконец возвращаясь к исходной теме скажу, что судя по статистике сишники требуются в большем количистве и оплачиваются выше во вполне определенное количество раз. Это факт, который подтверждается цифирью. которую я привел в начале этой ветки.
Я не совсем понял что тебя смутило. У тебя какая-то личная неприязнь к жоб.ру, Ну возьми какой-нить другой общеизвестный сайт по работе. Я уверен там соотношение будет то же.
Здравствуйте, AVM, Вы писали:
AVM>Здравствуйте, Glоbus, Вы писали:
G>>Здравствуйте, AVM, Вы писали:
AVM>>>Здравствуйте, Glоbus, Вы писали:
G>>>>То есть налицо — рынок нуждается в С++ программерах больше чем в С# программерах в 6 раз сильнее и ценяться в 3 раза больше. То есть готовы товарищи потерпеть и шаблоны, больной непонятный код, и длительную разработку и т.п. А вот за шарп и нет с его скоростью, удобством и тп мало чтото платят. Наверное лохи, как и с делфи нихрена не соображают. (Кстати соотношение объяв С++/Делфи так же бяло приблизительно таким же в 5 раз больше и в 3 раза дороже) Так что "Факты — вещь упрямая" И.В.Сталин.
AVM>>>Сейчас ситуация такая. В будущем она должна обязательно изменится. AVM>>>В отчете GG (весна 2003) приводит такой прогноз:
AVM>>>
AVM>>>Сам отчет находится на: http://www.gartnervoice.com/homepageApril2003/enetvJavaDW.pdf
AVM>>>С уважением, AVM>>>AVM
G>>1) А что такое ГГ? AVM>Gartner Group — www.gartnergroup.com G>>2) Мне интересно как можно делать прогнозы относительно технологии, про которую пока мало что известно. AVM>Прогнозы делать очень легко , сложно делать "реальные прогнозы", которые сбываются с высокой долей вероятности.
Здравствуйте, Glоbus, Вы писали:
А>>> А насчет специфики сайта — очень просто. Отвечая на вопрос какова специфика сайта — скажу: сайт в большенстве своем предназначен непосредтсвенно для программистов.
AVK>>А что — программисты на С++ это не программисты?
G>Ну и к чем ты сказал это.
К тому что ориентированность сайта на программистов отнюдь не означает предпочтение дотнета.
AVK>>Вот бы еще все таки услышать аргументы, окромя количества объявлений на job.ru .
G>То есть какая-бы клевая технология не была, она нахрен не нужна если за нее не платят.
Лично мне платят.
G>В случае же с НЕТом мне лично кажется что это все есть веяния моды.
Ну а мне так не кажется. Понимаешь тут какая фишка — тебе люди говорят что от реального использования дотнета есть вполне конкретный эффект, а ты, даже не пробовав, делаешь высосанные из пальца выводы.
G> Опять же наконец возвращаясь к исходной теме скажу, что судя по статистике сишники требуются в большем количистве и оплачиваются выше во вполне определенное количество раз.
Статистика у тебя больно куцая.
G> Это факт, который подтверждается цифирью. которую я привел в начале этой ветки.
Неа, не подтверждается.
G>Я не совсем понял что тебя смутило. У тебя какая-то личная неприязнь к жоб.ру,
Нет, у меня неприязнь к далеко идущим выводам, сделанным на основании бог знает чего.
G> Ну возьми какой-нить другой общеизвестный сайт по работе. Я уверен там соотношение будет то же.
А ты возьми тот самый job.ru, только поиск сделай не только по шарпу, но и по другим языкам дотнета и по платформе .NET в целом.
Здравствуйте, Vladimir Khatzkevich, Вы писали:
VK>Здравствуйте, mikа, Вы писали:
VK>>>Ты, главное, рекламный щит найди
M>>Какой-такой щит? VK>Обыкновенный рекламный... Таких везде много... У дорог обычно стоят... большие такие... VK>Неужели ни разу не замечал?
Ты себя нормально чувствуешь? Или это такие приколы?
G>>>1) А что такое ГГ? AVM>>Gartner Group — www.gartnergroup.com G>>>2) Мне интересно как можно делать прогнозы относительно технологии, про которую пока мало что известно. AVM>>Прогнозы делать очень легко , сложно делать "реальные прогнозы", которые сбываются с высокой долей вероятности.
G>Ну и че, сбылось что-нибудь ? )))
Судя по тому сколько GG клиентов (и какие деньги GG зарабатывает) их прогнозы чаще всего вбываются , хотя наверное и ошибки бывают — как без этого.
Здравствуйте, mikа, Вы писали:
M> Ты себя нормально чувствуешь? Или это такие приколы?
Спасибо, чувствую себя хорошо.
Извини, mika Твоё фамильярное общение с Г.В. сбило меня с толку. Я решил, что ты с ним знаком лично (один из его теперешних коллег, например). Тогда бы ты понял шутку про щит. Но это не так, посему забудь об этом
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Glоbus, Вы писали:
А>>>> А насчет специфики сайта — очень просто. Отвечая на вопрос какова специфика сайта — скажу: сайт в большенстве своем предназначен непосредтсвенно для программистов.
AVK>>>А что — программисты на С++ это не программисты?
G>>Ну и к чем ты сказал это.
AVK>К тому что ориентированность сайта на программистов отнюдь не означает предпочтение дотнета.
Смешной человек. А где я сказал про доннет. Если ты помнишь это ты у меня спросил про специфику этого сайта и я сказал что он предназначен для программистов. Ни слова про нет не было. почитай выше мои посты, а то ты теряешь нить рассуждения.
AVK>>>Вот бы еще все таки услышать аргументы, окромя количества объявлений на job.ru .
G>>То есть какая-бы клевая технология не была, она нахрен не нужна если за нее не платят.
AVK>Лично мне платят.
А речь не о тебе и не о нете. Да и ваще не будь формалистом — платят за многое, но платят по разному.
G>>В случае же с НЕТом мне лично кажется что это все есть веяния моды.
AVK>Ну а мне так не кажется. Понимаешь тут какая фишка — тебе люди говорят что от реального использования дотнета есть вполне конкретный эффект, а ты, даже не пробовав, делаешь высосанные из пальца выводы.
Вах! Со зла, со зла. Пробовал. Больше года на нем сидел.
G>> Опять же наконец возвращаясь к исходной теме скажу, что судя по статистике сишники требуются в большем количистве и оплачиваются выше во вполне определенное количество раз.
AVK>Статистика у тебя больно куцая
На безрыбье как грится... У тя ваще никакой нет.
G>> Это факт, который подтверждается цифирью. которую я привел в начале этой ветки.
AVK>Неа, не подтверждается.
Конечно подтверждается.
G>>Я не совсем понял что тебя смутило. У тебя какая-то личная неприязнь к жоб.ру,
AVK>Нет, у меня неприязнь к далеко идущим выводам, сделанным на основании бог знает чего.
G>> Ну возьми какой-нить другой общеизвестный сайт по работе. Я уверен там соотношение будет то же.
AVK>А ты возьми тот самый job.ru, только поиск сделай не только по шарпу, но и по другим языкам дотнета и по платформе .NET в целом.
А так кроме шарпа только ВБ. И я крупно сомневаюсь что специалистов по ВБ.НЕТ ценят больше и оплачивают их труд лучше чем сишников.
Здравствуйте, Glоbus, Вы писали:
AVK>>К тому что ориентированность сайта на программистов отнюдь не означает предпочтение дотнета.
G>Смешной человек. А где я сказал про доннет.
Заголовок темы прочти, да?
G>Если ты помнишь это ты у меня спросил про специфику этого сайта и я сказал что он предназначен для программистов. Ни слова про нет не было. почитай выше мои посты, а то ты теряешь нить рассуждения.
Это ты теряешь. Ты привел специфику сайта в качестве аргумента за то что форум о работе на rsdn.ru не отражает реального соотношения потребностей в дотнет и С++ программистах.
AVK>>Лично мне платят.
G>А речь не о тебе и не о нете. Да и ваще не будь формалистом — платят за многое,
Мы не про многое, мы про дотнет разговариваем.
То есть какая-бы клевая технология не была, она нахрен не нужна если за нее не платят.
Так вот — за дотнет платят.
G> но платят по разному.
Хорошо платят
AVK>>Ну а мне так не кажется. Понимаешь тут какая фишка — тебе люди говорят что от реального использования дотнета есть вполне конкретный эффект, а ты, даже не пробовав, делаешь высосанные из пальца выводы.
G>Вах! Со зла, со зла. Пробовал. Больше года на нем сидел.
Вах! И че высидел?
AVK>>Статистика у тебя больно куцая
G>На безрыбье как грится... У тя ваще никакой нет.
Тут Василий вовремя ссылочку напомнил, www.monster.com. Wелкам!
AVK>>А ты возьми тот самый job.ru, только поиск сделай не только по шарпу, но и по другим языкам дотнета и по платформе .NET в целом.
G>А так кроме шарпа только ВБ.
VB.NET. Проблема только в том что иногда в объявлениях пишут просто .NET. Или просто ASP.NET.
G>>А так кроме шарпа только ВБ.
AVK>VB.NET. Проблема только в том что иногда в объявлениях пишут просто .NET. Или просто ASP.NET.
ВБ, ВБ.НЕТ — это не принципиально. Ты врубился о чем я говорю.
И Интересно, что они под этим подразумевают? АСП.НЕТ это подраздел для сайтолобалова, внутринними языками которого являются шарп и ВБ.НЕТ. Вот как ты думаешь, о чем думает чел, когда он в объяве пишет просто НЕТ? кого он хочет найти и с какими знаниясми?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Glоbus, Вы писали:
AVK>>>К тому что ориентированность сайта на программистов отнюдь не означает предпочтение дотнета.
G>>Смешной человек. А где я сказал про доннет.
AVK>Заголовок темы прочти, да?
Братела, ты совсем в потерях. Если ты не заметил, ты давно уже с тобой не по теме этого топика базарим. Или ты не врубаешся реально?
G>>Если ты помнишь это ты у меня спросил про специфику этого сайта и я сказал что он предназначен для программистов. Ни слова про нет не было. почитай выше мои посты, а то ты теряешь нить рассуждения.
AVK>Это ты теряешь. Ты привел специфику сайта в качестве аргумента за то что форум о работе на rsdn.ru не отражает реального соотношения потребностей в дотнет и С++ программистах.
Нет. Я привел специфику сайта как аргумент в пользу того, что сюда с меньшей вероятностью придет человек давать объявы по работе, нежели на специализированный сайт, предназначенный для этого. Ваще это ты очень клевую политику продвигаешь — перекручивать мои утвержедния в заведомо ложные и на этой основе строить цепочки своих гениальных рассуждений.
AVK>>>Лично мне платят.
Рад за тебя. Повторюсь. Я не говорил что не платят, я говорил что всреднем платят меньше. Разнуцу почувствовал?
G>>А речь не о тебе и не о нете. Да и ваще не будь формалистом — платят за многое,
AVK>Мы не про многое, мы про дотнет разговариваем. AVK>
AVK>То есть какая-бы клевая технология не была, она нахрен не нужна если за нее не платят.
AVK>Так вот — за дотнет платят.
Это называется буквоедтсво. Если ты внимательно читал все мои посты то должен был понять, что я не пывтаюсь доказать что за нет не платят совсем. как я и писал выше, я хочу указать на тот факт что за него платят меньше
G>> но платят по разному.
AVK>Хорошо платят
Ой, я щас умру просто от черной зависти. Надеюсь когда ты это писал у тебя было довольное и сытое лицо.
AVK>>>Ну а мне так не кажется. Понимаешь тут какая фишка — тебе люди говорят что от реального использования дотнета есть вполне конкретный эффект, а ты, даже не пробовав, делаешь высосанные из пальца выводы.
G>>Вах! Со зла, со зла. Пробовал. Больше года на нем сидел.
AVK>Вах! И че высидел?
Много чего.
AVK>>>Статистика у тебя больно куцая
G>>На безрыбье как грится... У тя ваще никакой нет.
AVK>Тут Василий вовремя ссылочку напомнил, www.monster.com. Wелкам!
Здравствуйте, Glоbus, Вы писали:
AVK>>Заголовок темы прочти, да?
G>Братела, ты совсем в потерях. Если ты не заметил, ты давно уже с тобой не по теме этого топика базарим. Или ты не врубаешся реально?
Не знаю как ты, а я стараюсь придерживаться исходной темы.
AVK>>Это ты теряешь. Ты привел специфику сайта в качестве аргумента за то что форум о работе на rsdn.ru не отражает реального соотношения потребностей в дотнет и С++ программистах.
G>Нет.
Да. Все зафиксированно. Прочти свои же топики если подзабыл.
G>Я привел специфику сайта как аргумент в пользу того, что сюда с меньшей вероятностью придет человек давать объявы по работе, нежели на специализированный сайт, предназначенный для этого.
А зачем? Ведь речь то шла о востребованности С#.
G> Ваще это ты очень клевую политику продвигаешь — перекручивать мои утвержедния в заведомо ложные
Нет, я просто игнорирую твои попытки перевести разговор на другое.
AVK>>>>Лично мне платят.
G>Рад за тебя. Повторюсь. Я не говорил что не платят, я говорил что всреднем платят меньше. Разнуцу почувствовал?
То есть какая-бы клевая технология не была, она нахрен не нужна если за нее не платят.
Поскольку все таки платят, то следовательно она кому то нужна. Где пробел в логике?
AVK>>Мы не про многое, мы про дотнет разговариваем. AVK>>
AVK>>То есть какая-бы клевая технология не была, она нахрен не нужна если за нее не платят.
AVK>>Так вот — за дотнет платят.
G>Это называется буквоедтсво.
Нет, это называется попытка отказаться от своих слов.
G>>>Вах! Со зла, со зла. Пробовал. Больше года на нем сидел.
AVK>>Вах! И че высидел?
G>Много чего.
Ну например?
AVK>>Тут Василий вовремя ссылочку напомнил, www.monster.com. Wелкам!
G>Ну так че, вопросы будут еще?
Будут. См. предыдущие сообщения про то какие кейворды указывать надо.
AVK>>VB.NET. Проблема только в том что иногда в объявлениях пишут просто .NET. Или просто ASP.NET.
G>ВБ, ВБ.НЕТ — это не принципиально.
Принципиально.
G>И Интересно, что они под этим подразумевают? АСП.НЕТ это подраздел для сайтолобалова, внутринними языками которого являются шарп и ВБ.НЕТ.
Ну как же так, если ты год сидел под дотнетом то должен был знать что ASP.NET это часть фреймворка и использовать его не зная фреймворка невозможно.
G> Вот как ты думаешь, о чем думает чел, когда он в объяве пишет просто НЕТ? кого он хочет найти и с какими знаниясми?
Человека, умеющего работать с дотнетом. Используемый язык не так важен.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Glоbus, Вы писали:
AVK>>>VB.NET. Проблема только в том что иногда в объявлениях пишут просто .NET. Или просто ASP.NET.
G>>ВБ, ВБ.НЕТ — это не принципиально.
AVK>Принципиально.
Старику, посмотри на название топика. Видишь там слово ".НЕТ"? Я думал ты врубишся что я говорю о ВБ.НЕТ.
G>>И Интересно, что они под этим подразумевают? АСП.НЕТ это подраздел для сайтолобалова, внутринними языками которого являются шарп и ВБ.НЕТ.
AVK>Ну как же так, если ты год сидел под дотнетом то должен был знать что ASP.NET это часть фреймворка и использовать его не зная фреймворка невозможно.
Ну часть и часть. Я че-то не понимаю, с чем иты споришь. Я с тобой могу забится на любые деньги что научить человека лобать на асп.нет можно за 2 месяца и при этмо абсолютно не раскидывая ему ничего не про фреймвор, ни про нет ни про что ваще — лишь бы у него были хоть какие-нибудь знания по программингу и хотя бы небольшое представление о том, что такое веб..
G>> Вот как ты думаешь, о чем думает чел, когда он в объяве пишет просто НЕТ? кого он хочет найти и с какими знаниясми?
AVK>Человека, умеющего работать с дотнетом. Используемый язык не так важен.
Что значит работать с дотнетом? Дотнет как раз и нужен вместе с языками. Без языков он не впал никому. А язык важен — во всяком случае для конторы, которая объявы дает. Конечно если она не пишет на всем от асма до шарпа и вб.
Лобал сайтилы на асп.нет — могу адреса дать если уж совсем мне не веришь.
А непосредстенно на C# систему (сервеную часть) live customer support — думаю, ты понял о чем речь — Icq-like сервак с наворотами типа отслеживания перемещений юзера, ремот-контролом за машиной и кучей разной фигни.
AVK>>>Тут Василий вовремя ссылочку напомнил, www.monster.com. Wелкам!
G>>Ну так че, вопросы будут еще?
AVK>Будут. См. предыдущие сообщения про то какие кейворды указывать надо.
Ясно. То есть не будет вопросов. А то какие-то левые ссылки пошли.
Здравствуйте, Glоbus, Вы писали:
AVK>>Ну как же так, если ты год сидел под дотнетом то должен был знать что ASP.NET это часть фреймворка и использовать его не зная фреймворка невозможно.
G>Ну часть и часть.
Значит программисты под ASP.NET это программисты для платформы .NET.
G>Я с тобой могу забится на любые деньги что научить человека лобать на асп.нет можно за 2 месяца и при этмо абсолютно не раскидывая ему ничего не про фреймвор,
Точно так же за 2 месяца можно научить человека лабать на С++.
G>>> Вот как ты думаешь, о чем думает чел, когда он в объяве пишет просто НЕТ? кого он хочет найти и с какими знаниясми?
AVK>>Человека, умеющего работать с дотнетом. Используемый язык не так важен.
G>А язык важен — во всяком случае для конторы, которая объявы дает.
Что то мне подсказывает что ты не очень хорошо себе представляешь особенности дотнета.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Glоbus, Вы писали:
G>>>>Много чего.
AVK>>>Ну например?
G>>Лобал сайтилы на асп.нет — могу адреса дать если уж совсем мне не веришь.
AVK>А, ну если "лобал сайтилы" тогда понятно. Вопросов больше нет.
Ну я так и понял из твоего предпоследнего поста что вопросов не будет.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Glоbus, Вы писали:
AVK>>>Ну как же так, если ты год сидел под дотнетом то должен был знать что ASP.NET это часть фреймворка и использовать его не зная фреймворка невозможно.
G>>Ну часть и часть.
AVK>Значит программисты под ASP.NET это программисты для платформы .NET.
G>>Я с тобой могу забится на любые деньги что научить человека лобать на асп.нет можно за 2 месяца и при этмо абсолютно не раскидывая ему ничего не про фреймвор,
AVK>Точно так же за 2 месяца можно научить человека лабать на С++.
Нельзя. Через 2 месяца он вряд ли сможет выдавать приложения коммерческого уровня. А вот АСП.НЕТ-лобатель легко. Склеить сайт средней сложности на АСП.НЕТ за пару месяцев не представляет никаких проблем. Это говорит о разнице в уровне подготовки в среднем между сишниками и товарищами на НЕТе.
G>>>> Вот как ты думаешь, о чем думает чел, когда он в объяве пишет просто НЕТ? кого он хочет найти и с какими знаниясми?
AVK>>>Человека, умеющего работать с дотнетом. Используемый язык не так важен.
G>>А язык важен — во всяком случае для конторы, которая объявы дает.
AVK>Что то мне подсказывает что ты не очень хорошо себе представляешь особенности дотнета.
Ну наконец-то!!!! Вот теперь будь любезен, не сочти за труд, поведай мне, простому человеку от земли, в чем же особенности дотнета. То есть в чем он лучше других и что в нем такого, чего не было раньше?
Здравствуйте, Glоbus, Вы писали:
G> Это говорит о разнице в уровне подготовки в среднем между сишниками и товарищами на НЕТе.
Да ладно тебе, так можно про любую технологию сказать. Некоторые, кто сейчас на дотнете, переползли с С++.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, is, Вы писали:
is>Здравствуйте, Glоbus, Вы писали:
G>> Это говорит о разнице в уровне подготовки в среднем между сишниками и товарищами на НЕТе.
is>Да ладно тебе, так можно про любую технологию сказать. Некоторые, кто сейчас на дотнете, переползли с С++.
Оно конечно того...Но кроме этого есть там еще товарищи которые переползли с ВБ и т.п. Вообще в вышеприведенном предложении слово "в среднем" имеет одно из ключевых значений. Я не хочу оперировать абсолютными понятиями, так как понятное дело и на сях есть много делитантов.
Здравствуйте, Glоbus, Вы писали:
G> Вообще в вышеприведенном предложении слово "в среднем" имеет одно из ключевых значений.
Но и делает его неконкретным и размытым.
G> Я не хочу оперировать абсолютными понятиями, так как понятное дело и на сях есть много делитантов.
Естественно. Кроме того, не нужно забывать, что все когда-то были делатантами и остаются ими в той, или иной области.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, Glоbus, Вы писали:
G>Рад за тебя. Повторюсь. Я не говорил что не платят, я говорил что всреднем платят меньше. Разнуцу почувствовал?
Ага, в больнице тоже средняя температура 36.6.
G>Это называется буквоедтсво. Если ты внимательно читал все мои посты то должен был понять, что я не пывтаюсь доказать что за нет не платят совсем. как я и писал выше, я хочу указать на тот факт что за него платят меньше
Откуда дровишки? Сдается мне, что ты лично раза в полтора меньше чем АВК получаешь... в среднем.
G>Ой, я щас умру просто от черной зависти. Надеюсь когда ты это писал у тебя было довольное и сытое лицо.
А ты думал?
G>Ну так че, вопросы будут еще?
Ага. Ты на зарплаты смотрел?
... << RSDN@Home 1.1.2 beta 3 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Впрочем, это уже совсем другая история. Главное другое: xxxxx Server Pages — по сути обеспечивают коммуникации (ИМХО), а точнее — коммуникацию пользователя с программой в среде Web. Так что, это ничего под Луной не меняет.
Вот ты мне скажи как профессионал, где тут прав dad? В том, что он не знает что такое RPC? RCP — это протокол общения (AKA транспортный). SOAP — это протокол форматирования. Обычно SOAP передаеться в HTTP. Сравнивать SOAP и RPC все равно, что самолет с унитазом. Это раз. Во-вторых, кодогенерация — вообще никаким боком не подходит к RCP ибо появлась тогда, когда еще и сетевого общения в помине не было.
Если нам не помогут, то мы тоже никого не пощадим.
Одинаковые ошибки необязательно делать каждый раз, достаточно сделать одну, а затем обращаться к ней по мере необходимости из любого места программы.
