Скажи Microsoft НЕТ!

← →
Soft © (2005-02-21 17:36) [0]

Купил Delphi2005 (на базаре на-посмотреть). Поставил, особенно меня интересовал Delphi.NET. Так оказывается что, код, скомпилированный на Delphi.NET, не работает ни на каких платформах кроме Win32/Win64. На том же WinCE он не пойдет, там нужно компилировать программу специально под Net Framework Compact!!! Ну и где заявленная многоплатформенность и переносимость кода как на Java?

КАК Я ЗОЛ! КАК Я СЕРДИТ! КАКИЕ ВСЕ ТАКИ MS-ОВЦЫ П######Ы.

Неужели в Microsoft ничего не умеют делать, как через то самое место?

← →
iZEN © (2005-02-21 17:44) [1]

Поспокойнее. Переносимость кода бывает только в умах.

Для Java компиляция тоже производится под конкретную, настольную или мобильную, платформу. Но, правда, классы (чисто алгоритмические модели, например), сделанные для J2ME и которые не используют обращений к мобильным библиотекам, можно без перекомпиляции(!) использовать в десктопном приложении J2SE, а вот обратно - фигушки - нужно применять preverify...(Не знаю, зачем такой гемор с preverify, видимо хотели кого-то обмануть - смысла в нём мало).

← →
Vovchik_A © (2005-02-21 17:45) [2]

Сам поймешь или надо объяснять ?

← →
arhis (2005-02-21 17:58) [3]

В который раз слышу про технологии NET. Объясните на какого ляда она нужна если у нас нет разнооборазия не то что платформ, а даже ос? Неужели все думают, что то, что они написали бесценно как теория относительности и через 100 лет с помощью netа их творения заставят работать на каких нибудь нанобиокомпьютерах?

← →
vecna © (2005-02-21 18:01) [4]

Че-та я не догнал...
Как ты собираешься переносить программу из Win32, например, в тот же WinCE ??? Это же совершенно разные операционные системы, с разной идеологией, разным подходом к написанию ПО.

Всегда необходимо указывать под какую платформу ты компилишься.

Кстати вопрос, Delphi2005 умеет компилить под эээ SmartDevice это называется в Visual Studio Net, ну КПК короче ?

← →
iZEN © (2005-02-21 18:03) [5]

arhis (21.02.05 17:58) [3]
Разнообразия мало только в России.

← →
kai © (2005-02-21 18:05) [6]

да здравствуют интерпретаторы! -)

← →
arhis (2005-02-21 18:05) [7]

iZEN © (21.02.05 18:03) [5]
Можно примеры? Линух? Ну ладно, хотя очень сомнительно, вы все круглыми сутками пишите генияальные апачи?

← →
BorisMor © (2005-02-21 18:21) [8]

arhis (21.02.05 17:58) [3]

> Объясните на какого ляда она нужна если у нас нет разнооборазия
> не то что платформ, а даже ос?

Позиционируется что с помощью .NET вы сможете разрабатывать приложения на том языке, на котором вам удобно, а не на каком надо.
Пример: вы любите Delphi, а ваш сокамерник по работе любит С++. Так вот если вы пишите оба под NET. Вопрос "что лучше ?" отпадает (в теории :).

К вопросу о разработке для КПК. Раньше под Delphi вобще не было ни каких средств для разработки для этих машинок. Так что получайте удовольствие от того что есть и не гундите :)

Многоплатформенность... Ну тут все сложней так как было бы странно если бы МС делала .NET для Linux. Но уже есть такой активно развивающийся проект как MONO
http://www.mono-project.com/about/index.html
Позволяет писать под Linux.

← →
Petr V. Abramov © (2005-02-21 18:26) [9]

> 100 лет с помощью netа их творения заставят работать на каких нибудь нанобиокомпьютерах?
Вы хотите их банкротства? Лет через 5 будет еще более совершенная и прогрессивая технология, за которую опять надо будет отдать деньги

← →
arhis (2005-02-21 18:32) [10]

BorisMor © (21.02.05 18:21) [8] вообще не понял цели. Они и раньше неплохо сосуществовали вместе а на уровне исходников они никогда не сойдуться.

← →
iZEN © (2005-02-21 18:49) [11]

К BorisMor © (21.02.05 18:21) [8].
Под Java VM существует порядка двухсот(!!!) языков. Странно, но это почему-то не афишируется.

У меня лично в КПК (WM2003SE+Jeode) крутятся без перекомпиляции приложения из демок Sun Java 1.1.8, а у MS под "одну" платформу (.Net и CF) нужно писать и компилировать по-разному. ;))

← →
BorisMor © (2005-02-21 19:18) [12]

> arhis (21.02.05 18:32) [10]
> BorisMor © (21.02.05 18:21) [8] вообще не понял цели.
> Они и раньше неплохо сосуществовали вместе а на уровне исходников
> они никогда не сойдуться.

Одни и тежи классы. Одни и тежи типы данных.

Если сейчас вы пишите систему плагинов и надеетесь что у кто то захочет написать для вашего приложения плагин на С++, то вам придется не применять string, забыть про классы и подумать как грамотно построить передачу параметров.
Маленький практический пример…

> К BorisMor © (21.02.05 18:21) [8].
> Под Java VM существует порядка двухсот(!!!) языков. Странно,
> но это почему-то не афишируется.

Действительно странно.
Возможно они не одинаково эффективны, раз разработчики с упорством используют Java.
Я не слышал что бы SUN предоставила официально поддержку еще одному языку.
Возможность писать под VMJava на Pascal и С++

> У меня лично в КПК (WM2003SE+Jeode) крутятся без перекомпиляции
> приложения из демок Sun Java 1.1.8, а у MS под "одну" платформу
> (.Net и CF) нужно писать и компилировать по-разному. ;))

Не знаю почему. Я писал маленький примерчик на C# под Net Framework Compact (правда это был VS) работало и на ПК и на КПК.

Надо еще заметить что приложения под NET работают все же быстрей чем под JavaVM (и это будет еще заметней когда выйдет Windows построенная на NET ;)

В некоторых областях (например 3D) Java совершенно не используется. А тот то же С# (брат близнец всеми любимой Java) можно уже использовать везде: от баз до создания приложений работающих с 3D (в DirectX SDK 9.0 прилагаются для него уже библиотеки).

Мне самому нравится Java (хоть и знаком только по институту), но боюсь выиграет тот кто более гибок и у кого больше денег…

← →
Soft © (2005-02-21 19:56) [13]

>>BorisMor © (21.02.05 19:18) [12]
>>Надо еще заметить что приложения под NET работают все же быстрей чем под JavaVM (и это будет еще заметней когда выйдет Windows построенная на NET ;)

Jar?

>>В некоторых областях (например 3D) Java совершенно не используется. А тот то же С# (брат близнец всеми любимой Java) можно уже использовать везде: от баз до создания приложений работающих с 3D (в DirectX SDK 9.0 прилагаются для него уже библиотеки).

Не надо ля-ля.
Java3D
http://ru.infocom.uz/more.php?id=348_0_1_60_M

← →
iZEN © (2005-02-21 19:59) [14]

К BorisMor © (21.02.05 19:18) [12]
> Надо еще заметить что приложения под NET работают все же быстрей чем под JavaVM (и это будет еще заметней когда выйдет Windows построенная на NET ;)
Смотря чем и что мерять. На RSDN была ветка про сравнение производительности C#, Java, VC++ при работе с массивами. Так вот в одном сообщении результаты оказались в пользу Java (но в силу идеологической ориентированности в пользу C# результаты раскритиковали и замяли ;)))

> В некоторых областях (например 3D) Java совершенно не используется.
Всё есть и для OpenGL и для DirectX: http://j3d.org/
- очень неплохо для 3D-движка.

Java - это компонентная технология. Наращивается сторонними библиотеками в том направлении, в котором необходимо, зачастую бесплатно и с исходниками. ;)

Что вы будете делать с System.WinForms на CF.Net?

← →
kaif © (2005-02-21 20:25) [15]

С приложениями я бы согласился.
А вот сервера баз данных тоже будут под .NET переписываться?
То есть я имею в виду системы, для которых критична скорость.
Вот, к примеру, MS SQL сервер будет на .NET переписан?
А его конкуренты?

← →
iZEN © (2005-02-21 20:30) [16]

/**kaif © (21.02.05 20:25) [15]
С приложениями я бы согласился.
А вот сервера баз данных тоже будут под .NET переписываться?
То есть я имею в виду системы, для которых критична скорость.
Вот, к примеру, MS SQL сервер будет на .NET переписан?
А его конкуренты?
*/
А конкуренты это хто?
Эти что ли:
http://theserverside.com/reviews/matrix.tss

???

← →
BorisMor © (2005-02-21 20:44) [17]

> iZEN © (21.02.05 19:59) [14]
> К BorisMor © (21.02.05 19:18) [12]
> Смотря чем и что мерять. На RSDN была ветка про сравнение
> производительности C#, Java, VC++ при работе с массивами.
> Так вот в одном сообщении результаты оказались в пользу
> Java (но в силу идеологической ориентированности в пользу
> C# результаты раскритиковали и замяли ;)))

Плохой пример :)
У меня диск от RSDN Magazin под рукой так что могу сказать что кроме "Tree Sort" C# не проиграл Java. Во всех остальных тестах быстрей.

Но не в этом дело. Обычный пользователь (ну те который нечего не знает про сервлеты и прочие умные слова от SUN ;) считают Javа такой же тормозной как и VB.
Обычные GUI приложения, написанные на Java наводят на них ужас, так как жрут чудовищно много памяти и при этом откровенно притормаживают. Они просто не читали умных статей про преимущество Java :)
А на меня ужас наводит Swing с его классами для размещения контролов.
Гораздо привычней для человека работающего в Delphi будет C# и классы WinForm

Soft © (21.02.05 19:56) [13]

> Не надо ля-ля.
> Java3D
> http://ru.infocom.uz/more.php?id=348_0_1_60_M

Да действительно очень прилично.
Но все равно Sun придется догонять в своих “фантазиях” DirectX SDK :)

iZEN © (21.02.05 19:59) [14]

> Java - это компонентная технология. Наращивается сторонними
> библиотеками в том направлении, в котором необходимо, зачастую
> бесплатно и с исходниками. ;)

Да тут тоже признаю правоту.
Но хочется заметить что C# компилятор бесплатный. А найти удобную среду для него тоже не проблема. Например: SharpDevelop
http://www.icsharpcode.net/OpenSource/SD/Default.aspx
Думаю со временем и библиотек будет под С# написано не меньше чем под Java

iZEN © (21.02.05 19:59) [14]

> Что вы будете делать с System.WinForms на CF.Net?

Да то же самое что и на обычном фрэймворке. Эти классы там и там поддерживается :)

← →
BorisMor © (2005-02-21 20:49) [18]

> kaif © (21.02.05 20:25) [15]
> С приложениями я бы согласился.
> А вот сервера баз данных тоже будут под .NET переписываться?
> То есть я имею в виду системы, для которых критична скорость.
> Вот, к примеру, MS SQL сервер будет на .NET переписан?
> А его конкуренты?

MS обещает все переписать от Офиса до самой Windows.
Будет один сплошной .NET :)
И я вовсе не утверждаю что будет лучше...

← →
AlterEgo of WondeRu © (2005-02-21 20:54) [19]

BorisMor © (21.02.05 20:44) [17]
Гораздо привычней для человека работающего в Delphi будет C# и классы WinForm
согласен... за месяц общения с C# смог уже познакомиться с прорисовкой, потоками, ремоутингом и прочими нужностями... на ЯВЕ думаю этого бы я и за год не освоил...

← →
kaif © (2005-02-21 20:56) [20]

2 iZEN © (21.02.05 20:30) [16]
Не понял Ваш вопрос. Там сплошь сервера приложений.
Я спрашивал, скажем, что будет, если взять исходный код InterBase или Oracle и перевести его на .net? Если скорость выполнения SQL-запросов упадет хотя бы в 2 раза, этого достаточно, чтобы сильно сомневаться в практической полезности .net. Если компьютеры на сегодня что-то полезное и делают (за что люди готовы деньги платить), так это обслуживают Интернет и др. связь, а так же работают с изображениями и базами данных. Скорость всегда была и останется критическим фактором для всех видов программирования, кроме скриптового на стороне клиента. Где, кстати, с успехом интерпретаторы и применяются. Однако перевод серверов на .net я совершенно не представляю. Вот и хотелось бы послушать тех, кто более плотно с .net работал. Как вопросы со скоростью, если речь идет о сервере? Например, сервере баз данных или Web-сервере.

← →
iZEN © (2005-02-21 20:56) [21]

Касателно Java3D.
Это не просто библиотека одинаково поддерживающая OpenGL и DirectX - это фреймворк с собственной иерахией, парадигмой "вложенных миров", трансформаций, окружающим звуком Sound3D.
DirectX и OpenGL для Java3D всего лишь "сервера", которые занимаются низкоуровневыми вещами. На Java3D написан Quake2
http://www.bytonic.de/html/jake2.html
Performance: http://www.bytonic.de/html/benchmarks.html

Swing.
Больная избитая тема. Зато своё, родное. Ни от какой ОС не зависит. ;)

← →
iZEN © (2005-02-21 21:07) [22]

/**kaif © (21.02.05 20:56) [20]
2 iZEN © (21.02.05 20:30) [16]
Не понял Ваш вопрос. Там сплошь сервера приложений.
*/
Да. Но. Сервера приложений это ещё своеобразный КЭШ ДАННЫХ!

/*
Я спрашивал, скажем, что будет, если взять исходный код InterBase или Oracle и перевести его на .net? Если скорость выполнения SQL-запросов упадет хотя бы в 2 раза, этого достаточно, чтобы сильно сомневаться в практической полезности .net.
*/
Скорость парсинга строк в managed-средах выше. Чтобы добиться такой же скорости в C++ необходимо использовать изощрённые методы по работе со строками (в CLR и JVM они изначально заложены).
Тормоза будут только при работе с жёсткими дисками (низкоуровневые операции), но в свете сегодняшней реализации NIO в Java это всё нивелируется.
Селяви.
/*
Если компьютеры на сегодня что-то полезное и делают (за что люди готовы деньги платить), так это обслуживают Интернет и др. связь, а так же работают с изображениями и базами данных. Скорость всегда была и останется критическим фактором для всех видов программирования, кроме скриптового на стороне клиента. Где, кстати, с успехом интерпретаторы и применяются. Однако перевод серверов на .net я совершенно не представляю.
*/
2D и "реальное время" оставим нативному коду до поры, до времени.
(Пока не появится Longhorn с Avalon и Java Looking Glass
http://www.izcity.com/data/system/article839.htm
)
*/

2 iZEN © (21.02.05 21:07) [22]
Спасибо. Ваши разъяснения по поводу строк меня заинтересовали. Видно не все так плохо, как я себе представлял. Надо будет вникнуть в .net. Я купил для пробы Delphi8, но еще не экспериментировал. Хотя, видно, начинать надо с чего-то другого, чтобы понять основные принципы. Или можно сразу на Delphi осваивать эти технологии?

kaif © (21.02.05 21:15) [23].
Говорят, что Delphi8 - не лучшее решение для программирования под .Net. Но попробовать стоит. Всё-таки "переходная среда".

Далее стоит искать Delphi2005.

← →
Sergey_Masloff (2005-02-21 22:54) [26]

iZEN © (21.02.05 21:21) [24]
>Говорят, что Delphi8 - не лучшее решение для программирования >под .Net.
"не лучшее" это очень мягко сказано. Глючная среда, убогая справка, ошибки реализации работы с SOAP в WebService-ах и вообще вчерашний день ИМХО.

Delphi2005 - монстр, среда на порядок тормозней MSVS2003. В остальном конечно получше D8 но... я лично ушел на VisualStudio - удобнее, быстрее и вообще. Для Win32 мне вполне хватает Delphi5, для .NET я на Delphi писать не буду (если партия не скажет надо)

> Скорость парсинга строк в managed-средах выше. Чтобы добиться
> такой же скорости в C++ необходимо использовать изощрённые
> методы по работе со строками (в CLR и JVM они изначально
> заложены).
"Заложены" - значит реализованы какие-то "изощренные" алгоритмы. Наверняка реализованные как сисшные библиотеки

> Тормоза будут только при работе с жёсткими дисками
Не будут. Поток передал операционке команду "чти", и уснул.

Вы считаете, при обработке запроса СУБД бОльшую часть времени тратит на парсинг? :))))

Насчет платформ: у нас в фирме наверно половина машин - Sun Solaris, а еще есть HP-UX и AIX.

← →
АлексейК (2005-02-22 04:53) [29]

Delphi2005 - монстр, среда на порядок тормозней MSVS2003. В остальном конечно получше D8 но... я лично ушел на VisualStudio - удобнее, быстрее и вообще. Для Win32 мне вполне хватает Delphi5, для .NET я на Delphi писать не буду (если партия не скажет надо)

Аналогичная ситуация.

К Petr V. Abramov © (22.02.05 01:24) [27].
При вызовах нативного кода из managed-сред появляются задержки, обусловленные дополнительными преобразованиями параметров/результатов функций. Время ответа системы увеличивается (помните "тормозной" Swing или Pentium4 с длинным конвейером на неоптимизированных операциях?)
Это называется латентность. Чем больше "неупорядоченных" вызовов, тем больше "накладных" расходов на преобразование туда-сюда, тем больше латентность - общая производительность падает. NIO и другие подобные методики (типа Java2D) частично компенсируют множественные часто неупорядоченные вызовы, заменяя их блочным чтением/записью, использованием системно-зависимых особенностей внутри JVM (CLR). Но латентность всё равно остаётся.

СУБД большую часть времени тратит на построение реквеста и особенно различных соединений (join). Здесь очень важен как кэш в памяти, так и скорость дисковой подсистемы (на больших выборках). Процессор в этом участвует чисто номинально. Managed-среды с этим (реализуют СУБД) справятся вполне сносно при огромных резервах памяти - их производительность зависит от частоты процессора линейно, а вот от объёма памяти экспоненциально.

В какой-то момент объём памяти на обычных десктопах перевалил "магическую" границу (между 128 и 256Мб), улучшились виртуальные машины, и стало выгоднее использовать для работы managed-среды вместо нативных приложений - объём памяти нивелировал накладные расходы, а скорость процессора (после отметки 1ГГц) - разницу в быстродействии.

[12] BorisMor © (21.02.05 19:18)
> Одни и тежи классы. Одни и тежи типы данных.
>
> Если сейчас вы пишите систему плагинов и надеетесь что
> у кто то захочет написать для вашего приложения плагин на
> С++, то вам придется не применять string, забыть про классы
> и подумать как грамотно построить передачу параметров.
> Маленький практический пример…

Вообще-то под Вин32 есть еще АктивеХ. :)
То-есть, если взаимодействие с плагины оформить через ОЛЕ, то, точно также никакой разницы на чем написано само приложение и эти плагины, хоть на скриптовых языках. :))

Скажи Microsoft НЕТ! Найти похожие ветки