Господа, не могли бы вы доступно и по-русски объяснить, что такое .NET. Как её позиционирует Microsoft? Для чего её придумали? Почему этим все восхищаются?
Слышал, что программы переводятся в некоторое промежуточное представление (наподобие байт-кода Java). Это означает, что нужна виртуальная машина (как для Java)? Есть ли она в Windows XP (или нет, как у Java)? Можно ли генерировать файлы формата PE?
Здравствуйте Firefly, Вы писали:
F> Господа, не могли бы вы доступно и по-русски объяснить, что такое .NET. Как её позиционирует Microsoft? Для чего её придумали? Почему этим все восхищаются?
Посмотрите в разделе Статьи этого сайта. Там есть много полезных статей, кстати
Плюс посмотрите ниже по веткам, там периодически поднимаются обширные дискуссии по разным поводам, но читая их легко выудить и ответы на Ваш вопрос. В будущем смотрите сначала Cтатьи, которые уже имеются на сайте и пользуйтесь Поиском! Как в переделах сайта, так и вообще по сети. Думается, что в MSDN про .NET тоже найдется, что почитать по этому поводу.
F>Заранее спасибо.
U R welcome
Здравствуйте Firefly, Вы писали:
F>Господа, не могли бы вы доступно и по-русски объяснить, что такое .NET.
Ну так вот прямо в двух словах вряд ли расскажешь. Если её с чем-то и можно сравнить, то скорее всего с Java. Но это естественно больше чем Java. MS была бы не MS. В Java VM сделана под один язык — Java. В .NET CLR сделан для поддержки любых языков программирования, в том числе и для Java.
F>Как её позиционирует Microsoft? Для чего её придумали?
. MS делает новую платформу взамен дряхлеющей Windows.
F>Почему этим все восхищаются?
Потому что легче и быстрее разрабатывать, проше понять и использовать, местами надёжней (хотя об этом говорить ещё рано). Как правило люди, реально попробовавшие с ней поработать становятся её апологетами. По крайней мере, я ещё ни разу не слышал аргументированного объяснения почему .NET отстой. В основном только недалёкие выпады скептиков типа "Вот когда покажешь реально работающую систему, тогда и поговорим". Но это всё либо от лени вникать в новое, либо от болезненной привязанности к старому.
F>Слышал, что программы переводятся в некоторое промежуточное представление (наподобие байт-кода Java). Это означает, что нужна виртуальная машина (как для Java)?
Нужна среда исполнения. Компиляторы действительно генерируют байт-код, но этот байт код никогда не выполняет в режиме иетерпретации, сначала он всегда компилируется в native-код процессора, а затем исполняется.
F>Есть ли она в Windows XP (или нет, как у Java)? Можно ли генерировать файлы формата PE?
Здравствуйте IT, Вы писали:
IT>Здравствуйте Firefly, Вы писали:
F>>Господа, не могли бы вы доступно и по-русски объяснить, что такое .NET.
IT>Ну так вот прямо в двух словах вряд ли расскажешь. Если её с чем-то и можно сравнить, то скорее всего с Java. Но это естественно больше чем Java. MS была бы не MS. В Java VM сделана под один язык — Java. В .NET CLR сделан для поддержки любых языков программирования, в том числе и для Java.
F>>Как её позиционирует Microsoft? Для чего её придумали?
IT>Об этом хорошо написал Влад здесь — http://rsdn.ru/forum/message.asp?mid=34859&only
. MS делает новую платформу взамен дряхлеющей Windows.
Большое спасибо! Рад, что Microsoft решила перестать сосать деньги из древних решений и обновляет идеологию. F>>Почему этим все восхищаются?
IT>Потому что легче и быстрее разрабатывать, проше понять и использовать, местами надёжней (хотя об этом говорить ещё рано). Как правило люди, реально попробовавшие с ней поработать становятся её апологетами. По крайней мере, я ещё ни разу не слышал аргументированного объяснения почему .NET отстой. В основном только недалёкие выпады скептиков типа "Вот когда покажешь реально работающую систему, тогда и поговорим". Но это всё либо от лени вникать в новое, либо от болезненной привязанности к старому.
F>>Слышал, что программы переводятся в некоторое промежуточное представление (наподобие байт-кода Java). Это означает, что нужна виртуальная машина (как для Java)?
IT>Нужна среда исполнения. Компиляторы действительно генерируют байт-код, но этот байт код никогда не выполняет в режиме иетерпретации, сначала он всегда компилируется в native-код процессора, а затем исполняется.
F>>Есть ли она в Windows XP (или нет, как у Java)? Можно ли генерировать файлы формата PE?
IT>Первая "встроенная" поддержка .NET будет в Windows.NET. Скачать среду исполнения можно здесь — Microsoft .NET Framework Redistributable, ~20 M. SDK здесь — Microsoft .NET Framework SDK — ~130 M.
Здравствуйте IT, Вы писали:
IT>Ну так вот прямо в двух словах вряд ли расскажешь. Если её с чем-то и можно сравнить, то скорее всего с Java. Но это естественно больше чем Java. MS была бы не MS. В Java VM сделана под один язык — Java.
Действительно, .NET -- это больше чем Microsoft Java из J++,
НО пока меньше, чем Sun Java2 Platform.
IT>В .NET CLR сделан для поддержки любых языков программирования, в том числе и для Java.
Ошибаетесь, кроме других языков поддерживается только Microsoft Java, в урезанном варианте из MS JDK 1.1.4 без JFC/Swing. На смену идёт такой же урезанный язык J# — жалкое подобие Java.
F>>Почему этим все восхищаются?
IT>Потому что легче и быстрее разрабатывать, проше понять и использовать, местами надёжней (хотя об этом говорить ещё рано). Как правило люди, реально попробовавшие с ней поработать становятся её апологетами. По крайней мере, я ещё ни разу не слышал аргументированного объяснения почему .NET отстой. В основном только недалёкие выпады скептиков типа "Вот когда покажешь реально работающую систему, тогда и поговорим". Но это всё либо от лени вникать в новое, либо от болезненной привязанности к старому.
Я реально попробовал поработать с Sun Java в 1998 году в среде Borland JBuilder. С того момента стал, говоря Вашими словами, "апологетом" Java. Наверно, то же самое происходит и с теми, кто впервые "прикасается" к интероперабельным технологиям.
Есть несколько "НО":
1) для .Net пока(надеюсь, со временем этого не будет) только декларируется переносимость программ, созданных и работающих в среде .Net Framework;
2) Microsoft скрывает исходники ключевых реализаций библиотек, без которых создание полноценных средств разработки сторонними производителями невозможно;
3) практически нет реальных приложений уровня предприятия, написанных целиком под .Net (со временем будут написаны);
4) в Java2 SE/EE есть все те особенности, к которым только-только подбирается .Net, причём исходники и документацию библиотек Java можно бесплатно загрузить, проанализировать открытый код, написать своё средство разработки.
F>>Слышал, что программы переводятся в некоторое промежуточное представление (наподобие байт-кода Java). Это означает, что нужна виртуальная машина (как для Java)?
IT>Нужна среда исполнения. Компиляторы действительно генерируют байт-код, но этот байт код никогда не выполняет в режиме иетерпретации, сначала он всегда компилируется в native-код процессора, а затем исполняется.
Эта особенность JIT-компилятора, нельзя приписывать это только .Net Framework, это давно уже было и сейчас есть и в Sun JRE, и в IBM JRE, etc.
F>>Есть ли она в Windows XP (или нет, как у Java)? Можно ли генерировать файлы формата PE?
IT>Первая "встроенная" поддержка .NET будет в Windows.NET. Скачать среду исполнения можно здесь — Microsoft .NET Framework Redistributable, ~20 M. SDK здесь — Microsoft .NET Framework SDK — ~130 M.
Ну и размерчики! :)
Sun JRE 1.4 SE — ~12Мб в дистрибутиве, нужно для запуска Java2-приложений;
Sun JDK с JRE 1.4 SE и исходниками(10Мб в ZIP) — всего ~36Мб в дистрибутиве, нужно для разработки и запуска Java2-приложений;
Sun JavaDoc к JDK 1.4 SE — 30Мб в ZIP-архиве(распаковывать не надо), нужно при разработке Java2-приложений.
Скачать можно здесь: http://sun.java.com/j2se/1.4/
Другие расширения: http://java.sun.com/products/
Здравствуйте iZEN, Вы писали:
IT>>Ну так вот прямо в двух словах вряд ли расскажешь. Если её с чем-то и можно сравнить, то скорее всего с Java. Но это естественно больше чем Java. MS была бы не MS. В Java VM сделана под один язык — Java.
ZEN>Действительно, .NET -- это больше чем Microsoft Java из J++, ZEN>НО пока меньше, чем Sun Java2 Platform.
Опять начинается флей, ну, право, это уже не так интересно.
IT>>В .NET CLR сделан для поддержки любых языков программирования, в том числе и для Java.
ZEN>Ошибаетесь, кроме других языков поддерживается только Microsoft Java, в урезанном варианте из MS JDK 1.1.4 без JFC/Swing. На смену идёт такой же урезанный язык J# — жалкое подобие Java.
Не надо путать язык программирования и его окружение. Давай мухи отдельно, котлеты отдельно. Microsoft Java — это таже Java, но с окружением заточенным под Windows. J# — Java, в которой в качестве окружения используется .NET Framework. Но язык то — Java. Или нет?
ZEN>Есть несколько "НО": ZEN>1) для .Net пока(надеюсь, со временем этого не будет) только декларируется переносимость программ, созданных и работающих в среде .Net Framework;
От переносимости я при случае конечно не откажусь, но надобности в этом в моих задачах я пока не просматриваю даже в микроскоп. Возможно это и актуально в мире Юникс, где возможно существуют реальные проблемы переносимости внутри одного клона операционных систем, но это их проблемы. Мне переносимость пока не нужна и я буду стараться избегать этого как можно дольше, т.к. считаю её источником проблем.
ZEN>2) Microsoft скрывает исходники ключевых реализаций библиотек, без которых создание полноценных средств разработки сторонними производителями невозможно;
Я не понимаю как связаны исходники и создание полноценных средств разработки. Или ты хочешь и исходники самих средств разработки? Влад вот например хочет, я знаю Но, скорее всего, ему было бы достаточно и просто доступа к некоторым интерфейсам.
ZEN>3) практически нет реальных приложений уровня предприятия, написанных целиком под .Net (со временем будут написаны);
Зато полно разработанных на Win32 и COM технологиях. И их не надо полностью переписывать (как если бы я захотел перейти на Java). .NET нормально и без проблем вписывается в существующую схему.
ZEN>4) в Java2 SE/EE есть все те особенности, к которым только-только подбирается .Net, причём исходники и документацию библиотек Java можно бесплатно загрузить, проанализировать открытый код, написать своё средство разработки.
Да полно те, можно подумать ты в курсе всех особенностей и возможностей .NET. Я сомневаюсь, что таких людей сейчас найдётся много и в самой MS
А про открытый код — это конечно здорово, да только вот на практике он нужен либо если что-то явно глючит в самой библиотеке, либо библиотека достаточно запутанная, а документация никакая и без поллитры и исходников там не разберёшся. Гораздо более полезная вещь — примеры. Один хороший пример может заменить сотни строк исходников, результат будет тем же. Так что наличие исходников можно рассматривать совсем в другом ключе, а именно как недостаток Хотя всё это конечно балтология, тем не менее, наличие исходников — это не аргумент.
IT>>Нужна среда исполнения. Компиляторы действительно генерируют байт-код, но этот байт код никогда не выполняет в режиме иетерпретации, сначала он всегда компилируется в native-код процессора, а затем исполняется.
ZEN>Эта особенность JIT-компилятора, нельзя приписывать это только .Net Framework, это давно уже было и сейчас есть и в Sun JRE, и в IBM JRE, etc.
Разве я когда то утверждал обратное? Я подчеркнул, что в .NET это делается всегда, только потому, что в той же Java это не так.
ZEN>Ну и размерчики!
Нет, ну это просто песня какая-то
Лично мне что 12, что 20, что 120 без разницы. Но зато Java нет на CD в RSDN Mag, а .NET FSDK есть и скачивать ничего не надо.
В общем, наблюдается ещё одна попытка развести флейм. Оно конечно можно, но скажу сразу. Я привёл в качесве примера Java не для того чтобы начать сравнивать две технологии, а только для того, чтобы человеку было понятней, если он о Java имеет представление. Я сказал .NET больше чем Java, потому, что это действительно так. Java — это один язык с очень большой и развитой средой. .NET — это каким-хочешь-таким-и-пользуйся-а-не-хочешь-сделай-свой язык с одной на всех очень большой и развитой средой, плюс совместимость и интеграция с существующим ПО. Если я, например, хочу перенести свой код на Java, то у меня только один выбор — всё переписать на Java, в случае .NET мне не понадобятся столь серьёзные переделки.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте IT, Вы писали:
IT>Опять начинается флей, ну, право, это уже не так интересно.
Я и не собирался разводить флейм. Я просто добавил свою точку зрения в дополнение к Вашей. Хотел подчеркнуть некоторые особенности обеих технологий для спрашивающего новичка, почему-то это Вы посчитали за начало флейма. Странно.
IT>Не надо путать язык программирования и его окружение. Давай мухи отдельно, котлеты отдельно. Microsoft Java — это таже Java, но с окружением заточенным под Windows. J# — Java, в которой в качестве окружения используется .NET Framework. Но язык то — Java. Или нет?
Java без своего "стандартного"(т.е. одобренного движением Java Community Process) окружения не представляет из себя ничего в технологическом плане -- просто ещё один интерпретируемый язык с "подвязанным" JIT, по аналогии VISUAL BASIC.
IT>От переносимости я при случае конечно не откажусь, но надобности в этом в моих задачах я пока не просматриваю даже в микроскоп. Возможно это и актуально в мире Юникс, где возможно существуют реальные проблемы переносимости внутри одного клона операционных систем, но это их проблемы. Мне переносимость пока не нужна и я буду стараться избегать этого как можно дольше, т.к. считаю её источником проблем.
Ну вот, переносимость для Вас -- это источник проблем. Странно. Если так случится, что Вам надо будет большой проект перенести/портировать под более мощную платформу(не-Win32), будете переписывать всё с нуля?
ZEN>>2) Microsoft скрывает исходники ключевых реализаций библиотек, без которых создание полноценных средств разработки сторонними производителями невозможно;
IT>Я не понимаю как связаны исходники и создание полноценных средств разработки. Или ты хочешь и исходники самих средств разработки? Влад вот например хочет, я знаю ;) Но, скорее всего, ему было бы достаточно и просто доступа к некоторым интерфейсам.
Я намекал на монополизм MS в сфере создания средств разработки под .Net и вытекающая отсюда лицензионная политика.
IT>А про открытый код — это конечно здорово, да только вот на практике он нужен либо если что-то явно глючит в самой библиотеке, либо библиотека достаточно запутанная, а документация никакая и без поллитры и исходников там не разберёшся. Гораздо более полезная вещь — примеры. Один хороший пример может заменить сотни строк исходников, результат будет тем же. Так что наличие исходников можно рассматривать совсем в другом ключе, а именно как недостаток ;) Хотя всё это конечно балтология, тем не менее, наличие исходников — это не аргумент.
Вам не нужны исходники библиотек? Вы обходитесь интерфейсами и MSDN с примерами? Зря. ;)
MSDN разваливается под своей тяжестью, MS до сих пор описывают в MSDN свои Win32 API и примочки к ним.
ZEN>>Эта особенность JIT-компилятора, нельзя приписывать это только .Net Framework, это давно уже было и сейчас есть и в Sun JRE, и в IBM JRE, etc.
IT>Разве я когда то утверждал обратное? Я подчеркнул, что в .NET это делается всегда, только потому, что в той же Java это не так.
В Java этот процесс настраивается из командной строки запуска Java-приложения (вплоть до отключения JIT и выделения динамической памяти). Есть разные JVM разных производителей, подчиняющиеся общепринятым спецификациям на Java, имеющие разные "скоростные" характеристики JIT-а.
IT>Лично мне что 12, что 20, что 120 без разницы. Но зато Java нет на CD в RSDN Mag, а .NET FSDK есть и скачивать ничего не надо. :))
А по сети слабо качнуть? Как многие это делают/предстоит сделать. :maniac:
Здравствуйте iZEN, Вы писали:
~20 M. SDK здесь — Microsoft .NET Framework SDK — ~130 M.
ZEN>Ну и размерчики! ZEN>Sun JRE 1.4 SE — ~12Мб в дистрибутиве, нужно для запуска Java2-приложений;
Справедливости ради — во первых .Net Redist все таки не 20 а 18Мб. Во вторых в Redist включены компиляторы, в JRE нет. Таким образом для asp.net redist достаточно, а вот для jsp серверов нужно ставить весь jdk.
ZEN>Sun JDK с JRE 1.4 SE и исходниками(10Мб в ZIP) — всего ~36Мб в дистрибутиве, нужно для разработки и запуска Java2-приложений;
Без документации надо заметить
ZEN>Sun JavaDoc к JDK 1.4 SE — 30Мб в ZIP-архиве(распаковывать не надо), нужно при разработке Java2-приложений.
Ты забыл еще JLS. В JavaDoc его нет.
Здравствуйте IT, Вы писали:
ZEN>>2) Microsoft скрывает исходники ключевых реализаций библиотек, без которых создание полноценных средств разработки сторонними производителями невозможно;
IT>Я не понимаю как связаны исходники и создание полноценных средств разработки. Или ты хочешь и исходники самих средств разработки? Влад вот например хочет, я знаю Но, скорее всего, ему было бы достаточно и просто доступа к некоторым интерфейсам.
Увы, идеальной документации не бывает и некоторые тонкости могут быть не представлены. Когда есть исходники — всегдна можно в них заглянуть. В свое время мне очень исходники библиотек Дельфи помогли. Да и в исходники библиотек java несколько раз приходилось лазить.
IT>Зато полно разработанных на Win32 и COM технологиях. И их не надо полностью переписывать (как если бы я захотел перейти на Java). .NET нормально и без проблем вписывается в существующую схему.
Для корпоративных приложений java все же остается более предпочтительной. На порядок больше специфических API. Где например в .net аналог EJB или JDO?
IT>Да полно те, можно подумать ты в курсе всех особенностей и возможностей .NET. Я сомневаюсь, что таких людей сейчас найдётся много и в самой MS
При чем здесь все возможности. Вот скажи для примера — если мне LinkedList нужен — мне его ручками писать или ArrayList пользовать? Ни Queue ни Stack мне не подходят ввиду необходимости удалять элементы из середины.
IT>А про открытый код — это конечно здорово, да только вот на практике он нужен либо если что-то явно глючит в самой библиотеке, либо библиотека достаточно запутанная, а документация никакая и без поллитры и исходников там не разберёшся.
Все же бывает он нужен. Да и от глюков в .Net никто не застрахован. Знаешь как xslt процессор в beta2 чудесатил.
IT>Разве я когда то утверждал обратное? Я подчеркнул, что в .NET это делается всегда, только потому, что в той же Java это не так.
В java в свое время это делалось всегда. Сейчас есть такая фишка как hotspot. Там действительно код не всегда компилируется, когда быстрее интерпретировать он интерпретируется. И работает Hostspot быстрее чистого JIT. Только подозреваю я что и в .Net используется подобная технология, только это особенно не афишируется.
ZEN>Я намекал на монополизм MS в сфере создания средств разработки под .Net и вытекающая отсюда лицензионная политика.
А зря намекали... между прочим, уже делают C# для Linux. Естественно, не MS Да и любой компании нет НИКАКИХ технологических и юридических ограничений — сделать свой аналог VisualStudio, свой язык (Borland, например будет делать Delphi.NET) для .NET. И это гуд. Кстати, с Java как раз имхо ситуация хуже.
Здравствуйте iZEN, Вы писали:
ZEN>Действительно, .NET -- это больше чем Microsoft Java из J++, ZEN>НО пока меньше, чем Sun Java2 Platform.
Спорный вопрос...
IT>>В .NET CLR сделан для поддержки любых языков программирования, в том числе и для Java.
ZEN>Ошибаетесь, кроме других языков поддерживается только Microsoft Java, в урезанном варианте из MS JDK 1.1.4 без JFC/Swing. На смену идёт такой же урезанный язык J# — жалкое подобие Java.
Ты о языке или о библиотеках? А то ведь Свинг можно с WinForms сравнить, и т.п.
И вообще получается бесполезный разговор. Ты сам то пробывал писать под .Net?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте IT, Вы писали:
IT>А про открытый код — это конечно здорово, да только вот на практике он нужен либо если что-то явно глючит в самой библиотеке, либо библиотека достаточно запутанная, а документация никакая и без поллитры и исходников там не разберёшся. Гораздо более полезная вещь — примеры. Один хороший пример может заменить сотни строк исходников, результат будет тем же. Так что наличие исходников можно рассматривать совсем в другом ключе, а именно как недостаток Хотя всё это конечно балтология, тем не менее, наличие исходников — это не аргумент.
Ну, одно другого не исключает. Я бы от исходников не отказался. К тому же это заставило бы MS серьезнее подходить к проектированию и реализации библиоткет. Минуса в этом быть не может. Но я согласен, что если есть куча стетей, хорошая документация, библиотеки хорошо спроектированы и не глючат, то исходники не нужны. Жаль только, что этого идеала невозможно достичь. Но если бы исходники были решающим аргументом, то все давно пересели бы на Линукс, а этого (совершенно объективно) нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте iZEN, Вы писали:
ZEN>Java без своего "стандартного"(т.е. одобренного движением Java Community Process) окружения не представляет из себя ничего в технологическом плане -- просто ещё один интерпретируемый язык с "подвязанным" JIT, по аналогии VISUAL BASIC.
VB здесь вообще не причем, а библиотеки у .Net тоже есть. По-моему, они даже лучше чем в Яве, но дело не в этом... они просто другие.
ZEN>Ну вот, переносимость для Вас -- это источник проблем. Странно. Если так случится, что Вам надо будет большой проект перенести/портировать под более мощную платформу(не-Win32), будете переписывать всё с нуля?
Тебе же сказали, ну ненужна ему (мне и еще нескольким сотням тысяч программистов) переносимость на Unix-ы и Линуксы. Железо на создаваемое на Intel/AMD-камнях мало чем отличается от Санвкого. IBM-овские Дипнутые Блю практически всем не по корману. Софт же пишется под конкретное железо... Под ним отлаживается... Использует его лучшие стороны и обходит слабые. Если мне нужн будет писать под Мэйнфрэйм, я буду писать по другому... причем, даже на Яве (там и память другая и стоимость многих опираций). Те кому нужна переносимость будут выбирать Яву, а то и обычные C/C++ (у них переносимость по выше будет). Не бинарная, ну, и что? Если .Net станет перенасима хотя бы в серверном варианте, т.е. без клиентского интерфейса (WinForms), то у Явы пропадет последний фиговый листок, но тем кто выбрал .Net это будет по фигу.
ZEN>Я намекал на монополизм MS в сфере создания средств разработки под .Net и вытекающая отсюда лицензионная политика.
И чем лицензионная политика на VS.Net хуже чем на Borland JBuilder? И кто тебе сказал, что нет независимых сред разработки. Они есть, только слабоваты по сравнению с MS-ными. Деньжат маловато у конкурентов, ... но, думаю, Борланд в ближайшее время сделает среду а-ля Дельфи, для .Net. Небыло бы Борланда для Явы вообще не создали бы приличной среды разработки. :(
ZEN>MSDN разваливается под своей тяжестью, MS до сих пор описывают в MSDN свои Win32 API и примочки к ним.
Ну, это опять беспочвенные наезды... Если не умеешь искать в MSDN, то спроси... мы тебе статейку подкинем, а так... остальным хватает... по сравнению с документацией от той же Явы MSDN — это рай. Ну, а наличие под рукой описания всех API ОС — это вообще большое достоинство. Под Линукс потому и софта меньше пишут, что вся документация по разным манам навалена, качество ее порой отвратительное, а средой разработки называют текстовый редактор позволящий вызывать MAKE. :(
IT>>Лично мне что 12, что 20, что 120 без разницы. Но зато Java нет на CD в RSDN Mag, а .NET FSDK есть и скачивать ничего не надо. :))
Не, ну это чё народ захочет, то и положим. Это ты уже сам во флэйм лезеш.
ZEN>А по сети слабо качнуть? Как многие это делают/предстоит сделать. :maniac:
Ты знаешь?! 30 мег по диалапу — слабо! :(
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте VladD2, Вы писали:
VD>VB здесь вообще не причем, а библиотеки у .Net тоже есть. По-моему, они даже лучше чем в Яве, но дело не в этом... они просто другие.
По моему их заметно меньше. Это тоже не надо забывать.
VD>Тебе же сказали, ну ненужна ему (мне и еще нескольким сотням тысяч программистов) переносимость на Unix-ы и Линуксы. Железо на создаваемое на Intel/AMD-камнях мало чем отличается от Санвкого. IBM-овские Дипнутые Блю практически всем не по корману. Софт же пишется под конкретное железо... Под ним отлаживается... Использует его лучшие стороны и обходит слабые.
А вот представь ситуацию. Начал я производить и продавать скажем сухарики. Через полгода, продавая сухарики в своем городе я заработал денег и сделали мне систему автоматизации моего производства скажем за $100K. Система изумительная и почти во всем меня устраивает. Проходит год, я дорабатываю систему и под это дело трачу еще $100K. Но тут объемы возрастают и мой супер пупер четырехмоторный бомбардиров... то есть сервер перестает справляться. Платформа винтель мне ничего круче предложить не может. What I can do? По новой выкидывать две сотни килобаксов?
Так что не надо бросаться из одной крайности в другую — да, многоплатформенность это не панацея от всех бед, но это не значит что она никому не нужна. Тому же MS придет блаж в голову и он что нибудь накорежит несовместимое. Или таки засудят его — и что, останешся на бобах?
VD>Небыло бы Борланда для Явы вообще не создали бы приличной среды разработки.
Не знаешь — не говори. Есть много по крайней мере не худших средств разработки. Forte например или IDEA. Есть и покруче — Together.
VD>Ну, это опять беспочвенные наезды... Если не умеешь искать в MSDN, то спроси... мы тебе статейку подкинем, а так... остальным хватает... по сравнению с документацией от той же Явы MSDN — это рай.
Чем тебе документация Java не понравилась, чем она хуже MSDN?
VD>И вообще получается бесполезный разговор. Ты сам то пробывал писать под .Net?
Не воспринимай как наезд — а ты пробовал писать на java? Я вот пробовал писать и на том и на другом.
Здравствуйте AndrewVK, Вы писали:
AVK>А вот представь ситуацию. Начал я производить и продавать скажем сухарики. Через полгода, продавая сухарики в своем городе я заработал денег и сделали мне систему автоматизации моего производства скажем за $100K. Система изумительная и почти во всем меня устраивает. Проходит год, я дорабатываю систему и под это дело трачу еще $100K. Но тут объемы возрастают и мой супер пупер четырехмоторный бомбардиров... то есть сервер перестает справляться. Платформа винтель мне ничего круче предложить не может. What I can do? По новой выкидывать две сотни килобаксов?
Эта демонстрирует лишь недостатки архитектуры предложенной тобой системы, но не платформы Wintel. Есть такое понятие расширяемость, про которое ты наверняка и сам знаешь. Такие вещи решаются не увеличением мегагерц на сервере, а установкой дополнительных серверов. И на это совсем не надо тратить по $100k каждый год. Приличный app-сервер стоит в 10-30 раз дешевле.
AVK>Так что не надо бросаться из одной крайности в другую — да, многоплатформенность это не панацея от всех бед, но это не значит что она никому не нужна. Тому же MS придет блаж в голову и он что нибудь накорежит несовместимое. Или таки засудят его — и что, останешся на бобах?
Я ж говорил, что при случае не откажусь. Но я не считаю её главным достоинством и последним аргументом. Напереносились в своё время, знаем.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте AndrewVK, Вы писали:
IT>>Я не понимаю как связаны исходники и создание полноценных средств разработки. Или ты хочешь и исходники самих средств разработки? Влад вот например хочет, я знаю Но, скорее всего, ему было бы достаточно и просто доступа к некоторым интерфейсам.
AVK>Увы, идеальной документации не бывает и некоторые тонкости могут быть не представлены. Когда есть исходники — всегдна можно в них заглянуть. В свое время мне очень исходники библиотек Дельфи помогли. Да и в исходники библиотек java несколько раз приходилось лазить.
Я пытаюсь вспомнить когда мне исходники реально помогли.
1. Надо было сделать локализацию ещё в DOS для DPMI в BC++ 4.5, что-то там Борланд нахимичил с DLL'ками.
2. Много пришлось погулять по MFC, что бы понять what's going on там внутри.
3. ATL пришлось покопать, хотя после ATL Internals
многие вопросы снялись.
Т.е. в первом случае это было связано с глюками, в остальных с недостатком литературы по изучаемому вопросу.
IT>>Зато полно разработанных на Win32 и COM технологиях. И их не надо полностью переписывать (как если бы я захотел перейти на Java). .NET нормально и без проблем вписывается в существующую схему.
AVK>Для корпоративных приложений java все же остается более предпочтительной. На порядок больше специфических API. Где например в .net аналог EJB или JDO?
Давай ты мне расшифруешь эти аббревиатуры и скажешь для чего они нужны, а я постараюсь привести примеры аналогов. Только сразу предупреждаю, как я уже говорил, .NET дополняет Win32 и возможно некоторые вещи эффективнее реализовывать на последней.
IT>>Да полно те, можно подумать ты в курсе всех особенностей и возможностей .NET. Я сомневаюсь, что таких людей сейчас найдётся много и в самой MS
AVK>При чем здесь все возможности. Вот скажи для примера — если мне LinkedList нужен — мне его ручками писать или ArrayList пользовать? Ни Queue ни Stack мне не подходят ввиду необходимости удалять элементы из середины.
А чем ArrayList не подходит?
IT>>А про открытый код — это конечно здорово, да только вот на практике он нужен либо если что-то явно глючит в самой библиотеке, либо библиотека достаточно запутанная, а документация никакая и без поллитры и исходников там не разберёшся.
AVK>Все же бывает он нужен. Да и от глюков в .Net никто не застрахован. Знаешь как xslt процессор в beta2 чудесатил.
Ok, пусть без исходников никуда, убалтали Можете напечатаь исходники CRTL или библиотек Java и обвешать ими все стены. А про beta2 это не честно. Это ж бэта, она глючить должна по определению
IT>>Разве я когда то утверждал обратное? Я подчеркнул, что в .NET это делается всегда, только потому, что в той же Java это не так.
AVK>В java в свое время это делалось всегда. Сейчас есть такая фишка как hotspot. Там действительно код не всегда компилируется, когда быстрее интерпретировать он интерпретируется. И работает Hostspot быстрее чистого JIT. Только подозреваю я что и в .Net используется подобная технология, только это особенно не афишируется.
В .NET код компилируется всегда, правда есть разные режимы опимизации. Если время компиляции не кретично, например она производится при инсталяции, то оптимизация делается по полной. Если нужно то и дело компилировать, то оптимизатор может вообще не использоваться.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте IT, Вы писали:
IT>Здравствуйте AndrewVK, Вы писали:
IT>Эта демонстрирует лишь недостатки архитектуры предложенной тобой системы, но не платформы Wintel.
Ага, ты предлагаешь мне сразу вкладывать огромные деньги в софт способный работать в кластере?
IT> Есть такое понятие расширяемость, про которое ты наверняка и сам знаешь. Такие вещи решаются не увеличением мегагерц на сервере, а установкой дополнительных серверов. И на это совсем не надо тратить по $100k каждый год. Приличный app-сервер стоит в 10-30 раз дешевле.
Видиш ли какое дело — когда я начинаю создавать систему я не знаю — проживет ли мой бизнес по производству сухариков еще хотя бы полгода. Я готов рискнуть и вложить деньги с учетом того что мой бизнес проживет год. Но на больший риск я категорически не соглачен. Если бы все решалось покупкой апп-серверов — было бы хорошо. Однако в реальности для работы в кластерной среде реальные приложения приходится дорабатывать, иногда очень серьезно, учытывая специфику распределенных транзакций, своевременной синхронизации, надежности работы сети.
Кроме того, кластеры наименее эффективный способ распараллеливания вычислений, как с точки зрения эффективности так и с точки зрения надежности и управляемости. SMP-система аналогичной производительности будет дешевле, значительно надежнее, ее проще администрировать. Так что не все так просто. Хотя иногда кластерное решение способно решить проблему.
IT>Я ж говорил, что при случае не откажусь. Но я не считаю её главным достоинством и последним аргументом. Напереносились в своё время, знаем.
Тут я с тобой согласен. Но и говорить что она почти никому не нужна не стоит. Иногда очень даже нужна.
Здравствуйте AndrewVK, Вы писали:
VD>>VB здесь вообще не причем, а библиотеки у .Net тоже есть. По-моему, они даже лучше чем в Яве, но дело не в этом... они просто другие. AVK>По моему их заметно меньше. Это тоже не надо забывать.
Во я и говорю это не спор это наезды. Ты приведи список того чего нет в .Net, но есть в Яве и чтобы при этом все это хоть кому ни будь было нужно. А так... Ну, я заявлю обратное, кто правее? :)
AVK>А вот представь ситуацию. Начал я производить и продавать скажем сухарики. Через полгода, продавая сухарики в своем городе я заработал денег и сделали мне систему автоматизации моего производства скажем за $100K. Система изумительная и почти во всем меня устраивает. Проходит год, я дорабатываю систему и под это дело трачу еще $100K. Но тут объемы возрастают и мой супер пупер четырехмоторный бомбардиров... то есть сервер перестает справляться. Платформа винтель мне ничего круче предложить не может. What I can do? По новой выкидывать две сотни килобаксов? AVK>Так что не надо бросаться из одной крайности в другую — да, многоплатформенность это не панацея от всех бед, но это не значит что она никому не нужна. Тому же MS придет блаж в голову и он что нибудь накорежит несовместимое. Или таки засудят его — и что, останешся на бобах?
Я только не пойму, что мене представлять? Я вот этот сайт вижу, до этого месяца он жил на Access-е и выдерживал по 1500 человек в день... сейчас живет на MS SQL2k на этом гребаном Интеле. Будет здесь посетителей не 1500 и 1 500 000, то мы продадим пару реклам и за этот счет купим сервер с восьмью процессорами и будет все летать. Пусть этот твой сухареклепатель деньги зарабатывает, если заработает на заводик эдак на 30 000 человек, то у него и деньги будут на другое железо, да и систему нужно будет другую делать. Нельзя управлять пекарем и заводом по одному шаблону, а ПО как раз шаблон и задает.
VD>>Небыло бы Борланда для Явы вообще не создали бы приличной среды разработки. :( AVK>Не знаешь — не говори. Есть много по крайней мере не худших средств разработки. Forte например или IDEA. Есть и покруче — Together.
Не, ну, я конечно понимаю гордость за любимый продукт... но работать на бесплатной барахолке как-то от этого не хочется (для .Net-а этого го-а тоже хватает), а использовать продукты в сотни тысяч долларов, как то не скромно :). Их у нас по 80 руб. не продают. :))) Если же сравнить их с тем самым продуктом убогого монополиста... то и Borland-овские продукты конкуренции не выдерживают...
VD>>Ну, это опять беспочвенные наезды... Если не умеешь искать в MSDN, то спроси... мы тебе статейку подкинем, а так... остальным хватает... по сравнению с документацией от той же Явы MSDN — это рай. AVK>Чем тебе документация Java не понравилась, чем она хуже MSDN?
Ну, ты открой... посмотри... поиск попробуй... по деревцу полазай... Знаешь, мне пришлось и с тем и с тем возится, но в .Net все находится в лет, а в Яве мучаешься, мучаешься потом лезешь в конфы. :( А в большинстве случаев нужная подсказка видна прямо в комплит-ворде, и лезть никуда не надо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте AndrewVK, Вы писали:
IT>>Эта демонстрирует лишь недостатки архитектуры предложенной тобой системы, но не платформы Wintel.
AVK>Ага, ты предлагаешь мне сразу вкладывать огромные деньги в софт способный работать в кластере?
Почему огромные? Хотя конечно если сначала писать базу на Access, а потом всё переносить в многозвенку, то повозиться придётся.
AVK>Видиш ли какое дело — когда я начинаю создавать систему я не знаю — проживет ли мой бизнес по производству сухариков еще хотя бы полгода. Я готов рискнуть и вложить деньги с учетом того что мой бизнес проживет год. Но на больший риск я категорически не соглачен. Если бы все решалось покупкой апп-серверов — было бы хорошо. Однако в реальности для работы в кластерной среде реальные приложения приходится дорабатывать, иногда очень серьезно, учытывая специфику распределенных транзакций, своевременной синхронизации, надежности работы сети.
Мы начали с того, что ты говорил, что тебя спасёт переносимое ПО. И где тут связь? Переносимость не означает автоматическую расширяемость, проблемы будут те же. Более того, когда подобные проблемы начинают решаться закупками оборудования о котором ты говоришь, то суммы в $100k тут рояли уже не играют. Такие железки стоят на порядок дороже, а уж софт к ним и подавно. Если же ты имел ввиду, что сервер на Sun будет работать аж в 2 раза быстрее W2k+Intel, то во-первых сегодня это уже спорно, а во-вторых два раза ничего на даст, завтра это ПО будет тормозить и на Sun.
AVK>Кроме того, кластеры наименее эффективный способ распараллеливания вычислений, как с точки зрения эффективности так и с точки зрения надежности и управляемости. SMP-система аналогичной производительности будет дешевле, значительно надежнее, ее проще администрировать. Так что не все так просто. Хотя иногда кластерное решение способно решить проблему.
Распаралеливать можно ещё и задачи. Например можно бизнес-логику по заказу сухариков поставить на один сервер, отгрузку на другой, бухгалтерию на третий, сервер печати на четвёртый, а уже потом смотреть где остаются узкие места.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
AVK>>Увы, идеальной документации не бывает и некоторые тонкости могут быть не представлены. Когда есть исходники — всегдна можно в них заглянуть. В свое время мне очень исходники библиотек Дельфи помогли. Да и в исходники библиотек java несколько раз приходилось лазить.
IT>Я пытаюсь вспомнить когда мне исходники реально помогли. IT>1. Надо было сделать локализацию ещё в DOS для DPMI в BC++ 4.5, что-то там Борланд нахимичил с DLL'ками. IT>2. Много пришлось погулять по MFC, что бы понять what's going on там внутри. IT>3. ATL пришлось покопать, хотя после ATL Internals
многие вопросы снялись. IT>Т.е. в первом случае это было связано с глюками, в остальных с недостатком литературы по изучаемому вопросу.
Где это противоречит тому что я сказал? В свое время мне очень сильно пришлось поковыряться в исходниках Дельфей ввиду не очень внятной документации по design-time среде (тогда это была 2 версия ее). Увы, идеального в природе нет и .Net документация тоже не идеальна. И когда ты упрешся в какой нибудь темный угол — что ты будешь делать?
AVK>>Для корпоративных приложений java все же остается более предпочтительной. На порядок больше специфических API. Где например в .net аналог EJB или JDO? IT>Давай ты мне расшифруешь эти аббревиатуры и скажешь для чего они нужны, а я постараюсь привести примеры аналогов.
Нет проблем. Начнем с более простой. JDO — Java Data Objects. Технология сериализации объектов в различные источники (обычно DB и XML) с возможностью выборочной десериализации. А главное — умеющая десериализовывать по набору условий при помощи языка похожего на SQL но для работы с объектами. Короче — механизм персистентности.
Ничего похожего у MS пока нет.
EJB — Enterprise Java Beans, ключевая технология J2EE. Это сервер приложений. Главное отличие от других подобных технологий — более глубокое взаимодейстиве с объектами. К примеру EJB сервер сам загружает, выгружает и инициализирует бизнес-объекты, активно их кеширует, обеспечивает безопасность, механизм транзакций, в т.ч. и распределенных, пул соединений с SQL сервером, балансировку нагрузки и работу в кластерах. Существуе механизм полностью автоматической загрузки\выгрузки объектов, когда контейнер сам создает запросы к БД, выполняет их и результат предоставляет разработчику. Ну и наконец это полноценный Object-Relational преобразователь реализующий отношения 1-1, 1-n, n-1, n-n. Самое похожее на это у MS — COM+ и serviced components, но они не умеют многое из того что могут EJB-сервера.
IT>Только сразу предупреждаю, как я уже говорил, .NET дополняет Win32 и возможно некоторые вещи эффективнее реализовывать на последней.
Э нет, так не пойдет. Идеология .Net такова что следует по возможности максимально избегать legacy интерфейсов, особенно Win32 API. И не только для переносимости. При этом вся система anti dll-hell идет нафик. Да и за что тогда боролись? Чтобы все писать на Win32? А нафига тогда дотнет?
AVK>>При чем здесь все возможности. Вот скажи для примера — если мне LinkedList нужен — мне его ручками писать или ArrayList пользовать? Ни Queue ни Stack мне не подходят ввиду необходимости удалять элементы из середины. IT>А чем ArrayList не подходит?
Сделаем проще. Вот исходник
using System;
using System.Collections;
public class Coll {
public static void Main() {
ArrayList al = new ArrayList();
int st = Environment.TickCount;
for(int i = 0; i < 1000000; i++) {
al.Insert(0,new object());
if(al.Count > 1000)
al.RemoveAt(al.Count-1);
}
Console.WriteLine(Environment.TickCount-st);
Queue q = new Queue();
st = Environment.TickCount;
for(int i = 0; i < 1000000; i++) {
q.Enqueue(new object());
if(q.Count > 1000)
q.Dequeue();
}
Console.WriteLine(Environment.TickCount-st);
}
}
А вот результат его выполнения на моей машине
1859
188
Комментарии я думаю излишни. Если интересно почему такой результат — могу рассказать.
AVK>>Все же бывает он нужен. Да и от глюков в .Net никто не застрахован. Знаешь как xslt процессор в beta2 чудесатил.
IT>Ok, пусть без исходников никуда, убалтали ;o) Можете напечатаь исходники CRTL или библиотек Java и обвешать ими все стены.
Зачем ими стены обвешивать. Просто наличие исходников уменьшает степень риска. И ничего более.
IT> А про beta2 это не честно. Это ж бэта, она глючить должна по определению ;)
Думаешь есть существенная разница между бетами и релизами? То-то MS не успел выпустить релиз дотнета уже сервис пак к нему лежит.
Здравствуйте VladD2, Вы писали:
AVK>>По моему их заметно меньше. Это тоже не надо забывать. VD>Во я и говорю это не спор это наезды. Ты приведи список того чего нет в .Net, но есть в Яве и чтобы при этом все это хоть кому ни будь было нужно.
Мне заняться что ли нечем? То с чем я столкнулся я уже перечислил. Могу еще раз
1) LinkedList
2) RandomAccessFile
3) MemoryMappedFile
Из API
1) JDO
2) EJB
3) JAAS. Правда что то похожее есть в ASP.NET, но не вебом единым
Ты не сомневайся, я не первый день пытаюсь что то на дотнете сделать. И искал то что мне нужно очень хорошо.
AVK>>Так что не надо бросаться из одной крайности в другую — да, многоплатформенность это не панацея от всех бед, но это не значит что она никому не нужна. Тому же MS придет блаж в голову и он что нибудь накорежит несовместимое. Или таки засудят его — и что, останешся на бобах?
VD>Я только не пойму, что мене представлять? Я вот этот сайт вижу, до этого месяца он жил на Access-е и выдерживал по 1500 человек в день... сейчас живет на MS SQL2k на этом гребаном Интеле. Будет здесь посетителей не 1500 и 1 500 000, то мы продадим пару реклам и за этот счет купим сервер с восьмью процессорами и будет все летать.
Господи, да что ты все про веб. Нафига он сухарепекателю нужен? Я про КИС толкую. А там нагрузки более другие нежели для веб серверов. Yahoo в свое время работал на 4 P-90 и обслуживал более миллиона запросов в день.
VD> Пусть этот твой сухареклепатель деньги зарабатывает, если заработает на заводик эдак на 30 000 человек, то у него и деньги будут на другое железо, да и систему нужно будет другую делать. Нельзя управлять пекарем и заводом по одному шаблону, а ПО как раз шаблон и задает.
Я тебе по опыту знаешь что скажу — заводик может так и остаться небольшим, а обороты возрастут на порядок. И именно хорошая КИС поможет ему не раздувать до неимоверных размеров управленческий аппарат. А работяг при хорошем оборудовании много не нужно. Так что КИС для него — вопрос жизни и смерти. В общем вопрос возможности миграции на другую платформу для подобных систем очень важен. Если не веришь — больше ничего доказывать тебе не буду, ибо бесполезно.
AVK>>Не знаешь — не говори. Есть много по крайней мере не худших средств разработки. Forte например или IDEA. Есть и покруче — Together.
VD>Не, ну, я конечно понимаю гордость за любимый продукт...
Я что то говорил про свой любимый продукт?
VD> но работать на бесплатной барахолке как-то от этого не хочется (для .Net-а этого го-а тоже хватает), а использовать продукты в сотни тысяч долларов, как то не скромно .
Все три вышеперечисленных не бесплатны и не стоят сотни тысяч. Так что мимо.
VD> Их у нас по 80 руб. не продают. Если же сравнить их с тем самым продуктом убогого монополиста... то и Borland-овские продукты конкуренции не выдерживают...
Т.е. ты считаешь что отсутствие выбора средства разработки это хорошо? Дальнейший разговор похоже лишен смысла.
AVK>>Чем тебе документация Java не понравилась, чем она хуже MSDN? VD>Ну, ты открой... посмотри... поиск попробуй... по деревцу полазай...
Открывал, смотрел и лазил очень много. VD> Знаешь, мне пришлось и с тем и с тем возится, но в .Net все находится в лет, а в Яве мучаешься, мучаешься потом лезешь в конфы.
Мне вот тоже. И нахожу я в DotNet информацию ничуть не быстрее чем в java.
VD> А в большинстве случаев нужная подсказка видна прямо в комплит-ворде, и лезть никуда не надо.
Это уже не документация а средства ее просмотра. И если ты не знаешь таковых в java это не значит что их нет в природе.
Здравствуйте IT, Вы писали:
IT>Почему огромные? Хотя конечно если сначала писать базу на Access, а потом всё переносить в многозвенку, то повозиться придётся.
Потому что сервера умеющие распределенные транзакции недешевы.
IT>Мы начали с того, что ты говорил, что тебя спасёт переносимое ПО. И где тут связь?
Иногда перенести с винтела на тяжелый сервер эффективнее нежели перенос на винтел кластер. Так моя мысль понятна?
IT>Переносимость не означает автоматическую расширяемость, проблемы будут те же. Более того, когда подобные проблемы начинают решаться закупками оборудования о котором ты говоришь, то суммы в $100k тут рояли уже не играют.
Давай к цифрам придираться не будем. Я тут не бизнес-план проекта составляю. Цифры взяты с потолка. А вот цифры не с потолка — стоимость железок в проекте обычно составляет 3-5% стоимости софта.
IT> Такие железки стоят на порядок дороже, а уж софт к ним и подавно. Если же ты имел ввиду, что сервер на Sun будет работать аж в 2 раза быстрее W2k+Intel, то во-первых сегодня это уже спорно, а во-вторых два раза ничего на даст, завтра это ПО будет тормозить и на Sun.
Да при чем здесь сан. Просто винтел сервера занимают только самый нижний уровень производительности. Это факт. Если я не прав — найди мне коммерческий винтель сервер ну скажем с 32 процессорами, парой десятков гиг оперативки и парой терабайт дисковых накопителей. И никакой кластер тут не поможет ибо эффективность его падает с увеличением количества машин.
IT>Распаралеливать можно ещё и задачи. Например можно бизнес-логику по заказу сухариков поставить на один сервер, отгрузку на другой, бухгалтерию на третий, сервер печати на четвёртый, а уже потом смотреть где остаются узкие места.
Вот! Об этом я и говорю. Бизнес логику придеться переделывать. И никаким супер-пупер апп-сервером это не сделать. А затраты на существенную переделку софта на порядок выше стоимости любых железок. Да и железку мне установят и настроят за 3 дня без моего участия. А софт будут переделывать месяца 3 в лучшем случае. А потом еще полгода будут глюки ловить.
Здравствуйте AndrewVK, Вы писали:
IT>>Давай ты мне расшифруешь эти аббревиатуры и скажешь для чего они нужны, а я постараюсь привести примеры аналогов.
AVK>Нет проблем. Начнем с более простой. JDO — Java Data Objects. Технология сериализации объектов в различные источники (обычно DB и XML) с возможностью выборочной десериализации. А главное — умеющая десериализовывать по набору условий при помощи языка похожего на SQL но для работы с объектами. Короче — механизм персистентности. AVK>Ничего похожего у MS пока нет.
Я тоже иногда кидаюсь голословными заявлениями, потом приходится жалеть. ;) В .NET не просто сериализация, а сериализация на сериализации и сериализацией погоняет. Возможно она реализована не так как в Java, но это не значит что хуже. Всё сериализуется по-умолчанию, если есть желание, то можно этим довольно гибко управлять простыми атрибутами без всяких языков. Но если и этого не достаточно, то перекрывай ISerializable и вытворяй что хочешь. Для сохранения/восстановления объектов предназначены форматеры, сейчас их есть для binary и xml. Никто тебе не мешает нарисовать свой и сохранять как тебе хочется.
AVK>EJB — Enterprise Java Beans, ключевая технология J2EE. Это сервер приложений. Главное отличие от других подобных технологий — более глубокое взаимодейстиве с объектами. К примеру EJB сервер сам загружает, выгружает и инициализирует бизнес-объекты, активно их кеширует, обеспечивает безопасность, механизм транзакций, в т.ч. и распределенных, пул соединений с SQL сервером, балансировку нагрузки и работу в кластерах.
Насколько мне известно, там внутри под всем этим хозяйством лежит CORBA. Или я ошибаюсь? MS рекомендует для этих целей использовать COM+. С одной стороны он тесно интегрирован с ОС, с другой с .NET. Все перечисленные тобой возможности в нём имеются.
AVK>Существуе механизм полностью автоматической загрузки\выгрузки объектов, когда контейнер сам создает запросы к БД, выполняет их и результат предоставляет разработчику. Ну и наконец это полноценный Object-Relational преобразователь реализующий отношения 1-1, 1-n, n-1, n-n. Самое похожее на это у MS — COM+ и serviced components, но они не умеют многое из того что могут EJB-сервера.
Этого я не припомню, но пока и не соображу зачем это надо.
IT>>Только сразу предупреждаю, как я уже говорил, .NET дополняет Win32 и возможно некоторые вещи эффективнее реализовывать на последней.
AVK>Э нет, так не пойдет. Идеология .Net такова что следует по возможности максимально избегать legacy интерфейсов, особенно Win32 API. И не только для переносимости. При этом вся система anti dll-hell идет нафик. Да и за что тогда боролись? Чтобы все писать на Win32? А нафига тогда дотнет?
Ещё раз повторюсь. .NET не отменяет Windows, более того, это было бы просто самоубийство. Скороее всего, постепенно большинство сервисов, предоставляемых Windows будут заменяться на собственные. Но это будет происходить эволюционно. И это правильно. Переход должен быть постепенным и должна быть обеспечена интеграция с существующими технологиями. В частности для написания объектов COM+ в .NET совсем не надо прибегать к использованию WinAPI, всё делается интерфейсами и атрибутами.
AVK>>>При чем здесь все возможности. Вот скажи для примера — если мне LinkedList нужен — мне его ручками писать или ArrayList пользовать? Ни Queue ни Stack мне не подходят ввиду необходимости удалять элементы из середины.
IT>>А чем ArrayList не подходит?
AVK>Сделаем проще. Вот исходник
[skip]
Тогда рассказывай что такое LinkedList, если ни список ни коллекция тебе не подходит.
IT>> А про beta2 это не честно. Это ж бэта, она глючить должна по определению ;)
AVK>Думаешь есть существенная разница между бетами и релизами? То-то MS не успел выпустить релиз дотнета уже сервис пак к нему лежит.
То что я в бессильной злобе пытался решить на бете в релизе было пофиксено. А быстрые сервис-паки это неплохо, работают ребята :)
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте AndrewVK, Вы писали:
IT>>Мы начали с того, что ты говорил, что тебя спасёт переносимое ПО. И где тут связь?
AVK>Иногда перенести с винтела на тяжелый сервер эффективнее нежели перенос на винтел кластер. Так моя мысль понятна?
Т.е. базу на Access или DBF перенести на DB2? Кажется мы начинали с совсем простых систем.
AVK>Да при чем здесь сан. Просто винтел сервера занимают только самый нижний уровень производительности. Это факт. Если я не прав — найди мне коммерческий винтель сервер ну скажем с 32 процессорами, парой десятков гиг оперативки и парой терабайт дисковых накопителей. И никакой кластер тут не поможет ибо эффективность его падает с увеличением количества машин.
Зачем кластер?
IT>>Распаралеливать можно ещё и задачи. Например можно бизнес-логику по заказу сухариков поставить на один сервер, отгрузку на другой, бухгалтерию на третий, сервер печати на четвёртый, а уже потом смотреть где остаются узкие места.
AVK>Вот! Об этом я и говорю. Бизнес логику придеться переделывать. И никаким супер-пупер апп-сервером это не сделать. А затраты на существенную переделку софта на порядок выше стоимости любых железок. Да и железку мне установят и настроят за 3 дня без моего участия. А софт будут переделывать месяца 3 в лучшем случае. А потом еще полгода будут глюки ловить.
Я не о том. Не надо кластеров, не надо особых переделок. Есть задача печати отчётов, есть работы с клиентами, есть что-то ещё. Разносим их по разным серверам и всё.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
IT>Я тоже иногда кидаюсь голословными заявлениями, потом приходится жалеть. ;) В .NET не просто сериализация, а сериализация на сериализации и сериализацией погоняет. Возможно она реализована не так как в Java, но это не значит что хуже. Всё сериализуется по-умолчанию, если есть желание, то можно этим довольно гибко управлять простыми атрибутами без всяких языков. Но если и этого не достаточно, то перекрывай ISerializable и вытворяй что хочешь. Для сохранения/восстановления объектов предназначены форматеры, сейчас их есть для binary и xml. Никто тебе не мешает нарисовать свой и сохранять как тебе хочется.
Вот так и знал что не стоит слово сериализация употреблять. Не сериализация это а персистентность. К примеру сериализуй ты как тебе хочется скажем 1000000 объектов. А потом выбери из них полсотни у которых свойство Prop1 like %XXX%. Теперь понимаешь что никаких форматтеры не помогут, нужен специальный фреймворк.
IT>Насколько мне известно, там внутри под всем этим хозяйством лежит CORBA.
Не обязательно. Все основные механизмы вполне работают без CORBA.
Или я ошибаюсь? MS рекомендует для этих целей использовать COM+. С одной стороны он тесно интегрирован с ОС, с другой с .NET. Все перечисленные тобой возможности в нём имеются.
IT>Этого я не припомню, но пока и не соображу зачем это надо.
Честно говоря долго здесь объяснять. Если интересно — посмотри на java.sun.com. EJB это не просто библиотека, это технология и методология создания и эксплуатации корпоративных систем.
IT>Ещё раз повторюсь. .NET не отменяет Windows, более того, это было бы просто самоубийство.
Ну так из Java тоже можно и до Win32 и даже до COM достучаться, только вот не надо этого делать. IT>Скороее всего, постепенно большинство сервисов, предоставляемых Windows будут заменяться на собственные.
Вот об этом то я и говорю. Да, я надеюсь будет. Но пока то нет! А в java уже. Об этом я и говорю.
Дело то не в том что технология дотнет в чем то ущербна. Просто у нее нет многолетней истории развития как у java. Она ведь все эти годы не стояла на месте. И мне очень нравится то что дотнет многое перенял. Но мясом он пока что не оброс в должной степени. IT> Но это будет происходить эволюционно. И это правильно. Переход должен быть постепенным и должна быть обеспечена интеграция с существующими технологиями. В частности для написания объектов COM+ в .NET совсем не надо прибегать к использованию WinAPI, всё делается интерфейсами и атрибутами.
Но сервер то по прежнему нативный. Вобщем я не против эволюции. И вполне верю что дотнет в конечном этоге превзойдет java по всем параметрам. Уже сейчас C# заметно удобнее. Но пока для серьезных проектов я бы дотнет применять не торопился бы. Вот для веб решений совсем другое дело.
IT>Тогда рассказывай что такое LinkedList, если ни список ни коллекция тебе не подходит.
А LinkedList это по сути Queue или Stack но с интерфейсом IList.
IT>То что я в бессильной злобе пытался решить на бете в релизе было пофиксено. А быстрые сервис-паки это неплохо, работают ребята :)
Хорошо конечно. Просто это доказывает что релиз увы не безглючен.
Здравствуйте IT, Вы писали:
AVK>>Иногда перенести с винтела на тяжелый сервер эффективнее нежели перенос на винтел кластер. Так моя мысль понятна?
IT>Т.е. базу на Access или DBF перенести на DB2? Кажется мы начинали с совсем простых систем.
Кажется мы начинали с дотнета?
IT>Зачем кластер?
Кто то здесь кластер предлагал как решение проблемы масштабируемости. Вот я и пытаюсь объяснить что кластер не есть самая оптимальная система.
IT> Я не о том. Не надо кластеров, не надо особых переделок. Есть задача печати отчётов, есть работы с клиентами, есть что-то ещё. Разносим их по разным серверам и всё.
Низзя просто так. Думаешь зря репликацию и DTC придумали? Данные то в корпоративных системах очень тесно связаны и просто так разрезать ядро на практически независимые части сложно. А тормозить как правило начинает не вся система а какое то узкое место. Я согласен — более правилным решением будет перепроектирование, но к сожалению это будет и самым дорогим решением.
Ладно, пора завязывать. Мы тут уже совсем не о том о чем начали говорим. Если хочешь обсудить вопросы проектирования корпоративных систем — давай другой топик заведем.
Здравствуйте AndrewVK, Вы писали:
VD>>И вообще получается бесполезный разговор. Ты сам то пробывал писать под .Net? AVK>Не воспринимай как наезд — а ты пробовал писать на java? Я вот пробовал писать и на том и на другом.
Пробывал. Причем на Яве дважды. Первый раз до появления джитов и зачислил Яву в разряд полной клиники и сумашедшего пиара, и второй раз после появления ХотСпота... это уже показалось похожим на нечто человеческое, только постоянно не покидает ощущение, что тебя связали по рукам и ногам. Я понимашъ, до этого на разных C/C++ по программировал и еще на десятке языков... Думаю, .Net замечательное средство для подстегивания Сана... может тепрь они начнут устранять дурь мешающую многим программистам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте AndrewVK, Вы писали:
AVK>Кроме того, кластеры наименее эффективный способ распараллеливания вычислений, как с точки зрения эффективности так и с точки зрения надежности и управляемости. SMP-система аналогичной производительности будет дешевле, значительно надежнее, ее проще администрировать. Так что не все так просто. Хотя иногда кластерное решение способно решить проблему.
В общем о чем разговр я уже не понимаю, но после столь смелых заявлений и таких убедительных аргументов дальнейший разговор безполезен. Ты хоть знаешь сколько стоит 8 однопроцесорных машин (без наворотов) и один 8-ми процесорный сервер? И что нужно предпринять чтобы это сервер не сдох от того что сгорел кондер в блоке питания? И как SMP-системы масшатбируются после 8-ми процессоров? Короче, при таких смелых заявлениях нужно хоть как то обосновывать свое мнение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте IT, Вы писали:
IT>...Если же ты имел ввиду, что сервер на Sun будет работать аж в 2 раза быстрее W2k+Intel, то во-первых сегодня это уже спорно...
Не ну почему же спорно. Последние эксперементы уже доказывают, что тормозить будет... только Ява. MS тут очередной пресрелиз залудил. По их раскладкам даже обычный ASP + COM+ делает Ява сервера, а ASP.Net делает со свистом. Вот только как я уже говорил — это все бред. Программы писались... пишутся... и будут писаться в расчете на производиетльность и особенности конкретного железа. Если программа не способна паралелиться, то никакой супер пупер Сан или IBM не помогут. Там же SMP/MMP! А целочисленные операции отстают даже от AMD. Если есть параллелизм на уровне сессий, то опять же все будет зависить от крамотности проектирования и изначальной заточенности под этот самый параллеилизм. Система изготавливаемая для пекаря не нуждается во всех этих наворотах. Они попроту дороги в реализации. А система для супер-мега-завода построеная из системы для пекаря просто развалится или потребует больше ресурсов на переписывание. Так что лучше не мучаться. Кесарю ...
AVK>>Кроме того, кластеры наименее эффективный способ распараллеливания вычислений, как с точки зрения эффективности так и с точки зрения надежности и управляемости. SMP-система аналогичной производительности будет дешевле, значительно надежнее, ее проще администрировать. Так что не все так просто. Хотя иногда кластерное решение способно решить проблему.
IT>Распаралеливать можно ещё и задачи. Например можно бизнес-логику по заказу сухариков поставить на один сервер, отгрузку на другой, бухгалтерию на третий, сервер печати на четвёртый, а уже потом смотреть где остаются узкие места.
Ты чё серьезно считаешь, что SMP надежнее кластеров, да еще и, что SMP лучше масшатбируется?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте VladD2, Вы писали:
IT>>Распаралеливать можно ещё и задачи. Например можно бизнес-логику по заказу сухариков поставить на один сервер, отгрузку на другой, бухгалтерию на третий, сервер печати на четвёртый, а уже потом смотреть где остаются узкие места.
VD>Ты чё серьезно считаешь, что SMP надежнее кластеров, да еще и, что SMP лучше масшатбируется?
Кажется я неудачно применил слово распаралеливать
Я серьёзно считаю, что ещё до того как заниматься переделкой всей архитектуры, кое что (а иногда и очень много) можно выжать из существующей простым выносом некоторых ресурсоёмких и относительно независимых подзадач на отдельные недорогие машины (не процессоры). Например, какую-нибудь тупую обработку данных, поставил машинку в уголок и пусть себе маслает неспеша и главное никого не отвлекая. Можно ставить отдельные app-сервера для отдельных рабочих групп и т.д. Много чего можно до того как будет принято решение купить Крэй и замонстрячить всё под него.
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте VladD2, Вы писали:
VD>Ты чё серьезно считаешь, что SMP надежнее кластеров, да еще и, что SMP лучше масшатбируется?
ЗЫ. За SMP я кажеться вообще ничего не говорил. Это вообще не моё прикладниковое дело. Помнится давным-давно один дядька на конференции кажется Графикон-92 долго рассказывал как они распаралеливают обсчёт графики на транспьютерах. Так вот, собственно о графике он ничего особенного и не говорил, в основном про то как это тяжко всё распаралелить. Повозился и я в своё время с этими транспьютерами, больше желания пока не возникало
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте AndrewVK, Вы писали:
AVK>1) LinkedList AVK>2) RandomAccessFile AVK>3) MemoryMappedFile AVK>Из API AVK>1) JDO AVK>2) EJB AVK>3) JAAS. Правда что то похожее есть в ASP.NET, но не вебом единым AVK>Ты не сомневайся, я не первый день пытаюсь что то на дотнете сделать. И искал то что мне нужно очень хорошо.
И что в .Net по твоему для задачь решаемых этим миксом API, классов и отдельных алгоритмов нет замены? Хорошо же ты занимался .Net-ом.
AVK>Господи, да что ты все про веб. Нафига он сухарепекателю нужен? Я про КИС толкую. А там нагрузки более другие нежели для веб серверов. Yahoo в свое время работал на 4 P-90 и обслуживал более миллиона запросов в день.
И что же там другого. Ну, на яхе ясно все только на чтение, но в любой конфе все тоже самое, а нагрузка в сотни раз больше. Может чем рассуждать про килобаксы начать заниматься серьезным проектированием и задумываться о общей производительности системы не только в момент когда выкладываешь деньги на очередной мэйнфрэйм?
AVK>Я тебе по опыту знаешь что скажу — заводик может так и остаться небольшим, а обороты возрастут на порядок.
Тогда этому сухареклёпу нужно думать как и где нанять нормальных менеджеров, а не вбухивать деньги в софт.
AVK>И именно хорошая КИС поможет ему не раздувать до неимоверных размеров управленческий аппарат. А работяг при хорошем оборудовании много не нужно. Так что КИС для него — вопрос жизни и смерти. В общем вопрос возможности миграции на другую платформу для подобных систем очень важен. Если не веришь — больше ничего доказывать тебе не буду, ибо бесполезно.
А что мне верить... не верить я как бы этим все занимался и знаю, что любая программа — это всего лишь инструмент. К ней голова и руки нужны. В нашей стране большая чатсть предприятий работают на 1C, Бэстах и разных там Галактиках... и ты не поверишь?! Работают и прибыль получают. Хороший менеджер и в Ёкселе все что нжуно (по зарез) посчитат. А похому и супер-пупер КИС не поможет. На западе разные SAP тоже без явы обходятся и все заявляют об ориентации на MS SQL (который сам знаешь на какой платформе работает) заявляют. Короче, я до сих пор не пйму, ну если другим переносимость не нужна, то чё ее так навязывать. Нужна тебе переносимость... ну, дык используй Яву, но не объясняй другим, что это главный критерий (в мире где PS 90%).
AVK>Все три вышеперечисленных не бесплатны и не стоят сотни тысяч. Так что мимо.
Ну, ты цены то обшие назови. Форт вроде стоит, около $2000. Это конечно не сотни тысяч, но примерно на эти деньги можно купить MSDN Universal и плучить весь софт MS, в том числе ОС, серверы [включая SQL Server] и VS.Net верхней редакции. А сколько стоит Together? И что такое IDEA? Мог бы и по подробнее рассказать.
VD>> Их у нас по 80 руб. не продают. :))) Если же сравнить их с тем самым продуктом убогого монополиста... то и Borland-овские продукты конкуренции не выдерживают... AVK>Т.е. ты считаешь что отсутствие выбора средства разработки это хорошо? Дальнейший разговор похоже лишен смысла.
Не, я о том, что из из чувства протеста, или непостижимой любви к переносимости пользоваься менее удобными средствами я бы не стал. :(
AVK>Это уже не документация а средства ее просмотра. И если ты не знаешь таковых в java это не значит что их нет в природе.
Будь добор, отрой глаза. Что же за чудо средства зарыты от простых смертных так глубоко и зачем?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте AndrewVK, Вы писали:
AVK>Да при чем здесь сан. Просто винтел сервера занимают только самый нижний уровень производительности. Это факт. Если я не прав — найди мне коммерческий винтель сервер ну скажем с 32 процессорами, парой десятков гиг оперативки и парой терабайт дисковых накопителей. И никакой кластер тут не поможет ибо эффективность его падает с увеличением количества машин.
Класс! Ты на TCP-тесты ходил смотреть? http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
Особое внимание обрати на колонки: Database, Operating System и TP Monitor.
:)))
AVK>Вот! Об этом я и говорю. Бизнес логику придеться переделывать. И никаким супер-пупер апп-сервером это не сделать. А затраты на существенную переделку софта на порядок выше стоимости любых железок. Да и железку мне установят и настроят за 3 дня без моего участия. А софт будут переделывать месяца 3 в лучшем случае. А потом еще полгода будут глюки ловить.
Ну, бизнес-логику можно и сразу разрабатывать с расчетом на параллелизм, а про 3 дня на какой-нить Fujitsu PRIMEPOWER 2000 с Solaris 8 тебе и за три месяца не поставят. :)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте IT, Вы писали:
IT>Кажется я неудачно применил слово распаралеливать IT>Я серьёзно считаю, что ещё до того как заниматься переделкой всей архитектуры, кое что (а иногда и очень много) можно выжать из существующей простым выносом некоторых ресурсоёмких и относительно независимых подзадач на отдельные недорогие машины (не процессоры). Например, какую-нибудь тупую обработку данных, поставил машинку в уголок и пусть себе маслает неспеша и главное никого не отвлекая. Можно ставить отдельные app-сервера для отдельных рабочих групп и т.д. Много чего можно до того как будет принято решение купить Крэй и замонстрячить всё под него.
Другой бы спорить начал... кулаками махать... а я так не буду. Я почему-то тоже считаю, что голова — лучшее средство повышение производительности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Вот так и знал что не стоит слово сериализация употреблять. Не сериализация это а персистентность. К примеру сериализуй ты как тебе хочется скажем 1000000 объектов. А потом выбери из них полсотни у которых свойство Prop1 like %XXX%. Теперь понимаешь что никаких форматтеры не помогут, нужен специальный фреймворк.
А ты разницу в производительности прямой работы с SQL и бинднутых бобов сравнивал?
IT>>Насколько мне известно, там внутри под всем этим хозяйством лежит CORBA. AVK>Не обязательно. Все основные механизмы вполне работают без CORBA.
А ну как поделись. Какая реазация объодится без CORBA-ы?
AVK>Честно говоря долго здесь объяснять. Если интересно — посмотри на java.sun.com. EJB это не просто библиотека, это технология и методология создания и эксплуатации корпоративных систем.
А-га. То-то сплош и рядом вопросы по RMI всплывают. :)
AVK>Ну так из Java тоже можно и до Win32 и даже до COM достучаться, только вот не надо этого делать.
Ну, зачем же так? Не на Яве, а на C... ведь про JNI?
AVK>Вот об этом то я и говорю. Да, я надеюсь будет. Но пока то нет! А в java уже. Об этом я и говорю.
Во-во! И разница в том, что если в .Net чего-нить нет, можно взять из WinAPI (причем в два счета, не используя других языков), а если чёго-нить нет в Яве, то можно смело отдыхать предвкушая трах по обходу проблем. За то переносимость! И фиг с ним, что не одна версия программы никогда не запускалась на чем-нибудь отличном от PC.
AVK>Дело то не в том что технология дотнет в чем то ущербна. Просто у нее нет многолетней истории развития как у java. Она ведь все эти годы не стояла на месте. И мне очень нравится то что дотнет многое перенял. Но мясом он пока что не оброс в должной степени.
Нда... с такими критериями нужно выбирать Паскаль или С. У них история куда больше...
Мяса то у .Net хватает. На рынке програм для клиентских ПК Ява даже рядом не стояла, да и на сервере все очень даже ничего. В области Web-а Ява опять же отдыхает. Как ты думаешь в какую сторону изменится положение через год? Ну, а два?
AVK>Но сервер то по прежнему нативный. Вобщем я не против эволюции. И вполне верю что дотнет в конечном этоге превзойдет java по всем параметрам. Уже сейчас C# заметно удобнее. Но пока для серьезных проектов я бы дотнет применять не торопился бы. Вот для веб решений совсем другое дело.
Значит Web-решения вещь не серьезная. :) Вон IT вообще все хочет не Web-сервисах переписать. :)
AVK>А LinkedList это по сути Queue или Stack но с интерфейсом IList.
А ты что (конкретно) сделать хочешь? Зчем он тебе нужен? И что мешает просто написать это дело самому (так ты хочешь) или просто не сделать сэлф-ссылку в класе?
IT>>То что я в бессильной злобе пытался решить на бете в релизе было пофиксено. А быстрые сервис-паки это неплохо, работают ребята :) AVK>Хорошо конечно. Просто это доказывает что релиз увы не безглючен.
А что есть хоть одна безглючная программа размеров более чем в 100 000 строк кода? Или глюки исчезают через 5 лет существования продукта?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Пробывал. Причем на Яве дважды. Первый раз до появления джитов и зачислил Яву в разряд полной клиники и сумашедшего пиара, и второй раз после появления ХотСпота... это уже показалось похожим на нечто человеческое, только постоянно не покидает ощущение, что тебя связали по рукам и ногам. Я понимашъ, до этого на разных C/C++ по программировал и еще на десятке языков...
Я тебя понял. Дело в том что java помимо всего прочего представляет собой еще и методологию программирования, заметно отличную от применяемой в том же С/С++. И если пытаться программировать вразрез с этой методологией — как раз и будет появляться подобное ощущение. Либо ты ее принимаешь либо нет. C# в этом плане чуть менее академичен, но и он много ближе к java нежели к С++. Т.е. на C# таки можно программировать в стиле С++, но при этом все его преимущества теряются.
VD> Думаю, .Net замечательное средство для подстегивания Сана... может тепрь они начнут устранять дурь мешающую многим программистам.
Ну не такая уж там и дурь. Есть две крайности — крайне правильный, чисто объектный и очень строгий язык и язык, не накладывающий практически никаких ограничений. Истина как всегда по середине.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали:
VD>В общем о чем разговр я уже не понимаю, но после столь смелых заявлений и таких убедительных аргументов дальнейший разговор безполезен. Ты хоть знаешь сколько стоит 8 однопроцесорных машин (без наворотов) и один 8-ми процесорный сервер?
Знаю. А ты? Учти — однопроцессорные машины — это тоже сервера + дорогой коммутатор. VD> И что нужно предпринять чтобы это сервер не сдох от того что сгорел кондер в блоке питания?
Вот еслки палки. Ты поинтересуйся для интереса чем сервер отличается от обычной машины. Отнюдь не только быстродействием. В частности в 8-мипроцессорных серверах 2 или 4 блока питания. Еще один вопрос — что вероятнее, сгорание одного дорогого блока питания — или одного из 8 подешевле? VD> И как SMP-системы масшатбируются после 8-ми процессоров?
Лучше чем кластеры. а главное проще. VD> Короче, при таких смелых заявлениях нужно хоть как то обосновывать свое мнение.
Честно говоря разговор об этом мне не очень интересен. Я для себя этот вопрос в свое время хорошо изучил. Если не веришь — ради бога, из порток выпрыгивать я не стану.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали:
AVK>>1) LinkedList AVK>>2) RandomAccessFile AVK>>3) MemoryMappedFile AVK>>Из API AVK>>1) JDO AVK>>2) EJB AVK>>3) JAAS. Правда что то похожее есть в ASP.NET, но не вебом единым AVK>>Ты не сомневайся, я не первый день пытаюсь что то на дотнете сделать. И искал то что мне нужно очень хорошо.
VD>И что в .Net по твоему для задачь решаемых этим миксом API, классов и отдельных алгоритмов нет замены? Хорошо же ты занимался .Net-ом.
ОК. Давай, расскажи хотя бы про 1 пункт. Как мне на .Net получить LinkedList?
VD>И что же там другого. Ну, на яхе ясно все только на чтение, но в любой конфе все тоже самое, а нагрузка в сотни раз больше. Может чем рассуждать про килобаксы начать заниматься серьезным проектированием и задумываться о общей производительности системы не только в момент когда выкладываешь деньги на очередной мэйнфрэйм?
Можно. Вот только реальная жизнь увы все красивые планы ломает. Естественно, разрабатывая новую систему нужно уделять очень большое внимание ее архитектуре. Но, в отличие от того же веб софта КИС очень активно видоизменяется в процессе жизнедеятельности. А планировать на 5 лет вперед просто не реально. Крупные фирмы с нуля создаются очень редко, как правило на этих фирмах уже накоплен приличный багаж. Ты предлагаешь все это похерить и переписать все заново. Извини, но ни один нормальный руководитель тебе этого не позволит. И дело даже не во вложеных деньгах. Дело в том что смена информационной системы для крупного предприятия это очень тяжелое испытание. И это чревато потерей денег куда больших нежели стоимость самой разработки. Перепроектировать систему имеет смысл только в том случае когда иными способами улучшения ее работы уже не добиться. И поверь — любой сановский или ибмовский сервер обойдется на порядок дешевле нежели перепроектирование. Зайди в любую более менее серьезную фирму подобного профиля и задай вопрос — увидишь что тебе ответят.
Да и вобще, к корпоративному софту предъявляются совершенно иные требования нежели к десктопному, это другая вселенная со своими законами. И именно на этот софт нацелены все те технологии которые вызывают здесь ожесточенные споры в их нужности.
Ладно, все, на эту тему я больше спорить не буду, ибо не вижу смысла.
AVK>>Я тебе по опыту знаешь что скажу — заводик может так и остаться небольшим, а обороты возрастут на порядок. VD>Тогда этому сухареклёпу нужно думать как и где нанять нормальных менеджеров, а не вбухивать деньги в софт.
Ему нужно думать и о том и о том.
VD>А что мне верить... не верить я как бы этим все занимался и знаю, что любая программа — это всего лишь инструмент. К ней голова и руки нужны. В нашей стране большая чатсть предприятий работают на 1C, Бэстах и разных там Галактиках... и ты не поверишь?! Работают и прибыль получают.
У меня здесь 1С. Так что поверю.
VD>Хороший менеджер и в Ёкселе все что нжуно (по зарез) посчитат.
В экселе? Эдак несколько сотен заказов в день? Все, я тебя понял. Мы вобще то о разных масштабах говорим. Фактик для примера — на одном предприятии не очень большого размера список тех. операций одного цеха — толмуд больше тысячи листов. Задача — в разумное время посчитать в экселе фактическую себестоимость продукции.
VD> А похому и супер-пупер КИС не поможет. На западе разные SAP тоже без явы обходятся и все заявляют об ориентации на MS SQL (который сам знаешь на какой платформе работает) заявляют.
А не к ночи буде упомянутый SAP зачем то свою SAP DB ваяет
VD> Короче, я до сих пор не пйму, ну если другим переносимость не нужна, то чё ее так навязывать.
А ее никто и не навязывает.
VD> Нужна тебе переносимость... ну, дык используй Яву, но не объясняй другим, что это главный критерий (в мире где PS 90%).
Э нет, ты пожалуйста за меня не говори. Это ты всем доказывал что переносимость нафик никому не нужна. Я тебе и объясняю что иногда она таки нужна. Найди цитату где я говорил что это главный критерий.
AVK>>Все три вышеперечисленных не бесплатны и не стоят сотни тысяч. Так что мимо.
VD>Ну, ты цены то обшие назови. Форт вроде стоит, около $2000. Это конечно не сотни тысяч, но примерно на эти деньги можно купить MSDN Universal и плучить весь софт MS, в том числе ОС, серверы [включая SQL Server] и VS.Net верхней редакции.
Ага, 120-тидневные. А знаешь сколько студия стоит?
VD>>> А сколько стоит Together? www.togethersoft.com VD>>> И что такое IDEA? Мог бы и по подробнее рассказать. www.intellij.com
AVK>>Это уже не документация а средства ее просмотра. И если ты не знаешь таковых в java это не значит что их нет в природе.
VD>Будь добор, отрой глаза. Что же за чудо средства зарыты от простых смертных так глубоко и зачем?
Они не зарыты.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали:
AVK>>Вот так и знал что не стоит слово сериализация употреблять. Не сериализация это а персистентность. К примеру сериализуй ты как тебе хочется скажем 1000000 объектов. А потом выбери из них полсотни у которых свойство Prop1 like %XXX%. Теперь понимаешь что никаких форматтеры не помогут, нужен специальный фреймворк. VD>А ты разницу в производительности прямой работы с SQL и бинднутых бобов сравнивал?
Аксиома — разработка софта стоит дороже железок. Далее спорить бесполезно.
IT>>>Насколько мне известно, там внутри под всем этим хозяйством лежит CORBA. AVK>>Не обязательно. Все основные механизмы вполне работают без CORBA. VD>А ну как поделись. Какая реазация объодится без CORBA-ы?
Resin, JBoss, Orion
VD>А-га. То-то сплош и рядом вопросы по RMI всплывают. VD> AVK>>Ну так из Java тоже можно и до Win32 и даже до COM достучаться, только вот не надо этого делать. VD>Ну, зачем же так? Не на Яве, а на C... ведь про JNI?
Есть к примеру Java2COM bridge.
AVK>>Вот об этом то я и говорю. Да, я надеюсь будет. Но пока то нет! А в java уже. Об этом я и говорю.
VD>Во-во! И разница в том, что если в .Net чего-нить нет, можно взять из WinAPI (причем в два счета, не используя других языков), а если чёго-нить нет в Яве, то можно смело отдыхать
То можно взять через WinAPI
VD> предвкушая трах по обходу проблем. За то переносимость! И фиг с ним, что не одна версия программы никогда не запускалась на чем-нибудь отличном от PC.
И зачем только куча идиетов пишет для своих серверов jvm?
VD>Нда... с такими критериями нужно выбирать Паскаль или С. У них история куда больше... VD>Мяса то у .Net хватает. На рынке програм для клиентских ПК Ява даже рядом не стояла, да и на сервере все очень даже ничего. В области Web-а Ява опять же отдыхает.
Блин, ну что за лексика, отдыхает. Некоторые еще круче говорят — сосет.
Вобщем ты не прав — доказывать не буду. Все кто хочет могут убедиться в обратном сами.
VD>Значит Web-решения вещь не серьезная. Вон IT вообще все хочет не Web-сервисах переписать.
Серьезная то она серьезная, но деньги там не те.
AVK>>А LinkedList это по сути Queue или Stack но с интерфейсом IList. VD>А ты что (конкретно) сделать хочешь? Зчем он тебе нужен? И что мешает просто написать это дело самому (так ты хочешь)
Круто! Хорош дотнет если в нем даже коллекции приходится руками переписывать. А нужен он частенько — когда нужен список в который часто добавляют и из которого часто удаляют, а произвольный доступ не нужен, нужен только через итератор. Разницу в производительности между ArrayList и LinkedList я тебе наглядно показал.
AVK>>Хорошо конечно. Просто это доказывает что релиз увы не безглючен. VD>А что есть хоть одна безглючная программа размеров более чем в 100 000 строк кода? Или глюки исчезают через 5 лет существования продукта?
Ну видимо если тебе исходники библиотеки не нужны — то наверное есть.
Мне вот нужны.
Здравствуйте AndrewVK, Вы писали:
AVK>>>А LinkedList это по сути Queue или Stack но с интерфейсом IList. VD>>А ты что (конкретно) сделать хочешь? Зчем он тебе нужен? И что мешает просто написать это дело самому (так ты хочешь) AVK>Круто! Хорош дотнет если в нем даже коллекции приходится руками переписывать. А нужен он частенько — когда нужен список в который часто добавляют и из которого часто удаляют, а произвольный доступ не нужен, нужен только через итератор. Разницу в производительности между ArrayList и LinkedList я тебе наглядно показал.
А чем тебе не нравиться Queue? Он вроде под это и заточен?
Здравствуйте DarkGray, Вы писали:
DG>А чем тебе не нравиться Queue? Он вроде под это и заточен?
Тем что в нем не реализован IList. Особенно мне не хватает Insert и RemoveAt
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте DarkGray, Вы писали:
DG>>А чем тебе не нравиться Queue? Он вроде под это и заточен? AVK>Тем что в нем не реализован IList. Особенно мне не хватает Insert и RemoveAt
Да, проблема...
Но это скорее проблема всех сред-языков, типа Java, Delphi, VB, C#.
В них нельзя создать свой эффективный контейнер, в отличии, от C++.
Но в .Net можно попытаться решить эту проблему через наследование контейнера из C++.
В остальных средах даже это к сожалению не возможно.
Здравствуйте DarkGray, Вы писали:
DG>>>А чем тебе не нравиться Queue? Он вроде под это и заточен? AVK>>Тем что в нем не реализован IList. Особенно мне не хватает Insert и RemoveAt
DG>Да, проблема...
DG>Но это скорее проблема всех сред-языков, типа Java, Delphi, VB, C#.
Это проблема библиотеки дотнета. DG>В них нельзя создать свой эффективный контейнер, в отличии, от C++. DG>Но в .Net можно попытаться решить эту проблему через наследование контейнера из C++. DG>В остальных средах даже это к сожалению не возможно.
Контейнер тут не при чем. Достаточно было сделать LinkedList а уж от него унаследовать Queue и Stack. Причем судя по ildasm практически один и тот же связаный список реализован в Queue и Stack раздельно. Причины этого мне не понятны.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте iZEN, Вы писали: AVK>~20 M. SDK здесь — Microsoft .NET Framework SDK — ~130 M.
ZEN>>Ну и размерчики! :) ZEN>>Sun JRE 1.4 SE — ~12Мб в дистрибутиве, нужно для запуска Java2-приложений; AVK>Справедливости ради — во первых .Net Redist все таки не 20 а 18Мб. Во вторых в Redist включены компиляторы, в JRE нет. Таким образом для asp.net redist достаточно, а вот для jsp серверов нужно ставить весь jdk.
Для jsp-серверов не нужно ставить JDK, если не надо их дорабатывать (как правило, jsp-сервера не надо дорабатывать, они и так пригодны для использования). JDK предназначено ТОЛЬКО ДЛЯ РАЗРАБОТЧИКОВ, дополнительные серверные расширения в виде JSP, EJB, WebServices, JMS, JavaMail, JTA/JTS и т.д. загруются отдельно и ДОПОЛНЯЮТ JRE J2SE на сервере, превращая её в J2EE, вернее, в контейнер серверных Java-приложений (Законченные сервера J2EE -- такие как Borland AppServer/Enterprise Server, IBM WebSphere, iPlanet Application Server, BEA WebLogic, etc, как правило, поставляются совместно с J2EE-расширением, уже готовыми к запуску).
ZEN>>Sun JDK с JRE 1.4 SE и исходниками(10Мб в ZIP) — всего ~36Мб в дистрибутиве, нужно для разработки и запуска Java2-приложений; AVK>Без документации надо заметить
ZEN>>Sun JavaDoc к JDK 1.4 SE — 30Мб в ZIP-архиве(распаковывать не надо), нужно при разработке Java2-приложений. AVK>Ты забыл еще JLS. В JavaDoc его нет.
Что такое JLS? :???: Я уже три года занимаюсь Java, но такой аббревиатуры не встречал. :)
Всё, что я перечислил ранее, для меня достаточно.
Здравствуйте AndrewVK, Вы писали:
AVK>Ты забыл еще JLS. В JavaDoc его нет.
К сведению: JavaDoc -- это спецификация документирования Java-кода в HTML-формате, доступном для просмотра в любом Internet-браузере. Разработчики Java2-решений могут предоставлять документацию на свои инструментальные API в формате "JavaDoc".
Здравствуйте VladD2, Вы писали:
IT>>>Насколько мне известно, там внутри под всем этим хозяйством лежит CORBA. AVK>>Не обязательно. Все основные механизмы вполне работают без CORBA.
VD>А ну как поделись. Какая реазация объодится без CORBA-ы?
AVK>>Честно говоря долго здесь объяснять. Если интересно — посмотри на java.sun.com. EJB это не просто библиотека, это технология и методология создания и эксплуатации корпоративных систем.
VD>А-га. То-то сплош и рядом вопросы по RMI всплывают. :)
Например, RMI, входящий в J2SE(которая работает на клиенте), использует протокол JRMP поверх TCP/IP;
RMI, входящий в J2EE(которая работает на сервере), может использовать кроме протокола JRMP ещё и CORBA-протокол IIOP поверх TCP/IP для "прозрачного" взаимодействия с CORBA-клиентами и серверами.
Здравствуйте iZEN, Вы писали:
ZEN>Для jsp-серверов не нужно ставить JDK, если не надо их дорабатывать (как правило, jsp-сервера не надо дорабатывать, они и так пригодны для использования).
Видишь ли в чем дело — jsp странички лежат в war в текстовом виде, как они есть, поскольку механизмы преобразования jsp в код в стандарте не определены и в каждом сервере свои. Поэтому даже если ты ничего в страничках не менял — хотя бы первый раз их придется скомпилировать и на продакшн сервере. А теперь расскажи — как ты собрался компилировать при наличии одной только JRE? ZEN> JDK предназначено ТОЛЬКО ДЛЯ РАЗРАБОТЧИКОВ,
Как видишь — не только ZEN> дополнительные серверные расширения в виде JSP, EJB, WebServices, JMS, JavaMail, JTA/JTS и т.д. загруются отдельно и ДОПОЛНЯЮТ JRE J2SE на сервере, превращая её в J2EE,
Во первых — ничего никуда не превращается, J2EE это дополнительный пакет, ставящийся в дополнение к SE, причем не к JRE а к JDK. J2EE JRE вобще в природе не существует, только J2EE SDK. Я тебе больше скажу — большинство EJB серверов тоже требуют для работы JDK — им стабы тоже на ходу генерить надо.
ZEN> вернее, в контейнер серверных Java-приложений (Законченные сервера J2EE -- такие как Borland AppServer/Enterprise Server, IBM WebSphere, iPlanet Application Server, BEA WebLogic, etc, как правило, поставляются совместно с J2EE-расширением, уже готовыми к запуску).
Однако без JDK они не работают в принципе.
ZEN>>>Sun JavaDoc к JDK 1.4 SE — 30Мб в ZIP-архиве(распаковывать не надо), нужно при разработке Java2-приложений. AVK>>Ты забыл еще JLS. В JavaDoc его нет.
ZEN>Что такое JLS? Я уже три года занимаюсь Java, но такой аббревиатуры не встречал.
Странно ты как то занимался, с этого обычно начинают. JLS — Java Language Specification
Здравствуйте iZEN, Вы писали:
ZEN>Здравствуйте AndrewVK, Вы писали:
AVK>>Ты забыл еще JLS. В JavaDoc его нет.
ZEN>К сведению: JavaDoc -- это спецификация документирования Java-кода в HTML-формате, доступном для просмотра в любом Internet-браузере. Разработчики Java2-решений могут предоставлять документацию на свои инструментальные API в формате "JavaDoc".
Ну и? Что сказать хотел? Что такое JavaDoc я знаю.
Здравствуйте IT, Вы писали:
IT>Здравствуйте AndrewVK, Вы писали:
IT>>>Давай ты мне расшифруешь эти аббревиатуры и скажешь для чего они нужны, а я постараюсь привести примеры аналогов.
AVK>>Нет проблем. Начнем с более простой. JDO — Java Data Objects. Технология сериализации объектов в различные источники (обычно DB и XML) с возможностью выборочной десериализации. А главное — умеющая десериализовывать по набору условий при помощи языка похожего на SQL но для работы с объектами. Короче — механизм персистентности. AVK>>Ничего похожего у MS пока нет.
IT>Я тоже иногда кидаюсь голословными заявлениями, потом приходится жалеть. В .NET не просто сериализация, а сериализация на сериализации и сериализацией погоняет. Возможно она реализована не так как в Java, но это не значит что хуже. Всё сериализуется по-умолчанию, если есть желание, то можно этим довольно гибко управлять простыми атрибутами без всяких языков. Но если и этого не достаточно, то перекрывай ISerializable и вытворяй что хочешь. Для сохранения/восстановления объектов предназначены форматеры, сейчас их есть для binary и xml. Никто тебе не мешает нарисовать свой и сохранять как тебе хочется.
AVK>>EJB — Enterprise Java Beans, ключевая технология J2EE. Это сервер приложений. Главное отличие от других подобных технологий — более глубокое взаимодейстиве с объектами. К примеру EJB сервер сам загружает, выгружает и инициализирует бизнес-объекты, активно их кеширует, обеспечивает безопасность, механизм транзакций, в т.ч. и распределенных, пул соединений с SQL сервером, балансировку нагрузки и работу в кластерах.
IT>Насколько мне известно, там внутри под всем этим хозяйством лежит CORBA. Или я ошибаюсь? MS рекомендует для этих целей использовать COM+. С одной стороны он тесно интегрирован с ОС, с другой с .NET. Все перечисленные тобой возможности в нём имеются.
AVK>>Существуе механизм полностью автоматической загрузки\выгрузки объектов, когда контейнер сам создает запросы к БД, выполняет их и результат предоставляет разработчику. Ну и наконец это полноценный Object-Relational преобразователь реализующий отношения 1-1, 1-n, n-1, n-n. Самое похожее на это у MS — COM+ и serviced components, но они не умеют многое из того что могут EJB-сервера.
IT>Этого я не припомню, но пока и не соображу зачем это надо.
IT>>>Только сразу предупреждаю, как я уже говорил, .NET дополняет Win32 и возможно некоторые вещи эффективнее реализовывать на последней.
AVK>>Э нет, так не пойдет. Идеология .Net такова что следует по возможности максимально избегать legacy интерфейсов, особенно Win32 API. И не только для переносимости. При этом вся система anti dll-hell идет нафик. Да и за что тогда боролись? Чтобы все писать на Win32? А нафига тогда дотнет?
IT>Ещё раз повторюсь. .NET не отменяет Windows, более того, это было бы просто самоубийство. Скороее всего, постепенно большинство сервисов, предоставляемых Windows будут заменяться на собственные. Но это будет происходить эволюционно. И это правильно. Переход должен быть постепенным и должна быть обеспечена интеграция с существующими технологиями. В частности для написания объектов COM+ в .NET совсем не надо прибегать к использованию WinAPI, всё делается интерфейсами и атрибутами.
AVK>>>>При чем здесь все возможности. Вот скажи для примера — если мне LinkedList нужен — мне его ручками писать или ArrayList пользовать? Ни Queue ни Stack мне не подходят ввиду необходимости удалять элементы из середины.
IT>>>А чем ArrayList не подходит?
AVK>>Сделаем проще. Вот исходник
IT>[skip]
IT>Тогда рассказывай что такое LinkedList, если ни список ни коллекция тебе не подходит.
IT>>> А про beta2 это не честно. Это ж бэта, она глючить должна по определению
AVK>>Думаешь есть существенная разница между бетами и релизами? То-то MS не успел выпустить релиз дотнета уже сервис пак к нему лежит.
IT>То что я в бессильной злобе пытался решить на бете в релизе было пофиксено. А быстрые сервис-паки это неплохо, работают ребята
Да как-то криво .NET работает с COM+:
1. распределенные транзакции не поддерживаются
2. JIT активация не работает
3. pooling не работает
4. пул подсоениения к SQL серверу через SQLConnection не работает
5. с настройкой безопсности какие-то траблы
Правда 2, 3 реализовано в CLR
И вообще:
The Microsoft speaker shocked me by saying
that COM+ services in .NET are just for backward compatibility and we
should avoid using them. For example use ADO.NET manual transactions
instead of COM+ automatic transactions and System.Messaging for
asynchronous communication. He also said that the COM+ support will either
be **removed** or there will be **no enhancements** to it in future
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте iZEN, Вы писали:
ZEN>>Для jsp-серверов не нужно ставить JDK, если не надо их дорабатывать (как правило, jsp-сервера не надо дорабатывать, они и так пригодны для использования). AVK>Видишь ли в чем дело — jsp странички лежат в war в текстовом виде, как они есть, поскольку механизмы преобразования jsp в код в стандарте не определены и в каждом сервере свои. Поэтому даже если ты ничего в страничках не менял — хотя бы первый раз их придется скомпилировать и на продакшн сервере. А теперь расскажи — как ты собрался компилировать при наличии одной только JRE? ZEN>> JDK предназначено ТОЛЬКО ДЛЯ РАЗРАБОТЧИКОВ, AVK>Как видишь — не только
Хорошо. Я не так выразился. Я имел ввиду исполняемую среду сервера(неудачно назвав её "серверной JRE"), дополняемую расширением J2EE.
JSP-сранички не компилируются вручную -- их подхватывает сервер из архива, компилит налету и кладёт в кэш. Другой случай с сервлетами (Servlets) -- они получаются в откомпилированном виде (не важно кем -- сервером после компиляции из JSP, или разработчиком, и в принципе не важно, куда кладутся -- сразу в кэш памяти или в каталог на диске).
ZEN>> дополнительные серверные расширения в виде JSP, EJB, WebServices, JMS, JavaMail, JTA/JTS и т.д. загруются отдельно и ДОПОЛНЯЮТ JRE J2SE на сервере, превращая её в J2EE, AVK>Во первых — ничего никуда не превращается, J2EE это дополнительный пакет, ставящийся в дополнение к SE, причем не к JRE а к JDK. J2EE JRE вобще в природе не существует, только J2EE SDK. Я тебе больше скажу — большинство EJB серверов тоже требуют для работы JDK — им стабы тоже на ходу генерить надо.
Уламали вконец. :)
Ещё раз повторю, я имел ввиду среду времени выполнения сервера (серверную JRE), я знаю, что JDK включает в себя, кроме JRE, ещё инструментарий разработчика. Прошу так строго не судить меня за не совсем точное использование терминов. За поправку спасибо.
Пока не могу ничего сказать о нюансах создания и использования EJB -- я только учусь. Вы в этом вопросе, наверно, больше меня разбираетесь. С EJB я не работал, но постепенно иду к этому, только-только начал изучать.
ZEN>> вернее, в контейнер серверных Java-приложений (Законченные сервера J2EE -- такие как Borland AppServer/Enterprise Server, IBM WebSphere, iPlanet Application Server, BEA WebLogic, etc, как правило, поставляются совместно с J2EE-расширением, уже готовыми к запуску). AVK>Однако без JDK они не работают в принципе.
Да, не работают, но разве JDK не поставляется вместе с ними? (Риторический вопрос).
Они не спосбны к развёртыванию обычными пользователями, которые уже имеют пакет интернет-магазина с JSP, допустим?
ZEN>>>>Sun JavaDoc к JDK 1.4 SE — 30Мб в ZIP-архиве(распаковывать не надо), нужно при разработке Java2-приложений. AVK>>>Ты забыл еще JLS. В JavaDoc его нет.
ZEN>>Что такое JLS? :???: Я уже три года занимаюсь Java, но такой аббревиатуры не встречал. :) AVK>Странно ты как то занимался, с этого обычно начинают. JLS — Java Language Specification
Что, так трудно изучить Java без JLS?
Хотя это не относится к "настоящим адептам" Java -- типа: "изучить-то нетрудно, но кто поверит тебе, если ты не пользовался JLS, что твоё программистское произведение создано "в соответствии с генеральной линией партии"? :) Так что ли?
И что, JLS так велика по объёму, что тяжело скачать? :)
Действительно, документация по Java2 API, ещё есть в PDF-формате(т.н. руководства программиста по использованию тех или иных API), но это только дополняет основной справочник API, находящийся в формате JavaDoc. JavaDoc -- это достаточно краткое описание того, что хотел сказать программист о том или ином классе, интерфейсе, методе и т.д.(Тоже самое, что и развёрнутые комментарии в тексте программы о функциональном назначении какой-либо сущности). Вы наверняка знаете, как получают javadoc из программы -- просто пропускают файл с текстом программы через утилиту javadoc.exe.
Ребята, Вам не надоело? Первый Ваш флейм который начался в теме по распространению приложений на .Net я с удовольствием почитал, подчерпнул так сказать для себя много нового. Тут же Вы, извините, говорите попусту. Вам нужны исходники, ну так не все сразу, вот скоро увидите: http://www.compulenta.ru/news/2002/3/28/27481/
Конечно многово в .Net ещё нет, ну так он и младше чем Java. Я не понимаю этот спор. То что это новое и сделано весьма неплохо — это Вы отрицать не сможете. Мелкомягкие не на пустом месте это делали и учли многие нароботки того же Sun.
Вообще, в любом случае нам же от этого лучше — они там конкурируют, что-то новое, интересное придумывают.
Так что может не нужно больше флеймить? Предыдуший разговор, который я упоминал, был ЗНАЧИТЕЛЬНО интересней.
----
With best regards, Kot Burov aka W@ndERR ®
UIN: 108043419
--------
W®>Конечно многово в .Net ещё нет, ну так он и младше чем Java.
Так я то же самое пытаюсь доказать. Для веб приложений дотнет уже вполне созрел, для корпоративных еще пока не дотягивает.
W®>Так что может не нужно больше флеймить? Предыдуший разговор, который я упоминал, был ЗНАЧИТЕЛЬНО интересней.
Ну так предложи тему поинтереснее.
Здравствуйте AndrewVK, Вы писали:
VD>>В общем о чем разговор я уже не понимаю, но после столь смелых заявлений и таких убедительных аргументов дальнейший разговор бесполезен. Ты хоть знаешь сколько стоит 8 однопроцессорных машин (без наворотов) и один 8-ми процессорный сервер? AVK>Знаю. А ты?
И что ты знаешь? Я тебе уже давал ссылку на www.tpc.org. Ты тот разговор благополучно обошел (как и все темы которые тебе не нравятся). Так вот сходит туда и объясни почему кластерные системы созданные на писевых камнях быстрее чем твои хваленые суперкомпьютеры. За одно посмотри, ОС, менеджер транзакций и СУБД у победителя в TPC-C. Потом зайди на http://www.tpc.org/tpcc/results/tpcc_price_perf_results.asp (сортировка по цена/производительность) и попробуй найти там Сан. Потом поищи там свои любимые EJB да и вообще Яву под любым соусом.
AVK>Учти — однопроцессорные машины — это тоже сервера + дорогой коммутатор.
И тут ты тоже ошибаешься. Это для отдельного сервера нужно брать особую машину, а для сервера в кластере достаточно взять самую обычную писучину за $400. Сам принцип кластеров позволяет использовать дешевые машины. Если одна выйдет из строя, то ее заменят (на время) другие. И даже если выйдут из строя все, кроме одной, машины кластер будет жить (хотя и не будет таким производительным).
VD>> И что нужно предпринять чтобы это сервер не сдох от того что сгорел кондер в блоке питания? AVK>Вот еслки палки. Ты поинтересуйся для интереса чем сервер отличается от обычной машины.
Ну, куда нам лапотникам? :-\
AVK>Отнюдь не только быстродействием. В частности в 8-мипроцессорных серверах 2 или 4 блока питания. Еще один вопрос — что вероятнее, сгорание одного дорогого блока питания — или одного из 8 подешевле?
Ну, и подумай выход из строя одной микросхемы чипсета приведет к остановке сервера, а гибель одной из машин кластера только снизить (на время) производительность. Смерть процессора в одной из кластерных машин ничего страшного не влечет, в прочем как и любой другой железки. К тому же кластер тоже можно делать на многопроцессорных машинах с высокой степенью отказоустойчивости и это даст возможность увеличить устойчивость системы в сони раз (по сравнению с одним сервером, пусть даже самым дорогим).
VD>> И как SMP-системы масштабируются после 8-ми процессоров? AVK>Лучше чем кластеры.
Ты чем ерунду говорить сходил бы по ссылкочке и посмотрел результаты. ;)
AVK>а главное проще.
Ага! Куда проще выкинуть суперкомпьютер и купить новый, чем добавить сервер в кластер. Да и думать мозгами дорого! Дешевле купить супер-пупер Сан.
VD>> Короче, при таких смелых заявлениях нужно хоть как то обосновывать свое мнение. AVK>Честно говоря разговор об этом мне не очень интересен. Я для себя этот вопрос в свое время хорошо изучил. Если не веришь — ради бога, из порток выпрыгивать я не стану.
Ну, а чего тогда ты пытаешься здесь доказать?
Я вообще не понимаю как можно судить о качестве, возможностях, а главное востребованности системы не найдя в ней какой-нибудь финтифлюшки.
Может у меня действительно мозги не так работают. Ну, сказывается время проведенное за C++... Но я ни как не могу понять, ну, даже если нет нужной тебе реализации связанного списка, ну, так сядь и напиши. Алгоритмы то там плевые. Или берешь массив и делаешь к нему нужные методы (может выйти эффективнее) или работать на ссылках. Думаю пару часов и у тебя все заработало бы как надо
PS
В конце концов если тебя .Net не устраивает, то что ты его не бросишь и не продолжишь работать на Яве. Она на сегодня неплохо развилась... грабли все ее ты уже знаешь... они тебя не смущают... так бросай других агитировать. .Net это для тех кто программировал COM на C++ или VB, и для тех кому больше важна гибкость, а не переносимость.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте AndrewVK, Вы писали:
AVK>ОК. Давай, расскажи хотя бы про 1 пункт. Как мне на .Net получить LinkedList?
class Node
{
publib Noden pNext = null;
SomeDataType SomeData;
};
...
Node Root = new Node();
Node pNewNode = Root;
for(int i = 0; i < 100; i++)
{
Node pTmp = new Node();
pNewNode.pNext = pTmp;
pNewNode = pTmp;
}
Если очень хочется, можешь написать универсальную реализацию с интерфейсом IList.
Интересно все же что за задача стоит. Может все можно сделать проще и быстрее?
AVK>Но, в отличие от того же веб софта КИС очень активно видоизменяется в процессе жизнедеятельности. А планировать на 5 лет вперед просто не реально.
Т.е. форумы не изменяются. Ты это IT раскажи вот он обрадуется. :)
AVK>Крупные фирмы с нуля создаются очень редко,
Я даже больше скажу они и не снуля очень редко создаются. Есть такой закон природы... большых всегда меньше. :)
AVK> как правило на этих фирмах уже накоплен приличный багаж. Ты предлагаешь все это похерить и переписать все заново.
Если фирма растет, такие изменения происходят постоянно и система постоянно перепроектируется. В некоторых этпапх, когда руководство тех. отдела понимает, что количество примочек слишком велико, принимается решение и перепроектируется система. В ином случае фирма или перестает расти, или плюет на систему автоматизации, или дохнет.
AVK> Извини, но ни один нормальный руководитель тебе этого не позволит.
Извени, я сам руководитель и много с таковыми общался... и давально чато видел принятие решения о замене/перепроектировании системы автоматизации.
AVK>И дело даже не во вложеных деньгах. Дело в том что смена информационной системы для крупного предприятия это очень тяжелое испытание. И это чревато потерей денег куда больших нежели стоимость самой разработки.
Когда выбор стоит между тяжолым решением и прозибанием, зачастую выбирается трудная жизнь, а не легкая смерть. :)
AVK> Перепроектировать систему имеет смысл только в том случае когда иными способами улучшения ее работы уже не добиться.
Обычно к этому моменту перепроектировать систему уже поздно. :))
AVK> И поверь — любой сановский или ибмовский сервер обойдется на порядок дешевле нежели перепроектирование.
Чушь это полная. Как я уже сказал если нужно перепроектирование, заменой железа не обойтить. Какой смысл гонять ненужный софт на суперкомпьютерах?
AVK>Зайди в любую более менее серьезную фирму подобного профиля и задай вопрос — увидишь что тебе ответят.
Блин ну какое самомнение. Ты серьезно считаешь, что один видел все на свете?
AVK>Да и вобще, к корпоративному софту предъявляются совершенно иные требования нежели к десктопному, это другая вселенная со своими законами.
Ну, ну. Если не получается сделать дело быстро и качественно, то нужно объявить его искуством и говорть остальным, что они в нем (в искустве) ничего не понимают. ;)
AVK> И именно на этот софт нацелены все те технологии которые вызывают здесь ожесточенные споры в их нужности.
Да ну? А вто я, IT и MS думаем по другому. MS конечно не помешает замена VB, но он MS был бы не MS если бы в их планы не входил захват всех рынков на которых можно зарабатывать деньги. Не удевлюсь если через пру лет MS начнет обсуждать вопросы разработки драйверов на C#.
PS
Чтобы понять разницу между Явой И Нэтом нужно написать сотню строк на миксе из MC++ и C#. Я ничего не имею против параллельного развития Явы, но думаю Windows-программистам (коих большинство) ближе будет Нэт. И им будет куда проще преодалеть его подводные камни чем перейти в лагерь сана.
Кстати, а какую скорость показывает твой тест если его запустить на НотСпоте?
AVK>Ладно, все, на эту тему я больше спорить не буду, ибо не вижу смысла.
AVK>>>Я тебе по опыту знаешь что скажу — заводик может так и остаться небольшим, а обороты возрастут на порядок. VD>>Тогда этому сухареклёпу нужно думать как и где нанять нормальных менеджеров, а не вбухивать деньги в софт. AVK>Ему нужно думать и о том и о том.
VD>>А что мне верить... не верить я как бы этим все занимался и знаю, что любая программа — это всего лишь инструмент. К ней голова и руки нужны. В нашей стране большая чатсть предприятий работают на 1C, Бэстах и разных там Галактиках... и ты не поверишь?! Работают и прибыль получают. AVK>У меня здесь 1С. Так что поверю.
VD>>Хороший менеджер и в Ёкселе все что нжуно (по зарез) посчитат. AVK>В экселе? Эдак несколько сотен заказов в день? Все, я тебя понял. Мы вобще то о разных масштабах говорим. Фактик для примера — на одном предприятии не очень большого размера список тех. операций одного цеха — толмуд больше тысячи листов. Задача — в разумное время посчитать в экселе фактическую себестоимость продукции.
VD>> А похому и супер-пупер КИС не поможет. На западе разные SAP тоже без явы обходятся и все заявляют об ориентации на MS SQL (который сам знаешь на какой платформе работает) заявляют. AVK>А не к ночи буде упомянутый SAP зачем то свою SAP DB ваяет
VD>> Короче, я до сих пор не пйму, ну если другим переносимость не нужна, то чё ее так навязывать. AVK>А ее никто и не навязывает.
VD>> Нужна тебе переносимость... ну, дык используй Яву, но не объясняй другим, что это главный критерий (в мире где PS 90%). AVK>Э нет, ты пожалуйста за меня не говори. Это ты всем доказывал что переносимость нафик никому не нужна. Я тебе и объясняю что иногда она таки нужна. Найди цитату где я говорил что это главный критерий.
AVK>>>Все три вышеперечисленных не бесплатны и не стоят сотни тысяч. Так что мимо.
VD>>Ну, ты цены то обшие назови. Форт вроде стоит, около $2000. Это конечно не сотни тысяч, но примерно на эти деньги можно купить MSDN Universal и плучить весь софт MS, в том числе ОС, серверы [включая SQL Server] и VS.Net верхней редакции. AVK>Ага, 120-тидневные. А знаешь сколько студия стоит?
VD>>>> А сколько стоит Together? AVK>www.togethersoft.com VD>>>> И что такое IDEA? Мог бы и по подробнее рассказать. AVK>www.intellij.com
AVK>>>Это уже не документация а средства ее просмотра. И если ты не знаешь таковых в java это не значит что их нет в природе.
VD>>Будь добор, отрой глаза. Что же за чудо средства зарыты от простых смертных так глубоко и зачем? AVK>Они не зарыты.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Аксиома — разработка софта стоит дороже железок. Далее спорить бесполезно.
Когда как. Софт все равно писать и можно его написать так, что он ни на каких супер-железках быстро работать не будет. Супер машины стоят миллионы долларов. Думаю, буджеты многих российских контро имеющих своих разработчиков (и разработки) куда скромнее. К тому же ты сам себе противоричишь. Если всегда выгоднее купить более крутую железку, то выбрось свою Яву напиши свою програму абы как на нете и купи кластер за 10 килобаксов (тот что делает в два раза самый лучший Сан). Так что твои разсуждения о том, что LinkedList тормозит, по меньшей мере странны. :)
IT>>>>Насколько мне известно, там внутри под всем этим хозяйством лежит CORBA. AVK>>>Не обязательно. Все основные механизмы вполне работают без CORBA. VD>>А ну как поделись. Какая реазация объодится без CORBA-ы? AVK>Resin, JBoss, Orion
Я этих не видел. Но по статьям того же Цимбала основные сетевые решения для Явы серьезнвми конторами пишится на базе CORBA-ы. И по-моему это правильно.
VD>>А-га. То-то сплош и рядом вопросы по RMI всплывают. :) VD>> AVK>>>Ну так из Java тоже можно и до Win32 и даже до COM достучаться, только вот не надо этого делать. VD>>Ну, зачем же так? Не на Яве, а на C... ведь про JNI? AVK>Есть к примеру Java2COM bridge.
Может сравним производительность и простоту работы с COM-ом через этот бридж и в Нете?
К тому же ты снова уветрываешся от ответа. COM — это не Win32. Ты сравни сложность работы с Win32. Не я понимаю, что лично тебе это не нужно, но вот многим другим (мне например) не хочется отказываться от одобств даваемых Виндовс в пользу эфимерной (для меня) переносимости.
VD>>Во-во! И разница в том, что если в .Net чего-нить нет, можно взять из WinAPI (причем в два счета, не используя других языков), а если чёго-нить нет в Яве, то можно смело отдыхать AVK>То можно взять через WinAPI
Какой ценой? Да и далеко не все можно взять. А без JNI и C вообще мало чего получится.
VD>> предвкушая трах по обходу проблем. За то переносимость! И фиг с ним, что не одна версия программы никогда не запускалась на чем-нибудь отличном от PC. AVK>И зачем только куча идиетов пишет для своих серверов jvm?
А шоб денег по легкому срубить.
VD>>Нда... с такими критериями нужно выбирать Паскаль или С. У них история куда больше... VD>>Мяса то у .Net хватает. На рынке програм для клиентских ПК Ява даже рядом не стояла, да и на сервере все очень даже ничего. В области Web-а Ява опять же отдыхает. AVK>Блин, ну что за лексика, отдыхает. Некоторые еще круче говорят — сосет.
Мне до некоторых нет дела. А лексика обычная разговорная. Вот если статью сяду писать, то выберу слова по пристойнее и за ошипками начну следить. :)
AVK>Вобщем ты не прав — доказывать не буду. Все кто хочет могут убедиться в обратном сами.
Ты бы хоть сказал в чем не прав? Ну, а то что даказательст нет — это понятно. ;)
VD>>Значит Web-решения вещь не серьезная. :) Вон IT вообще все хочет не Web-сервисах переписать. :) AVK>Серьезная то она серьезная, но деньги там не те.
Тото я смотрю MS дла Сан занимаются этими "безденежными" технологиями, а крутой 1C окучивает самый богатый рынок! :)))
AVK>>>А LinkedList это по сути Queue или Stack но с интерфейсом IList. VD>>А ты что (конкретно) сделать хочешь? Зчем он тебе нужен? И что мешает просто написать это дело самому (так ты хочешь) AVK>Круто! ...
Нда на вопросы ты отвечать не хочешь...
AVK>Хорош дотнет если в нем даже коллекции приходится руками переписывать.
Я же говорю... менталитет у нас с тобой разный. Я привык писать на языке, а колекции воспринимаю как библитечную реализацию некоторого алгоритма. По этому ситуацию когда если чего нет, но можно дописать воспринимаю лучше, чем когда почти все есть, но то чего нет и желать не надо из-за нарушения стройности или проблем с переносимостью.
AVK>А нужен он частенько — когда нужен список в который часто добавляют и из которого часто удаляют, а произвольный доступ не нужен, нужен только через итератор. Разницу в производительности между ArrayList и LinkedList я тебе наглядно показал.
Ну, ты не сказал зачем он тебе нужне и не показал как это же будет выглядеть на Яве (скорость имеется в виду). В наших проектах на C++ очень часто необходимо работать со списками, но вот связанные списки там вообще не испльзуются (в чистом виде). Все сделано на универсальных массивах. Практика показала, что грамотный массив работает быстрее чем связанный список элементы которого занимаются через хип.
AVK>>>Хорошо конечно. Просто это доказывает что релиз увы не безглючен. VD>>А что есть хоть одна безглючная программа размеров более чем в 100 000 строк кода? Или глюки исчезают через 5 лет существования продукта? AVK>Ну видимо если тебе исходники библиотеки не нужны — то наверное есть. :) AVK>Мне вот нужны.
Да я собственно не против исходников, но намного больше мне нужна хорошая объектная модель, быстрый код, хорошая поддержка, совместимость с моими старыми ранаботками, и т.п. А колекции если мне от них будет нужна максимальная скорость я все равно перепишу сам. Мои реализации все равно будут выстрее, чем то что засунуто в Нэт или Яву. Именно по этому я ечень хочу, чтобы в Нэт и Яву добавили Шаблоны как в C++. Пока же я могу писать шаблоны на MC++, делать на их основе классы для конкретных типов .Нэт и испльзовать их в Шарпе и Васике, а на Яве я как всегда приплыл. И пока что ничего не поделаешь. :( Мои ActiveX-ы никак не засунуть в Яву, а в Нэт они входят как будто для него были написаны. Переносимость же у С (обычного не ++) выше. Так что же на нем писать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Контейнер тут не при чем. Достаточно было сделать LinkedList а уж от него унаследовать Queue и Stack. Причем судя по ildasm практически один и тот же связаный список реализован в Queue и Stack раздельно. Причины этого мне не понятны.
Как манимум Stack нмного эфективнее создавать на базе обычного массива.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Так я то же самое пытаюсь доказать. Для веб приложений дотнет уже вполне созрел, для корпоративных еще пока не дотягивает.
Ага Линкедлиста нет и тачках за 100 миллионов баксов не запускается.
W®>>Так что может не нужно больше флеймить? Предыдуший разговор, который я упоминал, был ЗНАЧИТЕЛЬНО интересней. AVK>Ну так предложи тему поинтереснее.
Ну, например попробуй сравнить стэйтлес технику предлагаемую MS и стытфул-EJB и им подобную. Это будет по интереснее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Я тебя понял. Дело в том что java помимо всего прочего представляет собой еще и методологию программирования, заметно отличную от применяемой в том же С/С++. И если пытаться программировать вразрез с этой методологией — как раз и будет появляться подобное ощущение. Либо ты ее принимаешь либо нет. C# в этом плане чуть менее академичен, но и он много ближе к java нежели к С++. Т.е. на C# таки можно программировать в стиле С++, но при этом все его преимущества теряются.
То что ты называешь "стилем" является не стилем, а просто навязываемой тактикой. C++ тем и хорош, что на нем можно испльзовать любой стиль программирования и реализовывать, то что нужно программисту теми методами которые ему нравятся. Сама Ява (как язык) имеет все го лишь ряд досадных, но не смертельных ограничений, основные ограничения делаются реализацией Явы.
VD>> Думаю, .Net замечательное средство для подстегивания Сана... может тепрь они начнут устранять дурь мешающую многим программистам. AVK>Ну не такая уж там и дурь. Есть две крайности — крайне правильный, чисто объектный и очень строгий язык и язык, не накладывающий практически никаких ограничений. Истина как всегда по середине.
"Крайне правильный" — это даже забавно. Я вот только не понимаю почему из-за этой крайней правильности нужно эмулировать [out]- и [in, out]-параметры через массивы. Оставили бы хотья бы передачу по ссылке...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Мне этот бессмысленный спор надоел, поэтому ничего на тему серверов я тебе отвечать не буду. Да и неинтересно это уже здесь никому.
VD>Ну, а чего тогда ты пытаешься здесь доказать?
Что многоплатформенность — не полностью бесполезная вещь. Больше ничего.
VD>Я вообще не понимаю как можно судить о качестве, возможностях, а главное востребованности системы не найдя в ней какой-нибудь финтифлюшки.
Я по моему не говорил что .Net неприменим из-за отсутствия связанного списка. Просто я тебе пример привел сыроватости библиотеки дотнета.
VD>Может у меня действительно мозги не так работают. Ну, сказывается время проведенное за C++...
Я тоже на C++ писал, особенно под Win32 (когда Борланд на Паскаль забил а Дельфи еще не вышла) VD> Но я ни как не могу понять, ну, даже если нет нужной тебе реализации связанного списка, ну, так сядь и напиши.
Я напишу. Но ведь это время! VD> Алгоритмы то там плевые.
Да все я прекрасно понимаю. Мне вот интересно — почему в библиотеке его нет? Недосмотр или специально так сделано?
VD> Или берешь массив и делаешь к нему нужные методы (может выйти эффективнее) или работать на ссылках.
А вот ArrayList как раз и сделан на основе массивов. И произвольный доступ там очень быстрый. А вот добавление-удаление ... Пример я привел.
VD>В конце концов если тебя .Net не устраивает,
Где я такое написал?
VD> то что ты его не бросишь и не продолжишь работать на Яве.
А кто сказал что я на java не работаю?
VD> Она на сегодня неплохо развилась... грабли все ее ты уже знаешь... они тебя не смущают... так бросай других агитировать.
Где я кого нибудь агитировал? Пока здесь агитируешь исключительно ты сам. И почему то упорно всем пытаешся доказать что ,Net это идеал а все остальное ацтой.
VD> .Net это для тех кто программировал COM на C++ или VB, и для тех кому больше важна гибкость, а не переносимость.
Я что то делал и на С++ и на Дельфи, под COM/DCOM, на 1С, на php, на java, на VB вот только не довелось. Мне как — подходит?
Меня убивает твоя позиция — для тебя все черное или белое. Либо рулез немеряный либо сакс полный. Любая технология имеет свои недостатки и свои достоинства, даже php. И надо уметь в каждом конкретном случае выбрать наиболее эффективную.
VD>Если очень хочется, можешь написать универсальную реализацию с интерфейсом IList.
Вот это я и хотел доказать — придется писать ручками с нуля. Больше вопросов нет.
AVK>>Но, в отличие от того же веб софта КИС очень активно видоизменяется в процессе жизнедеятельности. А планировать на 5 лет вперед просто не реально. VD>Т.е. форумы не изменяются. Ты это IT раскажи вот он обрадуется. :)
Весь местный форум проще и меньше чем процедура проведения скажем расходной накладной у меня, а ведь бывает много больше.
AVK>> как правило на этих фирмах уже накоплен приличный багаж. Ты предлагаешь все это похерить и переписать все заново.
VD>Если фирма растет, такие изменения происходят постоянно и система постоянно перепроектируется. В некоторых этпапх, когда руководство тех. отдела понимает, что количество примочек слишком велико, принимается решение и перепроектируется система. В ином случае фирма или перестает расти, или плюет на систему автоматизации, или дохнет.
Извини, но ты не прав. Я уже тебе говорил — даже если руководство согласно отдавать IT почти всю прибыль — частая замена информационных систем приведет к полному краху. Ибо людей не переделать. Если у тебя нет опыта внедрения подобных систем — не стоит на эту тему спорить. Я тебе говорил — там все по другому.
AVK>>И дело даже не во вложеных деньгах. Дело в том что смена информационной системы для крупного предприятия это очень тяжелое испытание. И это чревато потерей денег куда больших нежели стоимость самой разработки. VD>Когда выбор стоит между тяжолым решением и прозибанием, зачастую выбирается трудная жизнь, а не легкая смерть. :)
Ну когда такой выбор стоит — тогда конечно
VD>Блин ну какое самомнение. Ты серьезно считаешь, что один видел все на свете?
Нет. Но когда тебе говорят что черное это белое...
AVK>> И именно на этот софт нацелены все те технологии которые вызывают здесь ожесточенные споры в их нужности.
VD>Да ну? А вто я, IT и MS думаем по другому. MS конечно не помешает замена VB, но он MS был бы не MS если бы в их планы не входил захват всех рынков на которых можно зарабатывать деньги. Не удевлюсь если через пру лет MS начнет обсуждать вопросы разработки драйверов на C#.
Как ты думаешь почему столь уважаемый тобой MS использует CLR, GC, COM+, SOAP? Не иначе для того чтобы драйвера писать.
А за других я бы на твоем месте не стал говорить.
VD>Чтобы понять разницу между Явой И Нэтом нужно написать сотню строк на миксе из MC++ и C#. Я ничего не имею против параллельного развития Явы, но думаю Windows-программистам (коих большинство) ближе будет Нэт. И им будет куда проще преодалеть его подводные камни чем перейти в лагерь сана.
Я вот большую часть времени писал именно под Windows. Однако что то мне не кажется что дотнет безоговорочно лучше всего и везде.
VD>Кстати, а какую скорость показывает твой тест если его запустить на НотСпоте?
Нет проблем. Тест конечно пришлось немножко переписать. Вот код
import java.util.*;
public class Coll {
public static void main(String[] args) {
ArrayList al = new ArrayList();
long st = System.currentTimeMillis();
for(int i = 0; i < 1000000; i++) {
al.add(0,new Object());
if(al.size() > 1000)
al.remove(al.size()-1);
}
System.out.println(System.currentTimeMillis()-st);
LinkedList q = new LinkedList();
st = System.currentTimeMillis();
for(int i = 0; i < 1000000; i++) {
q.addFirst(new Object());
if(q.size() > 1000)
q.removeLast();
}
System.out.println(System.currentTimeMillis()-st);
}
}
Вот результат
2312
141
Результат старого теста на машине на которой я сейчас пишу
1547
156
Что же — массивы в дотнете быстрее :). Но не на столько чтобы заменить связаные списки.
Списки медленнее. Это при том что джавовски LinkedList это и очеред и стек в одном флаконе. Я честно говоря думал что у java результаты будут хуже.
Здравствуйте VladD2, Вы писали:
AVK>>Контейнер тут не при чем. Достаточно было сделать LinkedList а уж от него унаследовать Queue и Stack. Причем судя по ildasm практически один и тот же связаный список реализован в Queue и Stack раздельно. Причины этого мне не понятны.
VD>Как манимум Stack нмного эфективнее создавать на базе обычного массива.
Я на твоем месте попробовал бы и кинул сюда исходнички и результаты. Скорее всего ты прав. Впрочем попробуем:
using System;
using System.Collections;
class ArrayStack {
private ArrayList al = new ArrayList();
public void Push(object obj) {
al.Add(obj);
}
public object Pop() {
object obj = al[al.Count-1];
al.RemoveAt(al.Count-1);
return obj;
}
}
public class Test {
private const int ITER_COUNT = 1000000;
public static void Main() {
ArrayStack ars = new ArrayStack();
int st = Environment.TickCount;
for(int i = 0; i < ITER_COUNT; i++) {
ars.Push(new object());
}
for(int i = 0; i < ITER_COUNT; i++) {
ars.Push(new object());
ars.Pop();
}
for(int i = 0; i < ITER_COUNT; i++) {
ars.Pop();
}
Console.WriteLine(Environment.TickCount-st);
Stack s = new Stack();
st = Environment.TickCount;
for(int i = 0; i < ITER_COUNT; i++) {
s.Push(new object());
}
for(int i = 0; i < ITER_COUNT; i++) {
s.Push(new object());
s.Pop();
}
for(int i = 0; i < ITER_COUNT; i++) {
s.Pop();
}
Console.WriteLine(Environment.TickCount-st);
Queue q = new Queue();
st = Environment.TickCount;
for(int i = 0; i < ITER_COUNT; i++) {
q.Enqueue(new object());
}
for(int i = 0; i < ITER_COUNT; i++) {
q.Enqueue(new object());
q.Dequeue();
}
for(int i = 0; i < ITER_COUNT; i++) {
q.Dequeue();
}
Console.WriteLine(Environment.TickCount-st);
}
}
Смысл теста такой — сначала забиваем стек, затем работаем на его вершине и затем опустошаем. Очередь приведена в качестве стека на основе связаного списка. Понятно что забирает элементы она с другого конца, но для связаного списка конец с которого мы будем выдергивать элементы на скорость влияния не оказывает.
И результат
407
515
688
Что ж
1) Массивы действительно быстрее связаного списка. Впрочем это и понятно. В случае выдергивания элементов с конца нет необходимости передвижки всех элементов, а доступ к массиву быстрее.
2) Похоже что дотнетовкий список реализован на основе массивов
3) А вот почему самопальный стек на основе ArrayList оказался быстрее — для меня загадка.
Здравствуйте AndrewVK, Вы писали:
AVK>Мне этот бессмысленный спор надоел, поэтому ничего на тему серверов я тебе отвечать не буду. Да и неинтересно это уже здесь никому.
Т.е. если чувствуем, что не правы, объявляем спор бессмысленным и уходим от ответа.
VD>>Ну, а чего тогда ты пытаешься здесь доказать? AVK>Что многоплатформенность — не полностью бесполезная вещь. Больше ничего.
А те и говорят. Писюки давно в лидерах производительности... по цене они всех делали всегда... совместимость с большим количеством платформ — это дополнительный геморрой (даже на Яве)... Короче, для многих переносимость не показатель. Вот для меня с IT, например. Кому нужна переносимость пусть используют Яву или C++ с переносимыми библиотеками, а навязывать ее всем, да еще и объявлять это главным достоинством, не стоит.
VD>>Я вообще не понимаю как можно судить о качестве, возможностях, а главное востребованности системы не найдя в ней какой-нибудь финтифлюшки. AVK>Я по моему не говорил что .Net неприменим из-за отсутствия связанного списка. Просто я тебе пример привел сыроватости библиотеки дотнета.
Не... Ты заявлял нечто вроде этого "что же это за платформа если в ней нет даже...".
VD>> Но я ни как не могу понять, ну, даже если нет нужной тебе реализации связанного списка, ну, так сядь и напиши. AVK>Я напишу. Но ведь это время!
Не. Ну бывают действительно ресурсоемкие вещи. Если бы ты о тех же стэйтфул-EJB-ях заговорил, я бы понял... но связанный список!
VD>> Алгоритмы то там плевые. AVK>Да все я прекрасно понимаю. Мне вот интересно — почему в библиотеке его нет? Недосмотр или специально так сделано?
Думаю недосмотр или не посчитали эту фичу важной. Зато там много чего другого есть ценного. И главное есть стройная компонентная модель.
VD>> Или берешь массив и делаешь к нему нужные методы (может выйти эффективнее) или работать на ссылках. AVK>А вот ArrayList как раз и сделан на основе массивов. И произвольный доступ там очень быстрый. А вот добавление-удаление ... Пример я привел.
Ну, это уже зависит от реализации. Будет время можно будет поэкспериментировать.
VD>>В конце концов если тебя .Net не устраивает, AVK>Где я такое написал?
Ну, это как бы из критики вытекает. Чувствуется, что ты на этот продукт обижен, что ли...
VD>> то что ты его не бросишь и не продолжишь работать на Яве. AVK>А кто сказал что я на java не работаю?
Да из разговора видно, что работаешь... только вот это и странно, что вроде с выбором ты уже определился (или я ошибаюсь) но продолжаешь копать схожую технологию... причем делаешь это заранее предвзято. Я тоже могу много плохого про Нэт сказать. Но общее впечатление положительное. Думаю, если они в следующей версии прикрутят шаблоны в C# и повысят производительность компилятора, то будет просто замечательно (вот еще бы вернули возможность создавать деструкторы для value-типов ...).
VD>> Она на сегодня неплохо развилась... грабли все ее ты уже знаешь... они тебя не смущают... так бросай других агитировать. AVK>Где я кого ни будь агитировал? Пока здесь агитируешь исключительно ты сам. И почему то упорно всем пытаешся доказать что ,Net это идеал а все остальное ацтой.
Не, ну, нормально. Может этот спор я начал? Я Явы не отрицаю. Считаю, что это технология при некоторых обстоятельствах подходит для решения определенных задач. Нэт мне определенно нравится больше, но если кому охота использовать Яву я не против.
VD>> .Net это для тех кто программировал COM на C++ или VB, и для тех кому больше важна гибкость, а не переносимость. AVK>Я что то делал и на С++ и на Дельфи, под COM/DCOM, на 1С, на php, на java, на VB вот только не довелось. Мне как — подходит?
Ну, это уже решай сам. Я бы вот на 1С точно ничего делать не стал. Ну, разве что импортер данных из этого замечательного продукта, но мне можно по тому как я сам себе хозяин и определяю чем буду заниматься. Если по делу, скажу так везде есть свои особенности... Ява предлагает множество отдельных технологий направленных на построение систем автоматизации бизнеса, но не одна технология меня лично (заметь о других я не говорю) не привлекают, они или утопичны или настолько слабо реализованы, что меня не устраивает. И главное, что я не вижу как я могу реализовать свои идеи и удовлетворить свои потребности средствами этой платформы. Мне ведь нужно соблюдать генеральную линию партии. Нэт тоже предлагает свои решения но тут (если они меня не устраивают) я вижу как реализовать, то что мне нужно. Короче, каждому свое. Я (пока) выбрал Нэт. Все кто хочет могут выбирать что угодно. Например в нашем журнале "Кехнология Клиент-Сервер" мы уделяем внимание Яве не меньшее чем Нэту. Но писать про Яву я не буду. Пусть уж это делает наш постоянный автор Цимбал. (хотя он в глубине души тоже больше любит CORBA-у и C++ )
AVK>Меня убивает твоя позиция — для тебя все черное или белое. Либо рулез немеряный либо сакс полный. Любая технология имеет свои недостатки и свои достоинства, даже php. И надо уметь в каждом конкретном случае выбрать наиболее эффективную.
Можно выбирать язык для разработки конкретного проекта на конкретной платформе, но когда речь идет о выборе платформы (а Ява и нет несомненно платформы), то выбрать нечто для конкретного случая очень тяжело. Большинство людей сделают выбор один раз. И я их понимаю. Именно на смену платформы уходят немереные деньги.
А про черное и белое... ну вижу я что пытаются на выдернутых фактах создавать негативное впечатление о том что мне нравится. Что же мне молчать? Если бы ты начал Яву не по делу гасить, я бы тоже встрял. Конечно с меньшим энтузиазмом и знанием дела, но встрял бы.
Если бы у тебя был конкретный вопрос связанный с решение конкретной проблемы, то и спора бы не было. Мы просто попытались бы найти наилучшее решение. Но ты полез в обвинения, ну и получил отпор. В общем, мы мирные люди но наш бронепоезд...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали:
AVK>>Аксиома — разработка софта стоит дороже железок. Далее спорить бесполезно.
VD>Когда как. Софт все равно писать и можно его написать так, что он ни на каких супер-железках быстро работать не будет. Супер машины стоят миллионы долларов.
Согласен. Крайние случаи (простенькие программки и монстры-числомолотилки) не берем. Там все может быть наоборот.
VD>Думаю, буджеты многих российских контро имеющих своих разработчиков (и разработки) куда скромнее.
Россия для IT технологий мягко говоря не показатель. А то что в России труд своих разработчиков может быть дешевле импортных железок, увы это так.
VD> К тому же ты сам себе противоричишь. Если всегда выгоднее купить более крутую железку, то выбрось свою Яву напиши свою програму абы как на нете и купи кластер за 10 килобаксов (тот что делает в два раза самый лучший Сан).
Никакая, самая крутая железка не поможет улучшить некоторые характеристики, например управляемость. Я говорил что софт дороже железок к тому что потеря быстродействия и увеличенный расход ресурсов в угоду упрощения разработки и эксплуатации до определенного предела вполне оправдан.
VD> Так что твои разсуждения о том, что LinkedList тормозит, по меньшей мере странны. :)
Он не тормозит. Его просто нет :)
VD>>>А ну как поделись. Какая реазация объодится без CORBA-ы? AVK>>Resin, JBoss, Orion
VD>Я этих не видел. Но по статьям того же Цимбала основные сетевые решения для Явы серьезнвми конторами пишится на базе CORBA-ы. И по-моему это правильно.
А MS почему то на CORBA забил. И WS проталкивает. Хотя WS до CORBA в текущем состоянии еще далеко.
VD>Может сравним производительность и простоту работы с COM-ом через этот бридж и в Нете?
И что?
VD>К тому же ты снова уветрываешся от ответа. COM — это не Win32. Ты сравни сложность работы с Win32.
А ты сравни сложность работы скажем с so модулями? :)
VD>Не я понимаю, что лично тебе это не нужно, но вот многим другим (мне например) не хочется отказываться от одобств даваемых Виндовс в пользу эфимерной (для меня) переносимости.
Вот, для тебя. Очень важная оговорка. Все, больше вопросов к тебе нет.
AVK>>То можно взять через WinAPI VD>Какой ценой? Да и далеко не все можно взять. А без JNI и C вообще мало чего получится.
А JNI это уже не java?
VD>Мне до некоторых нет дела. А лексика обычная разговорная. Вот если статью сяду писать, то выберу слова по пристойнее и за ошипками начну следить. :)
Меня последнее время сильно достает безкультурье теперешней молодежи. Поэтому я так нервно и реагирую на слова вроде сосет, отдыхает, продвинутый, ацтой и т.д. Что, в русском языке слов не хватает? Так что извини если обидел.
VD>>>Значит Web-решения вещь не серьезная. :) Вон IT вообще все хочет не Web-сервисах переписать. :) AVK>>Серьезная то она серьезная, но деньги там не те. VD>Тото я смотрю MS дла Сан занимаются этими "безденежными" технологиями, а крутой 1C окучивает самый богатый рынок! :)))
Давая Россию поминать не будем.
AVK>>>>А LinkedList это по сути Queue или Stack но с интерфейсом IList. VD>>>А ты что (конкретно) сделать хочешь? Зчем он тебе нужен? И что мешает просто написать это дело самому (так ты хочешь) AVK>>Круто! ... VD>Нда на вопросы ты отвечать не хочешь...
На какой? Почему мне не хочется примитивные и практически везде используемые вещи писать ручками? Так я думаю это и так понятно.
VD>Я же говорю... менталитет у нас с тобой разный. Я привык писать на языке, а колекции воспринимаю как библитечную реализацию некоторого алгоритма.
Я вобще то говорю не о языке а о платформе.
VD>По этому ситуацию когда если чего нет, но можно дописать воспринимаю лучше, чем когда почти все есть, но то чего нет и желать не надо из-за нарушения стройности или проблем с переносимостью.
Ну почему обязательно вот так вот. Я например предпочитаю чтобы 99% моих неспецифических потребностей было уже реализовано, но при этом я могу дописать сам все что мне хочется. Я многого хочу?
AVK>>А нужен он частенько — когда нужен список в который часто добавляют и из которого часто удаляют, а произвольный доступ не нужен, нужен только через итератор. Разницу в производительности между ArrayList и LinkedList я тебе наглядно показал.
VD>Ну, ты не сказал зачем он тебе нужне и не показал как это же будет выглядеть на Яве (скорость имеется в виду).
Для чего нужен? Конкретный пример — писал кеш объектов. Размер кеша ограничивался определенным количеством элементов. Если их становилось больше — самые старые выпихивались. Т.е. обычная очередь. Но иногда объекты удалялись принудительно и их нужно было выкинуть из очереди вне очереди (сорри за каламбурчик :). Иногда их нужно было выпихнуть из середины в начало.
А вобще частенько приходилось использовать LinkedList, просто раньше как то не замечал его, а вот когда его не стало стразу обратил внимание. Еще пример вспомнил — при обработке XML SAX приходится где нибудь данные накапливать а затем произвольным образом часть из них выкидывать. VD> В наших проектах на C++ очень часто необходимо работать со списками, но вот связанные списки там вообще не испльзуются (в чистом виде). Все сделано на универсальных массивах. Практика показала, что грамотный массив работает быстрее чем связанный список элементы которого занимаются через хип.
Я тебе пример привел когда связаный список на порядок(!) быстрее списка на основе массивов.
VD>Да я собственно не против исходников, но намного больше мне нужна хорошая объектная модель, быстрый код, хорошая поддержка, совместимость с моими старыми ранаботками, и т.п.
Я где то говорил что все вышеперечисленное не нужно?
VD>А колекции если мне от них будет нужна максимальная скорость я все равно перепишу сам.
Точно, на ассемблере.
VD> Мои реализации все равно будут выстрее, чем то что засунуто в Нэт или Яву.
А я вот хочу переписывать базовые вещи очень редко. Опять многого хочу?
VD> Именно по этому я ечень хочу, чтобы в Нэт и Яву добавили Шаблоны как в C++.
В java в 1.5 точно уже добавят.В дотнет тоже вроде слухи ходили.
VD> Пока же я могу писать шаблоны на MC++, делать на их основе классы для конкретных типов .Нэт и испльзовать их в Шарпе и Васике, а на Яве я как всегда приплыл. И пока что ничего не поделаешь. :( Мои ActiveX-ы никак не засунуть в Яву, а в Нэт они входят как будто для него были написаны. Переносимость же у С (обычного не ++) выше. Так что же на нем писать?
Если понадобится — будешь и на нем писать. Я видел одну программку — так там на голом С был написан механизм реализующий ООП. А сделано это было для того чтобы работало на одной платформе на которой C++ отсутствовал. Вот такие вот пирожки с котятами.
Это так, не для спора, просто забавный пример извращений.
Здравствуйте VladD2, Вы писали:
AVK>>Ну так предложи тему поинтереснее. VD>Ну, например попробуй сравнить стэйтлес технику предлагаемую MS и стытфул-EJB и им подобную. Это будет по интереснее.
В каком плане сравнить?
Здравствуйте VladD2, Вы писали:
VD>То что ты называешь "стилем" является не стилем, а просто навязываемой тактикой. C++ тем и хорош, что на нем можно испльзовать любой стиль программирования и реализовывать, то что нужно программисту теми методами которые ему нравятся.
Тем же он и плох. Свобода средств увы приводит к увеличению количества ошибок даже при наличии некривых рух. А уж при их отсутствии.
VD>>> Думаю, .Net замечательное средство для подстегивания Сана... может тепрь они начнут устранять дурь мешающую многим программистам.
Кстати, посмотрел недавно новые JSR и планы sun на 1.5
1) В java добавят аттрибуты
2) В java добавят какое то подобие foreach
3) В java добавят boxing/unboxing. Вот уж где действительно косяк полный, отсутствие out параметров перед этим просто меркнет.
ну плюс еще generics(темплейты), улучшенная поддержка констант и кучу еще другого.
Так что таки подстегнули
VD>"Крайне правильный" — это даже забавно. Я вот только не понимаю почему из-за этой крайней правильности нужно эмулировать [out]- и [in, out]-параметры через массивы. Оставили бы хотья бы передачу по ссылке...
out параметры являются потенциальными источниками трудноуловимых ошибок. Это не мое ИМХО, это так разработчики говорят. Их можно эмулировать, но еще лучше так спроектировать систему чтобы надобность в них отпала.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали:
AVK>>Мне этот бессмысленный спор надоел, поэтому ничего на тему серверов я тебе отвечать не буду. Да и неинтересно это уже здесь никому. VD>Т.е. если чувствуем, что не правы, объявляем спор бессмысленным и уходим от ответа.
Нет, именно надоело.
VD>А те и говорят. Писюки давно в лидерах производительности... по цене они всех делали всегда... совместимость с большим количеством платформ — это дополнительный геморрой (даже на Яве)... Короче, для многих переносимость не показатель. Вот для меня с IT, например. Кому нужна переносимость пусть используют Яву или C++ с переносимыми библиотеками, а навязывать ее всем, да еще и объявлять это главным достоинством, не стоит.
Я где то это делал? Или ты о Sun? Так я с ними в этом плане тоже не согласен.
VD>Не... Ты заявлял нечто вроде этого "что же это за платформа если в ней нет даже...".
Я сказал что дотнет еще сыроват и привел списочек чего лично мне в нем не хватает.
VD>Не. Ну бывают действительно ресурсоемкие вещи. Если бы ты о тех же стэйтфул-EJB-ях заговорил, я бы понял... но связанный список!
Это пример. Причем не единственный. Еще раз кину списочек
1) LinkedList
2) RandomAccessFile
3) MemoryMappedFile
Из API
1) JDO
2) EJB
3) JAAS.
Список самый негемморойный.
А стейтфул для EJB это побочная особенность. Да и сравнивать с WS глупо — EJB это намного больше. Аналог WS в java это RMI. Хотя в java и WS есть.
VD>Думаю недосмотр или не посчитали эту фичу важной. Зато там много чего другого есть ценного. И главное есть стройная компонентная модель.
Ну так это не есть его уникальная особенность. К примеру свинг куда стройнее Windows.Forms.
Во, кстати, еще вспомнил — почему в этих самых формсах нет обычного грида, без всяких там Data? Тоже ручками писать надо?
VD>Ну, это уже зависит от реализации. Будет время можно будет поэкспериментировать.
Так LinkedList и ArrayList только реализацией и отличаются. Впрочем, сколько не экспериментируй — отставание на порядок ты не исправишь.
VD>Ну, это как бы из критики вытекает.
Не надо пожалуйста за меня говорить. Ничего такого из моей критики не вытекает
VD> Чувствуется, что ты на этот продукт обижен, что ли...
Не правильно чувствуется. Если говорить о моих чувствах то дотнет мне нравится. На данный момент главное от него ощущение — это как пересесть со спортивной машины(java) на шикарный представительский мерс(дотнет). Аналогия понятна?
VD>Да из разговора видно, что работаешь... только вот это и странно, что вроде с выбором ты уже определился (или я ошибаюсь) но продолжаешь копать схожую технологию...
То есть? Ты всерьез считаешь что я один раз определяюсь и затем пользуюсь только выбранной технологией? Это не так — технологию я выбираю для каждого проекта. В другом треде я кстати писал о совместном использовании java и .Net
VD> причем делаешь это заранее предвзято.
Нет, это твои личные впечатления.
VD> Я тоже могу много плохого про Нэт сказать.
Но будешь молчать? Это ли не предвзятое отношение? Я ведь и плохие моменты java тоже отмечаю.
VD> Но общее впечатление положительное.
У меня тоже.
VD> Думаю, если они в следующей версии прикрутят шаблоны в C# и повысят производительность компилятора, то будет просто замечательно
Да много чего еще дорабатывать надо. А на производительность компилятора мне честно говоря на*№ать. В С# incremental compiling есть, а в условиях отсутствия хидеров работает он просто идеально.
VD> (вот еще бы вернули возможность создавать деструкторы для value-типов ...).
А нафига? Эти типы — нечто вроде объектных заменителей ... ну скажем record в паскале. Т.е. сложных типов данных. А деструкторы им как бы не к чему.
Ну а отсутствие деструкторов у классов — да мешает. Но это цена которую приходится платить за GC и отложеное удаление.
VD>Не, ну, нормально. Может этот спор я начал?
Может я?
VD>Ну, это уже решай сам.
А я и решил.
VD> Я бы вот на 1С точно ничего делать не стал.
И опять у тебя все черно-белое. Сколько времени тебе понадобится чтобы написать на дотнете простенький складской учет? И сколько это будет денег стоить? Для маленьких предприятий 1С в России на данный момент лучше всего. Платишь сотню баксов и получаешь весьма приличный складской и бухгалтерский учет + бесплатные обновления в соответствии с весьма продуктивной деятельностью наших законодателей и чиновников.
VD> утопичны или настолько слабо реализованы, что меня не устраивает.
Таки на java очень много успешных проектов, больше чем на дотнет. Так что не так уж и утопично. Вобще — о вкусе устриц можно спорить только с тем кто их ел. VD> И главное, что я не вижу как я могу реализовать свои идеи и удовлетворить свои потребности средствами этой платформы.
Ну так рассказывай про свои потребности. VD> Мне ведь нужно соблюдать генеральную линию партии.
А кому нужно? VD> Нэт тоже предлагает свои решения но тут (если они меня не устраивают) я вижу как реализовать, то что мне нужно.
А что тебе нужно? VD> Короче, каждому свое. Я (пока) выбрал Нэт.
Для чего?
VD>Можно выбирать язык для разработки конкретного проекта на конкретной платформе, но когда речь идет о выборе платформы (а Ява и нет несомненно платформы), то выбрать нечто для конкретного случая очень тяжело.
Есть специальные люди для которых подобные задачи — один из основных вопросов профессиональной деятельности. И ценятся такие люди намного больше обычных программистов. VD> Большинство людей сделают выбор один раз. И я их понимаю. Именно на смену платформы уходят немереные деньги.
Зачем на смену? Уж коли ты начал делать проект на какой то платформе — потом менять поздно. А вот начиная новый проект можно и нужно рассмотреть вопрос выбора платформы, с учетом не только чисто технологических факторов. Я конечно понимаю — для программиста куда проще выбрать одну платформу и всю жизнь на ней писать. Но увы — так не получится. Выбрал бы ты к примеру в свое время весьма передовой FoxPro. Если не переучиваться — кому сейчас нужен такой специалист? Так что учиться и переучиваться придется, причем всю жизнь.
VD>А про черное и белое... ну вижу я что пытаются на выдернутых фактах создавать негативное впечатление о том что мне нравится.
Я не пытаю создавать никакого впечатления. Я пытаюсь донести свою мысль.
VD> Что же мне молчать? Если бы ты начал Яву не по делу гасить, я бы тоже встрял. Конечно с меньшим энтузиазмом и знанием дела, но встрял бы.
И никого не гашу.
VD>Если бы у тебя был конкретный вопрос связанный с решение конкретной проблемы, то и спора бы не было.
Увы, на данном этапе развития дотнета в России почти любой вопрос проще расковырять самому. Специалистов практически нет.
VD> Мы просто попытались бы найти наилучшее решение. Но ты полез в обвинения, ну и получил отпор. В общем, мы мирные люди но наш бронепоезд...
Странно ты как то воспринимаешь. Вот собственно фраза(не твоя) которая мне не понравилась IT>Ну так вот прямо в двух словах вряд ли расскажешь. Если её с чем-то и можно сравнить, то скорее всего с Java. Но это естественно больше чем Java.
А теперь твои фразы VD>Если .Net станет перенасима хотя бы в серверном варианте, т.е. без клиентского интерфейса (WinForms), то у Явы пропадет последний фиговый листок, но тем кто выбрал .Net это будет по фигу.
VD>Небыло бы Борланда для Явы вообще не создали бы приличной среды разработки.
VD>по сравнению с документацией от той же Явы MSDN — это рай.(MSDN имелся ввиду)
А вот где я кого то обвинял? До сих пор пытаюсь доказать что не все так однозначно. И ничего более. Все остальное — домыслы.
Здравствуйте AndrewVK, Вы писали:
AVK>И результат AVK>407 AVK>515 AVK>688
AVK>Что ж AVK>1) Массивы действительно быстрее связаного списка. Впрочем это и понятно. В случае выдергивания элементов с конца нет необходимости передвижки всех элементов, а доступ к массиву быстрее. AVK>2) Похоже что дотнетовкий список реализован на основе массивов AVK>3) А вот почему самопальный стек на основе ArrayList оказался быстрее — для меня загадка.
А у меня другие данные при запуске того же теста:
1883
1732
2224
Здравствуйте DarkGray, Вы писали:
DG>А у меня другие данные при запуске того же теста: DG>1883 DG>1732 DG>2224
Давай тогда сюда свою програмную и аппаратную конфигурацию. Судя по всему дело в медленной памяти. Потому как практически одинаковая скорость связаных списков и массивов.
Здравствуйте AndrewVK, Вы писали:
VD>>Если очень хочется, можешь написать универсальную реализацию с интерфейсом IList. AVK>Вот это я и хотел доказать — придется писать ручками с нуля. Больше вопросов нет.
Что доказать? То что ленив? Да мы тум все такие. Фунционильность нужная тебе, я так понял, в Нете есть. Тебя не устраивает производительность, хотя ты же говоришь, что намного дешевле купить более производительный компьютер. Ты говоришь, что в Яве все лучше, но времени выполнения того же теста, на том же железе не приводишь. Написать это дело можно было за два часа. На споры со мной ты убил куда больше. Так что выходит, что ты доказываешь свою лень. :)
AVK>Весь местный форум проще и меньше чем процедура проведения скажем расходной накладной у меня, а ведь бывает много больше.
Ну, что же значит он лучше спроектирован. По количеству единиц данных сообщение форума близко к накладной. Так что если у тебя делается очень много действий, не факт что они все необходимы. По объему информации наши постинги явно перекрывают среднюю накладную. :)
Я уже давно понял, что нельзя подходить к разным областям деятельности предвзято. Можно создать простую накладную и сложный форум, а можно наоборот. Для того чтобы сравнивать нежно как минимум изучить реализацию того и другого. В конечном счете это просто бессмысленно.
VD>>Если фирма растет, такие изменения происходят постоянно и система постоянно перепроектируется. В некоторых этапах, когда руководство тех. отдела понимает, что количество примочек слишком велико, принимается решение и перепроектируется система. В ином случае фирма или перестает расти, или плюет на систему автоматизации, или дохнет. AVK>Извини, но ты не прав.
Да ладно извиняться... мирный спор все таки. :)
AVK>Я уже тебе говорил — даже если руководство согласно отдавать IT почти всю прибыль — частая замена информационных систем приведет к полному краху. Ибо людей не переделать.
Так я с тобой почти согласен. В том плане, что полная переделка системы — это тяжелая и ответственная работа. Вот только ты не услышал моих аргументов о том, что в растущей фирме такие переделки идут постоянно (эволюционные изменения, тык сызыть), и то что систему рассчитанную на малое предприятие нельзя перенести на большое (при внезапном чдо-росте) путем копирования Явоского кода с одной машины на другую. Так что переносимость для внутрифирменных проектов нужна редко.
AVK>Если у тебя нет опыта внедрения подобных систем — не стоит на эту тему спорить. Я тебе говорил — там все по другому.
Боюсь если мы начнем "мериться членами", то ты можешь проиграть. :) Так что довай по сути и не будем оценивать опыт друг-друга. Я верю, что у тебя кое-какой опыт есть. Так что поверь, что и я, и IT тоже делали в своей жизни кое что. И если у нас не возникло надобности в Крэе, Сане или Яве — это не значит, что решаемые задачи у нас были слабенькие. В конце концов, тот же IT (как я понимаю) окучивает какую-то Маямскую контору...
AVK>>>И дело даже не во вложеных деньгах. Дело в том что смена информационной системы для крупного предприятия это очень тяжелое испытание. И это чревато потерей денег куда больших нежели стоимость самой разработки. VD>>Когда выбор стоит между тяжелым решением и прозябанием, зачастую выбирается трудная жизнь, а не легкая смерть. :) AVK>Ну когда такой выбор стоит — тогда конечно
VD>>Блин ну какое самомнение. Ты серьезно считаешь, что один видел все на свете? AVK>Нет. Но когда тебе говорят что черное это белое...
Ты пойми. М моей стороны все выглядит так же, но говоришь уже ты. :) Так что давай уж если спорим, то аргументировать свое мнение. Тогда от спора обязательно будет толк. А так действительно получится флэйм. Вот твое следующее письмо мне понравилось. Там ты аргументируешь свое мнение практическим кодом. И заметь она становится ближе к моему. :)
VD>>Да ну? А вот я, IT и MS думаем по другому. MS конечно не помешает замена VB, но он MS был бы не MS если бы в их планы не входил захват всех рынков на которых можно зарабатывать деньги. Не удивлюсь если через пру лет MS начнет обсуждать вопросы разработки драйверов на C#. AVK>Как ты думаешь почему столь уважаемый тобой MS использует CLR, GC, COM+, SOAP? Не иначе для того чтобы драйвера писать.
GC – это часть CLR. CLR – надстройка позволяющая создавать переносимые между языками бинарные компоненты, т.е. – это COM 2. COM+ – основанный на COM сервер приложений реализованный в виде сервиса ОС. SOAP – протокол удаленных вызовов через http и XML. Все это действительно не имеет отношения к драйверам. Ну, разве что нет теоретического запрета использования CLR-а в драйверах. Но .Net не == CLR. Статья IT и мои личные опыты показывают, что на MC++ (да и напрямую на MSIL, являющегося ни чем иным, как переносимым ассемблером) можно создавать бинарный байт-код (но не код для код для конкретного процессора) который может делать все, что угодно. Его JIT-вариант ни чем не отличается от машинного кода скомпилированного лучшими оптимизирующими компиляторами. Более того я могу делать вставки реального машинного кода. Это позволяет спокойно писать и драйверы на платформе .Net, при условии что JIT-компилятор будет запускаться в рамках необходимого кольца защиты. В Яве этот слой отсутствует как класс. И именно это (не драйверы, а открывающиеся возможности) меня и подкупает. Ты уже заметил, что не универсальный код написанный на .Net работает быстрее. Тоже самое верно и для Явы. MC++ позволяет создавать шаблоны, а на их основе конечные классы для конкретных типов данных. Классы же нет используют красивый, но априори более медленный универсальный стиль основанный на интерфейсах и типе object.
AVK>А за других я бы на твоем месте не стал говорить.
Ты можешь привести конкретное место где я это делал?
VD>>Чтобы понять разницу между Явой И Нэтом нужно написать сотню строк на миксе из MC++ и C#. Я ничего не имею против параллельного развития Явы, но думаю Windows-программистам (коих большинство) ближе будет Нэт. И им будет куда проще преодолеть его подводные камни чем перейти в лагерь сана. AVK>Я вот большую часть времени писал именно под Windows. Однако что то мне не кажется что дотнет безоговорочно лучше всего и везде.
Так и мне не кажется. Но моих рассуждений, это не отрицает. Хотел бы я посмотреть, что бы ты сказал если .Net ты увидел бы раньше Явы? Думаю твое отношение был бы совершенно иным.
VD>>Кстати, а какую скорость показывает твой тест если его запустить на НотСпоте? AVK>Нет проблем. Тест конечно пришлось немножко переписать. Вот код
AVK>Вот результат
AVK>2312 AVK>141
AVK>Результат старого теста на машине на которой я сейчас пишу
AVK>1547 AVK>156
AVK>Что же — массивы в дотнете быстрее :). Но не на столько чтобы заменить связаные списки. AVK>Списки медленнее. Это при том что джавовски LinkedList это и очеред и стек в одном флаконе. Я честно говоря думал что у java результаты будут хуже.
Да, правильный алгоритм может дать лучшую скорость и на худшем компиляторе и на худшем железе. У .Net-а конечно можно еще запустить ngen (надеюсь ты релиз тестировал) и выиграть еще процентов 10-20. Но общую картину это не изменит.
Зато я заною как при том же алгоритме увеличить скорость еще на порядок. Нужно просто заменить object на int (родной тип). Вот CLR и Ява тем и плохи, что полиморфность в них достигается за счет использования виртуальных методов и типа object. На C++ я бы написал шаблон и он бы дал лучшую производительность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте DarkGray, Вы писали:
DG>>А у меня другие данные при запуске того же теста: DG>>1883 DG>>1732 DG>>2224 AVK>Давай тогда сюда свою програмную и аппаратную конфигурацию. Судя по всему дело в медленной памяти. Потому как практически одинаковая скорость связаных списков и массивов.
Стек действительно несколько быстрее. Просто не нужно этот тест делать вторым. К тому же можно задать капасити, чтобы не фрагментировать память.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте DarkGray, Вы писали:
DG>>А у меня другие данные при запуске того же теста: DG>>1883 DG>>1732 DG>>2224 AVK>Давай тогда сюда свою програмную и аппаратную конфигурацию. Судя по всему дело в медленной памяти. Потому как практически одинаковая скорость связаных списков и массивов.
Извиняюсь это было в Debug-версии, в Release тоже самое, что и у тебя
Здравствуйте AndrewVK, Вы писали:
VD>>Как манимум Stack нмного эфективнее создавать на базе обычного массива. AVK>Я на твоем месте попробовал бы и кинул сюда исходнички и результаты. Скорее всего ты прав. Впрочем попробуем:
AVK>...Смысл теста такой — сначала забиваем стек, затем работаем на его вершине и затем опустошаем. Очередь приведена в качестве стека на основе связаного списка. Понятно что забирает элементы она с другого конца, но для связаного списка конец с которого мы будем выдергивать элементы на скорость влияния не оказывает.
AVK>И результат AVK>407 AVK>515 AVK>688
Результаты теста зависят от очередности (из-за фрагментированности памяти). К тому же я бы задал капасити заранее. Это уменьшило бы фрагментацию.
AVK>1) Массивы действительно быстрее связаного списка. Впрочем это и понятно. В случае выдергивания элементов с конца нет необходимости передвижки всех элементов, а доступ к массиву быстрее.
Дык. А ты думал тебя тут обмануть хотели?
AVK>2) Похоже что дотнетовкий список реализован на основе массивов AVK>3) А вот почему самопальный стек на основе ArrayList оказался быстрее — для меня загадка.
Да не быстрее он. Просто память уже фрагментировалась к этому времени. Переставь местами эти тесты и увидишь, что стэк даже быстрее.
А вот мой вариант твоего теста:
using System;
using System.Collections;
namespace Lists
{
class ArrayStack
{
public ArrayStack(int Capacity){ al = new ArrayList(Capacity); }
private ArrayList al;
public void Push(object obj)
{
al.Add(obj);
}
public object Pop()
{
object obj = al[al.Count-1];
al.RemoveAt(al.Count-1);
return obj;
}
}
class IntArrayStack
{
public IntArrayStack(int Capacity){ this.Capacity = Capacity; }
int m_iCapacity;
public int Capacity
{
get{ return m_iCapacity; }
set
{
if(value < 0)
throw new Exception("Capacity не может быть меньше нул!");
m_Array = new int[value];
m_iCapacity = value;
}
}
public void Grow(){ Capacity = Capacity * 2; }
int m_iCount = 0;
public int Count{ get{ return m_iCount; } }
private int[] m_Array;
public void Push(int obj)
{
if(m_iCount >= m_iCapacity)
Grow();
m_Array[m_iCount] = obj;
m_iCount++;
}
public int Pop()
{
m_iCount--;
return m_Array[m_iCount];
}
}
public class Test
{
private const int Capacity = 1100000;
private const int ITER_COUNT = 1000000;
static void StackTest()
{
Stack s = new Stack(Capacity);
int st = Environment.TickCount;
for(int i = 0; i < ITER_COUNT; i++)
{
s.Push(new object());
}
for(int i = 0; i < ITER_COUNT; i++)
{
s.Push(new object());
s.Pop();
}
for(int i = 0; i < ITER_COUNT; i++)
{
s.Pop();
}
Console.WriteLine("Stack: " + (Environment.TickCount - st));
}
static void ArrayStackTest()
{
ArrayStack ars = new ArrayStack(Capacity);
int st = Environment.TickCount;
for(int i = 0; i < ITER_COUNT; i++)
{
ars.Push(new object());
}
for(int i = 0; i < ITER_COUNT; i++)
{
ars.Push(new object());
ars.Pop();
}
for(int i = 0; i < ITER_COUNT; i++)
{
ars.Pop();
}
Console.WriteLine("ArrayStack: " + (Environment.TickCount - st));
}
static void IntArrayStackTest()
{
IntArrayStack iars = new IntArrayStack(Capacity);
int st = Environment.TickCount;
for(int i = 0; i < ITER_COUNT; i++)
{
iars.Push(i);
}
for(int i = 0; i < ITER_COUNT; i++)
{
iars.Push(i);
iars.Pop();
}
for(int i = 0; i < ITER_COUNT; i++)
{
iars.Pop();
}
Console.WriteLine("IntArrayStack: " + (Environment.TickCount - st));
}
static void QueueTest()
{
Queue q = new Queue(Capacity);
int st = Environment.TickCount;
for(int i = 0; i < ITER_COUNT; i++)
{
q.Enqueue(new object());
}
for(int i = 0; i < ITER_COUNT; i++)
{
q.Enqueue(new object());
q.Dequeue();
}
for(int i = 0; i < ITER_COUNT; i++)
{
q.Dequeue();
}
Console.WriteLine("Queue: " + (Environment.TickCount - st));
}
public static void Main()
{
QueueTest();
StackTest();
ArrayStackTest();
IntArrayStackTest();
Console.WriteLine("\nStep 2...");
QueueTest();
StackTest();
ArrayStackTest();
IntArrayStackTest();
Console.WriteLine("\nStep 3...");
IntArrayStackTest();
ArrayStackTest();
QueueTest();
StackTest();
Console.WriteLine("\nPress Enter to exit...");
Console.ReadLine();
}
}
}
Заметь насколько быстрее IntArrayStack. Мой тест еще интересен тем, что в нем легко переставлять тесты местами. При тестах я компилировал все в релиз и пре-JIT-ил EXE-шник ngen-ом. Машина AMD1400 RAM 512.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Заметь насколько быстрее IntArrayStack. Мой тест еще интересен тем, что в нем легко переставлять тесты местами. При тестах я компилировал все в релиз и пре-JIT-ил EXE-шник ngen-ом. Машина AMD1400 RAM 512.
Не корректно сравнивать IntArrayStack с остальными, т.к. для IntArrayStack не вызывается функция new object() для каждой итерации
Re[14]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали:
VD>Что доказать? То что ленив?
Нет, то что дотнет сыроват.
VD>Да мы тум все такие. Фунционильность нужная тебе, я так понял, в Нете есть. Тебя не устраивает производительность,
Знаешь, если бы производительность отличалась в 2 раза я бы пережил. Но когда на порядок! Ты вот пузырьковой сортировкой пользуешся? Это из той же оперы. VD>Ты говоришь, что в Яве все лучше,
Нет, я такого никогда не говорил.
VD> но времени выполнения того же теста, на том же железе не приводишь.
Как же так — я же привел. Плохо смотрел?
VD>Написать это дело можно было за два часа. На споры со мной ты убил куда больше. Так что выходит, что ты доказываешь свою лень.
Пятый раз говорю — плевать мне на LinkedList, я его в качестве примера привел. Я нигде не говорил что именно без него я жить не могу. Это ПРИМЕР, понимаешь?
AVK>>Весь местный форум проще и меньше чем процедура проведения скажем расходной накладной у меня, а ведь бывает много больше. VD>Ну, что же значит он лучше спроектирован.
А тест мой раз в сто наверное меньше чем местный форум. Наверное еще лучше спроектирован?
VD> По количеству единиц данных сообщение форума близко к накладной.
Нет. VD> Так что если у тебя делается очень много действий, не факт что они все необходимы. По объему информации наши постинги явно перекрывают среднюю накладную.
Нет.
VD>Я уже давно понял, что нельзя подходить к разным областям деятельности предвзято. Можно создать простую накладную и сложный форум, а можно наоборот. Для того чтобы сравнивать нежно как минимум изучить реализацию того и другого. В конечном счете это просто бессмысленно.
Да нельзя подобные задачи сравнивать. Я тебе потому и привел размер кода одной только проводки чтобы показать что форум и КИС абсолютно несравниваемы.
VD>Так я с тобой почти согласен. В том плане, что полная переделка системы — это тяжелая и ответственная работа. Вот только ты не услышал моих аргументов о том, что в растущей фирме такие переделки идут постоянно (эволюционные изменения, тык сызыть),
Переделки — да. Но не перепроектирование основ.
VD> и то что систему рассчитанную на малое предприятие нельзя перенести на большое (при внезапном чдо-росте) путем копирования Явоского кода с одной машины на другую. Так что переносимость для внутрифирменных проектов нужна редко.
Зато можно еще на год-другой отложить безвременную кончину и этим съэкономить денежек. Впрочем опять мы в какой то оффтопик скатываемся. Давай завязывать на эту тему.
VD>Боюсь если мы начнем "мериться членами", то ты можешь проиграть. Так что довай по сути и не будем оценивать опыт друг-друга. Я верю, что у тебя кое-какой опыт есть. Так что поверь, что и я, и IT тоже делали в своей жизни кое что. И если у нас не возникло надобности в Крэе, Сане или Яве — это не значит, что решаемые задачи у нас были слабенькие. В конце концов, тот же IT (как я понимаю) окучивает какую-то Маямскую контору...
Да не хочу я пиписьками меряться. Просто судя по твоим словам основной опыт у тебя в веб-проектах. И переносить его на КИС не стоит. Но если ты занимался именно КИС — расскажи поподробнее, если конечно не тайна. Всегда полезно обменяться опытом.
VD>>>Блин ну какое самомнение. Ты серьезно считаешь, что один видел все на свете? AVK>>Нет. Но когда тебе говорят что черное это белое... VD>Ты пойми. М моей стороны все выглядит так же, но говоришь уже ты. Так что давай уж если спорим, то аргументировать свое мнение. Тогда от спора обязательно будет толк. А так действительно получится флэйм.
Знаешь, я на тему серверов не хочу спорить. Давай все же ближе к дотнету. Я специально на остальное не отвечаю, ибо не интересно это никому здесь. VD> Вот твое следующее письмо мне понравилось. Там ты аргументируешь свое мнение практическим кодом. И заметь она становится ближе к моему.
Так я люблю, если это разъясняет, попробовать. Ибо снимает все вопросы и практически не требует словословия. Факты, так скать в голом виде.
AVK>>Как ты думаешь почему столь уважаемый тобой MS использует CLR, GC, COM+, SOAP? Не иначе для того чтобы драйвера писать.
VD>GC – это часть CLR.
GC — это технология прежде всего. VD> CLR – надстройка позволяющая создавать переносимые между языками бинарные компоненты,
Наврал я немножко. Не CLR я имел ввиду а MSIL и VM для его выполнения
VD>SOAP – протокол удаленных вызовов через http и XML.
html здесь лишний.
VD> Все это действительно не имеет отношения к драйверам. Ну, разве что нет теоретического запрета использования CLR-а в драйверах. Но .Net не == CLR. Статья IT и мои личные опыты показывают, что на MC++ (да и напрямую на MSIL, являющегося ни чем иным, как переносимым ассемблером) можно создавать бинарный байт-код (но не код для код для конкретного процессора) который может делать все, что угодно. Его JIT-вариант ни чем не отличается от машинного кода скомпилированного лучшими оптимизирующими компиляторами. Более того я могу делать вставки реального машинного кода. Это позволяет спокойно писать и драйверы на платформе .Net, при условии что JIT-компилятор будет запускаться в рамках необходимого кольца защиты.
Да я же не говорю что применить нельзя. Просто MSIL, CG, далее по списку для драйверов — ну примерно как для собаки пятая нога.
VD> В Яве этот слой отсутствует как класс. И именно это (не драйверы, а открывающиеся возможности) меня и подкупает. Ты уже заметил, что не универсальный код написанный на .Net работает быстрее.
Это я заметил с самого начала. И памяти кстати заметно меньше кушает.
AVK>>А за других я бы на твоем месте не стал говорить. VD>Ты можешь привести конкретное место где я это делал?
Поскипал ты зря. "А вто я, IT и MS думаем по другому." — твои слова?
VD>Так и мне не кажется. Но моих рассуждений, это не отрицает. Хотел бы я посмотреть, что бы ты сказал если .Net ты увидел бы раньше Явы? Думаю твое отношение был бы совершенно иным.
Вряд ли. Технологии я стараюсь оценивать объективно. Кстати после java очень легко воспринимаются многие дотнетовские фишки.
VD>Да, правильный алгоритм может дать лучшую скорость и на худшем компиляторе и на худшем железе. У .Net-а конечно можно еще запустить ngen (надеюсь ты релиз тестировал)
релиз, да еще и с SP1 VD> и выиграть еще процентов 10-20. Но общую картину это не изменит.
Пожалуйста, запустить ngen не сложно
1906
172
(напомню старые
1547
156)
Вот такие вот пирожки с котятами. До этого я еще кое что с ngen и без мерял — эффект был = 0 (на 2 бете еще). А теперь вобще все грустно Хотя я догадываюсь почему такой эффект.
VD>Зато я заною как при том же алгоритме увеличить скорость еще на порядок. Нужно просто заменить object на int (родной тип).
Э нет — так низзя. Нафига мне int хранить? Мне объекты хранить нужно. Впрочем опять же — никаких проблем попробовать.
1890
172
То есть эффект = 0. Догадываешся почему?
VD> Вот CLR и Ява тем и плохи, что полиморфность в них достигается за счет использования виртуальных методов и типа object. На C++ я бы написал шаблон и он бы дал лучшую производительность.
Вот о чем я и говорю — лучше пожертвовать производительностью в угоду удобству и надежности. Ибо железки ныне дешевеют а труд программеров дорожает. Это тенденция однако. Хотя я хорошо помню времена XT-шек когда основной ресурс был — время процессора и приходилось писать большие куски на ассемблере чтобы получить, нет, не большУю, просто приемлемую производительность. Но в отличие от некоторых об этих временах совсем не жалею. Я не тебя имею ввиду, просто достал треп что мол программисты программы писать разучились. Сами что такое ассемблер представляют по книжкам и примерчикам — зато с апломбом доказывают что мол если бы не MS все программы были бы написаны на ассемблере, в крайнем случае на голом С, занимали бы 20-30Кб и работали бы со свистом на трешках.
Здравствуйте VladD2, Вы писали:
VD>Стек действительно несколько быстрее.
Который? VD> Просто не нужно этот тест делать вторым.
Ага, знаешь. Есть такой косяк. VD> К тому же можно задать капасити, чтобы не фрагментировать память.
Кому? Я честно говоря не понял. Stack или ArrayStack?
Здравствуйте DarkGray, Вы писали:
DG>Если поменять местами Stack и ArrayList, то:
DG>621 DG>901 DG>1052
Виноват, забыл я про это. Исправляюсь
using System;
using System.Collections;
class ArrayStack {
private ArrayList al = new ArrayList();
public void Push(object obj) {
al.Add(obj);
}
public object Pop() {
object obj = al[al.Count-1];
al.RemoveAt(al.Count-1);
return obj;
}
}
public class Test {
private const int ITER_COUNT = 1000000;
public static void Main() {
ArrayStack ars = new ArrayStack();
int st = Environment.TickCount;
for(int i = 0; i < ITER_COUNT; i++) {
ars.Push(new object());
}
for(int i = 0; i < ITER_COUNT; i++) {
ars.Push(new object());
ars.Pop();
}
for(int i = 0; i < ITER_COUNT; i++) {
ars.Pop();
}
Console.WriteLine(Environment.TickCount-st);
//Изменено здесь
GC.Collect();
Stack s = new Stack();
st = Environment.TickCount;
for(int i = 0; i < ITER_COUNT; i++) {
s.Push(new object());
}
for(int i = 0; i < ITER_COUNT; i++) {
s.Push(new object());
s.Pop();
}
for(int i = 0; i < ITER_COUNT; i++) {
s.Pop();
}
Console.WriteLine(Environment.TickCount-st);
//И здесь
GC.Collect();
Queue q = new Queue();
st = Environment.TickCount;
for(int i = 0; i < ITER_COUNT; i++) {
q.Enqueue(new object());
}
for(int i = 0; i < ITER_COUNT; i++) {
q.Enqueue(new object());
q.Dequeue();
}
for(int i = 0; i < ITER_COUNT; i++) {
q.Dequeue();
}
Console.WriteLine(Environment.TickCount-st);
}
}
516
484
781
Вот теперь все стало на свои места и вполне предсказуемо. Небольшая разница у StackArray обусловлена наличием промежуточного слоя.
Ну, видишь... у нас тоже есть совподающие точки зрения. :)
VD>>Думаю, буджеты многих российских контро имеющих своих разработчиков (и разработки) куда скромнее. AVK>Россия для IT технологий мягко говоря не показатель. А то что в России труд своих разработчиков может быть дешевле импортных железок, увы это так.
Дык. Я... это в России живу. :shuffle: И все ее ограничения и/или радости на меня влияют. Вот IT (в смысле мужик) он тепарь буджуй, но все равно на писюках живет.
VD>> К тому же ты сам себе противоричишь. Если всегда выгоднее купить более крутую железку, то выбрось свою Яву напиши свою програму абы как на нете и купи кластер за 10 килобаксов (тот что делает в два раза самый лучший Сан). AVK>Никакая, самая крутая железка не поможет улучшить некоторые характеристики, например управляемость. Я говорил что софт дороже железок к тому что потеря быстродействия и увеличенный расход ресурсов в угоду упрощения разработки и эксплуатации до определенного предела вполне оправдан.
О вот ты и сам сказал ключевое слово "до определенного предела". Т.е. иногда проще софт поправить, а иногда жележку новую прикупить. И аксиом тут никаких нет. Есть только конкретные жизненные условия. А управляемость... вещь которую измерить турудно. Я вот считаю, что управлять ПО созданого для Windows и в его духе проще, но это мое личное мнение...
VD>> Так что твои разсуждения о том, что LinkedList тормозит, по меньшей мере странны. :) AVK>Он не тормозит. Его просто нет :)
Ну, есть же заменитель. В .Net есть почти все, что тебе нужно. Кое чего нет. Ну, так не трудно дописать. Скорости универсальной реализации хватит на 90% случаев, а в тонком месте можно всунуть свою (заточеную на конкретные условия) реализацию. Как я уже доказал это может дать значительный выигрыш производительности.
VD>>Я этих не видел. Но по статьям того же Цимбала основные сетевые решения для Явы серьезнвми конторами пишится на базе CORBA-ы. И по-моему это правильно. AVK>А MS почему то на CORBA забил. И WS проталкивает. Хотя WS до CORBA в текущем состоянии еще далеко.
Ну, с корбой нужно скорее сравнивать COM и CLR. Но оба этих дела перекрывают по областям применения CORBA. Так как являются и локальными и распределенными компонентными моделями, а не только технологией для сетевого взаимодействия.
VD>>Может сравним производительность и простоту работы с COM-ом через этот бридж и в Нете? AVK>И что?
И то, что для Явы все это будет геморой, а ясного пути интеграции с сервисами ОС вообще нет. Все нужно писать на С через JNI. Для .Net это делается на ура даже напрямую из C# или VB.Net, а на MC++ сожно тварить все что захочешь запаковывая результат в CLR-совместимые обертки.
VD>>К тому же ты снова уветрываешся от ответа. COM — это не Win32. Ты сравни сложность работы с Win32. AVK>А ты сравни сложность работы скажем с so модулями? :)
Не понял.
VD>>Не я понимаю, что лично тебе это не нужно, но вот многим другим (мне например) не хочется отказываться от одобств даваемых Виндовс в пользу эфимерной (для меня) переносимости. AVK>Вот, для тебя. Очень важная оговорка. Все, больше вопросов к тебе нет.
Какой раз у тебя "больше вопросов к тебе нет"? :)
Я говрю за себя, когда речь идет о пристрастиях. Межплатформная переносимость — это пристрастие. Ты веришь, что это спасительная волшебная палачка, я в то что это геморой, даже на Яве или Нэте. Вот и вся разница.
AVK>>>То можно взять через WinAPI VD>>Какой ценой? Да и далеко не все можно взять. А без JNI и C вообще мало чего получится. AVK>А JNI это уже не java?
Да не Ява. Это интерфейс между явой и С. В нет интеграция с реальной ОС сделана в разы лучше. Если бы у тебя было много С++-ного (например) кода, ты бы меня поныл.
AVK>Меня последнее время сильно достает безкультурье теперешней молодежи. Поэтому я так нервно и реагирую на слова вроде сосет, отдыхает, продвинутый, ацтой и т.д. Что, в русском языке слов не хватает? Так что извини если обидел.
Иногда, разнообразие не помешает. :) Главное, чтобы из этих слов весь лексикон не состоял. :) Меня, например, "ИМХО" вместо "по-моему" бесит... экономия трех букв... понимашъ. :) Ну, не бить же каждого по кумполу (:) ) за это?
VD>>>>Значит Web-решения вещь не серьезная. :) Вон IT вообще все хочет не Web-сервисах переписать. :) AVK>>>Серьезная то она серьезная, но деньги там не те. VD>>Тото я смотрю MS дла Сан занимаются этими "безденежными" технологиями, а крутой 1C окучивает самый богатый рынок! :))) AVK>Давая Россию поминать не будем.
Давая. :) Но, ПюплСофт тоже до MS не дотягивает, а те кто делает заказные проекты на Яве и подавно.
AVK>>>>>А LinkedList это по сути Queue или Stack но с интерфейсом IList. VD>>>>А ты что (конкретно) сделать хочешь? Зчем он тебе нужен? И что мешает просто написать это дело самому (так ты хочешь) AVK>>>Круто! ... VD>>Нда на вопросы ты отвечать не хочешь... AVK>На какой? Почему мне не хочется примитивные и практически везде используемые вещи писать ручками? Так я думаю это и так понятно.
Я тебе уже говорил, что у нас есть проект в котором 300 000 строк кода и в нем не разу не исползовлся связаный список? По этому и спрашиваю. Обычно есть более эфективные решения, чем использование связаных списков. Выигрывая в скорости обновления ты безнадежно проигрываешь во все остальных скоростных корактеристиках. Это GC в .Net и Яве еще картину сглаживает. С обычными хипами связанные списки — это натуральное вредительство. :)
VD>>Я же говорю... менталитет у нас с тобой разный. Я привык писать на языке, а колекции воспринимаю как библитечную реализацию некоторого алгоритма. AVK>Я вобще то говорю не о языке а о платформе.
Во. И библиотеки я тоже от платформы отделяю. Завтра появятся независимая реализация коллекций и я начну использовать ее. А не появится, свою создам. Мне главное, чтобы технологических препонов не было.
AVK>Ну почему обязательно вот так вот. Я например предпочитаю чтобы 99% моих неспецифических потребностей было уже реализовано, но при этом я могу дописать сам все что мне хочется. Я многого хочу?
Ну, и что связанный список нельзя отнести к 1 проценту? К тому же функциональность его можно воспроизводить другими методами, что ты и продемонстрировал...
AVK>Для чего нужен? Конкретный пример — писал кеш объектов. Размер кеша ограничивался определенным количеством элементов. Если их становилось больше — самые старые выпихивались. Т.е. обычная очередь. Но иногда объекты удалялись принудительно и их нужно было выкинуть из очереди вне очереди (сорри за каламбурчик :). Иногда их нужно было выпихнуть из середины в начало.
Так. Во-первых, зачем в Яве или Нете кешировать объекты? Это же делается автоматически.
Во-вторых, ты проанализируй свои слова "Иногда их нужно было выпихнуть". Ключевое слово "иногда", т.е. викидывание из середины прозводится редко (это, кстати, встречается очень часто). Тут реализация на массиве будет эффективнее. Задаш капасити по больше и вперед. Кстати, если объекты одного типа (унаследованы от такового или реализуют один интерфейс), то лучше сделать список объектов именно этого типа. Это будет работать куда быстрее.
AVK>Еще пример вспомнил — при обработке XML SAX приходится где нибудь данные накапливать а затем произвольным образом часть из них выкидывать.
Так может DOM использовать. И опять же встает вопрос о частоте произвольного и обычного выкидывания.
VD>> В наших проектах на C++ очень часто необходимо работать со списками, но вот связанные списки там вообще не испльзуются (в чистом виде). Все сделано на универсальных массивах. Практика показала, что грамотный массив работает быстрее чем связанный список элементы которого занимаются через хип. AVK>Я тебе пример привел когда связаный список на порядок(!) быстрее списка на основе массивов.
Не факт. Это может быть плохая реализация. Да и пример бессмысленный. В осмысленном все может быть совсем по другому.
Надо бы сделать рукопашный линкед-лист и посмотреть на его скорость.
VD>>Да я собственно не против исходников, но намного больше мне нужна хорошая объектная модель, быстрый код, хорошая поддержка, совместимость с моими старыми ранаботками, и т.п. AVK>Я где то говорил что все вышеперечисленное не нужно?
А это уже я говорил, что перечисленное мною (по-моему) в .Net лучше. :)
VD>>А колекции если мне от них будет нужна максимальная скорость я все равно перепишу сам. AVK>Точно, на ассемблере.
На объектов вряд ли. Но если будет надо, то и так. 10 строк критического кода можно переписать и для нескольких платформ и даже для разных процессоров.
VD>> Мои реализации все равно будут выстрее, чем то что засунуто в Нэт или Яву. AVK>А я вот хочу переписывать базовые вещи очень редко. Опять многого хочу?
Так у увсе разные запросы. Ты вот видел насколько быстрее типизированная коллекция, чем универсальная? Можешь глянуть как тормозить универсальная сортировка по сравнению с типизированной... А иногда бывают места где производительность нужно... и очень. Ты вот сам хочешь ведь не именно линкед-лист, а чтобы по быстрее было. :)
VD>> Именно по этому я ечень хочу, чтобы в Нэт и Яву добавили Шаблоны как в C++. AVK>В java в 1.5 точно уже добавят.В дотнет тоже вроде слухи ходили.
Я в курсе. Для Нэта даже был не официальный релиз быты :) от MS-ресерчь. Вот только обещанного тир года ждут. :( А многие еще не понимают всего кайфа этого дела. :(
VD>> Пока же я могу писать шаблоны на MC++, делать на их основе классы для конкретных типов .Нэт и испльзовать их в Шарпе и Васике, а на Яве я как всегда приплыл. И пока что ничего не поделаешь. :( Мои ActiveX-ы никак не засунуть в Яву, а в Нэт они входят как будто для него были написаны. Переносимость же у С (обычного не ++) выше. Так что же на нем писать? AVK>Если понадобится — будешь и на нем писать.
Ну, если понадобится, то конучно. Вот только очень не хочется. Я на нем уже в свое время по писал... с меня хватит.
AVK>Я видел одну программку — так там на голом С был написан механизм реализующий ООП. А сделано это было для того чтобы работало на одной платформе на которой C++ отсутствовал. Вот такие вот пирожки с котятами.
Гы. Ты видел одну программку. Я сам такие программки писал. Только было это тогда когда достать нормальную реализацию С++ не было никакой возможности. Вот после этого я и не хочу на нем писать. С++ нуда приятнее.
AVK>Это так, не для спора, просто забавный пример извращений.
Ты нас извращенцев не тронь. :)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>>>Ну так предложи тему поинтереснее. VD>>Ну, например попробуй сравнить стэйтлес технику предлагаемую MS и стытфул-EJB и им подобную. Это будет по интереснее. AVK>В каком плане сравнить?
Желательно во все.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте VladD2, Вы писали:
VD>>То что ты называешь "стилем" является не стилем, а просто навязываемой тактикой. C++ тем и хорош, что на нем можно испльзовать любой стиль программирования и реализовывать, то что нужно программисту теми методами которые ему нравятся. AVK>Тем же он и плох. Свобода средств увы приводит к увеличению количества ошибок даже при наличии некривых рух. А уж при их отсутствии.
Согласен. MS и оставило это средство для большей гибкости. Как клей и как срество оптимизации. Естественно, что не предполагалось, что MC++ будет использоваться как основное средство разработки. Но все же, заметь! Оно есть и я (и все остальные) могут выберать.
AVK>Кстати, посмотрел недавно новые JSR и планы sun на 1.5 AVK>1) В java добавят аттрибуты AVK>2) В java добавят какое то подобие foreach AVK>3) В java добавят boxing/unboxing. Вот уж где действительно косяк полный, отсутствие out параметров перед этим просто меркнет.
В смысле, что без него не удобно?
AVK>ну плюс еще generics(темплейты), улучшенная поддержка констант и кучу еще другого. AVK>Так что таки подстегнули
Надеюсь, MS в долгу не останется и добавит generics в Шарп.
AVK>out параметры являются потенциальными источниками трудноуловимых ошибок. Это не мое ИМХО, это так разработчики говорят. Их можно эмулировать, но еще лучше так спроектировать систему чтобы надобность в них отпала.
Глупость говорят твои разработчики. Это их отсутствие приводит к тому, что компилятор не может контралировать возвращаемую память. Ты сам можешь привести пример "опастности" [out]-параметров. Самый простой пример [out]-параметра это функция. Вернее ее возвращаемое значение. Что же Сан функции не запретил?
А [in, out] то чем провенился? Не понятно...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Результаты теста зависят от очередности (из-за фрагментированности памяти). К тому же я бы задал капасити заранее. Это уменьшило бы фрагментацию.
Неа, не угадал
Это GC родимый шуткует. Миллион объектов — это много и во втором цикле запускается GC, прибивая память за предыдущим. Я поправил — теперь все харашо.
VD>Дык. А ты думал тебя тут обмануть хотели?
Да нет. Мне то не стек и не очеред, а список с возможностью выдергивания и вставки в середину чаще требуется. Это я так, для интереса накидал.
VD>А вот мой вариант твоего теста:
VD>Step 2... VD>Queue: 881 VD>Stack: 581 VD>ArrayStack: 611 VD>IntArrayStack: 60
Вполне ожидаемо.
VD>Заметь насколько быстрее IntArrayStack.
Э какой хитрый. Ты Capacity делаешь сравнимым с количеством хранимых объектов. И твой список вырождается в массив. Да еще и кастинг выкидываешь за счет хранения простых типов. Плюс отсутствуют затраты на new. Плюс используются типы by value и нет выделения памяти в куче и GC. За что тогда боролись? Увы, чаще всего надо хранить объекты и возможный максимальный размер может быть сильно больше чем среднерабочий. А если это не так — проще использовать массивы. Короче — я переделал твой класс под object и задал начальный Capacity = 1000.
было для ArrayList 516. Для переделанного под object IntArrayList 391.
Мой тест еще интересен тем, что в нем легко переставлять тесты местами. При тестах я компилировал все в релиз и пре-JIT-ил EXE-шник ngen-ом. Машина AMD1400 RAM 512.
Аналогично релиз. ngen эффекта не дает. AMD XP 1466 512 памяти.
Здравствуйте VladD2, Вы писали:
VD>>>Думаю, буджеты многих российских контро имеющих своих разработчиков (и разработки) куда скромнее. AVK>>Россия для IT технологий мягко говоря не показатель. А то что в России труд своих разработчиков может быть дешевле импортных железок, увы это так.
VD>Дык. Я... это в России живу. :shuffle: И все ее ограничения и/или радости на меня влияют. Вот IT (в смысле мужик) он тепарь буджуй, но все равно на писюках живет.
Только вот и дотнет и джава не в России и не для России разработаны. И оченивать их с этой позиции наверное не стоит.
VD>О вот ты и сам сказал ключевое слово "до определенного предела". Т.е. иногда проще софт поправить, а иногда жележку новую прикупить.
Так граничные условия существуют почти для всего. Но тенденция то.
VD>И аксиом тут никаких нет. Есть только конкретные жизненные условия. А управляемость... вещь которую измерить турудно. Я вот считаю, что управлять ПО созданого для Windows и в его духе проще, но это мое личное мнение...
Проще чем что? Стиральной машинкой вот управлять все же проще будет :)
VD>Ну, есть же заменитель.
Медленнее на порядок? Это уже не заменитель.
VD> В .Net есть почти все, что тебе нужно.
Увы нет. VD> Кое чего нет. Ну, так не трудно дописать.
Допиши мне EJB или хотя бы JDO, а? Я тебе даже денег заплачу, не очень много :)
VD> Скорости универсальной реализации хватит на 90% случаев, а в тонком месте можно всунуть свою (заточеную на конкретные условия) реализацию. Как я уже доказал это может дать значительный выигрыш производительности.
Да можно. Кто же спорит? Только вот лучше бы все же в System.Collections он был.
VD>Ну, с корбой нужно скорее сравнивать COM и CLR.
Ну CORBA это архитектура больше, COM же определяе еще и реализацию. CLR вобще ни каким местом тут не прокатывает. Далее, к COM надо добавить LDAP сервер. Да и двоичный tlb и текстовый IDL сравнивать трудно.
VD>Но оба этих дела перекрывают по областям применения CORBA.
Да, но CORBA, о это ужасное слово, многоплатформенна.
VD>>>Может сравним производительность и простоту работы с COM-ом через этот бридж и в Нете? AVK>>И что?
VD>И то, что для Явы все это будет геморой,
Так ествственно, технология то ждля нее неродная и вобщем то необязательная.
VD> а ясного пути интеграции с сервисами ОС вообще нет.
Потому как ОС то разные.
VD> Все нужно писать на С через JNI.
Не все а платформозависимую часть. Она как правило совсем небольшая.
VD> Для .Net это делается на ура даже напрямую из C# или VB.Net, а на MC++ сожно тварить все что захочешь запаковывая результат в CLR-совместимые обертки.
VD>>>К тому же ты снова уветрываешся от ответа. COM — это не Win32. Ты сравни сложность работы с Win32. AVK>>А ты сравни сложность работы скажем с so модулями? :) VD>Не понял.
Объясняю. В *nix'ах dll'ек нет, там есть so. Ну так как? Многоплатформенность java — как ее достоинство так и недостаток. Как впрочем и одноплатформенность дотнета. Я потому и говорю — для каждого проекта надо выбирать свою технологию.
VD>Я говрю за себя, когда речь идет о пристрастиях. Межплатформная переносимость — это пристрастие. Ты веришь, что это спасительная волшебная палачка, я в то что это геморой, даже на Яве или Нэте. Вот и вся разница.
Нет. Я говорю что межплатформенность иногда все же нужна. Иногда, заметь, а не почти всегда.
VD>Я тебе уже говорил, что у нас есть проект в котором 300 000 строк кода и в нем не разу не исползовлся связаный список? По этому и спрашиваю. Обычно есть более эфективные решения, чем использование связаных списков. Выигрывая в скорости обновления ты безнадежно проигрываешь во все остальных скоростных корактеристиках.
А бывает с точностью до наоборот.
VD>Ну, и что связанный список нельзя отнести к 1 проценту? К тому же функциональность его можно воспроизводить другими методами, что ты и продемонстрировал...
Вот ты привязался к списку.
VD>Так. Во-первых, зачем в Яве или Нете кешировать объекты? Это же делается автоматически.
Ну как бы объекты персистентные. VD>Во-вторых, ты проанализируй свои слова "Иногда их нужно было выпихнуть". Ключевое слово "иногда", т.е. викидывание из середины прозводится редко (это, кстати, встречается очень часто).
Не очень редко. VD> Тут реализация на массиве будет эффективнее.
С чего это? Основная работа — впихивание в начало и вытаскивание с конца. А вот это то в массиве очень медленно. Мне бы Queue подошла, но вот выкинуть из середины я там не могу.
VD> Задаш капасити по больше и вперед. Кстати, если объекты одного типа (унаследованы от такового или реализуют один интерфейс), то лучше сделать список объектов именно этого типа. Это будет работать куда быстрее.
Нет, не будет. Потому как к самим объектам обращение не происходит. Собственно кеш хранится в хештаблице, очередь используется для контроля времени жизни объектов в кеше.
AVK>>Еще пример вспомнил — при обработке XML SAX приходится где нибудь данные накапливать а затем произвольным образом часть из них выкидывать. VD>Так может DOM использовать.
Используй DOM, а документик возьми мегабайт эдак 20-30. VD>И опять же встает вопрос о частоте произвольного и обычного выкидывания.
Обычное = 0. Произвольное = 100%.
AVK>>Я тебе пример привел когда связаный список на порядок(!) быстрее списка на основе массивов. VD>Не факт. Это может быть плохая реализация. Да и пример бессмысленный. В осмысленном все может быть совсем по другому.
Ну не охота мне городить что то осмысленное. Я просто показал режим при котором это проявляется. Реально такой примерно режим и есть. Только позиция выброса каждый раз новая. Просто для этого пришлось бы еще LinkedList реализовывать.
VD>Надо бы сделать рукопашный линкед-лист и посмотреть на его скорость.
Если завтра время будет — попробую.
VD>>>Да я собственно не против исходников, но намного больше мне нужна хорошая объектная модель, быстрый код, хорошая поддержка, совместимость с моими старыми ранаботками, и т.п. AVK>>Я где то говорил что все вышеперечисленное не нужно?
VD>А это уже я говорил, что перечисленное мною (по-моему) в .Net лучше. :)
Чем поддержка java хуже? И чем тебя не устроила ее объектная модель?
VD>Так у увсе разные запросы. Ты вот видел насколько быстрее типизированная коллекция, чем универсальная?
Не типизированная а by value. Разницу чувствуешь? Ты не там съэкономил.
VD> Можешь глянуть как тормозить универсальная сортировка по сравнению с типизированной... А иногда бывают места где производительность нужно... и очень. Ты вот сам хочешь ведь не именно линкед-лист, а чтобы по быстрее было. :)
Естественно. Просто я знаю как болезненно переносят array-списки добавление и удаление в/из начала и середины.
AVK>>Если понадобится — будешь и на нем писать. VD>Ну, если понадобится, то конучно. Вот только очень не хочется. Я на нем уже в свое время по писал... с меня хватит.
Это да.
AVK>>Это так, не для спора, просто забавный пример извращений.
VD>Ты нас извращенцев не тронь. :)
Да я сам такой :)
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали:
AVK>>3) В java добавят boxing/unboxing. Вот уж где действительно косяк полный, отсутствие out параметров перед этим просто меркнет. VD>В смысле, что без него не удобно?
Не удобно это мягко сказано. В EJB к примеру по стандарту типы могут быть только объектными. Представь сколько гемороя делать boxing/unboxing int и Integer ручками. Оне конечно извращенцы и советуют делать первичные ключи символьными и длинными. Но как же это все по сравнению с int тормозит.
VD>Глупость говорят твои разработчики.
Не мои а java. Мои разработчики это мама с папой
VD>Это их отсутствие приводит к тому, что компилятор не может контралировать возвращаемую память. Ты сам можешь привести пример "опастности" [out]-параметров. Самый простой пример [out]-параметра это функция. Вернее ее возвращаемое значение. Что же Сан функции не запретил?
Функции возвращают копию в стеке. А out параметр может пройти через несколько функций. Источником ошибок может являтся примерно такой код
int outparam = 1;
Func1(outparam);
//do something with outparam
Func2(outparam);
//do something with outparam
Func3(outparam);
//do something with outparam
Func4(outparam);
Здравствуйте AndrewVK, Вы писали:
AVK>Нет, именно надоело.
И все же спор "Кластеры vs Мэйнфрэймы" ты проиграл.
AVK>Я сказал что дотнет еще сыроват и привел списочек чего лично мне в нем не хватает.
Из всего этого отсутствует один линкед-лист. стэйтфул EJB-ей не будет по принципиальным причинам. Ну а обычные EJB ничем не отличаются от любого объекта .Net.
Что такое JAAS я не знаю.
AVK>Это пример. Причем не единственный. Еще раз кину списочек
Ну, давай по пунтам.
AVK>1) LinkedList
Эмулируется... ну, ты сам знаешь чем. Если что пишится за двадцать мину.
AVK>2) RandomAccessFile
В Нэт файлы читаются через стримы у которых есть метод Seek. Или ты имеещь в виду нечто иное?
AVK>3) MemoryMappedFile
Не имеет смысла, так как в предалах лотальной машины все данны всегда передаются через мапленную память, а с точки зрения файла это всего лишь метод доступа. Возможно обычный файловый доступ реализован через него. Так что это лишнее выпячивание алгортмов. В конце концов если уж пойти на принцип, в Нэт можно за пять минут описать функции работы с мапнутыми файлами ОС и испльзовать их.
AVK>Из API AVK>1) JDO
Не уверен что правильно понимаю, что это. Поясни, плиз.
AVK>2) EJB
Стыйтфул-объекты, т.е. эмуляция ДБ на объектах Явы в нете скорее вего не появится. Из-за того, что это не производительно и кривовато. Возможно подобные технологии будут встроены в SQL-Сервер. В .Net есть так называемый типизированный набор данных который выполняет похожие функции. В любом случае ставка делается на отключенные наборы данных которые могут сериализоваться в XML и пердаваться на другие серверы и клиентам. По сути другое решение того же самого.
Обычные EJB ничем не отличаются от любого объекта .Нэт.
AVK>3) JAAS.
Что это?
AVK>А стейтфул для EJB это побочная особенность. Да и сравнивать с WS глупо — EJB это намного больше. Аналог WS в java это RMI. Хотя в java и WS есть.
RMI — частная технология Сана. Большинство производителей делают ставку на CORBA/IIOP. И, по-моему, правильно делают. Если убрать "побочную особенность", то найти отилчий между любым объектом .Нэта и EJB я лично не смогу.
AVK>Ну так это не есть его уникальная особенность. К примеру свинг куда стройнее Windows.Forms.
Это же куда? Ты бы еще сказал быстрее. Убогость Свинга просто раздражает. И какая бы модель у него не была, пользоваться интерфейсами сделанными на Свинге просто не удобно.
AVK>Во, кстати, еще вспомнил — почему в этих самых формсах нет обычного грида, без всяких там Data? Тоже ручками писать надо?
А чем тебя дата не устраивает? К тому же ты здесь вообще смотришь не верно. У мс своих гридов от родясь не было. Они все делались разными Шариданами и в лайт-версии клались в VB. Если тебе нужен грид посмотри дополнительные компоненты. По стравнению с ними все что делается для Явы (да и для дельфи) просто детски лепет. Ко всему прочему, в .Net можно использовать ActiveX-ы.
VD>>Ну, это уже зависит от реализации. Будет время можно будет поэкспериментировать. AVK>Так LinkedList и ArrayList только реализацией и отличаются. Впрочем, сколько не экспериментируй — отставание на порядок ты не исправишь.
Думаю, если массивы писали бы мы, то реализация на массивах обгоняла бы линкед-листовую.
VD>>Ну, это как бы из критики вытекает. AVK>Не надо пожалуйста за меня говорить. Ничего такого из моей критики не вытекает
Тем не менее ощущение создаетсяю.
VD>> Чувствуется, что ты на этот продукт обижен, что ли... AVK>Не правильно чувствуется. Если говорить о моих чувствах то дотнет мне нравится. На данный момент главное от него ощущение — это как пересесть со спортивной машины(java) на шикарный представительский мерс(дотнет). Аналогия понятна?
Понятна. Но спортивная машина... это не совсе корректно. Нэт в большинстве вслучаев все же быстрее, т.е. сам компилятор оптимальнее и есть средства явной оптимизации. Те же value-типы, дают мощьную экономию ресурсов и повышают скорость. Вот бы к ним еще десрукторы приделали.
VD>>Да из разговора видно, что работаешь... только вот это и странно, что вроде с выбором ты уже определился (или я ошибаюсь) но продолжаешь копать схожую технологию... AVK>То есть? Ты всерьез считаешь что я один раз определяюсь и затем пользуюсь только выбранной технологией? Это не так — технологию я выбираю для каждого проекта. В другом треде я кстати писал о совместном использовании java и .Net
Ну, метания это тоже не здрово.
VD>> причем делаешь это заранее предвзято. AVK>Нет, это твои личные впечатления.
Ну, может быть.
VD>> Я тоже могу много плохого про Нэт сказать. AVK>Но будешь молчать? Это ли не предвзятое отношение?
А ты погляди остальные темы.
AVK>Я ведь и плохие моменты java тоже отмечаю.
А я вот этого ни разу не заметил. Ткни носом, плиз.
VD>> Но общее впечатление положительное. AVK>У меня тоже.
Ну, тогда того... по тише налетай. А то у мегя впечатление создалось, что ты не нашол пимпочки и давай крыть всю платформу...
VD>> Думаю, если они в следующей версии прикрутят шаблоны в C# и повысят производительность компилятора, то будет просто замечательно AVK>Да много чего еще дорабатывать надо. А на производительность компилятора мне честно говоря на*№ать. В С# incremental compiling есть, а в условиях отсутствия хидеров работает он просто идеально.
Я имел в виду производительность получаемого кода. У меня AMD 1400 я тормозов не замечаю.
VD>> (вот еще бы вернули возможность создавать деструкторы для value-типов ...). AVK>А нафига? Эти типы — нечто вроде объектных заменителей ... ну скажем record в паскале. Т.е. сложных типов данных. А деструкторы им как бы не к чему.
А шоб можно было создавть смарт-поинтеры в стеке. Для контроля внешних ресурсов... Накладных расходов ноль, а кайфа...
AVK>Ну а отсутствие деструкторов у классов — да мешает. Но это цена которую приходится платить за GC и отложеное удаление.
Мешает конучно, но тут я хотя бы понимаю, что если они появятся, то вся идея GC пойдет на смпрку, а в стеке их вызов ничего стоить не будет.
Хотя, отложенные деструкторы все же есть, только от них никакого толку.
VD>>Не, ну, нормально. Может этот спор я начал? AVK>Может я?
А кто же?
VD>> Я бы вот на 1С точно ничего делать не стал. AVK>И опять у тебя все черно-белое. Сколько времени тебе понадобится чтобы написать на дотнете простенький складской учет?
На, Нэте не знаю, а на VB в свое время ушло два с половиной месяца и не на простенький, а на очень даже ядреный. Если же все мои планы воплотятся в жизнь, то системы автматизации можно будет собирать прямо у заказчика.
AVK>И сколько это будет денег стоить? Для маленьких предприятий 1С в России на данный момент лучше всего.
Я бы уж лучше какой-нить Бэст выбрал. Ну, мозгов в этом 1С нуту. Про производительность лучше вообще молчать.
AVK> Платишь сотню баксов и получаешь весьма приличный складской и бухгалтерский учет + бесплатные обновления в соответствии с весьма продуктивной деятельностью наших законодателей и чиновников.
Я тебе штук десять продуктов за туже цену могу подобрат. Разве что конструктров среди них не будет.
VD>> утопичны или настолько слабо реализованы, что меня не устраивает. AVK>Таки на java очень много успешных проектов, больше чем на дотнет.
Еще бы Яве 6 лет, а Нэт вышел тлько месяц назад. Через два гда посмотрим. Думаю, не нете будет значительно больше. К тому же Нэт можно встраивать в уже существующие приложения.
Ну, и ко всему эти успешные обычно не используют всех наворотов. С базами работают через JDBC и т.п.
AVK>Так что не так уж и утопично. Вобще — о вкусе устриц можно спорить только с тем кто их ел.
Да. Наверно ты прав. Вот я видел порядка 600 коммерческих приложений для автоматизации бизнеса и не одно из них не было написано на Яве. А судя по воплям Сана они все давно должны быть переписаны на Яве.
VD>> И главное, что я не вижу как я могу реализовать свои идеи и удовлетворить свои потребности средствами этой платформы. AVK>Ну так рассказывай про свои потребности.
Ну, вот есть код на С++ (пордка 350 000 строк) и на VB (~10 000). Причем исползуются технологии COM, DCOM, COM+, WSH, ActiveX... Как мне все это перевести на Яву, и что мне это даст. Если даже переписанный с нуля код будет работать медленнее?
VD>> Мне ведь нужно соблюдать генеральную линию партии. AVK>А кому нужно?
Так ты сам говорил, чтобы использовать Яву нужно придерживаться определенной стратегии...
VD>> Нэт тоже предлагает свои решения но тут (если они меня не устраивают) я вижу как реализовать, то что мне нужно. AVK>А что тебе нужно?
А то чтобы все моих сегодняшние наработки не превратились в прах. И чтобы я мог делать то, что хочу, а не то что получается.
VD>> Короче, каждому свое. Я (пока) выбрал Нэт. AVK>Для чего?
и на нашем сайте www.optim.ru (но там сей час машина барахлит).
VD>>Можно выбирать язык для разработки конкретного проекта на конкретной платформе, но когда речь идет о выборе платформы (а Ява и нет несомненно платформы), то выбрать нечто для конкретного случая очень тяжело. AVK>Есть специальные люди для которых подобные задачи — один из основных вопросов профессиональной деятельности. И ценятся такие люди намного больше обычных программистов.
Дык. Это... я и есть тот кому выбирать приходится. Видишь... вот программисты рядом программируют, а я с тобой информацию обработываю.
VD>> Большинство людей сделают выбор один раз. И я их понимаю. Именно на смену платформы уходят немереные деньги. AVK>Зачем на смену? Уж коли ты начал делать проект на какой то платформе — потом менять поздно. А вот начиная новый проект можно и нужно рассмотреть вопрос выбора платформы, с учетом не только чисто технологических факторов. Я конечно понимаю — для программиста куда проще выбрать одну платформу и всю жизнь на ней писать. Но увы — так не получится. Выбрал бы ты к примеру в свое время весьма передовой FoxPro.
Ты знаешь в свое время я и выберал между Фоксом SQL-технологиями (тогда мало у нас распространенными) ... и выбрал последнее, о чем до сих пор не желею.
Если у тебя прокты пеняются по разу в год, то тебе так можно. Я вот 7 лет иду к одной идее. И на следующие 5 работы найдется, а технологии приходтя и уходят. Если я нучну прыгать выбрасывая все наработки, то вообще ничего не сделаю.
AVK>Если не переучиваться — кому сейчас нужен такой специалист? Так что учиться и переучиваться придется, причем всю жизнь.
Да я и не спорю с этим, но переучиваться и переделывать все с нуля это две большие разнецы.
VD>> Что же мне молчать? Если бы ты начал Яву не по делу гасить, я бы тоже встрял. Конечно с меньшим энтузиазмом и знанием дела, но встрял бы. AVK>И никого не гашу.
Так я от тебя Яву и не защищаю.
AVK>Увы, на данном этапе развития дотнета в России почти любой вопрос проще расковырять самому. Специалистов практически нет.
Ну, кое что можно и в росии раскопать. Вот на нашем сойте и на дотсайте на многие вопросы можно найти ответы. Да и янковские форумы не от кого не зкрыты.
AVK>Странно ты как то воспринимаешь. Вот собственно фраза(не твоя) которая мне не понравилась IT>>Ну так вот прямо в двух словах вряд ли расскажешь. Если её с чем-то и можно сравнить, то скорее всего с Java. Но это естественно больше чем Java. AVK>А теперь твои фразы VD>>Если .Net станет перенасима хотя бы в серверном варианте, т.е. без клиентского интерфейса (WinForms), то у Явы пропадет последний фиговый листок, но тем кто выбрал .Net это будет по фигу.
Ну, и все не состыкока? .Net — это действительно больше чем Ява, а его переносимость отымет козырную карту критиков. Что не так то?
VD>>по сравнению с документацией от той же Явы MSDN — это рай.(MSDN имелся ввиду)
AVK>А вот где я кого то обвинял? До сих пор пытаюсь доказать что не все так однозначно. И ничего более. Все остальное — домыслы.
Т.е. ты не говорил, что MSDN бяка?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте DarkGray, Вы писали:
VD>>Заметь насколько быстрее IntArrayStack. Мой тест еще интересен тем, что в нем легко переставлять тесты местами. При тестах я компилировал все в релиз и пре-JIT-ил EXE-шник ngen-ом. Машина AMD1400 RAM 512.
DG>Не корректно сравнивать IntArrayStack с остальными, т.к. для IntArrayStack не вызывается функция new object() для каждой итерации
Это что же такого не корректного? Хотя да. Чтобы это сравнение было корректно в object нужно еще и занчение i запихать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте AndrewVK, Вы писали:
VD>>Что доказать? То что ленив? AVK>Нет, то что дотнет сыроват.
Ну, это по большому счету и так всем понятно. Только сырость эта не так уж и велика.
AVK>Ты вот пузырьковой сортировкой пользуешся? Это из той же оперы.
Пузырек на больших объемах не на пордок медленнее. Он в квадрат лезет. А тут линейная зависимость. Хотя в критичном месте я бы это терпеть не стал бы.
VD>> но времени выполнения того же теста, на том же железе не приводишь. AVK>Как же так — я же привел. Плохо смотрел?
Ну, в том момент я этого постинга еще не видел.
AVK>Пятый раз говорю — плевать мне на LinkedList, я его в качестве примера привел. Я нигде не говорил что именно без него я жить не могу. Это ПРИМЕР, понимаешь?
Ну, дык для полноты картины еще бы нашел, а то пляшем все от листа...
VD>>Ну, что же значит он лучше спроектирован. AVK>А тест мой раз в сто наверное меньше чем местный форум. Наверное еще лучше спроектирован?
Задачи он решает совсем маленькие, а форум нет. Ну, а спроектирован он на на пятерочку. Я его малость подправил, а то менять местами трудно... ;)
VD>> Так что если у тебя делается очень много действий, не факт что они все необходимы. По объему информации наши постинги явно перекрывают среднюю накладную. :) AVK>Нет.
Да у тебя не накладные, а какие-то досье. :))
AVK>Да нельзя подобные задачи сравнивать. Я тебе потому и привел размер кода одной только проводки чтобы показать что форум и КИС абсолютно несравниваемы.
Так в чем принципиальная разница? И там и там OLTP, и там и там накопление промежуточных результатов и структурезация данных. Да форум не самый сложный код. Но тревиальным его тоже не назавешь. Зато он держит 1000 посетителей в день котрые создают море соощений.
AVK>Переделки — да. Но не перепроектирование основ.
Я тебе сказал, что систему спроектированную для малого придпиятия нельзя смаштабировть на большое только переносом на новые аппаратные средства. Ты мне начал возражать... Я тебе сказал, что если вдруг случится нечто похожее на золушку и маленькая пекарня превратится в хребозавад, то систему все равно перепроектировать (или покупать нувую), но в жизни такого не бывает. В жизни эволиюция...
VD>> и то что систему рассчитанную на малое предприятие нельзя перенести на большое (при внезапном чдо-росте) путем копирования Явоского кода с одной машины на другую. Так что переносимость для внутрифирменных проектов нужна редко. AVK>Зато можно еще на год-другой отложить безвременную кончину и этим съэкономить денежек. Впрочем опять мы в какой то оффтопик скатываемся. Давай завязывать на эту тему.
С тем же успехом можно перенести систему на кластер. Все одно главное будет параллелизм выполнения операций. Или твой 48-процессорный Сан бдет работать медленнее чем писюк за 400 баксов.
AVK>Да не хочу я пиписьками меряться. Просто судя по твоим словам основной опыт у тебя в веб-проектах.
Не поверишь, за все время сделал один сайт и 12 лет занимался автоматизацией предприятий. Начинал с продажи и внедрения чужих систем...
AVK> И переносить его на КИС не стоит. Но если ты занимался именно КИС — расскажи поподробнее, если конечно не тайна. Всегда полезно обменяться опытом.
Не, тайна сейчас мы работаем над универсальным учетным ядром. К сожалению наш сайт лежит и ссылки дать не могу. На слудующей неделе заменим машину у провайдера дам ссылку сам посмотришь.
AVK>Знаешь, я на тему серверов не хочу спорить. Давай все же ближе к дотнету. Я специально на остальное не отвечаю, ибо не интересно это никому здесь.
Ну, не хочешь так не хочешь, но про то что не интересно — это ты зблуждаешся.
VD>>GC – это часть CLR. AVK>GC — это технология прежде всего.
Это понятно, но в .Net она является частью CLR, а .Net? это как сказал IT, больше чем... Ну, и уж тем более больше чем CLR.
VD>> CLR – надстройка позволяющая создавать переносимые между языками бинарные компоненты, AVK>Наврал я немножко. Не CLR я имел ввиду а MSIL и VM для его выполнения
О это две большие разницы. Вот MC++ может создавать код на MSIL выполняемый VM (вернее он не выплняется, а Джитится или даже Преджитится), но при этом может вообще не использовать CLR, т.е. ни GC, ни комон-типов, ...
VD>>SOAP – протокол удаленных вызовов через http и XML. AVK>html здесь лишний.
Не, именно по http.
AVK>Да я же не говорю что применить нельзя. Просто MSIL, CG, далее по списку для драйверов — ну примерно как для собаки пятая нога.
CG да, но MSIL спокйно будет работать. А про собак... тебе хуже будет если драйвер будет компилироваться именно для твоего процессора, прямо при установке в систему? Но до этого еще далеко.
VD>> В Яве этот слой отсутствует как класс. И именно это (не драйверы, а открывающиеся возможности) меня и подкупает. Ты уже заметил, что не универсальный код написанный на .Net работает быстрее. AVK>Это я заметил с самого начала. И памяти кстати заметно меньше кушает.
Мои экспременты показывают обратное. Скачай примеры от шустрика посмотри. Ява жрет не меньше, да и родной код полглащает не моло.
AVK>>>А за других я бы на твоем месте не стал говорить. VD>>Ты можешь привести конкретное место где я это делал? AVK>Поскипал ты зря. "А вто я, IT и MS думаем по другому." — твои слова?
Ну, и где я за других говорил. Я цитирую их точку зрения. IT прямо в этом постинге тебе это сказал, а MS во всех пресрелизах.
VD>>Так и мне не кажется. Но моих рассуждений, это не отрицает. Хотел бы я посмотреть, что бы ты сказал если .Net ты увидел бы раньше Явы? Думаю твое отношение был бы совершенно иным. AVK>Вряд ли. Технологии я стараюсь оценивать объективно. Кстати после java очень легко воспринимаются многие дотнетовские фишки.
Вот и было бы объективно, но искл бы бяки ты в Яве. И не сомневаюсь, что нашол бы. :)
AVK>1906 AVK>172 AVK>(напомню старые AVK>1547 AVK>156) AVK>Вот такие вот пирожки с котятами. До этого я еще кое что с ngen и без мерял — эффект был = 0 (на 2 бете еще). А теперь вобще все грустно :( Хотя я догадываюсь почему такой эффект.
Странные у тебя результаты. У меря процентов 10 выигрышь. Что за щелезка?
VD>>Зато я заною как при том же алгоритме увеличить скорость еще на порядок. Нужно просто заменить object на int (родной тип). AVK>Э нет — так низзя. Нафига мне int хранить? Мне объекты хранить нужно. Впрочем опять же — никаких проблем попробовать.
В одном случае объекты, а в другом int придется. Да и объекты в родных типах должны работать быстрее.
AVK>1890 AVK>172 AVK>То есть эффект = 0. Догадываешся почему?
А ты замени object на реальный тип объекта. И к тому, же в слудующий раз тебе может понадобится int, а через object он будет в 10 раз медленнее.
VD>> Вот CLR и Ява тем и плохи, что полиморфность в них достигается за счет использования виртуальных методов и типа object. На C++ я бы написал шаблон и он бы дал лучшую производительность. AVK>Вот о чем я и говорю — лучше пожертвовать производительностью в угоду удобству и надежности.
Ну, и в сем же здесь пропадут надежность или удобство?
Шаблоны контролируют типы во время компиляции, а виртуальные методы и object делают рантайм-проверки. На лицо одни недостатки. И вдобства не пропадают. Ну в скобках прийдется тип указать.
AVK> Ибо железки ныне дешевеют а труд программеров дорожает.
Во блин. Снова за свое. То ему просадка на порядок из-за отсутсвия листа мешает, то он плюет на тот же порядок в том же случе. Ты подумай, если сложить тот порядок с этим то получится уже сотня.
AVK>Это тенденция однако. Хотя я хорошо помню времена XT-шек когда основной ресурс был — время процессора и приходилось писать большие куски на ассемблере чтобы получить, нет, не большУю, просто приемлемую производительность.
Так времена не изменились изменились задачи. У меня всегда программы работали на пределе железа, если появлялось новое железо, то для него сразу же поялялись новые задачи. Именно по этому я понимаю твое стремление найти более производительный способ работы с данными, и именно по этому не понимаю рассуждений про железки.
AVK>Но в отличие от некоторых об этих временах совсем не жалею. Я не тебя имею ввиду, просто достал треп что мол программисты программы писать разучились. Сами что такое ассемблер представляют по книжкам и примерчикам — зато с апломбом доказывают что мол если бы не MS все программы были бы написаны на ассемблере, в крайнем случае на голом С, занимали бы 20-30Кб и работали бы со свистом на трешках.
Да это знакомо. И самое смешное, что такие рассуждения я слышал от известных и уважаемых людей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте VladD2, Вы писали:
VD>>Стек действительно несколько быстрее. AVK>Который?
Родной. .Net-овски. Да возьми мой вариант и по переставляй местами функции... сам все увидишь.
VD>> К тому же можно задать капасити, чтобы не фрагментировать память. AVK>Кому? Я честно говоря не понял. Stack или ArrayStack?
Всем. В моем варианте для всех задан капасити (в конструкторе) несколько превышающий количество итераций.
Кстати, очередь, похоже тоже сделана на массиве. Иначе бы у нее не было бы капасити, не нужен такой параметр для связанных списков. Видимо делают змейку...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте VladD2, Вы писали:
VD>>Результаты теста зависят от очередности (из-за фрагментированности памяти). К тому же я бы задал капасити заранее. Это уменьшило бы фрагментацию. AVK>Неа, не угадал AVK>Это GC родимый шуткует. Миллион объектов — это много и во втором цикле запускается GC, прибивая память за предыдущим. Я поправил — теперь все харашо.
Ну, тогжа запусти мой вариант посмотри на результаты...
VD>>Заметь насколько быстрее IntArrayStack. AVK>Э какой хитрый. Ты Capacity делаешь сравнимым с количеством хранимых объектов. И твой список вырождается в массив.
Так он у всех такой. Думаю, если уменьшить его, то все равно расклад отстанется прежним.
AVK>Да еще и кастинг выкидываешь за счет хранения простых типов.
Ну, а ты что же хочешь чтобы производительность из воздуха бралась? Тебе этот кастинг нужен? Мне нет. На С++ только так все и работают. И скорось на уровне, и ошибок с кастингами меньше.
AVK> Плюс отсутствуют затраты на new.
Ну? Вот и подумай на фига козе баян. Зачем нюь для int? А это ведь самый распространенный тип...
AVK>Плюс используются типы by value и нет выделения памяти в куче и GC.
Ну? Так того и добивались, а с обжектом ты плучаешь весь этот кайф, а он ведь тебе не нужен.
AVK> За что тогда боролись?
Так за типобезопастность и производительность!
AVK> Увы, чаще всего надо хранить объекты и возможный максимальный размер может быть сильно больше чем среднерабочий.
Ну, при неаравильном приектировании конечно. А при правильном лучше хранить структуры или простые типы. В общем и целом, чем мешьше памяти в куче выделяется, тем лучше. GC это правило ослобляет, но не снимае. В сложных случаях GC проигрывает обычной куче.
AVK>А если это не так — проще использовать массивы. Короче — я переделал твой класс под object и задал начальный Capacity = 1000. AVK>было для ArrayList 516. Для переделанного под object IntArrayList 391.
Видишь даже с совершенно не производительным хранением информации мой вариант быстрее. Но ведь основной расчет тут делался на отбрасывание нунужных полиморфностей.
AVK>Аналогично релиз. ngen эффекта не дает. AMD XP 1466 512 памяти.
Странно. Похоже у меня маина более слабая, но результаты лучше. И нген эфект дает. У меня вот сервис-пака нет. Может это как влияет?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Только вот и дотнет и джава не в России и не для России разработаны. И оченивать их с этой позиции наверное не стоит.
Ну,я где живу. там и оцениваю. :) Ну, а про то, что IT в Америке обитает, ты надеюсь понял. Ты то сам вроде тоже в России обитаешь...
AVK>Так граничные условия существуют почти для всего. Но тенденция то.
Да нет никакой тенденции. Хороший софт работает на грани возможного и выжимает из железа все, что моежт, а плохой всехда называли тормозным. Так его и бдут называть...
VD>>И аксиом тут никаких нет. Есть только конкретные жизненные условия. А управляемость... вещь которую измерить турудно. Я вот считаю, что управлять ПО созданого для Windows и в его духе проще, но это мое личное мнение... AVK>Проще чем что? Стиральной машинкой вот управлять все же проще будет :)
Проще чем софт который создается для других платформ и тем более чем софт создающийся как переносимый и/или масштабируемый.
VD>>Ну, есть же заменитель. AVK>Медленнее на порядок? Это уже не заменитель.
Ну, тебе показал, что технологии абстракции данных в CLR и Яве тоже медленнее на порядок, но ты же из-за этого не откажешься от них?
Причем, в твоем случае нужно протянуть руку и написать свою реализацию, а вот полиморфизм через object & виртуальные методы — это приговор (пока не появятся шаблоны).
VD>> Кое чего нет. Ну, так не трудно дописать. AVK>Допиши мне EJB или хотя бы JDO, а? Я тебе даже денег заплачу, не очень много :)
Я тебе уже говорил, что есть прекрасные заменители EJB.
VD>> Скорости универсальной реализации хватит на 90% случаев, а в тонком месте можно всунуть свою (заточеную на конкретные условия) реализацию. Как я уже доказал это может дать значительный выигрыш производительности. AVK>Да можно. Кто же спорит? Только вот лучше бы все же в System.Collections он был.
Добавь. ;)
VD>>Ну, с корбой нужно скорее сравнивать COM и CLR. AVK>Ну CORBA это архитектура больше,
Не... спецификация. :)))
AVK>COM же определяе еще и реализацию. CLR вобще ни каким местом тут не прокатывает.
Это почему? Компонетная модель позволяющая создавать серверы приложений, динамически загружаемые компоненты и элементы управления. Позвоялет создавать и использовть омпоненты на разных языках, т.е. это больше чем COM и больше чем CORBA.
AVK>Далее, к COM надо добавить LDAP сервер.
Это еще зачем?
AVK>Да и двоичный tlb и текстовый IDL сравнивать трудно.
А зачем их сравнивать. Вон в нет эту идею еще дальше расширели. А маньяки от корбы до сих пор кричат, что видте ли это не гибко. Это биче гибкого. Просто один раз нужно разобраться. Сгенерить IDL по tlb или создать файл C# или VB.Net по сборке проще просого. А вот то, что в CORBA-е до сих пор нет объектной модели — это явный минус. В конце концов CORBA-а все равно приобретет многие четры COM-а. И я ничего плохого в этом не вижу. Как и в том, что Ява возьмет черты Шарпа.
VD>>Но оба этих дела перекрывают по областям применения CORBA. AVK>Да, но CORBA, о это ужасное слово, многоплатформенна.
Да, и DCOM многоплатформный. Просто все кому этого не хочется об этом и не знают. Ну, правда денег стоит, но и CORBA стоит. Вот только большинству людей COM не нужен не других платформах, да и корба тоже...
VD>>>>Может сравним производительность и простоту работы с COM-ом через этот бридж и в Нете? AVK>>>И что?
И выйдет, что в Нэт это продуманно и легко, а в Яве не очень, то.
VD>>И то, что для Явы все это будет геморой, AVK>Так ествственно, технология то ждля нее неродная и вобщем то необязательная.
Ана для меня обязательная и для многих тысяч программистов.
VD>> а ясного пути интеграции с сервисами ОС вообще нет. AVK>Потому как ОС то разные.
А мне пофигу. На любой ОС есть аналог DLL и сам разберусь, что мне в них нужно. Просто дайте мне спокойно делать, то что я хочу, а не то что получается.
VD>> Все нужно писать на С через JNI. AVK>Не все а платформозависимую часть. Она как правило совсем небольшая.
Она как правило есть. И как правило выливается в гемморой.
VD>>Не понял. AVK>Объясняю. В *nix'ах dll'ек нет, там есть so.
Ну, и что? А это знаю. Что мешает мне использовать на Линуксе одно, а на Виндузе другое?
AVK> Ну так как? Многоплатформенность java — как ее достоинство так и недостаток. Как впрочем и одноплатформенность дотнета. Я потому и говорю — для каждого проекта надо выбирать свою технологию.
Думаю, что MS обязатеьно сделает показательную портацию .Net на какой нибудь Mac OS 10. :) Про Моно ты надеюсь уже слышал?
VD>>Я тебе уже говорил, что у нас есть проект в котором 300 000 строк кода и в нем не разу не исползовлся связаный список? По этому и спрашиваю. Обычно есть более эфективные решения, чем использование связаных списков. Выигрывая в скорости обновления ты безнадежно проигрываешь во все остальных скоростных корактеристиках. AVK>А бывает с точностью до наоборот.
У кого? У нас небыло... Не, ну, в жизни все бывает...
VD>>Так. Во-первых, зачем в Яве или Нете кешировать объекты? Это же делается автоматически. AVK>Ну как бы объекты персистентные.
А! Замечательная технолгия... для загрузки процессора и свободной памяти. Вот только тебе пожалуй нужно не кэш, а пул создавать. Проще читать данные и ассоциировать их с инстансами. К тому же объекты ининтифицируются по ID, а их нужно не в связанных списках ранить, а в map-ах.
VD>>Во-вторых, ты проанализируй свои слова "Иногда их нужно было выпихнуть". Ключевое слово "иногда", т.е. викидывание из середины прозводится редко (это, кстати, встречается очень часто). AVK>Не очень редко.
Да ну тебя. Тогда пиши: "Объекты постоянно выпихиваются и иногда...".
VD>> Тут реализация на массиве будет эффективнее. AVK>С чего это? Основная работа — впихивание в начало и вытаскивание с конца. А вот это то в массиве очень медленно. Мне бы Queue подошла, но вот выкинуть из середины я там не могу.
А Queue в Нэте тоже на массиве сделана. Представь себе змейку... вытаскиваешь элемент с конца... указатель на голову сдвигается вперед, а на его метсо можно будет поместить хвост (при добавлении новгог элемента). Если места не хватает (хвост наезжает на голову), массив расширяется, если хватает, то протсо бегаем по кругу...
VD>> Задаш капасити по больше и вперед. Кстати, если объекты одного типа (унаследованы от такового или реализуют один интерфейс), то лучше сделать список объектов именно этого типа. Это будет работать куда быстрее. AVK>Нет, не будет. Потому как к самим объектам обращение не происходит. Собственно кеш хранится в хештаблице, очередь используется для контроля времени жизни объектов в кеше.
Я уже говорил, что очередь (в отличии от связанного списка) реализуется на массиве без потерь производительности? :) А ускорение будет хотя бы из-за того, что вместо object будет храниться менее абстрактная ссылка, меньшего размера.
VD>>Так может DOM использовать. AVK>Используй DOM, а документик возьми мегабайт эдак 20-30.
Ну, 30 это уже не документик, а база данных и довельно не маленькая. Прайс книжного магазина (Интернетного) занимает 12 мег. Да и выдержит он в лет. 30 мег для современного компьютера это фантики, ну а делее нужно переходить на БД.
VD>>И опять же встает вопрос о частоте произвольного и обычного выкидывания. AVK>Обычное = 0. Произвольное = 100%.
ТAVK>Чем поддержка java хуже?
Да тем, что книг по Яве и Нэту на русском примеро онинаковое количество, а Нэту всего месяц. Тем, что по нету создано сотни форумов за это время. Тем, что документация первой версии Нэта удобнее и понятнее, чем n-ной Явы. Тем, что вместо зачастую пустого ЯваДок, а имею MSDN и возможность качественного поиска по нему.
ТAVK>И чем тебя не устроила ее объектная модель?
Ну, ты посмотри CodeDom, Emit, дезайнеры типов, броузер свойств, да и сами свойства которые есть в EJB, но нет в самой Яве, и т.п. И покажи аналоги в Яве. А то может я просто чего не знаю?
VD>>Так у увсе разные запросы. Ты вот видел насколько быстрее типизированная коллекция, чем универсальная? AVK>Не типизированная а by value. Разницу чувствуешь? Ты не там съэкономил.
Не, не чувствую. Я разницу в скорости чувствую. Мне 4 байта хранить нужно. Из солидарности с апологетами плиморфизма я этого делать не намерен.
VD>> Можешь глянуть как тормозить универсальная сортировка по сравнению с типизированной... А иногда бывают места где производительность нужно... и очень. Ты вот сам хочешь ведь не именно линкед-лист, а чтобы по быстрее было. :) AVK>Естественно. Просто я знаю как болезненно переносят array-списки добавление и удаление в/из начала и середины.
Это как спроектируешь. У нас есть масмив который спокойно переносит. Он по кластерному принципу построен. А удаление из конца массивы (динамические) всегда переносят легко.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Функции возвращают копию в стеке. А out параметр может пройти через несколько функций. Источником ошибок может являтся примерно такой код AVK>
AVK>int outparam = 1;
AVK>Func1(outparam);
AVK>//do something with outparam
AVK>Func2(outparam);
AVK>//do something with outparam
AVK>Func3(outparam);
AVK>//do something with outparam
AVK>Func4(outparam);
AVK>
Ну, и в чем проблема? Кстати в шарпе он бы виглыдел так%
int outparam = 1;
Func1(out outparam);
//do something with outparam
Func2(out outparam);
//do something with outparam
Func3(out outparam);
//do something with outparam
Func4(out outparam);
Т.е. явное указанеи out.
А эквивалентно это этому:
int outparam = 1;
outparam = Func1();
//do something with outparam
outparam = Func2();
//do something with outparam
outparam = Func3();
//do something with outparam
outparam = Func4();
В чем опасность не понятно!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте VladD2, Вы писали:
AVK>>Пятый раз говорю — плевать мне на LinkedList, я его в качестве примера привел. Я нигде не говорил что именно без него я жить не могу. Это ПРИМЕР, понимаешь? VD>Ну, дык для полноты картины еще бы нашел, а то пляшем все от листа...
Мне третий раз сюда один и тот же списочек писать?
VD>>>Ну, что же значит он лучше спроектирован. AVK>>А тест мой раз в сто наверное меньше чем местный форум. Наверное еще лучше спроектирован?
VD>Задачи он решает совсем маленькие, а форум нет. Ну, а спроектирован он на на пятерочку. Я его малость подправил, а то менять местами трудно... ;)
Так и у процедуры проведения накладной тоже задачи побольше чем у форума.
AVK>>Нет. VD>Да у тебя не накладные, а какие-то досье. :))
А ты думал. Я же тебе говорю — не все так просто как кажется со стороны.
VD>Так в чем принципиальная разница? И там и там OLTP, и там и там накопление промежуточных результатов и структурезация данных.
В форуме еще и OLAP есть? Разбивка на партии? Проверка и коррекция остатков и оборотов? Контроль кредитов, договоров? Погашение долга? А там еще много чего есть.
VD> Да форум не самый сложный код. Но тревиальным его тоже не назавешь.
Так я и не говорю что он тривиальный. Но форум я могу написать скажем за недельку, не особенно напрягаясь. А вот нормальный оперативный учет уже несколько сложнее.
AVK>>Да не хочу я пиписьками меряться. Просто судя по твоим словам основной опыт у тебя в веб-проектах. VD>Не поверишь, за все время сделал один сайт и 12 лет занимался автоматизацией предприятий. Начинал с продажи и внедрения чужих систем...
Каких, если не секрет?
VD>Ну, не хочешь так не хочешь, но про то что не интересно — это ты зблуждаешся.
Ау, кому нибудь это интересно? :)
VD>>>GC – это часть CLR. AVK>>GC — это технология прежде всего. VD>Это понятно, но в .Net она является частью CLR, а .Net? это как сказал IT, больше чем... Ну, и уж тем более больше чем CLR.
Я где то говорил что это не так?
VD>>>SOAP – протокол удаленных вызовов через http и XML. AVK>>html здесь лишний. VD>Не, именно по http.
Как минимум часто еще SMTP часто используется. А вобще протокол может быть любой.
AVK>>Да я же не говорю что применить нельзя. Просто MSIL, CG, далее по списку для драйверов — ну примерно как для собаки пятая нога.
VD>CG да, но MSIL спокйно будет работать.
Будет. Но нафига он там?
VD> А про собак... тебе хуже будет если драйвер будет компилироваться именно для твоего процессора, прямо при установке в систему?
А при чем здесь MSIL? В *никсах вон так и поступают, без всякого IL. Или ты имеешь ввиду компиляцию IL в нейтив код — так увеличение производительности от этого — пока декларация как для дотнета так и для джавы.
VD>>> В Яве этот слой отсутствует как класс. И именно это (не драйверы, а открывающиеся возможности) меня и подкупает. Ты уже заметил, что не универсальный код написанный на .Net работает быстрее. AVK>>Это я заметил с самого начала. И памяти кстати заметно меньше кушает. VD>Мои экспременты показывают обратное. Скачай примеры от шустрика посмотри. Ява жрет не меньше,
Так я и говорю что больше она жрет.
VD>>>Так и мне не кажется. Но моих рассуждений, это не отрицает. Хотел бы я посмотреть, что бы ты сказал если .Net ты увидел бы раньше Явы? Думаю твое отношение был бы совершенно иным. AVK>>Вряд ли. Технологии я стараюсь оценивать объективно. Кстати после java очень легко воспринимаются многие дотнетовские фишки. VD>Вот и было бы объективно, но искл бы бяки ты в Яве. И не сомневаюсь, что нашол бы. :)
А чего их искать? Их там есть. Я тут даже упоминал некоторые. Могу еще сказать что в самом языке сильно не хватает свойств и типов-перечислений (это для меня основной недостаток именно языка).
AVK>>1906 AVK>>172 AVK>>(напомню старые AVK>>1547 AVK>>156) AVK>>Вот такие вот пирожки с котятами. До этого я еще кое что с ngen и без мерял — эффект был = 0 (на 2 бете еще). А теперь вобще все грустно :( Хотя я догадываюсь почему такой эффект.
VD>Странные у тебя результаты. У меря процентов 10 выигрышь. Что за щелезка?
Я уж вроде писал. AXP 1700+, 512 DDR
AVK>>Э нет — так низзя. Нафига мне int хранить? Мне объекты хранить нужно. Впрочем опять же — никаких проблем попробовать. VD>В одном случае объекты, а в другом int придется. Да и объекты в родных типах должны работать быстрее.
а тип object для экземпляров object не родной?
VD>А ты замени object на реальный тип объекта.
Так в тесте object как раз и есть реальный тип объекта. Ладно, небольшой примерчик
using System;
using System.Collections;
class ArrayStack {
private ArrayList al = new ArrayList();
public void Push(object obj) {
al.Add(obj);
}
public object Pop() {
object obj = al[al.Count-1];
al.RemoveAt(al.Count-1);
return obj;
}
}
public class Test {
private const int ITER_COUNT = 1000000;
public static void Main() {
ArrayStack ars = new ArrayStack();
int st = Environment.TickCount;
for(int i = 0; i < ITER_COUNT; i++) {
ars.Push(new object());
}
for(int i = 0; i < ITER_COUNT; i++) {
ars.Push(new object());
ars.Pop();
}
for(int i = 0; i < ITER_COUNT; i++) {
ars.Pop();
}
Console.WriteLine(Environment.TickCount-st);
GC.Collect();
ars = new ArrayStack();
st = Environment.TickCount;
object obj = new object();
for(int i = 0; i < ITER_COUNT; i++) {
ars.Push(obj);
}
for(int i = 0; i < ITER_COUNT; i++) {
ars.Push(obj);
ars.Pop();
}
for(int i = 0; i < ITER_COUNT; i++) {
ars.Pop();
}
Console.WriteLine(Environment.TickCount-st);
GC.Collect();
}
}
Результат
1132
480
Вот он твой эффект. А для int еще и нет конролируемых ссылок. VD>И к тому, же в слудующий раз тебе может понадобится int, а через object он будет в 10 раз медленнее.
Ну не в 10 раз — но таки да, для int можно. Только объекты все же почаще используются.
VD>>> Вот CLR и Ява тем и плохи, что полиморфность в них достигается за счет использования виртуальных методов и типа object. На C++ я бы написал шаблон и он бы дал лучшую производительность. AVK>>Вот о чем я и говорю — лучше пожертвовать производительностью в угоду удобству и надежности. VD>Ну, и в сем же здесь пропадут надежность или удобство?
В чем удобство полиморфности? В большей универсальности кода.
VD>Шаблоны контролируют типы во время компиляции, а виртуальные методы и object делают рантайм-проверки. На лицо одни недостатки. И вдобства не пропадают. Ну в скобках прийдется тип указать.
На шаблонах рефлекшн не будет работать. Но это так. А вобще использование шаблона для объектов в плане производительности ничего не даст. Шаблон просто привнесет дополнительный контроль типов.
AVK>> Ибо железки ныне дешевеют а труд программеров дорожает. VD>Во блин. Снова за свое. То ему просадка на порядок из-за отсутсвия листа мешает, то он плюет на тот же порядок в том же случе. Ты подумай, если сложить тот порядок с этим то получится уже сотня.
Не, использование связаного списка дает повышение производительности практьически бесплатно, а вот перепроектирование системы — нет.
AVK>>Это тенденция однако. Хотя я хорошо помню времена XT-шек когда основной ресурс был — время процессора и приходилось писать большие куски на ассемблере чтобы получить, нет, не большУю, просто приемлемую производительность. VD>Так времена не изменились изменились задачи. У меня всегда программы работали на пределе железа, если появлялось новое железо, то для него сразу же поялялись новые задачи. Именно по этому я понимаю твое стремление найти более производительный способ работы с данными, и именно по этому не понимаю рассуждений про железки.
А про железки это потому что мне приходится не только программить, но еще и заниматься эксплуатацией. И купить железку обычно куда как проще и дешевле нежели переписывать готовый код. Я могу конечно посадить программера, он за два-три месяца мне процентов на 10% тот же модуль перепроведения ускорит. Но за те же деньги я куплю еще один серверок и через 2-3 дня у меня все заработает быстрее на те же 10%, если не быстрее. Вот о чем я пытаюсь сказать. А то что иногда все же приходится кардинально все переделывать — да, такое тоже вполне возможно. У меня вот сейчас старый оперативный учет по одной фирме как раз полностью выкидывается, ибо проще сделать с нуля новый чем дорабатывать старый. Но он отработал 5 лет и вполне себя оправдал. А если бы я оставил старый серверок, на котором он первоначально работал — уже через 2 года мне бы пришлось думать об увеличении быстродействия. Как ты считаешь — 2 штуки, отданые за серверок за 3 года себя оправдали?
VD>Да это знакомо. И самое смешное, что такие рассуждения я слышал от известных и уважаемых людей.
Тут одно из двух — либо человек вобще нифига не понимает и говорит с чужих слов, либо его знания программных технологий так и остались десятилетней давности. Я помню как на БК-0010 приходилось байты экономить. Но это же не повод делать то же самое сейчас? Кого сейчас волнует — 400К или 4М занимает exe?
Здравствуйте VladD2, Вы писали:
AVK>>Я сказал что дотнет еще сыроват и привел списочек чего лично мне в нем не хватает.
VD>Из всего этого отсутствует один линкед-лист. стэйтфул EJB-ей не будет по принципиальным причинам.
Это что же за такие принципиальные причины? VD> Ну а обычные EJB ничем не отличаются от любого объекта .Net.
Обычные это какие? Есть четыре типа бинов
1) Stateless session
2) Stateful session
3) Entity BMP
4) Entity CMP
Только для первых аналогом может быть WS. Вторые можно на базе WS съэмулировать. А вот 3 и 4 — это уже проблема. Особенно 4.
VD>Что такое JAAS я не знаю. :(
Java Authentication and Authorization Service
AVK>>1) LinkedList VD>Эмулируется... ну, ты сам знаешь чем. Если что пишится за двадцать мину.
Не эмулируется а пишется целиком ручками
AVK>>2) RandomAccessFile VD>В Нэт файлы читаются через стримы у которых есть метод Seek. Или ты имеещь в виду нечто иное?
Ну как минимум нужно еще getLength() и setLength(). Плюс стримы оптимизированы под последовательный доступ.
AVK>>3) MemoryMappedFile VD>Не имеет смысла, так как в предалах лотальной машины все данны всегда передаются через мапленную память, а с точки зрения файла это всего лишь метод доступа.
Иногда очень удобный. Не критично но в некоторых случаях время экономит. VD> Возможно обычный файловый доступ реализован через него. Так что это лишнее выпячивание алгортмов. В конце концов если уж пойти на принцип, в Нэт можно за пять минут описать функции работы с мапнутыми файлами ОС и испльзовать их.
Можно, кто спорит. Но это уже не то.
AVK>>Из API AVK>>1) JDO VD>Не уверен что правильно понимаю, что это. Поясни, плиз.
Java Data Objects
цитата из спецификации
JDO specification provides for interface-based definitions of data stores and transactions; and selection and transformation of persistent storage data into native Java programming language objects
AVK>>2) EJB
VD>Стыйтфул-объекты, т.е. эмуляция ДБ на объектах Явы в нете скорее вего не появится. Из-за того, что это не производительно и кривовато.
По поводу производительности я уже говорил — это не самое главное. Да и подобное преобразование все равно делать приходится очень часто. Все дело в уровне абстракции и количестве ручной работы. Не устраивают CMP — есть же еще и BMP. Пиши в базу ручками наздоровье.
VD>Возможно подобные технологии будут встроены в SQL-Сервер.
Ну xml то он уже хранит. А это по сути уже почти что объекты.
VD> В .Net есть так называемый типизированный набор данных который выполняет похожие функции. В любом случае ставка делается на отключенные наборы данных которые могут сериализоваться в XML и пердаваться на другие серверы и клиентам. По сути другое решение того же самого.
Не, не тоже самое. Совсем не то.
AVK>>А стейтфул для EJB это побочная особенность. Да и сравнивать с WS глупо — EJB это намного больше. Аналог WS в java это RMI. Хотя в java и WS есть. VD>RMI — частная технология Сана. Большинство производителей делают ставку на CORBA/IIOP. И, по-моему, правильно делают. Если убрать "побочную особенность", то найти отилчий между любым объектом .Нэта и EJB я лично не смогу.
Автоматические транзакции, в т.ч. и распределенные. Умное кеширование везде где только можно. Entity бины. Меппинг объектов в базу, полуавтоматически и автоматически. EJB надо сравнивать с servviced components а не с дотнетовскими объектами.
AVK>>Ну так это не есть его уникальная особенность. К примеру свинг куда стройнее Windows.Forms. VD>Это же куда? Ты бы еще сказал быстрее. :) Убогость Свинга просто раздражает. И какая бы модель у него не была, пользоваться интерфейсами сделанными на Свинге просто не удобно.
Это тебе так кажется. По незнанию. На самом деле очень удобно. И от MVC в отличие от нета не отходит.
AVK>>Во, кстати, еще вспомнил — почему в этих самых формсах нет обычного грида, без всяких там Data? Тоже ручками писать надо?
VD>А чем тебя дата не устраивает?
Нафига мне для редактирования данных в табличке ADO.NET тащить? Это уже пушкой по воробьям получается.
VD> К тому же ты здесь вообще смотришь не верно. У мс своих гридов от родясь не было. Они все делались разными Шариданами и в лайт-версии клались в VB. Если тебе нужен грид посмотри дополнительные компоненты.
Гы. VD>По стравнению с ними все что делается для Явы (да и для дельфи) просто детски лепет.
Ты JTable видел? Особенно в 1.4. Все эти дельфовые и VB-шные гриды по сравнению с ним как раз детский лепет и есть.
VD>>>Ну, это уже зависит от реализации. Будет время можно будет поэкспериментировать. AVK>>Так LinkedList и ArrayList только реализацией и отличаются. Впрочем, сколько не экспериментируй — отставание на порядок ты не исправишь. VD>Думаю, если массивы писали бы мы, то реализация на массивах обгоняла бы линкед-листовую.
Про списки я другой топик заведу.
VD>>> Чувствуется, что ты на этот продукт обижен, что ли... AVK>>Не правильно чувствуется. Если говорить о моих чувствах то дотнет мне нравится. :) На данный момент главное от него ощущение — это как пересесть со спортивной машины(java) на шикарный представительский мерс(дотнет). Аналогия понятна?
VD>Понятна. Но спортивная машина... это не совсе корректно. Нэт в большинстве вслучаев все же быстрее, т.е. сам компилятор оптимальнее и есть средства явной оптимизации.
Не надо сравнивать. Скорость машины в моем примере это не скорость компиляции и программ а скорее надежность программирования.
AVK>>То есть? Ты всерьез считаешь что я один раз определяюсь и затем пользуюсь только выбранной технологией? Это не так — технологию я выбираю для каждого проекта. В другом треде я кстати писал о совместном использовании java и .Net VD>Ну, метания это тоже не здрово.
Кто говорит про метания. Возможность использовать наработаный опыт — один из факторов при выборе плаформы. Только он не определяющий.
AVK>>Я ведь и плохие моменты java тоже отмечаю. VD>А я вот этого ни разу не заметил. :( Ткни носом, плиз.
boxing/unboxing к примеру.
AVK>>У меня тоже. VD>Ну, тогда того... по тише налетай. А то у мегя впечатление создалось, что ты не нашол пимпочки и давай крыть всю платформу... :)
Да нет — просто хочу сказать что недостатки в дотнете есть и кое в чем он похуже java.
VD>А шоб можно было создавть смарт-поинтеры в стеке. Для контроля внешних ресурсов... Накладных расходов ноль, а кайфа...
Тогда уж лучше было бы ввести какой нибудь специальный механизм для классов, выделить их отдельно и соответственно настроить GC на работу с ними, т.е. убрать отложеное удаление, принудительно запускаться или даже реализовывать пул.
VD>>>Не, ну, нормально. Может этот спор я начал? AVK>>Может я? VD>А кто же?
Не я :)
VD>На, Нэте не знаю, а на VB в свое время ушло два с половиной месяца и не на простенький, а на очень даже ядреный.
На 1С день с нуля. Полмесяца с отладкой и внедрением.
AVK>>И сколько это будет денег стоить? Для маленьких предприятий 1С в России на данный момент лучше всего. VD>Я бы уж лучше какой-нить Бэст выбрал. Ну, мозгов в этом 1С нуту. Про производительность лучше вообще молчать.
Но таки 1С практически монополист на этом рынке.
AVK>> Платишь сотню баксов и получаешь весьма приличный складской и бухгалтерский учет + бесплатные обновления в соответствии с весьма продуктивной деятельностью наших законодателей и чиновников. VD>Я тебе штук десять продуктов за туже цену могу подобрат. Разве что конструктров среди них не будет.
Вот вот.
VD>Еще бы Яве 6 лет, а Нэт вышел тлько месяц назад. :)
2 уже. Так я о том и говорю — молодой он еще.
VD> Через два гда посмотрим. Думаю, не нете будет значительно больше. К тому же Нэт можно встраивать в уже существующие приложения.
Вот и посмотрим.
VD>>> И главное, что я не вижу как я могу реализовать свои идеи и удовлетворить свои потребности средствами этой платформы. AVK>>Ну так рассказывай про свои потребности. VD>Ну, вот есть код на С++ (пордка 350 000 строк) и на VB (~10 000). Причем исползуются технологии COM, DCOM, COM+, WSH, ActiveX... Как мне все это перевести на Яву, и что мне это даст. Если даже переписанный с нуля код будет работать медленнее?
Сам понимаешь — ActiveX это уже однозначно технологии от MS. Политика у него такая. J++ напомнить? Там ведь как раз из-за COM поцапались.
VD>>> Мне ведь нужно соблюдать генеральную линию партии. AVK>>А кому нужно? VD>Так ты сам говорил, чтобы использовать Яву нужно придерживаться определенной стратегии...
И при использовании дотнета тоже. И генеральная линия партии тут не при чем.
VD>А то чтобы все моих сегодняшние наработки не превратились в прах. И чтобы я мог делать то, что хочу, а не то что получается.
Ну так это не недостатки или достоинства платформы а твой конкретный случай. Точно так же если у меня основные наработки под CORBA — я дотнет ни при каких условиях использовать не буду.
VD>Если у тебя прокты пеняются по разу в год, то тебе так можно. Я вот 7 лет иду к одной идее.
Не раз в год. Но меняются. VD> И на следующие 5 работы найдется, а технологии приходтя и уходят. Если я нучну прыгать выбрасывая все наработки, то вообще ничего не сделаю. :(
У меня тоже идеи кое какие есть. Только их можно реализовать и на том и на другом и на обоих сразу.
AVK>>Если не переучиваться — кому сейчас нужен такой специалист? Так что учиться и переучиваться придется, причем всю жизнь. VD>Да я и не спорю с этим, но переучиваться и переделывать все с нуля это две большие разнецы.
Всегда приходится начинать с нуля. На дотнет же ты перешел. Мне с java это сделать было просто, все таки технологии очень похожи. А вот тебе с С++?
VD>Ну, и все не состыкока? .Net — это действительно больше чем Ява, а его переносимость отымет козырную карту критиков. Что не так то?
Чем больше?
VD>Т.е. ты не говорил, что MSDN бяка?
Да все оно по большому счету бяка, и MSDN и javadoc. :)
Здравствуйте VladD2, Вы писали:
VD>Кстати, очередь, похоже тоже сделана на массиве. Иначе бы у нее не было бы капасити, не нужен такой параметр для связанных списков. Видимо делают змейку...
В смысле скользящий по массиву указатель начала очереди? Может быть. Тогда понятно почему IList не реализован.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали: AVK>>Неа, не угадал AVK>>Это GC родимый шуткует. Миллион объектов — это много и во втором цикле запускается GC, прибивая память за предыдущим. Я поправил — теперь все харашо. VD>Ну, тогжа запусти мой вариант посмотри на результаты...
А ты мой запусти, с вызовом GC.
AVK>>Да еще и кастинг выкидываешь за счет хранения простых типов. VD>Ну, а ты что же хочешь чтобы производительность из воздуха бралась? Тебе этот кастинг нужен?
Нужен
AVK>> Плюс отсутствуют затраты на new. VD>Ну? Вот и подумай на фига козе баян. Зачем нюь для int? А это ведь самый распространенный тип...
Для списков самый распространенный тип — классы.
AVK>>Плюс используются типы by value и нет выделения памяти в куче и GC. VD>Ну? Так того и добивались, а с обжектом ты плучаешь весь этот кайф, а он ведь тебе не нужен.
Он мене как раз нужен.
AVK>> Увы, чаще всего надо хранить объекты и возможный максимальный размер может быть сильно больше чем среднерабочий.
VD>Ну, при неаравильном приектировании конечно. А при правильном лучше хранить структуры или простые типы. В общем и целом, чем мешьше памяти в куче выделяется, тем лучше. GC это правило ослобляет, но не снимае. В сложных случаях GC проигрывает обычной куче.
Он всегда в скорости проигрывает обычной куче. Зато на 100% исключает утечки памяти из-за потеряных указателей. Именно для этого его и придумали.
VD>Видишь даже с совершенно не производительным хранением информации мой вариант быстрее.
За счет capacity.
VD>Но ведь основной расчет тут делался на отбрасывание нунужных полиморфностей.
Но мне то они нужны.
AVK>>Аналогично релиз. ngen эффекта не дает. AMD XP 1466 512 памяти. VD>Странно. Похоже у меня маина более слабая, но результаты лучше. И нген эфект дает. У меня вот сервис-пака нет. Может это как влияет?
ОС может? У меня XP. Да и винамп наверное немножечко влияет, лишний раз контекст передергивает.
Здравствуйте VladD2, Вы писали:
AVK>>Так граничные условия существуют почти для всего. Но тенденция то.
VD>Да нет никакой тенденции. Хороший софт работает на грани возможного и выжимает из железа все, что моежт, а плохой всехда называли тормозным. Так его и бдут называть...
Пример хорошего и современного софта.
VD>Проще чем софт который создается для других платформ и тем более чем софт создающийся как переносимый и/или масштабируемый.
За все надо платить.
VD>>>Ну, есть же заменитель. AVK>>Медленнее на порядок? Это уже не заменитель. VD>Ну, тебе показал, что технологии абстракции данных в CLR и Яве тоже медленнее на порядок, но ты же из-за этого не откажешься от них?
Потому как очень много потеряю при этом. А что я потеряю от перехода на LinkedList?
AVK>>Допиши мне EJB или хотя бы JDO, а? Я тебе даже денег заплачу, не очень много VD>Я тебе уже говорил, что есть прекрасные заменители EJB.
Ты просто не понимаешь что такое EJB.
AVK>>COM же определяе еще и реализацию. CLR вобще ни каким местом тут не прокатывает.
VD>Это почему? Компонетная модель позволяющая создавать серверы приложений, динамически загружаемые компоненты и элементы управления. Позвоялет создавать и использовть омпоненты на разных языках, т.е. это больше чем COM и больше чем CORBA.
Так я им говорю что CLR тут никаким местом.
AVK>>Далее, к COM надо добавить LDAP сервер. VD>Это еще зачем?
А что ты в замен CORBA registry предложишь?
AVK>>Да и двоичный tlb и текстовый IDL сравнивать трудно. VD>А зачем их сравнивать. Вон в нет эту идею еще дальше расширели. А маньяки от корбы до сих пор кричат, что видте ли это не гибко. Это биче гибкого. Просто один раз нужно разобраться. Сгенерить IDL по tlb или создать файл C# или VB.Net по сборке проще просого.
А в дотнете уже не tlb. Тама WSDL.
VD>>>И то, что для Явы все это будет геморой, AVK>>Так ествственно, технология то ждля нее неродная и вобщем то необязательная. VD>Ана для меня обязательная и для многих тысяч программистов.
Ну значит для тебя и многих тысяч программистов java не подходит. Но для других многих тысяч программистов не подходит дотнет а подходит java.
VD>>>Не понял. AVK>>Объясняю. В *nix'ах dll'ек нет, там есть so. VD>Ну, и что? А это знаю. Что мешает мне использовать на Линуксе одно, а на Виндузе другое?
Отсутствие дотнета в Линуксе
VD>Думаю, что MS обязатеьно сделает показательную портацию .Net на какой нибудь Mac OS 10. Про Моно ты надеюсь уже слышал?
Слышал. И про Corel портирующий дотнет на фришку тоже слышал. Но глядя на Windows.Forms берут меня жуткие сомнения. Тама половину windows переностить придется.
VD>>>Так. Во-первых, зачем в Яве или Нете кешировать объекты? Это же делается автоматически. AVK>>Ну как бы объекты персистентные. VD>А! Замечательная технолгия... для загрузки процессора и свободной памяти. Вот только тебе пожалуй нужно не кэш, а пул создавать.
Нет, пул как раз не подходит. Нужен именно кеш. Иначе нафига мне объект, который можно использовать только в одном месте. VD> Проще читать данные и ассоциировать их с инстансами. К тому же объекты ининтифицируются по ID, а их нужно не в связанных списках ранить, а в map-ах.
Так у меня они в хештаблице и хранятся. Очередь для другого нужна.
AVK>>Используй DOM, а документик возьми мегабайт эдак 20-30. VD>Ну, 30 это уже не документик, а база данных и довельно не маленькая. Прайс книжного магазина (Интернетного) занимает 12 мег. Да и выдержит он в лет. 30 мег для современного компьютера это фантики, ну а делее нужно переходить на БД.
А зачем мне бешеный расход памяти, если можно SAX'ом обработать?
ТAVK>>Чем поддержка java хуже?
VD>Да тем, что книг по Яве и Нэту на русском примеро онинаковое количество, а Нэту всего месяц.
Не показатель VD>Тем, что по нету создано сотни форумов за это время.
В России здесь самый оживленный форум. А траффик больше мы с тобой вдвоем создаем.
ТAVK>>И чем тебя не устроила ее объектная модель? VD>Ну, ты посмотри CodeDom, Emit, дезайнеры типов, броузер свойств, да и сами свойства которые есть в EJB, но нет в самой Яве, и т.п. И покажи аналоги в Яве. А то может я просто чего не знаю?
А объектная модель то тут при чем?
VD>Не, не чувствую. Я разницу в скорости чувствую. Мне 4 байта хранить нужно. Из солидарности с апологетами плиморфизма я этого делать не намерен.
А мне в коллекциях объекты хранить надо. Мне повеситься или утопиться?
Здравствуйте AndrewVK, Вы писали:
VD>>Из всего этого отсутствует один линкед-лист. стэйтфул EJB-ей не будет по принципиальным причинам. AVK>Это что же за такие принципиальные причины?
Они развивают свою идеологию. Им важна не только красота, но и производительность. Поэтому они или встроят все это в БД, или вообще не будут ломать копья.
VD>> Ну а обычные EJB ничем не отличаются от любого объекта .Net. AVK>Обычные это какие? Есть четыре типа бинов AVK>1) Stateless session AVK>2) Stateful session AVK>3) Entity BMP AVK>4) Entity CMP
1 и 2.
Последние как раз не проходят по идеологическим соображениям. Хотя реализовать оба варианта на Нэте можно.
AVK>Только для первых аналогом может быть WS.
Web-сервисы здесь совершенно не нужны. Стыйтлес-объекты прекрасно реалзуются силами самого Нэта (его библиотек, точнее ремоутинга).
AVK> Вторые можно на базе WS съэмулировать. А вот 3 и 4 — это уже проблема. Особенно 4.
(Прежде чем продолжить материться поясню 3 (BMP) — это Entity компоненты с ручной записью. 4 (CMP) с автоматической, контейнером EJB-ей.)
Да нет там никакой проблемы. В прочем как и смысла от 3 и 4. :) Ты сам то их используешь? Вот MS продвигает для решения подобных задачь XML-технологии (кеширование данных на сервере приложений в формате XML). Лично я считаю, что использование обычных курсорных API доступа к БД эфективнее и проще. А абстракцию можно делать и другими методами. Ты видел ДатаСэты в Нэт?
VD>>Что такое JAAS я не знаю. :( AVK>Java Authentication and Authorization Service
Защита по руски? Ну, с этим у нета все впорядке. Кстати, это будет одной из палок которая прогонит Яву с клиентских компьютеров. Хотя ее там и так не много. :(
AVK>>>1) LinkedList VD>>Эмулируется... ну, ты сам знаешь чем. Если что пишится за двадцать мину. AVK>Не эмулируется а пишется целиком ручками
Ну, вроде массив тебе подходил... Да и писать там нечего. Болше пустых разговоров.
AVK>>>2) RandomAccessFile VD>>В Нэт файлы читаются через стримы у которых есть метод Seek. Или ты имеещь в виду нечто иное? AVK>Ну как минимум нужно еще getLength() и setLength(). Плюс стримы оптимизированы под последовательный доступ.
Не, под что они не оптимизированы. Это твои выдумки. Я просто уверен, что они сделаны или на тех же мапнутых файлах, или на обычных CreateFale, ReadeFale, ...
AVK>>>3) MemoryMappedFile VD>>Не имеет смысла, так как в предалах лотальной машины все данны всегда передаются через мапленную память, а с точки зрения файла это всего лишь метод доступа. AVK>Иногда очень удобный. Не критично но в некоторых случаях время экономит.
А ты пробывал просто объет по ссылке (а то и по значению) передать? В Нэт это может оказаться очень даже шустро.
VD>> Возможно обычный файловый доступ реализован через него. Так что это лишнее выпячивание алгортмов. В конце концов если уж пойти на принцип, в Нэт можно за пять минут описать функции работы с мапнутыми файлами ОС и испльзовать их. AVK>Можно, кто спорит. Но это уже не то.
А чего не то? У меня с этим проблем нет... Есть еще куча API которых или нет в Яве/Нэте или реализованных в них медленне и кривее чем в родных API, и что же теперь страдать из любви к искуствау?
AVK>Java Data Objects AVK>цитата из спецификации AVK>JDO specification provides for interface-based definitions of data stores and transactions; and selection and transformation of persistent storage data into native Java programming language objects
Ну, и чем это отличается от EJB-ей?
VD>>Стыйтфул-объекты, т.е. эмуляция ДБ на объектах Явы в нете скорее вего не появится. Из-за того, что это не производительно и кривовато. AVK>По поводу производительности я уже говорил — это не самое главное.
Да помню... купим Крэй. :)
AVK>Да и подобное преобразование все равно делать приходится очень часто.
Мне вот ни разу не приходилось.
AVK> Все дело в уровне абстракции и количестве ручной работы. Не устраивают CMP — есть же еще и BMP. Пиши в базу ручками наздоровье.
А меня и BMP не устраивает. Я считаю что:
UPDATE xxx SET fld1 = fld1 + 123 WHERE yyyy
Проще и эфективнее чем все эти извращения.
VD>>Возможно подобные технологии будут встроены в SQL-Сервер. AVK>Ну xml то он уже хранит. А это по сути уже почти что объекты.
Глупость какая. Объекты — это объекты, а xml — xml (язык разметки). Да и хранить его по человечески БД еще не научилиь, робкие попытки Informix-а в серьез можно не воспринмать.
VD>> В .Net есть так называемый типизированный набор данных который выполняет похожие функции. В любом случае ставка делается на отключенные наборы данных которые могут сериализоваться в XML и пердаваться на другие серверы и клиентам. По сути другое решение того же самого. AVK>Не, не тоже самое. Совсем не то.
Кочено. Это другое решение тех же проблем (работы с данными в приложениях).
AVK>Автоматические транзакции, в т.ч. и распределенные.
Ну, это в COM+-се (а вернее MTS-е) было за долго появления их в CORBA-е и Яве. И на сегодня COM+-самая масшатабируемая система управления распределенными тарнзакциями (ссылку на источник давать? :) ). Через некоторое время появится подобная функциональность и для Чистого Нэта, пока можно перебиться COM+-ом.
AVK> Умное кеширование везде где только можно.
Вот только ума там меньше, чем куриной башке. Ты закачай в эту хрень несколько миллионов записе и посмотри на этот великий ум. :)
AVK>Entity бины. Меппинг объектов в базу, полуавтоматически и автоматически. EJB надо сравнивать с servviced components а не с дотнетовскими объектами.
servviced components — это COM+ руками Нэта. И к твоим песням это отношения не имеет. Ну, а Entity бины — изначально дохлая идея. Вэб-обжектс замечательное доказательство ее глупости.
AVK>>>Ну так это не есть его уникальная особенность. К примеру свинг куда стройнее Windows.Forms. VD>>Это же куда? Ты бы еще сказал быстрее. :) Убогость Свинга просто раздражает. И какая бы модель у него не была, пользоваться интерфейсами сделанными на Свинге просто не удобно. AVK>Это тебе так кажется. По незнанию. На самом деле очень удобно. И от MVC в отличие от нета не отходит.
Я вообще не знаю, как можно отходть от реализации языка. Ты наверно имеешь в виду MFC — эту устаревшую дрехлятину. Я в ней ничего стройного не вижу. Ну, идея документ-вью... и все. Главное, что на Нэте можно создавть савременный и качественный GUI, а на свинге тормозных и убогих (функционально) монстриков.
VD>>А чем тебя дата не устраивает? AVK>Нафига мне для редактирования данных в табличке ADO.NET тащить? Это уже пушкой по воробьям получается.
Так он все равно на машине будет стоять. И к тому же это ты не разобрался. Там только датасэты тащутся, они к ADO отношения не имеют. В конце концов уже наклепано мнофество решений от независимых производтелей, для Явы такого разнообразия никогда не появится.
VD>> К тому же ты здесь вообще смотришь не верно. У мс своих гридов от родясь не было. Они все делались разными Шариданами и в лайт-версии клались в VB. Если тебе нужен грид посмотри дополнительные компоненты. AVK>Гы.
Что гы? Грамоно действуют. Себе забирают рынок по больше, а другим дают малеьнкие нишки. :))
VD>>По стравнению с ними все что делается для Явы (да и для дельфи) просто детски лепет. AVK>Ты JTable видел? Особенно в 1.4. Все эти дельфовые и VB-шные гриды по сравнению с ним как раз детский лепет и есть.
А ты Инфрогистиковские? Они еще и не тормозят. :))
VD>>Понятна. Но спортивная машина... это не совсе корректно. Нэт в большинстве вслучаев все же быстрее, т.е. сам компилятор оптимальнее и есть средства явной оптимизации. AVK>Не надо сравнивать. Скорость машины в моем примере это не скорость компиляции и программ а скорее надежность программирования.
Нда... странные ассоциации... "надежность" и "спортивная машина". :-\
И ты можешь привести пример когда Ява "надежнее" CLR?
VD>>Ну, метания это тоже не здрово. AVK>Кто говорит про метания. Возможность использовать наработаный опыт — один из факторов при выборе плаформы. Только он не определяющий.
Это зависит от размеров опыта. :)
VD>>А я вот этого ни разу не заметил. :( Ткни носом, плиз. AVK>boxing/unboxing к примеру.
Пожалуй, это один из не многих. А что ты думаешь про value-типы? Да и про остальные отличия Нэта?
AVK>Да нет — просто хочу сказать что недостатки в дотнете есть и кое в чем он похуже java.
Да! Нет линкедлиста. :)))
VD>>А шоб можно было создавть смарт-поинтеры в стеке. Для контроля внешних ресурсов... Накладных расходов ноль, а кайфа... AVK>Тогда уж лучше было бы ввести какой нибудь специальный механизм для классов, выделить их отдельно и соответственно настроить GC на работу с ними, т.е. убрать отложеное удаление, принудительно запускаться или даже реализовывать пул.
Нe, по разному можно. Но твой вариант сложен и далек от жизни, а то что я прдлагаю, реализуется легко и дает нужных эфект.
VD>>>>Не, ну, нормально. Может этот спор я начал? AVK>>>Может я? VD>>А кто же? AVK>Не я :)
А-га. Сам завелся... от сырости. :)
VD>>На, Нэте не знаю, а на VB в свое время ушло два с половиной месяца и не на простенький, а на очень даже ядреный. AVK>На 1С день с нуля. Полмесяца с отладкой и внедрением.
Лажа на твоем 1С-е хоть день... хоть год... То что у нас за те два месяца было сделано от 1С-а отличается одним небольшим достоинством... оно мозги имело и продуманную архитектуру.
AVK>>>И сколько это будет денег стоить? Для маленьких предприятий 1С в России на данный момент лучше всего. VD>>Я бы уж лучше какой-нить Бэст выбрал. Ну, мозгов в этом 1С нуту. Про производительность лучше вообще молчать. AVK>Но таки 1С практически монополист на этом рынке.
Канчай ерунду говрить. У них и 20% рынка нет. Кое что отхватили в мелких торговых фирмах... На этом рынке ~60 постоянно действующих мошьных контор и еще 540 по мельче. И всем хлеба хватает.
AVK>>> Платишь сотню баксов и получаешь весьма приличный складской и бухгалтерский учет + бесплатные обновления в соответствии с весьма продуктивной деятельностью наших законодателей и чиновников. VD>>Я тебе штук десять продуктов за туже цену могу подобрат. Разве что конструктров среди них не будет. AVK>Вот вот.
Что вот-вот? Access и тот интелектуальнее и удобнее. Чё бы на нем "стандартные конфигурации" не наклепать?
VD>>Еще бы Яве 6 лет, а Нэт вышел тлько месяц назад. :) AVK>2 уже. Так я о том и говорю — молодой он еще.
Да нет... Вроде официально объявили только месяц назад... Или это время летит?...
VD>> Через два гда посмотрим. Думаю, не нете будет значительно больше. К тому же Нэт можно встраивать в уже существующие приложения. AVK>Вот и посмотрим.
Договорились.
VD>>Ну, вот есть код на С++ (пордка 350 000 строк) и на VB (~10 000). Причем исползуются технологии COM, DCOM, COM+, WSH, ActiveX... Как мне все это перевести на Яву, и что мне это даст. Если даже переписанный с нуля код будет работать медленнее? AVK>Сам понимаешь — ActiveX это уже однозначно технологии от MS. Политика у него такая. J++ напомнить? Там ведь как раз из-за COM поцапались.
До появления Явы во всем не MS мире небыло нормальной универсальной компонентной технологии, а уж аналога контэйнера ActiveX-ов (а-ля VB) небыло и в помини. Что же нам было Яву дожидаться. Так он и сейчас не дотягиват.
VD>>Так ты сам говорил, чтобы использовать Яву нужно придерживаться определенной стратегии... AVK>И при использовании дотнета тоже. И генеральная линия партии тут не при чем.
Я тебе уже говорил. В Нэте я волен сам вибирать как жить. Захочу буду писать на MC++ с минимальными ограничениями, вернее без них. И стаый код интегрирую.
VD>>А то чтобы все моих сегодняшние наработки не превратились в прах. И чтобы я мог делать то, что хочу, а не то что получается. AVK>Ну так это не недостатки или достоинства платформы а твой конкретный случай. Точно так же если у меня основные наработки под CORBA — я дотнет ни при каких условиях использовать не буду.
Как-раз CORBA-у к Нэту прикрутить можно. Но Ява действительно будет ближе. Но моих проблем это не решает, а CORBA не компонентная технология которая была нужна нам.
VD>> И на следующие 5 работы найдется, а технологии приходтя и уходят. Если я нучну прыгать выбрасывая все наработки, то вообще ничего не сделаю. :( AVK>У меня тоже идеи кое какие есть. Только их можно реализовать и на том и на другом и на обоих сразу.
Везет тебе. А вот я так шустро не умею. Мне приемственность нужна.
AVK>Всегда приходится начинать с нуля. На дотнет же ты перешел.
Пока не совсем.
AVK>Мне с java это сделать было просто, все таки технологии очень похожи. А вот тебе с С++?
А мне не с С++, а с COM-а. Но если бы у меня бли такие наработки на Яве, то тоже было бы сложно.
VD>>Ну, и все не состыкока? .Net — это действительно больше чем Ява, а его переносимость отымет козырную карту критиков. Что не так то? AVK>Чем больше?
Тем, что Явная VM — это только интерпритатор байт-кода, а у нет это полнофункциональый слой, который прекрасно работает без Шарпа. Есть даже свой формат языка. MSIL — это ассемблер нового поколения. Вот CLR + C# это действительно аналог Явы. Несколько улучшенный, но аналог.
VD>>Т.е. ты не говорил, что MSDN бяка? AVK>Да все оно по большому счету бяка, и MSDN и javadoc. :)
Хытрущый... :)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте VladD2, Вы писали:
VD>>Кстати, очередь, похоже тоже сделана на массиве. Иначе бы у нее не было бы капасити, не нужен такой параметр для связанных списков. Видимо делают змейку... AVK>В смысле скользящий по массиву указатель начала очереди? Может быть. Тогда понятно почему IList не реализован.
Здравствуйте AndrewVK, Вы писали:
VD>>Ну, а ты что же хочешь чтобы производительность из воздуха бралась? Тебе этот кастинг нужен? AVK>Нужен
Зачет?
AVK>Для списков самый распространенный тип — классы.
Это у тебя стереотипы от Явы. Ты про value-типы забываешь (структуры, например).
AVK>>>Плюс используются типы by value и нет выделения памяти в куче и GC. VD>>Ну? Так того и добивались, а с обжектом ты плучаешь весь этот кайф, а он ведь тебе не нужен. AVK>Он мене как раз нужен.
В конкретном случае. А ты посмотри шире... Этот тормоз же всегда есть.
VD>>Ну, при неаравильном приектировании конечно. А при правильном лучше хранить структуры или простые типы. В общем и целом, чем мешьше памяти в куче выделяется, тем лучше. GC это правило ослобляет, но не снимае. В сложных случаях GC проигрывает обычной куче. AVK>Он всегда в скорости проигрывает обычной куче. Зато на 100% исключает утечки памяти из-за потеряных указателей. Именно для этого его и придумали.
Ошибаешься. Теоритически GC быстрее обычного хипа. ДонБокс замечательный фокус показывал... демострирующий скорость GC. А мотерь памяти и в VB6 небыло.
VD>>Видишь даже с совершенно не производительным хранением информации мой вариант быстрее. AVK>За счет capacity.
Я бы сказал проще, за счет более продуманного алгоритма.
VD>>Но ведь основной расчет тут делался на отбрасывание нунужных полиморфностей. AVK>Но мне то они нужны.
В одном случае из десяти. К томуже если бы ты хранил данные в структурах, то проигрыш блы лы куда больше.
AVK>ОС может? У меня XP.
У меня W2k сервер.
AVK> Да и винамп наверное немножечко влияет, лишний раз контекст передергивает.
Не, он почти ничего не жрет... проверено.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте VladD2, Вы писали:
AVK>>>Так граничные условия существуют почти для всего. Но тенденция то.
VD>>Да нет никакой тенденции. Хороший софт работает на грани возможного и выжимает из железа все, что моежт, а плохой всехда называли тормозным. Так его и бдут называть... AVK>Пример хорошего и современного софта.
Ну, вот простенький... Quake Xxx. Каждая новая версия идет на пределе железа и радует новыми наворотами... и при этом не жертвует играбельностью... Из облати тебе по ближе... SQL Server 2000 или Oracle 9i.
VD>>Проще чем софт который создается для других платформ и тем более чем софт создающийся как переносимый и/или масштабируемый. AVK>За все надо платить.
Вот я тебе и говрю, что нужно всзвешивать и выбирать.
AVK>Потому как очень много потеряю при этом. А что я потеряю от перехода на LinkedList?
Ничего.
А что ты потеряешь если воспользуешся шаблонами?
AVK>>>Допиши мне EJB или хотя бы JDO, а? Я тебе даже денег заплачу, не очень много :) VD>>Я тебе уже говорил, что есть прекрасные заменители EJB. AVK>Ты просто не понимаешь что такое EJB.
Не... Я именно этими вопросами и занимался. И что это такое прекрасно знаю. Лажа — это. Я уж лучше возьму какое нибудь Cache. Там будут теже объекты, но работать они будут на пордки бысрее и не будет тех гралей.
AVK>>>COM же определяе еще и реализацию. CLR вобще ни каким местом тут не прокатывает. VD>>Это почему? Компонетная модель позволяющая создавать серверы приложений, динамически загружаемые компоненты и элементы управления. Позвоялет создавать и использовть омпоненты на разных языках, т.е. это больше чем COM и больше чем CORBA. AVK>Так я им говорю что CLR тут никаким местом.
Как это не кместу, если функциональность перекрывается на 100%?
AVK>>>Далее, к COM надо добавить LDAP сервер. VD>>Это еще зачем? AVK>А что ты в замен CORBA registry предложишь?
Я не понмаю что это? Назови это русским языком.
AVK>>>Да и двоичный tlb и текстовый IDL сравнивать трудно. VD>>А зачем их сравнивать. Вон в нет эту идею еще дальше расширели. А маньяки от корбы до сих пор кричат, что видте ли это не гибко. Это биче гибкого. Просто один раз нужно разобраться. Сгенерить IDL по tlb или создать файл C# или VB.Net по сборке проще просого. AVK>А в дотнете уже не tlb. Тама WSDL.
Господи! От куда ты такого бреда набрался? Меньше читай/смотри рекламу пред сном.
Там сборки! В них лучший из виданных мною вариант метаданных, код и ресурсы. А WSDL это открытый язык которым даже Дельфи пользуетя. Но это дело прменимо только к Web-сервисам.
VD>>Ана для меня обязательная и для многих тысяч программистов. AVK>Ну значит для тебя и многих тысяч программистов java не подходит. Но для других многих тысяч программистов не подходит дотнет а подходит java.
Естественно.
VD>>>>Не понял. AVK>>>Объясняю. В *nix'ах dll'ек нет, там есть so. VD>>Ну, и что? А это знаю. Что мешает мне использовать на Линуксе одно, а на Виндузе другое? AVK>Отсутствие дотнета в Линуксе :)
Я еще раз спрашиваю ты про Моно слышал?
VD>>Думаю, что MS обязатеьно сделает показательную портацию .Net на какой нибудь Mac OS 10. :) Про Моно ты надеюсь уже слышал? AVK>Слышал. И про Corel портирующий дотнет на фришку тоже слышал. Но глядя на Windows.Forms берут меня жуткие сомнения. Тама половину windows переностить придется.
А кто тебе сказал что MS будет отдавать Дэсктоп каким-то там Линухам или Фришкам? :) Ну, а серверы — это другое дело. Тут, MS лезет в чужой огород...
VD>>А! Замечательная технолгия... для загрузки процессора и свободной памяти. Вот только тебе пожалуй нужно не кэш, а пул создавать. AVK>Нет, пул как раз не подходит. Нужен именно кеш. Иначе нафига мне объект, который можно использовать только в одном месте.
Так обект определяется его состоянием. В другом месте возьмешь другой объект и загрузишь в него то самое состояние. Между прочим многие EJB-контейнеры так и делают.
VD>> Проще читать данные и ассоциировать их с инстансами. К тому же объекты ининтифицируются по ID, а их нужно не в связанных списках ранить, а в map-ах. AVK>Так у меня они в хештаблице и хранятся. Очередь для другого нужна.
А... Понимаю... управляешь памятью в GC-среде. :)) Ну, что же дело перспективное...
VD>>Ну, 30 это уже не документик, а база данных и довельно не маленькая. Прайс книжного магазина (Интернетного) занимает 12 мег. Да и выдержит он в лет. 30 мег для современного компьютера это фантики, ну а делее нужно переходить на БД. AVK>А зачем мне бешеный расход памяти, если можно SAX'ом обработать?
В этом случае лучше обойтись каким нубудь Ораклом, ну, или МайСкулем. :)
ТAVK>>>Чем поддержка java хуже? VD>>Да тем, что книг по Яве и Нэту на русском примеро онинаковое количество, а Нэту всего месяц. AVK>Не показатель VD>>Тем, что по нету создано сотни форумов за это время. AVK>В России здесь самый оживленный форум.
Да... Скоро мы затмим всех. :)))
ТAVK>>>И чем тебя не устроила ее объектная модель? VD>>Ну, ты посмотри CodeDom, Emit, дезайнеры типов, броузер свойств, да и сами свойства которые есть в EJB, но нет в самой Яве, и т.п. И покажи аналоги в Яве. А то может я просто чего не знаю? AVK>А объектная модель то тут при чем?
А то что для Явы приходится придумывать "внешние" объектные модели... вроде EJB.
VD>>Не, не чувствую. Я разницу в скорости чувствую. Мне 4 байта хранить нужно. Из солидарности с апологетами плиморфизма я этого делать не намерен. AVK>А мне в коллекциях объекты хранить надо. Мне повеситься или утопиться?
Я же тебе уже сто раз говорил. В этот раз объекты (хотя можно обойтись и структурами), а в другой int придется. И тут...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
VD>>Ну, дык для полноты картины еще бы нашел, а то пляшем все от листа... AVK>Мне третий раз сюда один и тот же списочек писать?
Тебе ответили по поводу EJB. Они в .Net есть, но другие. Проблемы решают те же. Других проблем в библиотеках ты не показал.
VD>>Задачи он решает совсем маленькие, а форум нет. Ну, а спроектирован он на на пятерочку. Я его малость подправил, а то менять местами трудно... AVK>Так и у процедуры проведения накладной тоже задачи побольше чем у форума.
Зависит от конкретного форума и конкретной системы автоматизации.
VD>>Да у тебя не накладные, а какие-то досье. AVK>А ты думал. Я же тебе говорю — не все так просто как кажется со стороны.
У нас тоже накладные есть, но сложности в них особой нет.
VD>>Так в чем принципиальная разница? И там и там OLTP, и там и там накопление промежуточных результатов и структурезация данных. AVK>В форуме еще и OLAP есть?
А ты думал?! Причем с не хилой нагрузочкой.
Разбивка на партии?
Вместо нее подсчет рейтингов. К тому же это твой личный алгоритм, у нас в системе вот партии были, а разбивки на них нет. Модель позволяет.
Проверка и коррекция остатков и оборотов?
Корекция рейтингов, скоро еще и автомодерирование появится.
Контроль кредитов, договоров? Погашение долга? А там еще много чего есть.
Вот когда система продумана на 100%, то все это становится не так сложно, а если волить все в кучу, то конечно можно нагородить многое...
VD>> Да форум не самый сложный код. Но тревиальным его тоже не назавешь. AVK>Так я и не говорю что он тривиальный. Но форум я могу написать скажем за недельку, не особенно напрягаясь. А вот нормальный оперативный учет уже несколько сложнее.
Все зависит, от того как насколько ты правльно и целостно видишь постоновку задачи... Хотя за недельку вообще ничего путного не выйдет. Нормальный софт как минимум месяца два нужно отлаживать.
AVK>>>Да не хочу я пиписьками меряться. Просто судя по твоим словам основной опыт у тебя в веб-проектах. VD>>Не поверишь, за все время сделал один сайт и 12 лет занимался автоматизацией предприятий. Начинал с продажи и внедрения чужих систем... AVK>Каких, если не секрет?
В смысле продовал какие? Разные... От Турбо-бузгалтера, то черта лысого. Чаще всего приходилось возиться с Абакусом По этих... как их..., а про фешонал. Там технологическое воплощение было на 2 с плюсом, но было хоть какое-то ядро. На его базе можно было построить давльно прилисные вариации оучета. Аравда расширяемость там была нулевая. Но идейно этот продукт подтолкнул прилично.
VD>>Ну, не хочешь так не хочешь, но про то что не интересно — это ты зблуждаешся. AVK>Ау, кому нибудь это интересно?
А ты поставь отдельным топиком и попроси, чтобы народ проголосовал... сам увидишь.
VD>>Это понятно, но в .Net она является частью CLR, а .Net? это как сказал IT, больше чем... Ну, и уж тем более больше чем CLR. AVK>Я где то говорил что это не так?
Что это?
VD>>>>SOAP – протокол удаленных вызовов через http и XML. AVK>>>html здесь лишний. VD>>Не, именно по http. AVK>Как минимум часто еще SMTP часто используется. А вобще протокол может быть любой.
Откудо ты это взял?
VD>>CG да, но MSIL спокйно будет работать. AVK>Будет. Но нафига он там?
А нафига он здесь? Чтобы максимально эфективно использовать возможности конкретного камня и чтобы писать переносимый (хотя бы между разными процессорами, AI32, AI64, S.ARM, ...) код.
AVK>А при чем здесь MSIL? В *никсах вон так и поступают, без всякого IL. Или ты имеешь ввиду компиляцию IL в нейтив код
Ну?
AVK> — так увеличение производительности от этого — пока декларация как для дотнета так и для джавы.
Неее... Это факт. Скорость кода MSIL близка к аналогичному коду созданному с опциями оптимизации для конкретного симейства процессоров. Если бы еще не object-ы и virtual-ы используемые где попало из-за отсутствия шаблонов... Надеюсь в следующей версии они все это учтут.
VD>>Мои экспременты показывают обратное. Скачай примеры от шустрика посмотри. Ява жрет не меньше, AVK>Так я и говорю что больше она жрет.
Ну, тогда я тебя не поныл... А на счет больше... я этого как то не почувствовал, а вот, то что ей максимльный размер памяти нужно задавать почувствовал. Сама возможность этого — это хорошо, но вот то что нельзя просто сказать "используй всю имеющуюся память" — это дико не удобно.
AVK>А чего их искать? Их там есть. Я тут даже упоминал некоторые. Могу еще сказать что в самом языке сильно не хватает свойств и типов-перечислений (это для меня основной недостаток именно языка).
Дохленький какой-то недостаток. Хотя на счет enum-ов я с тобой согласен. Кстати, а ты видел как в Шарпе сделаны маски (aaa | bbb | sss), но атрибутах? Я всегда говрил, что в Паскале сэты сделаны удобно... Вот они вроде услышали.
VD>>Странные у тебя результаты. У меря процентов 10 выигрышь. Что за щелезка? AVK>Я уж вроде писал. AXP 1700+, 512 DDR
1500-й зачичь? А ты тесты из среды запускаешь или из консоли?
VD>>В одном случае объекты, а в другом int придется. Да и объекты в родных типах должны работать быстрее. AVK>а тип object для экземпляров object не родной?
Это частный случай. А этот идеотский подход "навязывается" самой идеологией.
AVK>Результат AVK>1132 AVK>480
AVK>Вот он твой эффект. А для int еще и нет конролируемых ссылок.
Не... Мой эфект был 60! А на твоем камне должен быть 50 или даже 40. Это не в два раза... это на порядок!
Ну, а то что ссылок нет, так это и замечательно. Я тебе уже второй день толдычу, что использование универсальных в Нэт и Ява сделан глупейшим образом. Вместо того чтобы возложить работу на компилятор все сваливается на рантаймный полиморфизм, а нужно это в одном случае из 1000. Именно из-за этого код написаный на С++ пока что будет быстрее чем аналогичный на Нэт или Яве.
VD>>И к тому, же в слудующий раз тебе может понадобится int, а через object он будет в 10 раз медленнее. AVK>Ну не в 10 раз — но таки да, для int можно. Только объекты все же почаще используются.
Я тебе уже показал что в 10. Можешь проверить на соей мшине. И это еще пример который ничего не делает. На реальных задачах может оказаться и больше чем в 10. VARIANT в обычном С++ давл меньший провал по скорости.
VD>>>> Вот CLR и Ява тем и плохи, что полиморфность в них достигается за счет использования виртуальных методов и типа object. На C++ я бы написал шаблон и он бы дал лучшую производительность. AVK>>>Вот о чем я и говорю — лучше пожертвовать производительностью в угоду удобству и надежности. VD>>Ну, и в сем же здесь пропадут надежность или удобство? AVK>В чем удобство полиморфности? В большей универсальности кода.
Во-первых, ты снова ушел от ответа.
А, во-вторых, та рантаймная полимофность которая сплошь и рядом испльзуется в Нэт и Яве, практически никогда не нужна. Обычно надежнее и быстрее будет если вместо рантаймной полиморфности будет применена фолиморфность копайлтаймная. Шаблоны в С++ это замечательно доказывают, на этом языке можно создавать коллекции которые идельны по скорости, безопасны и удобны в исползовании. Для Нэта есть только одна проблема, как реализовать Шаблоны на уровне IL. Иначе они так и останутся особенностями язвка.
AVK>На шаблонах рефлекшн не будет работать. Но это так.
Ты что сказать то хотел? А рабоать будет. Иначе бы в яву 1.5 их не заложили. Для Нэта даже был выпущен пробный билд в которм шаблоны поддерживалиь на уровне IL. Так что это уже факт.
AVK>А вобще использование шаблона для объектов в плане производительности ничего не даст. Шаблон просто привнесет дополнительный контроль типов.
Я тебе уже показал пример который работает в 10 раз быстрее. Попробуй домыслить и представить, что вместо int там был поставлен дженерик-тип... И получится, что шаблон дает возможность писать универсальный код без ущерба для производительности, что наблюдаетя при использования object.
Если речь идет о хранении ссылог на объекты, то думаю, высокого роста производительности добитья не удастся. Ну, процентов 10 максимум 20. Но в Нэт есть же и value-типы! Тут скорость возрастет на порядок (а скорее всего и больше). Если хочешь могу провести следственный эксперемент? Кстати, отсутствие value-типов — это серьезный недостаток Явы! Они не хотят его устранить?
AVK>>> Ибо железки ныне дешевеют а труд программеров дорожает. VD>>Во блин. Снова за свое. То ему просадка на порядок из-за отсутсвия листа мешает, то он плюет на тот же порядок в том же случе. Ты подумай, если сложить тот порядок с этим то получится уже сотня. AVK>Не, использование связаного списка дает повышение производительности практьически бесплатно, а вот перепроектирование системы — нет.
А какое тут перепроектирование? Просто нужно заменить реализации колекций на более эфективные (как и в твоем случае). Вот только это уже недостаток платформ.
AVK>А про железки это потому что мне приходится не только программить, но еще и заниматься эксплуатацией. И купить железку обычно куда как проще и дешевле нежели переписывать готовый код.
Не, переписывать, а оптимизировать. Это две большие разницы. И стоит это обычно дешевле, чем замена и без того не дешевого железа на более дорогое.
AVK> Я могу конечно посадить программера, он за два-три месяца мне процентов на 10% тот же модуль перепроведения ускорит.
А если не на 10, а на 1000? Я такие факты видел...
AVK> Но за те же деньги я куплю еще один серверок
Э милый. Еще один — это будет кластер (или машина под выделенную задачу), с которыми ты так боришься.
AVK>и через 2-3 дня у меня все заработает быстрее на те же 10%, если не быстрее. Вот о чем я пытаюсь сказать.
Твоя мысль понятна. И иногда это действительно правильное решение, но все это от безысходности. Вот елси бы ты действительно мог докупив сервачок и вставив его в кластер поднять (пропроцианально) производительность — это было бы дело.
AVK>А то что иногда все же приходится кардинально все переделывать — да, такое тоже вполне возможно. У меня вот сейчас старый оперативный учет по одной фирме как раз полностью выкидывается, ибо проще сделать с нуля новый чем дорабатывать старый. Но он отработал 5 лет и вполне себя оправдал. А если бы я оставил старый серверок, на котором он первоначально работал — уже через 2 года мне бы пришлось думать об увеличении быстродействия. Как ты считаешь — 2 штуки, отданые за серверок за 3 года себя оправдали?
Ну, это вопрос об упущенной выгое... Вот ты как считаешь, если ли бы ты отдал $500 на более грамотное проектирование системы и еще $500 на оптимизацию алгоритмов, не вышл бы лучше?
VD>>Да это знакомо. И самое смешное, что такие рассуждения я слышал от известных и уважаемых людей. AVK>Тут одно из двух — либо человек вобще нифига не понимает и говорит с чужих слов, либо его знания программных технологий так и остались десятилетней давности. Я помню как на БК-0010 приходилось байты экономить. Но это же не повод делать то же самое сейчас?
Похоже второе. А человека этого ты (скорее всего) знаешь он главный редактор в одном очень авторитетном компьютрном издании (русской редакции, конечно).
AVK>Кого сейчас волнует — 400К или 4М занимает exe?
Многих. Вот у меня диалап, а библиотеки нужно выкладывать на Интернет. 400К я прокачаю, а 4М — нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте iZEN, Вы писали:
IT>>От переносимости я при случае конечно не откажусь, но надобности в этом в моих задачах я пока не просматриваю даже в микроскоп. Возможно это и актуально в мире Юникс, где возможно существуют реальные проблемы переносимости внутри одного клона операционных систем, но это их проблемы. Мне переносимость пока не нужна и я буду стараться избегать этого как можно дольше, т.к. считаю её источником проблем.
ZEN>Ну вот, переносимость для Вас -- это источник проблем. Странно. Если так случится, что Вам надо будет большой проект перенести/портировать под более мощную платформу(не-Win32), будете переписывать всё с нуля?
А так ли часто возникает вот эта самая мифическая "необходимость большой проект перенести/портировать под более мощную платформу (не Win32)"? Приведите примеры, а? Действительно интересно!
IT>>Лично мне что 12, что 20, что 120 без разницы. Но зато Java нет на CD в RSDN Mag, а .NET FSDK есть и скачивать ничего не надо.
ZEN>А по сети слабо качнуть? Как многие это делают/предстоит сделать.
Кому это многим? Западным странам? Так это им примерно так же, как нам сходить на рынок за компактами. А у нас как всегда единицы действительно скачают, а потом просто будет все выложено на раскладках. И что самое интересное — это вполне законно, насколько я понимаю.
Здравствуйте The Lex, Вы писали:
TL>Здравствуйте iZEN, Вы писали:
IT>>>От переносимости я при случае конечно не откажусь, но надобности в этом в моих задачах я пока не просматриваю даже в микроскоп. Возможно это и актуально в мире Юникс, где возможно существуют реальные проблемы переносимости внутри одного клона операционных систем, но это их проблемы. Мне переносимость пока не нужна и я буду стараться избегать этого как можно дольше, т.к. считаю её источником проблем.
ZEN>>Ну вот, переносимость для Вас -- это источник проблем. Странно. Если так случится, что Вам надо будет большой проект перенести/портировать под более мощную платформу(не-Win32), будете переписывать всё с нуля?
TL>А так ли часто возникает вот эта самая мифическая "необходимость большой проект перенести/портировать под более мощную платформу (не Win32)"? Приведите примеры, а? Действительно интересно!
Скажем так, мне приходится работать с зоопарком машин и я не хочу что-то делать дважды и трижды. :user:
Re[18]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
Здравствуйте VladD2, Вы писали:
VD>Они развивают свою идеологию. Им важна не только красота, но и производительность.
Так производительность у Entity бинов, особенно BMP не такая уж и плохая. На некоторых задачах (особенно при большом количестве клиентов) за счет правильного кеширования EJB может быть и побыстрее обычного SQL.
VD>Поэтому они или встроят все это в БД, или вообще не будут ломать копья.
Да понятно конечно что они пошли по другому пути. Наступать на горло собственной мечте, т.е. COM+ и xml'ным возможностям SQL сервера они не будут. И дело тут не в идеологии, а как всегда в бабках. (Ох уж эти бабки, вечно суют свой нос куда не следует. Сидели бы себе на пенсии. :) )
VD>1 и 2.
Если нужно только 1 и 2 — проще и дешевле использовать сервлеты.
VD>Последние как раз не проходят по идеологическим соображениям. Хотя реализовать оба варианта на Нэте можно.
Было бы странно если бы было нельзя.
AVK>>Только для первых аналогом может быть WS. VD>Web-сервисы здесь совершенно не нужны. Стыйтлес-объекты прекрасно реалзуются силами самого Нэта (его библиотек, точнее ремоутинга).
Ремоутинг конечно хорошо. Вот только кешировать придется ручками — иначе будут такие тормозаааааааааааааааааааааааааа.
VD>(Прежде чем продолжить материться поясню 3 (BMP) — это Entity компоненты с ручной записью. 4 (CMP) с автоматической, контейнером EJB-ей.)
VD>Да нет там никакой проблемы. В прочем как и смысла от 3 и 4. :) Ты сам то их используешь?
Да.
VD>Вот MS продвигает для решения подобных задачь XML-технологии (кеширование данных на сервере приложений в формате XML). Лично я считаю, что использование обычных курсорных API доступа к БД эфективнее и проще. А абстракцию можно делать и другими методами. Ты видел ДатаСэты в Нэт?
Видел. Увы — сфера применения подобных технологий весьма ограничена.
AVK>>Java Authentication and Authorization Service VD>Защита по руски? Ну, с этим у нета все впорядке. Кстати, это будет одной из палок которая прогонит Яву с клиентских компьютеров. Хотя ее там и так не много. :(
Не защита. Фреймворк для аутентификации и авторизации. Подобное в дотнете есть, но только в asp+.
VD>>>Эмулируется... ну, ты сам знаешь чем. Если что пишится за двадцать мину. AVK>>Не эмулируется а пишется целиком ручками VD>Ну, вроде массив тебе подходил... Да и писать там нечего. Болше пустых разговоров.
Я в другом топике показал как мне массив подходит :)
VD>>> Возможно обычный файловый доступ реализован через него. Так что это лишнее выпячивание алгортмов. В конце концов если уж пойти на принцип, в Нэт можно за пять минут описать функции работы с мапнутыми файлами ОС и испльзовать их. AVK>>Можно, кто спорит. Но это уже не то. VD>А чего не то? У меня с этим проблем нет... Есть еще куча API которых или нет в Яве/Нэте или реализованных в них медленне и кривее чем в родных API, и что же теперь страдать из любви к искуствау?
Сама же MS с легкостью выпустит очередную операционку с измененной функциональностью этих API. Примеры были. Тот же comctl32. Или тебе под WinCE перетащить понадобится или какой нибудь XBox.
AVK>>Java Data Objects AVK>>цитата из спецификации AVK>>JDO specification provides for interface-based definitions of data stores and transactions; and selection and transformation of persistent storage data into native Java programming language objects VD>Ну, и чем это отличается от EJB-ей?
EJB это сервер прежде всего. JDO — отдельный механизм. Ты же не будешь использовать EJB скажем в почтовом клиенте. А JDO пожалуйста.
AVK>>Да и подобное преобразование все равно делать приходится очень часто. VD>Мне вот ни разу не приходилось.
Ты его неявно делаешь. В C# все равно потом результаты выборок приходится в объектах хранить.
AVK>> Все дело в уровне абстракции и количестве ручной работы. Не устраивают CMP — есть же еще и BMP. Пиши в базу ручками наздоровье.
VD>А меня и BMP не устраивает. Я считаю что: VD>
VD>UPDATE xxx SET fld1 = fld1 + 123 WHERE yyyy
VD>
VD>Проще и эфективнее чем все эти извращения.
Зато менее понятно, больше зависит от конкретного sql сервера, структуры БД. Намного тяжелее потом меняется. Я прекрасно помню кучу рутинной работы при взаимодействии непосредственно с sql сервером. Одни и те же вещи занимали с использованием ejb и генераторов исходников иногда в десятки раз меньше чем на sql+ado. Хотя конечно все зависит от задачи. Кое где прямые запросы к базе вне конкуренции.
Впрочем сам MS рекомендует пользоваться не дотнет API как можно реже.
VD>>>Возможно подобные технологии будут встроены в SQL-Сервер. AVK>>Ну xml то он уже хранит. А это по сути уже почти что объекты. VD>Глупость какая. Объекты — это объекты, а xml — xml (язык разметки).
Основная сложность хранения объектов — преобразование их модели данных к реляционной. Именно здесь случается основной оверхед. А xml уже как бы имеет нереляционную структуру. Хранить же состояние объектов в xml очень легко.
VD> Да и хранить его по человечески БД еще не научилиь, робкие попытки Informix-а в серьез можно не воспринмать.
А MSSQL чего? Не катит? Я тут один проектик (веб) видел на asp.net. Там ребятки описывают объекты на xml, затем благополучно хранят их ввиде этого самого xml в базе (mssql естественно), а при выводе накидывают xslt прямо на выборку. Все очень красиво.
AVK>>Не, не тоже самое. Совсем не то. VD>Кочено. Это другое решение тех же проблем (работы с данными в приложениях).
Не решают они те проблемы которые нужны мне в моих задачах. Я в свое время поковырялся с ado.net и понял что мне оно не подходит совершенно. Ту задачку я решил на обычном ADO + свои механизмы.
AVK>>Автоматические транзакции, в т.ч. и распределенные. VD>Ну, это в COM+-се (а вернее MTS-е) было за долго появления их в CORBA-е и Яве.
Да ладно тебе. CORBA уже фиг знает сколько лет.
VD>И на сегодня COM+-самая масшатабируемая система управления распределенными тарнзакциями (ссылку на источник давать? :) ). Через некоторое время появится подобная функциональность и для Чистого Нэта, пока можно перебиться COM+-ом.
Тут кто то писал о том что COM+ в дотнете поддерживается очень криво и MS не собирается это менять "по идеологическим причинам".
AVK>> Умное кеширование везде где только можно. VD>Вот только ума там меньше, чем куриной башке. Ты закачай в эту хрень несколько миллионов записе и посмотри на этот великий ум. :)
А вот под задачи где нужны выборки в несколько миллионов записей подобные системы совершенно не рассчитаны. Как впрочем и ado.net тоже. А кеширование там весьма правильное, поскольку для сервера доступно куда больше информации о выполняемых задачах чем для сервера БД.
AVK>>Entity бины. Меппинг объектов в базу, полуавтоматически и автоматически. EJB надо сравнивать с servviced components а не с дотнетовскими объектами. VD>servviced components — это COM+ руками Нэта. И к твоим песням это отношения не имеет.
Еще как имеет. VD>Ну, а Entity бины — изначально дохлая идея.
Странно только — на что та же BEA живет? У ней ведь WebLogic — основной продукт.
AVK>>Это тебе так кажется. По незнанию. На самом деле очень удобно. И от MVC в отличие от нета не отходит. VD>Я вообще не знаю, как можно отходть от реализации языка. Ты наверно имеешь в виду MFC — эту устаревшую дрехлятину. Я в ней ничего стройного не вижу.
Нет, я имею ввиду именно MVC, паттерн такой, Model-View-Controller. VD>Ну, идея документ-вью... и все. Главное, что на Нэте можно создавть савременный и качественный GUI, а на свинге тормозных и убогих (функционально) монстриков.
На свинге можно создавать современный и качественный GUI. Скачай и посмотри ту же IDEA — она небольшая. Ну или JBuilder.
VD>>>А чем тебя дата не устраивает? AVK>>Нафига мне для редактирования данных в табличке ADO.NET тащить? Это уже пушкой по воробьям получается. VD>Так он все равно на машине будет стоять. И к тому же это ты не разобрался. Там только датасэты тащутся, они к ADO отношения не имеют.
А расход памяти? А куча ненужных действий для инициализации этой штуки? VD> В конце концов уже наклепано мнофество решений от независимых производтелей, для Явы такого разнообразия никогда не появится.
Естественно. Оно там уже есть.
VD>>> К тому же ты здесь вообще смотришь не верно. У мс своих гридов от родясь не было. Они все делались разными Шариданами и в лайт-версии клались в VB. Если тебе нужен грид посмотри дополнительные компоненты. AVK>>Гы. VD>Что гы? Грамоно действуют. Себе забирают рынок по больше, а другим дают малеьнкие нишки. :))
Еще раз Гы.
VD>>>Понятна. Но спортивная машина... это не совсе корректно. Нэт в большинстве вслучаев все же быстрее, т.е. сам компилятор оптимальнее и есть средства явной оптимизации. AVK>>Не надо сравнивать. Скорость машины в моем примере это не скорость компиляции и программ а скорее надежность программирования. VD>Нда... странные ассоциации... "надежность" и "спортивная машина". :-\
Какая главная характеристика спортивной машины? Скорость и время разгона наверное? А платформы, Отнюдь не скорость, иначе все бы до сих пор на ассемблере писали.
VD>И ты можешь привести пример когда Ява "надежнее" CLR?
А это только практика покажет.
VD>>>Ну, метания это тоже не здрово. AVK>>Кто говорит про метания. Возможность использовать наработаный опыт — один из факторов при выборе плаформы. Только он не определяющий. VD>Это зависит от размеров опыта. :)
Естественно. Но если он становится определяющим — на проект можно положить
VD>Пожалуй, это один из не многих. А что ты думаешь про value-типы?
Здравая мысль. VD>Да и про остальные отличия Нэта?
Какие именно?
AVK>>Тогда уж лучше было бы ввести какой нибудь специальный механизм для классов, выделить их отдельно и соответственно настроить GC на работу с ними, т.е. убрать отложеное удаление, принудительно запускаться или даже реализовывать пул. VD>Нe, по разному можно. Но твой вариант сложен и далек от жизни, а то что я прдлагаю, реализуется легко и дает нужных эфект.
Использование чего то не по назначению не есть хороший метод.
VD>Лажа на твоем 1С-е хоть день... хоть год... То что у нас за те два месяца было сделано от 1С-а отличается одним небольшим достоинством... оно мозги имело и продуманную архитектуру.
Но менять что то реально могли только вы сами.
AVK>>>>И сколько это будет денег стоить? Для маленьких предприятий 1С в России на данный момент лучше всего. VD>>>Я бы уж лучше какой-нить Бэст выбрал. Ну, мозгов в этом 1С нуту. Про производительность лучше вообще молчать. AVK>>Но таки 1С практически монополист на этом рынке.
VD>Канчай ерунду говрить. У них и 20% рынка нет. Кое что отхватили в мелких торговых фирмах...
Цитату прочитай. Я как раз и говорил про маленькие предприятия.
VD>Да нет... Вроде официально объявили только месяц назад... Или это время летит?...
13 февраля. А выложили на неделю раньше. 1 марта объявили в России.
VD>Как-раз CORBA-у к Нэту прикрутить можно.
Как и ActiveX к Java.
AVK>>Всегда приходится начинать с нуля. На дотнет же ты перешел. VD>Пока не совсем.
Ну так и я пока пробую. А на java есть проект который я доделал.
VD>>>Ну, и все не состыкока? .Net — это действительно больше чем Ява, а его переносимость отымет козырную карту критиков. Что не так то? AVK>>Чем больше?
VD>Тем, что Явная VM — это только интерпритатор байт-кода, а у нет это полнофункциональый слой, который прекрасно работает без Шарпа.
Ты удивишся, но JVM — примерно то же самое.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали:
VD>Тебе ответили по поводу EJB. Они в .Net есть, но другие. Проблемы решают те же. Других проблем в библиотеках ты не показал.
В общем слова о том что мол сама идея CMP и CMR изначально бесполезная — для меня неубедительны. Я эти технологии попробовал и убедился в их практической применимости и экономии времени и кода. Спорить на эту тему больше не буду — уже времени не хватает вовремя на такие огромные письма отвечать.
VD>>>Так в чем принципиальная разница? И там и там OLTP, и там и там накопление промежуточных результатов и структурезация данных. AVK>>В форуме еще и OLAP есть?
А нафига он там?
VD>Все зависит, от того как насколько ты правльно и целостно видишь постоновку задачи... Хотя за недельку вообще ничего путного не выйдет. Нормальный софт как минимум месяца два нужно отлаживать.
Один форум? Мне кажется ты преувеличиваешь.
VD>В смысле продовал какие?
Не продавал а использовал в своих разработках.
AVK>>Как минимум часто еще SMTP часто используется. А вобще протокол может быть любой. VD>Откудо ты это взял?
Из спецификации. Вот выдержка
SOAP provides the definition of an XML document which can be used for exchanging structured and typed information between peers in a decentralized, distributed environment. It is fundamentally a stateless, one-way message exchange paradigm, but applications can create more complex interaction patterns (e.g., request/response, request/multiple responses, etc.) by combining such one-way exchanges with features provided by an underlying transport protocol and/or application-specific information.
VD>>>Мои экспременты показывают обратное. Скачай примеры от шустрика посмотри. Ява жрет не меньше, AVK>>Так я и говорю что больше она жрет. VD>Ну, тогда я тебя не поныл...
А что непонятного. Я же тебе уже говорил — я не являюсь ярым сторонником ни одной ни другой платформы. У и дотнеда и у джавы есть свои достоинства и свои недостатки. Ни одна из этих технологий не является безоговорочно лучше другой. В каждом конкретном случае за счет своих особенностей может быть более эффективной как та так и другая технология.
VD> А на счет больше... я этого как то не почувствовал, а вот, то что ей максимльный размер памяти нужно задавать почувствовал. :( Сама возможность этого — это хорошо, но вот то что нельзя просто сказать "используй всю имеющуюся память" — это дико не удобно.
А кто тебе сказал что так нельзя? Если не задавать — именно так и происходит.
AVK>>А чего их искать? Их там есть. Я тут даже упоминал некоторые. Могу еще сказать что в самом языке сильно не хватает свойств и типов-перечислений (это для меня основной недостаток именно языка).
VD>Дохленький какой-то недостаток. Хотя на счет enum-ов я с тобой согласен. Кстати, а ты видел как в Шарпе сделаны маски (aaa | bbb | sss), но атрибутах? Я всегда говрил, что в Паскале сэты сделаны удобно... Вот они вроде услышали. :)
VD>1500-й зачичь? А ты тесты из среды запускаешь или из консоли?
1466. А среда у меня — Far. Так что и из среды и с консоли :)
AVK>>а тип object для экземпляров object не родной? VD>Это частный случай. А этот идеотский подход "навязывается" самой идеологией. :(
Этот подход навязывается ООП.
VD>Не... Мой эфект был 60! А на твоем камне должен быть 50 или даже 40. Это не в два раза... это на порядок!
Так это я уже на рабочем компе пускал. Cel-800.
А ссылки подсчитывать — это очень затратная вещь.
VD>Ну, а то что ссылок нет, так это и замечательно. Я тебе уже второй день толдычу, что использование универсальных в Нэт и Ява сделан глупейшим образом.
Я а тебе талдычу что мне нужны именно ОБЪЕКТЫ!
VD>Вместо того чтобы возложить работу на компилятор все сваливается на рантаймный полиморфизм, а нужно это в одном случае из 1000. Именно из-за этого код написаный на С++ пока что будет быстрее чем аналогичный на Нэт или Яве.
Долой ООП!
VD>Во-первых, ты снова ушел от ответа. ;) VD>А, во-вторых, та рантаймная полимофность которая сплошь и рядом испльзуется в Нэт и Яве, практически никогда не нужна.
Все, дальше можешь не продолжать. Я не считаю ООП безполезным наворотом. А ООП без полиморфности это уже не ООП. Без полиморфности ты не реализуешь практически ни одного паттерна. А программирование без использования паттернов я для себя уже не мыслю. Надоело каждый раз лисапет изобретать.
VD>Если речь идет о хранении ссылог на объекты, то думаю, высокого роста производительности добитья не удастся. Ну, процентов 10 максимум 20. Но в Нэт есть же и value-типы! Тут скорость возрастет на порядок (а скорее всего и больше).
Пробовал. По непонятным причинам оказалось что struct медленее object в полтора раза. Разбираться было лень.
VD>Если хочешь могу провести следственный эксперемент? :)
Давай. VD> Кстати, отсутствие value-типов — это серьезный недостаток Явы!
В плане производительности — да. VD>Они не хотят его устранить?
Не слышал.
AVK>>А про железки это потому что мне приходится не только программить, но еще и заниматься эксплуатацией. И купить железку обычно куда как проще и дешевле нежели переписывать готовый код. VD>Не, переписывать, а оптимизировать. Это две большие разницы. И стоит это обычно дешевле, чем замена и без того не дешевого железа на более дорогое.
У меня почему то чаще бывает обратное.
VD>А если не на 10, а на 1000? Я такие факты видел...
Ну это вряд ли. Не настолько там все тупо сделано.
AVK>>и через 2-3 дня у меня все заработает быстрее на те же 10%, если не быстрее. Вот о чем я пытаюсь сказать. VD>Твоя мысль понятна. И иногда это действительно правильное решение, но все это от безысходности.
От экономии. VD> Вот елси бы ты действительно мог докупив сервачок и вставив его в кластер поднять (пропроцианально) производительность — это было бы дело.
Ну все, убедил. Для систем определенного уровня кластер чего то вроде blade серверов — вполне приемлемое решение.
VD>Ну, это вопрос об упущенной выгое... Вот ты как считаешь, если ли бы ты отдал $500 на более грамотное проектирование системы и еще $500 на оптимизацию алгоритмов, не вышл бы лучше?
Нет, ибо за такие мизерные деньги я бы нифига не получил.
Здравствуйте VladD2, Вы писали:
AVK>>Для списков самый распространенный тип — классы.
VD>Это у тебя стереотипы от Явы.
Это у меня стереотип от ООП и паттернов.
AVK>>Он мене как раз нужен. VD>В конкретном случае. А ты посмотри шире... Этот тормоз же всегда есть.
Я лично для себя не считаю допустимым существенно увеличивать сложность структур в угоду не очень большому приросту быстродействия. Оптимизация по скорости это то чем я буду заниматься в последнюю очередь, когда все уже работает.
AVK>>Он всегда в скорости проигрывает обычной куче. Зато на 100% исключает утечки памяти из-за потеряных указателей. Именно для этого его и придумали. VD>Ошибаешься. Теоритически GC быстрее обычного хипа. ДонБокс замечательный фокус показывал... демострирующий скорость GC. А мотерь памяти и в VB6 небыло.
Были. В случае потери кольца. Ибо его алгоритм простого подсчета ссылок эти вещи не обрабатывал.
VD>Я бы сказал проще, за счет более продуманного алгоритма.
И перерасхода памяти.
AVK>> Да и винамп наверное немножечко влияет, лишний раз контекст передергивает. VD>Не, он почти ничего не жрет... проверено.
Жрать то не жрет. Но контекст задачи и кеши процессора лишний раз сбрасывает.
Здравствуйте VladD2, Вы писали:
VD>Ну, вот простенький... Quake Xxx. Каждая новая версия идет на пределе железа и радует новыми наворотами... и при этом не жертвует играбельностью...
Извини, но это не совсем софт. По крайней мере для меня. VD> Из облати тебе по ближе... SQL Server 2000 или Oracle 9i.
И ты уверен что они работают на грани возможностей железа? Особенно последний, будучи многоплатформенным.
VD>Вот я тебе и говрю, что нужно всзвешивать и выбирать.
И я тебе тоже самое говорю. О чем мы тогда спорим?
AVK>>Потому как очень много потеряю при этом. А что я потеряю от перехода на LinkedList? VD>Ничего. VD>А что ты потеряешь если воспользуешся шаблонами?
А их, как и LinkedList, в C# нету. А так конечно ничего не потеряю.
VD>Не... Я именно этими вопросами и занимался. И что это такое прекрасно знаю. Лажа — это.
Я тоже занимался. И я так не считаю.
AVK>>Так я им говорю что CLR тут никаким местом. VD>Как это не кместу, если функциональность перекрывается на 100%?
Какую функциональность CORBA перекрывает CLI?
AVK>>А что ты в замен CORBA registry предложишь? VD>Я не понмаю что это? Назови это русским языком.
Давай с другой стороны. Для WS эта служба называется UDDI.
AVK>>А в дотнете уже не tlb. Тама WSDL. VD>Господи! От куда ты такого бреда набрался? Меньше читай/смотри рекламу пред сном.
VD>Там сборки!
Это внутренний интерфейс. То что в сборках метаданные хранятся я знаю. VD>А WSDL это открытый язык которым даже Дельфи пользуетя. Но это дело прменимо только к Web-сервисам.
Так и IDL даже Дельфи пользуется. Но применимо это только к CORBA.
AVK>>Ну значит для тебя и многих тысяч программистов java не подходит. Но для других многих тысяч программистов не подходит дотнет а подходит java. VD>Естественно.
О чем тогда спор?
AVK>>Отсутствие дотнета в Линуксе VD>Я еще раз спрашиваю ты про Моно слышал?
Не только слышал. Поэтому и сомневаюсь.
VD>А кто тебе сказал что MS будет отдавать Дэсктоп каким-то там Линухам или Фришкам?
А кто у него спрашивать будет
VD>Так обект определяется его состоянием. В другом месте возьмешь другой объект и загрузишь в него то самое состояние. Между прочим многие EJB-контейнеры так и делают.
Не так. Entity бин он потому и entity что всегда один. И копировать его нельзя.
AVK>>Так у меня они в хештаблице и хранятся. Очередь для другого нужна. VD>А... Понимаю... управляешь памятью в GC-среде. Ну, что же дело перспективное...
Не памятью — активацией/деактивацией персистентных объектов. Этого GC пока не умеет.
AVK>>А зачем мне бешеный расход памяти, если можно SAX'ом обработать? VD>В этом случае лучше обойтись каким нубудь Ораклом, ну, или МайСкулем.
Мне как — ораклевую базу туда/сюда таскать. XML именно для обмена данными нужен. Прайсы магазина я в XML хранить не собираюсь.
VD>Ошибаешся. Зайди на http://dotsite.spb.ru/forum/display_forum.asp?fid=4
Ты всерьез полагаешь что я там не был? Там так же скушно, да к тому же неудобно жутко. Наплодили два десятка форумов в каждом из которых одно сообщение в неделю проскакивает. Есть еще gotdotnet.ru — по началу довольно оживленно было. Потом они тоже вместо одного уже пяток наплодили. В результате и там все почти умерло.
AVK>>А объектная модель то тут при чем? VD>А то что для Явы приходится придумывать "внешние" объектные модели... вроде EJB.
EJB для java это внутренняя модель. J2EE однако.
VD>Я же тебе уже сто раз говорил. В этот раз объекты (хотя можно обойтись и структурами), а в другой int придется. И тут...
Так и я тебе говорю — у меня объекты нужно хранить намного чаще чем int.
Судя по всему у нас с тобой совершенно разные подходы к проектированию. Я стараюсь как можно чаще пользовать паттерны ООП, что в свою очередь подразумевает очень частое использование объектов, полиморфизма и рефлекшена. Переход на простые типы вроде int, чистый SQL и прямое использование WinAPI для меня неприемлемо. И одно из главных преимуществ C# и Java как языков (опять же для меня) — на них максимально просто реализовывать самые часто используемые паттерны.
Поэтому видимо спор наш теряет смысл. Ты меня не убедишь в неправильности моего подхода к проектированию систем, я тебя скорее всего тоже. Поэтому и глядим мы на одни и те же вещи с разных колоколен.
Здравствуйте VladD2, Вы писали:
AVK>>Опасность в том что изменение одной функции непосредственно влияет на остальные. VD>Ты о чем? Поясни.
Чем больше зависимостей внутри кода между его частями тем менее надежен код.
Здравствуйте AndrewVK, Вы писали:
VD>>Они развивают свою идеологию. Им важна не только красота, но и производительность. AVK>Так производительность у Entity бинов, особенно BMP не такая уж и плохая. На некоторых задачах (особенно при большом количестве клиентов) за счет правильного кеширования EJB может быть и побыстрее обычного SQL.
Да. Ну, тогда повтори вот эту операцию.
UPDATE set OperSum = OperSum * 1.2 WHERE OperDate >= '01.01.2002 and OperDate < '01.02.2002'
За одно приведи объем полученого кода на Яве.
Про кеширование я уже говорил в Нэте оно делается в датасете или напрмую в XML-е.
AVK>...И дело тут не в идеологии, а как всегда в бабках. (Ох уж эти бабки, вечно суют свой нос куда не следует. Сидели бы себе на пенсии. :) )
Так бабки идеологию и определяют. :(
VD>>1 и 2. AVK>Если нужно только 1 и 2 — проще и дешевле использовать сервлеты.
Так в нете любой объект может быть серверным причем без доп. программирования.
AVK>Ремоутинг конечно хорошо. Вот только кешировать придется ручками — иначе будут такие тормозаааааааааааааааааааааааааа.
Вроде в COM+-се все было пучечьком...
VD>>...Ты видел ДатаСэты в Нэт? AVK>Видел. Увы — сфера применения подобных технологий весьма ограничена.
Конечно... работой с БД.
AVK>Не защита. Фреймворк для аутентификации и авторизации. Подобное в дотнете есть, но только в asp+.
Ты просто еще не все знаешь. К примеру про терариум занаешь? Попробуй написать свой код который завалит их сервер... Вот тогда поговорим о том что в Нэте нет защиты.
AVK>Я в другом топике показал как мне массив подходит :)
Кстати, там (пока мы разговаривали) MS частично открыл коды Нэта. Все коллекции там есть. Как я и говорил все реализовано на массивах. Так что унаследовать очередь от списка не получится.
VD>>
VD>>UPDATE xxx SET fld1 = fld1 + 123 WHERE yyyy
VD>>
VD>>Проще и эфективнее чем все эти извращения. AVK>Зато менее понятно, больше зависит от конкретного sql сервера, структуры БД.
И что здесь зависит от сервера? Да и понятно все и всем. А главное что эфективенее на три порядка.
AVK>Впрочем сам MS рекомендует пользоваться не дотнет API как можно реже.
В Нэте есть и свои драйверы к БД.
AVK>Основная сложность хранения объектов — преобразование их модели данных к реляционной. Именно здесь случается основной оверхед. А xml уже как бы имеет нереляционную структуру. Хранить же состояние объектов в xml очень легко.
Я не знаю кто чего имеет, вот только в xml курсоры БД превращаются в лет. И работать удобно и эфективно.
VD>> Да и хранить его по человечески БД еще не научилиь, робкие попытки Informix-а в серьез можно не воспринмать. AVK>А MSSQL чего? Не катит? Я тут один проектик (веб) видел на asp.net. Там ребятки описывают объекты на xml, затем благополучно хранят их ввиде этого самого xml в базе (mssql естественно), а при выводе накидывают xslt прямо на выборку. Все очень красиво.
MSSQL умеет выдавать данные в виде XML, но эфективно хранить XML он не умеет, только в виде обычной текстовой строки.
AVK>>>Автоматические транзакции, в т.ч. и распределенные. VD>>Ну, это в COM+-се (а вернее MTS-е) было за долго появления их в CORBA-е и Яве. AVK>Да ладно тебе. CORBA уже фиг знает сколько лет.
Спецификация была, а реализации были такими убогими... Да и спецификация за последнее время сильно изменилась.
VD>>И на сегодня COM+-самая масшатабируемая система управления распределенными тарнзакциями (ссылку на источник давать? :) ). Через некоторое время появится подобная функциональность и для Чистого Нэта, пока можно перебиться COM+-ом. AVK>Тут кто то писал о том что COM+ в дотнете поддерживается очень криво и MS не собирается это менять "по идеологическим причинам".
Чушь этот ктото писал.
AVK>А вот под задачи где нужны выборки в несколько миллионов записей подобные системы совершенно не рассчитаны. Как впрочем и ado.net тоже. А кеширование там весьма правильное, поскольку для сервера доступно куда больше информации о выполняемых задачах чем для сервера БД.
Если кеширование такое правильное, почему Ява и серверы на ее базе не попдают в качестве серверов транзакций в рейтинки tpc.org?
VD>>Ну, а Entity бины — изначально дохлая идея. AVK>Странно только — на что та же BEA живет? У ней ведь WebLogic — основной продукт.
Ну, по нашим меркам живет. А так прозибает...
AVK>На свинге можно создавать современный и качественный GUI. Скачай и посмотри ту же IDEA — она небольшая. Ну или JBuilder.
Дай прямой линк на IDEA. Ну, а JBuilder довольно тормозной продукт с интерфейсом значительно уступающим VC.Net.
AVK>Какая главная характеристика спортивной машины? Скорость и время разгона наверное? А платформы, Отнюдь не скорость, иначе все бы до сих пор на ассемблере писали.
Ну, а зачем тогда такие аналогии проводить?
VD>>И ты можешь привести пример когда Ява "надежнее" CLR? AVK>А это только практика покажет.
Ну, а зачем тогда говорить ерунду непроверенную?
VD>>А что ты думаешь про value-типы? VD>>Да и про остальные отличия Нэта? AVK>Какие именно?
Ну, хотя бы value-типы, unsafe-режим, нововедения в C#.
AVK>Использование чего то не по назначению не есть хороший метод.
А что там не по назначению, то? В С++ деструкторы существовали десятки лет и все было по назначению.
VD>>Как-раз CORBA-у к Нэту прикрутить можно. AVK>Как и ActiveX к Java.
Можем на спор соревнуться. ;) Ты прикрутишь к яве Ax-ы, а я корбу из Ныта заюзаю. :))
VD>>Тем, что Явная VM — это только интерпритатор байт-кода, а у нет это полнофункциональый слой, который прекрасно работает без Шарпа. AVK>Ты удивишся, но JVM — примерно то же самое.
Примерно, да дне тоже. Как минимум возможность интерпретатци и нет промежуточного языка.
Здравствуйте VladD2, Вы писали:
VD>Да. Ну, тогда повтори вот эту операцию.
VD>
VD>UPDATE set OperSum = OperSum * 1.2 WHERE OperDate >= '01.01.2002 and OperDate < '01.02.2002'
VD>
Видишь ли — для EJB тут информации недостаточно. EJB работают в объектной области а не в реляционной. Поэтому важно знать смысл данной обработки. ВПрочем можно на EJB базу натравить такой же update.
VD>Про кеширование я уже говорил в Нэте оно делается в датасете или напрмую в XML-е.
Это немножко не то кеширование. Кеширование аналогичное EJB не реализуемо на датасетах в принципе. Дело в том что при работе с датасетами у нас нет информации какую сущность они представляют. В EJB же механизм примерно такой:
при первом запросу сущности происходит поиск и загрузка этой сущности из базы. При этом она помещается в кеш. Все последующие обращения к этой сущности будут приводить просто к ее выборке из кеша. Если же у тебя датасет — не зная как сущность выражена в таблицах ты подобный алгоритм реализовать не сможешь.
VD>>>1 и 2. AVK>>Если нужно только 1 и 2 — проще и дешевле использовать сервлеты. VD>Так в нете любой объект может быть серверным причем без доп. программирования.
Сервлеты это не просто серверные объекты. Сервлеты — аналоги HttpHandler в ASP+
AVK>>Видел. Увы — сфера применения подобных технологий весьма ограничена. VD>Конечно... работой с БД.
Нет. WS большей частью и некоторыми разновидностями трехзвенки. Управление руками процессом выборки в память для обычных sql-клиентов просто лишнее, для таких задач обычный ADO подходит лучше.
AVK>>Не защита. Фреймворк для аутентификации и авторизации. Подобное в дотнете есть, но только в asp+. VD>Ты просто еще не все знаешь. К примеру про терариум занаешь? Попробуй написать свой код который завалит их сервер... Вот тогда поговорим о том что в Нэте нет защиты.
Еще раз — JAAS никакого отношения к защите не имеет. Это фреймфорк для аутентификации и авторизации. То что в виндовсе реализуется целым зоопарком API и технологий. Вроде бы есть стандартный windows authentification, но в mssql до сих пор пользуют свой собственный, потому как виндовый неудобен. В старом asp тоже вроде windows authentification использовали. В asp+ свой собственный механизм. Не пора ли сделать что то стандартное?
AVK>>Я в другом топике показал как мне массив подходит :) VD>Кстати, там (пока мы разговаривали) MS частично открыл коды Нэта. Все коллекции там есть. Как я и говорил все реализовано на массивах. Так что унаследовать очередь от списка не получится.
Ты имеешь ввиду CLI? Кинь тогда мне исходники списков, все качать неохота.
И зачем наследовать очередь от списка? И от какого? Или ты IList имеешь ввиду? Так это не класс а интерфейс. От него не наследовать, его реализовывать надо.
VD>>>
VD>>>UPDATE xxx SET fld1 = fld1 + 123 WHERE yyyy
VD>>>
VD>>>Проще и эфективнее чем все эти извращения. AVK>>Зато менее понятно, больше зависит от конкретного sql сервера, структуры БД. VD>И что здесь зависит от сервера? Да и понятно все и всем. А главное что эфективенее на три порядка.
Что тут понятно? Нифига тут не понятно. Кто такой fld1? Что такое yyyy. А если у тебя есть целостность, которую нельзя выразить при помощи check и reference constraints? Тут у тебя два пути — либо писать триггеры и sp, а это уже зависит от сервера, либо втаскивать в клиента логику которая будет твою целостность поддерживать — а это приведет к серьезному усложнению и запутыванию кода.
Впрочем есть же EJB-QL, тот же SQL, но ориентированный на работу с объектами.
AVK>>Впрочем сам MS рекомендует пользоваться не дотнет API как можно реже. VD>В Нэте есть и свои драйверы к БД.
Да много там чего своего. XML-парсер к примеру.
VD>Я не знаю кто чего имеет, вот только в xml курсоры БД превращаются в лет. И работать удобно и эфективно.
Не, из чего то в xml это очень легко. В этом вся прелесть xml и есть. А вот из xml во что то — уже намного сложнее.
AVK>>А MSSQL чего? Не катит? Я тут один проектик (веб) видел на asp.net. Там ребятки описывают объекты на xml, затем благополучно хранят их ввиде этого самого xml в базе (mssql естественно), а при выводе накидывают xslt прямо на выборку. Все очень красиво. VD>MSSQL умеет выдавать данные в виде XML, но эфективно хранить XML он не умеет, только в виде обычной текстовой строки.
Я особо не разбирался, но там он именно xml хранил, не ввиде текстовой строки. Вроде бы там использовалось что то дополнительно, тоже от MS но в поставку sql 2000 не входящее. Возможно какие то фишки от Commerce Server или Content Management Server.
AVK>>>>Автоматические транзакции, в т.ч. и распределенные. VD>>>Ну, это в COM+-се (а вернее MTS-е) было за долго появления их в CORBA-е и Яве. AVK>>Да ладно тебе. CORBA уже фиг знает сколько лет. VD>Спецификация была, а реализации были такими убогими... Да и спецификация за последнее время сильно изменилась.
Тебе рассказать про убогость первых реализаций DCOM. У меня тут один проект из-за DCOM чуть не завалился. То есть — писали проект, трехзвенка на DCOM. И все было хорошо. До определенного момента. А потом при приличной нагрузке оно иногда стало вылетать с малопонятными исключениями. Перекопали весь код — ошибок не нашли. Хорошо что система была спроектирована так что механизм взаимодействия был очень хорошо изолирован от всего остального и переписать под CORBA с VisiBrocker удалось быстро. После этого все глюки пропали и больше не появлялись.
AVK>>Тут кто то писал о том что COM+ в дотнете поддерживается очень криво и MS не собирается это менять "по идеологическим причинам". VD>Чушь этот ктото писал.
Да нет, там даже какие то цитаты от MS были.
VD>Если кеширование такое правильное, почему Ява и серверы на ее базе не попдают в качестве серверов транзакций в рейтинки tpc.org?
А ты про этот тест почитай — что он делает. Для EJB он абсолютно не подходит. Для EJB есть ECPerf.
VD>>>Ну, а Entity бины — изначально дохлая идея. AVK>>Странно только — на что та же BEA живет? У ней ведь WebLogic — основной продукт. VD>Ну, по нашим меркам живет. А так прозибает...
Да нет, очень даже неплохо живет. Акции постоянно растут, даже в теперешнее тяжелое время.
VD>Дай прямой линк на IDEA. http://www.intellij.com/downloads/idea-2_5_2.zip
но там все равно регистрироваться нужно чтобы evaluation key получить
VD>Ну, а JBuilder довольно тормозной продукт с интерфейсом значительно уступающим VC.Net.
Ты какую версию последней видел?
AVK>>Какая главная характеристика спортивной машины? Скорость и время разгона наверное? А платформы, Отнюдь не скорость, иначе все бы до сих пор на ассемблере писали. VD>Ну, а зачем тогда такие аналогии проводить?
А ты измерения преобразовать не в состоянии?
VD>>>Да и про остальные отличия Нэта? AVK>>Какие именно?
VD>unsafe-режим,
Трудно сказать насколько он необходим. Мне он просто не нужен в текущих задачах. Так что даже не знаю.
VD> нововедения в C#.
Какие именно?
AVK>>Использование чего то не по назначению не есть хороший метод. VD>А что там не по назначению, то? В С++ деструкторы существовали десятки лет и все было по назначению.
struct не есть объект в чистом виде. Они для другого предназначены — для хранения сложных наборов данных.
VD>>>Как-раз CORBA-у к Нэту прикрутить можно. AVK>>Как и ActiveX к Java. VD>Можем на спор соревнуться. ;) Ты прикрутишь к яве Ax-ы, а я корбу из Ныта заюзаю. :))
Ага, ты CORBA клиента руками писать будешь? А я просто COM2Java bridge заюзаю.
AVK>>Ты удивишся, но JVM — примерно то же самое. VD>Примерно, да дне тоже. Как минимум возможность интерпретатци
Возможность интерпретации чего? VD> и нет промежуточного языка.
А куда ж он делся. У Java тоже свой ассемблер есть.
Здравствуйте VladD2, Вы писали:
VD>Да. Ну, тогда повтори вот эту операцию.
VD>
VD>UPDATE set OperSum = OperSum * 1.2 WHERE OperDate >= '01.01.2002 and OperDate < '01.02.2002'
VD>
Видишь ли — для EJB тут информации недостаточно. EJB работают в объектной области а не в реляционной. Поэтому важно знать смысл данной обработки. ВПрочем можно на EJB базу натравить такой же update.
VD>Про кеширование я уже говорил в Нэте оно делается в датасете или напрмую в XML-е.
Это немножко не то кеширование. Кеширование аналогичное EJB не реализуемо на датасетах в принципе. Дело в том что при работе с датасетами у нас нет информации какую сущность они представляют. В EJB же механизм примерно такой:
при первом запросу сущности происходит поиск и загрузка этой сущности из базы. При этом она помещается в кеш. Все последующие обращения к этой сущности будут приводить просто к ее выборке из кеша. Если же у тебя датасет — не зная как сущность выражена в таблицах ты подобный алгоритм реализовать не сможешь.
VD>>>1 и 2. AVK>>Если нужно только 1 и 2 — проще и дешевле использовать сервлеты. VD>Так в нете любой объект может быть серверным причем без доп. программирования.
Сервлеты это не просто серверные объекты. Сервлеты — аналоги HttpHandler в ASP+
AVK>>Видел. Увы — сфера применения подобных технологий весьма ограничена. VD>Конечно... работой с БД.
Нет. WS большей частью и некоторыми разновидностями трехзвенки. Управление руками процессом выборки в память для обычных sql-клиентов просто лишнее, для таких задач обычный ADO подходит лучше.
AVK>>Не защита. Фреймворк для аутентификации и авторизации. Подобное в дотнете есть, но только в asp+. VD>Ты просто еще не все знаешь. К примеру про терариум занаешь? Попробуй написать свой код который завалит их сервер... Вот тогда поговорим о том что в Нэте нет защиты.
Еще раз — JAAS никакого отношения к защите не имеет. Это фреймфорк для аутентификации и авторизации. То что в виндовсе реализуется целым зоопарком API и технологий. Вроде бы есть стандартный windows authentification, но в mssql до сих пор пользуют свой собственный, потому как виндовый неудобен. В старом asp тоже вроде windows authentification использовали. В asp+ свой собственный механизм. Не пора ли сделать что то стандартное?
AVK>>Я в другом топике показал как мне массив подходит :) VD>Кстати, там (пока мы разговаривали) MS частично открыл коды Нэта. Все коллекции там есть. Как я и говорил все реализовано на массивах. Так что унаследовать очередь от списка не получится.
Ты имеешь ввиду CLI? Кинь тогда мне исходники списков, все качать неохота.
И зачем наследовать очередь от списка? И от какого? Или ты IList имеешь ввиду? Так это не класс а интерфейс. От него не наследовать, его реализовывать надо.
VD>>>
VD>>>UPDATE xxx SET fld1 = fld1 + 123 WHERE yyyy
VD>>>
VD>>>Проще и эфективнее чем все эти извращения. AVK>>Зато менее понятно, больше зависит от конкретного sql сервера, структуры БД. VD>И что здесь зависит от сервера? Да и понятно все и всем. А главное что эфективенее на три порядка.
Что тут понятно? Нифига тут не понятно. Кто такой fld1? Что такое yyyy. А если у тебя есть целостность, которую нельзя выразить при помощи check и reference constraints? Тут у тебя два пути — либо писать триггеры и sp, а это уже зависит от сервера, либо втаскивать в клиента логику которая будет твою целостность поддерживать — а это приведет к серьезному усложнению и запутыванию кода.
Впрочем есть же EJB-QL, тот же SQL, но ориентированный на работу с объектами.
AVK>>Впрочем сам MS рекомендует пользоваться не дотнет API как можно реже. VD>В Нэте есть и свои драйверы к БД.
Да много там чего своего. XML-парсер к примеру.
VD>Я не знаю кто чего имеет, вот только в xml курсоры БД превращаются в лет. И работать удобно и эфективно.
Не, из чего то в xml это очень легко. В этом вся прелесть xml и есть. А вот из xml во что то — уже намного сложнее.
AVK>>А MSSQL чего? Не катит? Я тут один проектик (веб) видел на asp.net. Там ребятки описывают объекты на xml, затем благополучно хранят их ввиде этого самого xml в базе (mssql естественно), а при выводе накидывают xslt прямо на выборку. Все очень красиво. VD>MSSQL умеет выдавать данные в виде XML, но эфективно хранить XML он не умеет, только в виде обычной текстовой строки.
Я особо не разбирался, но там он именно xml хранил, не ввиде текстовой строки. Вроде бы там использовалось что то дополнительно, тоже от MS но в поставку sql 2000 не входящее. Возможно какие то фишки от Commerce Server или Content Management Server.
AVK>>>>Автоматические транзакции, в т.ч. и распределенные. VD>>>Ну, это в COM+-се (а вернее MTS-е) было за долго появления их в CORBA-е и Яве. AVK>>Да ладно тебе. CORBA уже фиг знает сколько лет. VD>Спецификация была, а реализации были такими убогими... Да и спецификация за последнее время сильно изменилась.
Тебе рассказать про убогость первых реализаций DCOM. У меня тут один проект из-за DCOM чуть не завалился. То есть — писали проект, трехзвенка на DCOM. И все было хорошо. До определенного момента. А потом при приличной нагрузке оно иногда стало вылетать с малопонятными исключениями. Перекопали весь код — ошибок не нашли. Хорошо что система была спроектирована так что механизм взаимодействия был очень хорошо изолирован от всего остального и переписать под CORBA с VisiBrocker удалось быстро. После этого все глюки пропали и больше не появлялись.
AVK>>Тут кто то писал о том что COM+ в дотнете поддерживается очень криво и MS не собирается это менять "по идеологическим причинам". VD>Чушь этот ктото писал.
Да нет, там даже какие то цитаты от MS были.
VD>Если кеширование такое правильное, почему Ява и серверы на ее базе не попдают в качестве серверов транзакций в рейтинки tpc.org?
А ты про этот тест почитай — что он делает. Для EJB он абсолютно не подходит. Для EJB есть ECPerf.
VD>>>Ну, а Entity бины — изначально дохлая идея. AVK>>Странно только — на что та же BEA живет? У ней ведь WebLogic — основной продукт. VD>Ну, по нашим меркам живет. А так прозибает...
Да нет, очень даже неплохо живет. Акции постоянно растут, даже в теперешнее тяжелое время.
VD>Дай прямой линк на IDEA. http://www.intellij.com/downloads/idea-2_5_2.zip
но там все равно регистрироваться нужно чтобы evaluation key получить
VD>Ну, а JBuilder довольно тормозной продукт с интерфейсом значительно уступающим VC.Net.
Ты какую версию последней видел?
AVK>>Какая главная характеристика спортивной машины? Скорость и время разгона наверное? А платформы, Отнюдь не скорость, иначе все бы до сих пор на ассемблере писали. VD>Ну, а зачем тогда такие аналогии проводить?
А ты измерения преобразовать не в состоянии?
VD>>>Да и про остальные отличия Нэта? AVK>>Какие именно?
VD>unsafe-режим,
Трудно сказать насколько он необходим. Мне он просто не нужен в текущих задачах. Так что даже не знаю.
VD> нововедения в C#.
Какие именно?
AVK>>Использование чего то не по назначению не есть хороший метод. VD>А что там не по назначению, то? В С++ деструкторы существовали десятки лет и все было по назначению.
struct не есть объект в чистом виде. Они для другого предназначены — для хранения сложных наборов данных.
VD>>>Как-раз CORBA-у к Нэту прикрутить можно. AVK>>Как и ActiveX к Java. VD>Можем на спор соревнуться. ;) Ты прикрутишь к яве Ax-ы, а я корбу из Ныта заюзаю. :))
Ага, ты CORBA клиента руками писать будешь? А я просто COM2Java bridge заюзаю.
AVK>>Ты удивишся, но JVM — примерно то же самое. VD>Примерно, да дне тоже. Как минимум возможность интерпретатци
Возможность интерпретации чего? VD> и нет промежуточного языка.
А куда ж он делся. У Java тоже свой ассемблер есть.
Здравствуйте VladD2, Вы писали:
VD>Да. Ну, тогда повтори вот эту операцию.
VD>
VD>UPDATE set OperSum = OperSum * 1.2 WHERE OperDate >= '01.01.2002 and OperDate < '01.02.2002'
VD>
Видишь ли — для EJB тут информации недостаточно. EJB работают в объектной области а не в реляционной. Поэтому важно знать смысл данной обработки. ВПрочем можно на EJB базу натравить такой же update.
VD>Про кеширование я уже говорил в Нэте оно делается в датасете или напрмую в XML-е.
Это немножко не то кеширование. Кеширование аналогичное EJB не реализуемо на датасетах в принципе. Дело в том что при работе с датасетами у нас нет информации какую сущность они представляют. В EJB же механизм примерно такой:
при первом запросу сущности происходит поиск и загрузка этой сущности из базы. При этом она помещается в кеш. Все последующие обращения к этой сущности будут приводить просто к ее выборке из кеша. Если же у тебя датасет — не зная как сущность выражена в таблицах ты подобный алгоритм реализовать не сможешь.
VD>>>1 и 2. AVK>>Если нужно только 1 и 2 — проще и дешевле использовать сервлеты. VD>Так в нете любой объект может быть серверным причем без доп. программирования.
Сервлеты это не просто серверные объекты. Сервлеты — аналоги HttpHandler в ASP+
AVK>>Видел. Увы — сфера применения подобных технологий весьма ограничена. VD>Конечно... работой с БД.
Нет. WS большей частью и некоторыми разновидностями трехзвенки. Управление руками процессом выборки в память для обычных sql-клиентов просто лишнее, для таких задач обычный ADO подходит лучше.
AVK>>Не защита. Фреймворк для аутентификации и авторизации. Подобное в дотнете есть, но только в asp+. VD>Ты просто еще не все знаешь. К примеру про терариум занаешь? Попробуй написать свой код который завалит их сервер... Вот тогда поговорим о том что в Нэте нет защиты.
Еще раз — JAAS никакого отношения к защите не имеет. Это фреймфорк для аутентификации и авторизации. То что в виндовсе реализуется целым зоопарком API и технологий. Вроде бы есть стандартный windows authentification, но в mssql до сих пор пользуют свой собственный, потому как виндовый неудобен. В старом asp тоже вроде windows authentification использовали. В asp+ свой собственный механизм. Не пора ли сделать что то стандартное?
AVK>>Я в другом топике показал как мне массив подходит :) VD>Кстати, там (пока мы разговаривали) MS частично открыл коды Нэта. Все коллекции там есть. Как я и говорил все реализовано на массивах. Так что унаследовать очередь от списка не получится.
Ты имеешь ввиду CLI? Кинь тогда мне исходники списков, все качать неохота.
И зачем наследовать очередь от списка? И от какого? Или ты IList имеешь ввиду? Так это не класс а интерфейс. От него не наследовать, его реализовывать надо.
VD>>>
VD>>>UPDATE xxx SET fld1 = fld1 + 123 WHERE yyyy
VD>>>
VD>>>Проще и эфективнее чем все эти извращения. AVK>>Зато менее понятно, больше зависит от конкретного sql сервера, структуры БД. VD>И что здесь зависит от сервера? Да и понятно все и всем. А главное что эфективенее на три порядка.
Что тут понятно? Нифига тут не понятно. Кто такой fld1? Что такое yyyy. А если у тебя есть целостность, которую нельзя выразить при помощи check и reference constraints? Тут у тебя два пути — либо писать триггеры и sp, а это уже зависит от сервера, либо втаскивать в клиента логику которая будет твою целостность поддерживать — а это приведет к серьезному усложнению и запутыванию кода.
Впрочем есть же EJB-QL, тот же SQL, но ориентированный на работу с объектами.
AVK>>Впрочем сам MS рекомендует пользоваться не дотнет API как можно реже. VD>В Нэте есть и свои драйверы к БД.
Да много там чего своего. XML-парсер к примеру.
VD>Я не знаю кто чего имеет, вот только в xml курсоры БД превращаются в лет. И работать удобно и эфективно.
Не, из чего то в xml это очень легко. В этом вся прелесть xml и есть. А вот из xml во что то — уже намного сложнее.
AVK>>А MSSQL чего? Не катит? Я тут один проектик (веб) видел на asp.net. Там ребятки описывают объекты на xml, затем благополучно хранят их ввиде этого самого xml в базе (mssql естественно), а при выводе накидывают xslt прямо на выборку. Все очень красиво. VD>MSSQL умеет выдавать данные в виде XML, но эфективно хранить XML он не умеет, только в виде обычной текстовой строки.
Я особо не разбирался, но там он именно xml хранил, не ввиде текстовой строки. Вроде бы там использовалось что то дополнительно, тоже от MS но в поставку sql 2000 не входящее. Возможно какие то фишки от Commerce Server или Content Management Server.
AVK>>>>Автоматические транзакции, в т.ч. и распределенные. VD>>>Ну, это в COM+-се (а вернее MTS-е) было за долго появления их в CORBA-е и Яве. AVK>>Да ладно тебе. CORBA уже фиг знает сколько лет. VD>Спецификация была, а реализации были такими убогими... Да и спецификация за последнее время сильно изменилась.
Тебе рассказать про убогость первых реализаций DCOM. У меня тут один проект из-за DCOM чуть не завалился. То есть — писали проект, трехзвенка на DCOM. И все было хорошо. До определенного момента. А потом при приличной нагрузке оно иногда стало вылетать с малопонятными исключениями. Перекопали весь код — ошибок не нашли. Хорошо что система была спроектирована так что механизм взаимодействия был очень хорошо изолирован от всего остального и переписать под CORBA с VisiBrocker удалось быстро. После этого все глюки пропали и больше не появлялись.
AVK>>Тут кто то писал о том что COM+ в дотнете поддерживается очень криво и MS не собирается это менять "по идеологическим причинам". VD>Чушь этот ктото писал.
Да нет, там даже какие то цитаты от MS были.
VD>Если кеширование такое правильное, почему Ява и серверы на ее базе не попдают в качестве серверов транзакций в рейтинки tpc.org?
А ты про этот тест почитай — что он делает. Для EJB он абсолютно не подходит. Для EJB есть ECPerf.
VD>>>Ну, а Entity бины — изначально дохлая идея. AVK>>Странно только — на что та же BEA живет? У ней ведь WebLogic — основной продукт. VD>Ну, по нашим меркам живет. А так прозибает...
Да нет, очень даже неплохо живет. Акции постоянно растут, даже в теперешнее тяжелое время.
VD>Дай прямой линк на IDEA. http://www.intellij.com/downloads/idea-2_5_2.zip
но там все равно регистрироваться нужно чтобы evaluation key получить
VD>Ну, а JBuilder довольно тормозной продукт с интерфейсом значительно уступающим VC.Net.
Ты какую версию последней видел?
AVK>>Какая главная характеристика спортивной машины? Скорость и время разгона наверное? А платформы, Отнюдь не скорость, иначе все бы до сих пор на ассемблере писали. VD>Ну, а зачем тогда такие аналогии проводить?
А ты измерения преобразовать не в состоянии?
VD>>>Да и про остальные отличия Нэта? AVK>>Какие именно?
VD>unsafe-режим,
Трудно сказать насколько он необходим. Мне он просто не нужен в текущих задачах. Так что даже не знаю.
VD> нововедения в C#.
Какие именно?
AVK>>Использование чего то не по назначению не есть хороший метод. VD>А что там не по назначению, то? В С++ деструкторы существовали десятки лет и все было по назначению.
struct не есть объект в чистом виде. Они для другого предназначены — для хранения сложных наборов данных.
VD>>>Как-раз CORBA-у к Нэту прикрутить можно. AVK>>Как и ActiveX к Java. VD>Можем на спор соревнуться. ;) Ты прикрутишь к яве Ax-ы, а я корбу из Ныта заюзаю. :))
Ага, ты CORBA клиента руками писать будешь? А я просто COM2Java bridge заюзаю.
AVK>>Ты удивишся, но JVM — примерно то же самое. VD>Примерно, да дне тоже. Как минимум возможность интерпретатци
Возможность интерпретации чего? VD> и нет промежуточного языка.
А куда ж он делся. У Java тоже свой ассемблер есть.
Здравствуйте VladD2, Вы писали:
VD>Да. Ну, тогда повтори вот эту операцию.
VD>
VD>UPDATE set OperSum = OperSum * 1.2 WHERE OperDate >= '01.01.2002 and OperDate < '01.02.2002'
VD>
Видишь ли — для EJB тут информации недостаточно. EJB работают в объектной области а не в реляционной. Поэтому важно знать смысл данной обработки. ВПрочем можно на EJB базу натравить такой же update.
VD>Про кеширование я уже говорил в Нэте оно делается в датасете или напрмую в XML-е.
Это немножко не то кеширование. Кеширование аналогичное EJB не реализуемо на датасетах в принципе. Дело в том что при работе с датасетами у нас нет информации какую сущность они представляют. В EJB же механизм примерно такой:
при первом запросу сущности происходит поиск и загрузка этой сущности из базы. При этом она помещается в кеш. Все последующие обращения к этой сущности будут приводить просто к ее выборке из кеша. Если же у тебя датасет — не зная как сущность выражена в таблицах ты подобный алгоритм реализовать не сможешь.
VD>>>1 и 2. AVK>>Если нужно только 1 и 2 — проще и дешевле использовать сервлеты. VD>Так в нете любой объект может быть серверным причем без доп. программирования.
Сервлеты это не просто серверные объекты. Сервлеты — аналоги HttpHandler в ASP+
AVK>>Видел. Увы — сфера применения подобных технологий весьма ограничена. VD>Конечно... работой с БД.
Нет. WS большей частью и некоторыми разновидностями трехзвенки. Управление руками процессом выборки в память для обычных sql-клиентов просто лишнее, для таких задач обычный ADO подходит лучше.
AVK>>Не защита. Фреймворк для аутентификации и авторизации. Подобное в дотнете есть, но только в asp+. VD>Ты просто еще не все знаешь. К примеру про терариум занаешь? Попробуй написать свой код который завалит их сервер... Вот тогда поговорим о том что в Нэте нет защиты.
Еще раз — JAAS никакого отношения к защите не имеет. Это фреймфорк для аутентификации и авторизации. То что в виндовсе реализуется целым зоопарком API и технологий. Вроде бы есть стандартный windows authentification, но в mssql до сих пор пользуют свой собственный, потому как виндовый неудобен. В старом asp тоже вроде windows authentification использовали. В asp+ свой собственный механизм. Не пора ли сделать что то стандартное?
AVK>>Я в другом топике показал как мне массив подходит :) VD>Кстати, там (пока мы разговаривали) MS частично открыл коды Нэта. Все коллекции там есть. Как я и говорил все реализовано на массивах. Так что унаследовать очередь от списка не получится.
Ты имеешь ввиду CLI? Кинь тогда мне исходники списков, все качать неохота.
И зачем наследовать очередь от списка? И от какого? Или ты IList имеешь ввиду? Так это не класс а интерфейс. От него не наследовать, его реализовывать надо.
VD>>>
VD>>>UPDATE xxx SET fld1 = fld1 + 123 WHERE yyyy
VD>>>
VD>>>Проще и эфективнее чем все эти извращения. AVK>>Зато менее понятно, больше зависит от конкретного sql сервера, структуры БД. VD>И что здесь зависит от сервера? Да и понятно все и всем. А главное что эфективенее на три порядка.
Что тут понятно? Нифига тут не понятно. Кто такой fld1? Что такое yyyy. А если у тебя есть целостность, которую нельзя выразить при помощи check и reference constraints? Тут у тебя два пути — либо писать триггеры и sp, а это уже зависит от сервера, либо втаскивать в клиента логику которая будет твою целостность поддерживать — а это приведет к серьезному усложнению и запутыванию кода.
Впрочем есть же EJB-QL, тот же SQL, но ориентированный на работу с объектами.
AVK>>Впрочем сам MS рекомендует пользоваться не дотнет API как можно реже. VD>В Нэте есть и свои драйверы к БД.
Да много там чего своего. XML-парсер к примеру.
VD>Я не знаю кто чего имеет, вот только в xml курсоры БД превращаются в лет. И работать удобно и эфективно.
Не, из чего то в xml это очень легко. В этом вся прелесть xml и есть. А вот из xml во что то — уже намного сложнее.
AVK>>А MSSQL чего? Не катит? Я тут один проектик (веб) видел на asp.net. Там ребятки описывают объекты на xml, затем благополучно хранят их ввиде этого самого xml в базе (mssql естественно), а при выводе накидывают xslt прямо на выборку. Все очень красиво. VD>MSSQL умеет выдавать данные в виде XML, но эфективно хранить XML он не умеет, только в виде обычной текстовой строки.
Я особо не разбирался, но там он именно xml хранил, не ввиде текстовой строки. Вроде бы там использовалось что то дополнительно, тоже от MS но в поставку sql 2000 не входящее. Возможно какие то фишки от Commerce Server или Content Management Server.
AVK>>>>Автоматические транзакции, в т.ч. и распределенные. VD>>>Ну, это в COM+-се (а вернее MTS-е) было за долго появления их в CORBA-е и Яве. AVK>>Да ладно тебе. CORBA уже фиг знает сколько лет. VD>Спецификация была, а реализации были такими убогими... Да и спецификация за последнее время сильно изменилась.
Тебе рассказать про убогость первых реализаций DCOM. У меня тут один проект из-за DCOM чуть не завалился. То есть — писали проект, трехзвенка на DCOM. И все было хорошо. До определенного момента. А потом при приличной нагрузке оно иногда стало вылетать с малопонятными исключениями. Перекопали весь код — ошибок не нашли. Хорошо что система была спроектирована так что механизм взаимодействия был очень хорошо изолирован от всего остального и переписать под CORBA с VisiBrocker удалось быстро. После этого все глюки пропали и больше не появлялись.
AVK>>Тут кто то писал о том что COM+ в дотнете поддерживается очень криво и MS не собирается это менять "по идеологическим причинам". VD>Чушь этот ктото писал.
Да нет, там даже какие то цитаты от MS были.
VD>Если кеширование такое правильное, почему Ява и серверы на ее базе не попдают в качестве серверов транзакций в рейтинки tpc.org?
А ты про этот тест почитай — что он делает. Для EJB он абсолютно не подходит. Для EJB есть ECPerf.
VD>>>Ну, а Entity бины — изначально дохлая идея. AVK>>Странно только — на что та же BEA живет? У ней ведь WebLogic — основной продукт. VD>Ну, по нашим меркам живет. А так прозибает...
Да нет, очень даже неплохо живет. Акции постоянно растут, даже в теперешнее тяжелое время.
VD>Дай прямой линк на IDEA. http://www.intellij.com/downloads/idea-2_5_2.zip
но там все равно регистрироваться нужно чтобы evaluation key получить
VD>Ну, а JBuilder довольно тормозной продукт с интерфейсом значительно уступающим VC.Net.
Ты какую версию последней видел?
AVK>>Какая главная характеристика спортивной машины? Скорость и время разгона наверное? А платформы, Отнюдь не скорость, иначе все бы до сих пор на ассемблере писали. VD>Ну, а зачем тогда такие аналогии проводить?
А ты измерения преобразовать не в состоянии?
VD>>>Да и про остальные отличия Нэта? AVK>>Какие именно?
VD>unsafe-режим,
Трудно сказать насколько он необходим. Мне он просто не нужен в текущих задачах. Так что даже не знаю.
VD> нововедения в C#.
Какие именно?
AVK>>Использование чего то не по назначению не есть хороший метод. VD>А что там не по назначению, то? В С++ деструкторы существовали десятки лет и все было по назначению.
struct не есть объект в чистом виде. Они для другого предназначены — для хранения сложных наборов данных.
VD>>>Как-раз CORBA-у к Нэту прикрутить можно. AVK>>Как и ActiveX к Java. VD>Можем на спор соревнуться. ;) Ты прикрутишь к яве Ax-ы, а я корбу из Ныта заюзаю. :))
Ага, ты CORBA клиента руками писать будешь? А я просто COM2Java bridge заюзаю.
AVK>>Ты удивишся, но JVM — примерно то же самое. VD>Примерно, да дне тоже. Как минимум возможность интерпретатци
Возможность интерпретации чего? VD> и нет промежуточного языка.
А куда ж он делся. У Java тоже свой ассемблер есть.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте VladD2, Вы писали:
AVK>>>Опасность в том что изменение одной функции непосредственно влияет на остальные. VD>>Ты о чем? Поясни. AVK>Чем больше зависимостей внутри кода между его частями тем менее надежен код.
Ну, и причем тут это?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.