Вышел Mono 0.30

Да, забыл добавить, mono тоже очень хорошо. Но кроме mono есть еще одна open source реализация .NET - http://www.gnu.org/projects/dotgnu/

>Например C? Только если взять большую кроссплатформенную программу на C, то можно будет увидеть, что многие куски по нескольку раз переписаны для каждой платформы и разделены ifdef'ами

А что же тогда делает ./configure

и что находится в config.h

anonymous (*) (04.02.2004 13:37:34) respect!

Фанфатизм идёт от глупости и малолетства. Здесь больше половины нынче студенты, которых Луговский любил опускать. (Жалко страничка у Антика накрылась.)

>Лозунг такой: "Write once, run anywhere", и никто ничего не скрывал.

Это лозунг маркетинга. Разработка её велась под другим. Помните, что на заборе написано?:-)

>К тому-же для бОльшей части платформы Java можно получить оригинальные исходники от SUN

Так вот вопрос: если можно получить и скомпилировать исходники, зачем нужен был байт-код?

>если взять большую кроссплатформенную программу на C

Ну, это всего лишь означает, что использованые библиотеки реализуют разный API. Грубо говоря, даже С - почти кросплатформенный. Отличаются _библиотеки_ на разных платформах. Это недоработка не языка.

>Платить не за что не надо, если ты это на прямую не используешь у себя и не распространяешь.

На большинстве лицензий написано "декомпилировать нельзя". И зачем тебе исходники без права ими пользоваться?

В mono JIT (x86, PPC) есть. Как с JIT в gnu CLR среде?

>Я все равно не понимаю, какая связь между "closed-source сущностью" Java и байткодом. Возьмем, к примеру, Python. Позволяет компилировать в байткод. Следует ли из этого, что сущность Python "closed-source"?

Байт-код питона - средство оптимизации работы интерпретатора. Т.е. необязательная часть системы. У явы же это краеугольный камень дизайна системы. О чем и речь.

>Апплеты. Грузить из сети исходники и компилировать на клиенте?

1. Это направление практически мертво.

2. Грузить из сети исходники и _интерпретировать_ их на клиенте.

>Фанфатизм идёт от глупости и малолетства. Здесь больше половины нынче студенты, которых Луговский любил опускать. (Жалко страничка у Антика накрылась.)

Кто такой Луговский? Что такое Антик? Yandex не сильно помог.

>Разговор от энумах выеденого яйца не стоит

Как я понимаю, разговор был об перечислимых типах. То есть об возможности определить новые типы данных, с физическим представлением int. И о контроле компилятором их использования.

>Интерпретируемый байткод хорошо, компилируемый в инструкции процессора еще лучше

А еще лучше - исходники, компилируемые в инструкции процессора:-)

>Разговор об исходниках тоже выеденого яйца не стоит

Разговор не об исходниках. А о том, _почему_ система сделана так, а не иначе.

>(Жалко страничка у Антика накрылась.)

Сидит Антик, горько плачит - довыебывался значит.

>> Лозунг такой: "Write once, run anywhere", и никто ничего не скрывал.

> Это лозунг маркетинга. Разработка её велась под другим.
> Помните, что на заборе написано?:-)
> Так вот вопрос: если можно получить и скомпилировать исходники, зачем нужен был байт-код?

Помним. Когда велась разработка явы лозунга вообще никакого небыло, потому что лозунги только для маркетинга и нужны. Была идея заставить тостеры и холодильники (утрированно) работать в единой инфраструктуре. Для этого Гослинг придумал язык Java (первоначально хотел переделать C++ но не получилось, потому что не получилось сделать его максимально независимым от архитектуры процессоров, коих видов в холодильниках и тостерах огромное количество (это не PC, где только x86 и PowerPC)).
Еще была идея заставить все эти тостеры работать совместно в единой сети (по сути гетерогенная среда), для чего нужно было передавать друг меж другом объекты, по этому и был введен аппаратно-независимый байт-код (представляю, если бы передавались исходники).

> Ну, это всего лишь означает, что использованые библиотеки реализуют
> разный API. Грубо говоря, даже С - почти кросплатформенный.
> Отличаются _библиотеки_ на разных платформах. Это недоработка не языка.

Java в отличии от C не язык, а платформа, к котором основным языком программирования является язык Java.

> На большинстве лицензий написано "декомпилировать нельзя". И зачем тебе исходники без права ими пользоваться?

А мне на лицензии... У нас в законодательстве написано, что я могу в личных целях (для изменения/добавления функциональности) декомпилировать и изменять все что угодно, главное чтоб друзьям не раздавал.

> А что же тогда делает ./configure

> и что находится в config.h

А configure эти самые define'ы устанавливает в соответствии с конфигурацией системы. Кода от этого меньше не становиться.

Масяныч, клоунишко! Antichrist aka Mauhuur жив, здоров и чмырит пионЭров

http://www.webboard.ru/mes.php?id=8676156&fs=0&ord=0&lst=&boa...

Хорошо. Байткод Python - необязательная часть системы, хотя и прекрасно работает даже в отсутствие "обязательной" - я имею ввиду работу модулей *.pyc без наличия *.py (разве это не способ скрыть исходный текст?).

Но почему

>Байт-код питона - средство оптимизации работы интерпретатора

всего лишь, в то время, как в Java

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

А как же двоичный код? Так ведь про любой язык, для которого существует компилятор в машинный код, можно сказать, что сущность его "closed-source".

Я только хочу сказать, что "open/closed-source сущность" платформы/языка определяется не архитектурой, а _лицензией_.

Интерпретация же исходников имеет свои недостатки в сравнении с интерпретацией байткода, как минимум, байткод свободен от ошибок, выявляемых на этапе компиляции.

>Гослинг придумал язык Java >Java в отличии от C не язык, а платформа,

Есть 2 явы - язык и платформа. Они могут существовать отдельно.

Не имею ничего против _языка_ Java. Качество не очень, хотя лучше многих.(не для флейма). Разговор об платформе/"технологии" - язык(несущественная часть) + передаваемый байт-код + стандарты API + интерпретирующая виртуальная машина. Эта технология нужна _только_ для обеспечения "закрытости" исходников. Ибо в противном случае было бы - любой язык + исходники + стандарты API + (кросс)компилятор. Намного проще и эффективнее. В обоих случаях необходим сдандарт API - что sun поняла и довольно быстро сделала для Явы. Именно API(не считая рекламы) является причиной успеха языка и платформы. IMO. Ибо это единственная выдающаяся часть "технологии".

>Была идея заставить тостеры и холодильники ... Еще была идея заставить все эти тостеры работать совместно ... для чего нужно было передавать друг меж другом объекты, по этому и был введен аппаратно-независимый байт-код (представляю, если бы передавались исходники).

Очень нужна была тостеру программа от холодильника :-). Данные передавать действительно нужно - но для этого не нужна новая платформа - достаточно протокола обмена и метода кодирования.

>А мне на лицензии... У нас в законодательстве...

Так то у вас. А у других - там где sun в частности - по другому. Разговор же был о том, почему Ява такая.

>Я только хочу сказать, что "open/closed-source сущность" платформы/языка определяется не архитектурой, а _лицензией_

Лицензией определяются условия распространения. А в платформе ява из щелей просечивает "это для того, чтобы не показывать исходники". Иначе _ЗАЧЕМ_ Яве виртуальная машина вместо набора кросс-компиляторов?

>байткод свободен от ошибок, выявляемых на этапе компиляции

Любой исходный код можно проверить на наличие ошибок _до_ выполнения. Зависит, правда, от того, что считать ошибкой.

> Есть 2 явы - язык и платформа. Они могут существовать отдельно.

Не спорю.

> Эта технология нужна _только_ для обеспечения "закрытости" исходников.

Опять о том-же. Я уже сказал, что она нужна (разрабатывалась) для обеспечения работы в разнородной среде.

> Данные передавать действительно нужно - но для этого не нужна новая
> платформа - достаточно протокола обмена и метода кодирования.

А зачем тогда DCOM, CORBA и пр.?

PS: а тостеру очень нужна программа от холодильника. Посмотри на недавнее детище Philips (умный холодильник).

>что она нужна (разрабатывалась) для обеспечения работы в разнородной среде

Я по прежнему утверждаю, что разнородные среды _могут_ успешно общаться друг с другом :-) Та же CORBA, DCOM, и т.д.

То, что 2 Ява машины могут общаться между собой - не заслуга "одноплатформенности" - там тоже есть для этого внешние библиотеки, RMI всякие, методы маршаллинга, и т.п. Единственное преимущество одноплатформенности состоит в возможности передачи _исполнимого_ _кода_. И много Вы видели примеров оправданного использования этого дела?

>а тостеру очень нужна программа от холодильника.

Ну и зачем? Тостеру нужен протокол обмена _данными_ с холодильником. Но никак не общий набор исполнимых кодов. Это если по уму делать.

>Лицензией определяются условия распространения.

Лицензией определяются условия использования. Распространение - частный случай использования.

>Любой исходный код можно проверить на наличие ошибок _до_ выполнения.

Да, но проверять придется каждый раз при интерпретации. А в случае больших объемов исходного текста это слишком расточительно.

>Эта технология нужна _только_ для обеспечения "закрытости" исходников.

Сделай для Palm или Сименса компилятор...

> И много Вы видели примеров оправданного использования этого дела?

Самый очевидный пример:
EJB. Передается исполнимый код класса RMI-заглушки, который реализует интерфейс бина.

>Да, но проверять придется каждый раз при интерпретации.

Нет. Проверять придется 1 раз перед _публикацией_ или установкой, etc. А потом уже запускай сколько хочешь. Можно даже байт-код закешировать - для скорости.

>Сделай для Palm или Сименса компилятор...

Оппонент считает, что для Palm или Сименса нет компилятора? Или они сделаны на ява-процессорах(в этом случае для них тоже есть компилятор)?

Приехали:-))

Про ejb я могу спорить долго. Начиная со слов "я же говорил 'оправданнго'" :-))

Сейчас нет нстроения для этого. Я потратил уйму времени, пытаясь понять что привлекает толпы программистов и менеджеров к этой технологии. И до сих пор не нашел ответа. Посему, предлагаю считать EJB табу - ибо разговор уйдет слишком далеко от темы. Кроме случая, если у Вас есть приемлемое обьяснение:-)

Все таки topic был про Mono, и мы только попытались коснуться темы соответствия некоторых технологий идее открытых сиходников:-)

> Приехали:-))

> Про ejb я могу спорить долго. Начиная со слов "я же говорил
> 'оправданнго'" :-))

> Сейчас нет нстроения для этого. Я потратил уйму времени, пытаясь
> понять что привлекает толпы программистов и менеджеров к этой
> технологии. И до сих пор не нашел ответа. Посему, предлагаю считать
> EJB табу - ибо разговор уйдет слишком далеко от темы. Кроме случая,
> если у Вас есть приемлемое обьяснение:-)

> Все таки topic был про Mono, и мы только попытались коснуться темы
> соответствия некоторых технологий идее открытых сиходников:-)

Зашибись! Тогда и про .NET не будем говорить, потому что я считаю, что её использование не оправдано!
Просил пример - ты его получил. И то, что эту технологию (EJB) используют десятки тысяч программистов и тысячи крупных и не очень контор, говорит о том, что ты плохо пытался понять "что привлекает толпы программистов и менеджеров к этой технологии".

Чтобы понять зачем нужно EJB, надо хотя бы раз попытаться изменить чут-чуть логику работающего бизнес приложения средней международной компании. А .NET - дерьмо отъявленное. Через какой зад на нем народ пишет (только по тупому велению заказчика) я знаю оччень хорошо. Хорошо, что почти всегда такие заказы нужны для прокручивания денег. И вот тут .NET вне конкуренции. AlexxZ

> средней международной компании

Как насчёт КРУПНОЙ международной компании в которой используется .NET? Не выставляейте себя на посмешище.

И сколько времени это там используется? Ни за что не поверю, что дольше 1 года! AlexxZ

2AlexxZ

Не лажайтесь с такими безапеляционными заявлениями. Выглядите круглым идиотом.

http://www.microsoft.com/net/momentum/

Ой, малыш, отмазочки начались, как фейсом в списочек ткнули! :)

>Тогда и про .NET не будем говорить, потому что я считаю, что её использование не оправдано

Не заводись. Начали спорить о том, что Java-технология специально заточена под "нераскрытие" исходников. Я утверждал это на основании того, что в технологию привнесены элементы, значительно усложнившие ее - и малополезные. Ты утвержнаешь, что от них есть существенная польза.

Мы сошлись на том, что VM+bytecode полезен только для передачи кода межды 2мя взаимодействующими разнородными системами.

>Просил пример - ты его получил

Еще один есть?

>ты плохо пытался понять

Я _пытался_ понять. То, что у меня не получилось свидетельствует о том, что (один из вариантов)

1. понять это крайне сложно для средних мозгов. В этом случае массовость использующих это несколько странно выглядит - ибо получится, что количество гениев от программирования ненормально велико :-).

2.0 множество людей решили уверовать в рекламу от sun - "чтобы избежать мучений, связанных с необходимостью думать" ((С) не мой).

2.1 принимающие решения менеджеры поверили в то, что с использованием этой технологии они получат возможность достичь результата с более дешевыми программистами( не противоречит п.2)

2.2 В этой технологии таки нет ничего _выдающегося_ - чего нельзя было бы сделать достаточно легко другими средствами - без навязаной "платформы" размера "one size fits all". Это не означает, что кто-либо сделал это - пожалуй SUN просто попал в незанятую нишу. Посему распространенность не свидетельствует об "качественности".

Вариант 2 выглядит более вероятным, не правда ли?

>Чтобы понять зачем нужно EJB, надо хотя бы раз попытаться изменить чут-чуть логику работающего бизнес приложения средней международной компании.

Неужели оно само все делает?

В том то и дело, что этот умник не пытался даже поставить IBM Java 2 1.4 под ASP9. Под слакой работает, а под ASP9 (RH9) - кукиш! Знатоки Жабы, млин...

> .NET - это мультиязыковая платформа, придурок. Единственная в своём роде, придурок. Тебе лечиться надо, придурок.

Угу, согласен, добавление слова "придурок" в конце каждой фразы делает утверждения более убедительными. И постить только анонимно можно...

Процы у нас все быстрее и быстрее, не за горами и на 10 герц пеньки, и просто непонятно, куда такую скорость девать? Вот и напишем всю винду на .NET, и будет она кросс... Только куда девать эту кросс, с такими мощностями-то? Больше занятся нечем, что ли, чем клепать "революционные" технологии каждый год? Где-то кидали уже ссылочку тут насчет того, что M$ постоянно клепает "модные" технологии, чтобы её конкуренты постоянно оставались позади, что и наблюдаем в данном случае.

Наклепали диалектов вроде C#, нормальный C++ под .NET написать не могли? Значит, нет, что сделали такой странный "язык".

> Единственная в своём роде

Эт точно. Другой такой не было, нет, и нах нужна.

На самом деле все не так очевидно. Складывается мнение, что .net действительно может решить проблему написания програмных систем на разных языках - что было бы полезно. Но похоже не все так просто - ограничения, заложеные в систему, возможно, оставляют за бортом "существенно другие" языки(или заставляют существенно обрезать их возможности), позволяя взаимодействовать "похожим" языкам. А последнее как раз имеет мало смысла.

Впрочем, это только предположения. Может кто-нибудь сказать, возможен ли например полнофункциональные Haskell и Python компиляторы .NET кода? И как они будут друг с другом общаться?

> Не заводись.

Не буду.

> Еще один есть?

Jini.

> Я _пытался_ понять. То, что у меня не получилось свидетельствует о том, что (один из вариантов)

> 1. понять это крайне сложно для средних мозгов. В этом случае
> массовость использующих это несколько странно выглядит - ибо
> получится, что количество гениев от программирования ненормально
> велико :-).

> 2.0 множество людей решили уверовать в рекламу от sun - "чтобы
> избежать мучений, связанных с необходимостью думать" ((С) не мой).

> 2.1 принимающие решения менеджеры поверили в то, что с
> использованием этой технологии они получат возможность достичь
> результата с более дешевыми программистами( не противоречит п.2)

> 2.2 В этой технологии таки нет ничего _выдающегося_ - чего нельзя
> было бы сделать достаточно легко другими средствами - без навязаной
> "платформы" размера "one size fits all". Это не означает, что
> кто-либо сделал это - пожалуй SUN просто попал в незанятую нишу.
> Посему распространенность не свидетельствует об "качественности".

1. Понять действительно не просто, но и не очень сложно, было бы желание. На самом деле практически все технологии в Java не очень просты для понимания (по крайней мере с первого взгляда), но я могу объяснить причину: почти все API - глубокая абстракция. Если вникнуть, то все оказывается просто.
2.0 Без маркетинга не обошлось. Да и могло-ли?
2.1 Тут я не спец. У нас менеджеры принимают решения на основе "показаний" технических специалистов, а не не на основе громких рекламных кампаний (больше свойственно поклонникам Microsoft)
2.2 Тут поспорю. До EJB (и в общем J2EE) было достаточно много технологий подобного толка и от Microsoft и от IBM и о других крупных и не очень контор. SUN сделал существенный шаг вперед. Качественный шаг. Сейчас Microsoft пытается сделать то-же, но у неё получаются только количественные шаги - до сих пор нет технологии, превосходящей по возможностям EJB (IMHO). Имеется в виду универсальность, масштабируемость, относительная простота использования, легкость интеграции с другими технологиями.

Sorry, забыл войти в систему :)

...мне кажется что тут какая-то тенденция к нездоровой универсальности.... Tempest25

==============
2.2 Тут поспорю. До EJB (и в общем J2EE) было достаточно много технологий подобного толка и от Microsoft и от IBM и о других крупных и не очень контор. SUN сделал существенный шаг вперед. Качественный шаг. Сейчас Microsoft пытается сделать то-же, но у неё получаются только количественные шаги - до сих пор нет технологии, превосходящей по возможностям EJB (IMHO). Имеется в виду универсальность, масштабируемость, относительная простота использования, легкость интеграции с другими технологиями
===============

Ты спрятал за деревом лес.

Основа EJB -- это разделение бизнес-логики и сервисной логики.
Прикладник пишет логику. И только её. Она у него как на ладони,
никаких левых "начать транзакцию, сохранить в базу, проверить
права" -- нету. Соответсвенно, ему легко и удобно, и
производительность растет. А вот все эти транзакции, persistence
и права -- имплементированы в контейнере. И рулишь ты ими
декларативно. Шаг примерно такой же, как от DBF к SQL. Плюс,
контейнер может реализовать еще массу сервисов, как кластеризация,
кэширование, fault-tolerance, что еще в голову придет.

Это всё очень похоже на AOP, и им, на самом деле, и является.

То есть -- руль EJB в кардинальном упрощении разработки за счет
декларативности всех служебных операций.

Got it?

> Складывается мнение, что .net действительно может решить проблему
> написания програмных систем на разных языках - что было бы полезно

А чем COM до этого занималась?

> .NET - это мультиязыковая платформа, придурок. Единственная в своём роде, придурок. Тебе лечиться надо, придурок

Ругаться зачем? :-(( Надо убеждать вежливо и вкрадчиво. :))

>> Складывается мнение, что .net действительно может решить проблему >> написания програмных систем на разных языках - что было бы полезно

>А чем COM до этого занималась?

На комах сложно было что-либо забацать, кроме как на VC++. VB6 не поддерживал все модели "аппартаментов", так что в отстой.

А так напишет что-нибудь Антик (предварительно математически доказав:)) на своём F# (http://research.microsoft.com/research/ppt/), а Вы вставите этот объект в свой проект и вызовите его из C# или J# программы. Так что mono - очень удобная в этом плане среда. Ещё более удобной она будет при появлении "дженериксов" и ObjectSpaces (аналог CMP2, но более удобный, IMHO, для разработчика).

С# developer

Обсуждение ушло в сторону. Предлагаю: Если интересно - обсуждение EJB перенести в форум - ибо тут не по теме. Несомненно "SUN сделал существенный шаг вперед." и, вероятно, "нет технологии, превосходящей по возможностям EJB". Я считаю, что такую (или эквивалентную, но другую) технологию очень просто реализовать и без Java. Было бы желание.

А по теме:

Стоит вспомнить, что до появления EJB JVM существовала не один год. И, вероятно, EJB был сделан именно таким для "оправдания" JVM - после провала идеи апплетов. А JVM - для доставки исполнимого кода _без_ _исходников_. И MS с их CIL(если я правильно помню название) сделало это лучше, IMНO. Им, правда, предстоит еще написать кучу библиотек, "технологий", завоевать разработчиков, etc. Но идея та же - избавить клиента от исходников.

Это, впрочем, имеет и преимущество - клиенту не нужно ставить себе множество компиляторов - достаточно 1го.

>> Складывается мнение, что .net действительно может решить проблему написания програмных систем на разных языках - что было бы полезно

>А чем COM до этого занималась?

Отож :-). Как я понимаю, разные языки привыкли по разному хранить данные, передавать аргументы, организовывать потоки, и пр. В таких условиях приходилось вручную заниматься преобразованиями - чаще всего при этом многие возможности языков "терялись". И МС попытались решить именно эту проблему.

Однако те или иные решения при разработке языков принимались не только от потолка. Посему, при втискивании в рамки CIL может все равно потеряться слишком многое. Что делает теннологию бессмысленной. IMHO.

Ибо: совмещать C#, C++, J#, Visual Basic, Object Pascal, Ada, Smalltalk, Objective-C лучше всего по критерию "я лучше знаю этот - на нем и пишем". Посему проще всего выучить всем Python - и не морочить себе голову :-).

Интересно совмещать Python/Erlang/Ocaml/Haskell/Forth/Lisp. А вот тут возникает вопрос - насколько язык (X) и (X).net эквивалентны?

Я тут недавно почитал про сборку Haskell на неподдерживаемые архитектуры. Они (как я понял) генерируют C-текст, C-компилятором генерируют asm, потом perl-ом в нем меняют C-вызовы на что-то свое - а из этого собирают бинарии. Так и .NET - он диктует нечто - и это нечто может быть несовместимым с требованиями "интересных" языков.

> В NET обязательно называть программу HelloWorld.exe и запускать ее > mono HelloWorld.exe

Ну в Debian например для mono делается привязка в binfmt, так что запускать можно просто ./helloworld.exe. Думаю можно ручками и в других дистрах такое устроить.