Mono наступает - Gnome не сдаётся

ну и ну , дела

лучше plain C и gtk+ самое то, а всякие .NET и C# это от лукавого, тормоза и прочие минусы вообщем все это в печку, а то что все идет в сторону простого в мире разработки не должно радовать ни сколько, скоро народ отупеет и все попрут на своих окошках и прочей гуевости деньги зарабатывать, вообщем либо с этим бороться, либо идти в подполье, либо просто работать, выбираю последнее.

ты всё это пробовал ? тормозов у моно нет. Очень приятные первые аплеты и приложения к гному появляются всё больше и больше. Суппер штука...

Дамссс, щас при прочтении аббревиатуры ГткШарп, у правоверных такая истерика начнется.

на самом деле пробовал, не Я тут один знакомый товарищ показывал - было интерестно ему пользовал два дня, потом вернулся к чистому C и к gtk+ нормальному, почему? да просто не понравилось, да и по сравнению со скоростью приложений написанный на обычных Сях mono позади, то есть при написании чего либо а-ля Evolution или что-то вроде (более менее крупное) то разница будет велика все-таки ... и именно в скорости.

>тормоза и прочие минусы

Ладно, с тормозами я еще могу согласиться, а расскажите про прочие минусы?

GNOME,GTK - блин :( лучше бы две команды (MONO & DotGNU Portable.NET) объединили свои усилия в доработке System.Windows.Forms и SystemData. А то у одних слоеный пирог Cairo/GDI+, у других flat xlib, в результате для создания GUI/C# приходится выбирать из двух сырых API. :(

>Mono наступает - Gnome не сдаётся

Типа, пчелы против меда?

А самый главный минус такой: подождёт Microsoft пока беззлобные дурачки из опен-сорса распространят и внедрят mono в Linux, GNOME и разом введёт плату за лицензирование .NET-технологии на ОС, отличных от собственных.

Проблема со SCO детским лепетом покажется. :-)

> А самый главный минус такой: подождёт Microsoft пока беззлобные дурачки из опен-сорса распространят и внедрят mono в Linux, GNOME и разом введёт плату за лицензирование .NET-технологии на ОС, отличных от собственных.

Фантастика. Microsoft крайне невыгодно делать подобные ходы. К тому же, насколько я помню (поправьте меня, если я неправ), на какие-то части технологии .NET существует открытый стандарт?

В комментариях к заметке есть такой:

>that is something i hadnt even realised, RMS would have a fit if gnome >went mono. he is currently quite proud of the fact gnome uses C instead >of C++, because of the legal reasons.

Меня заинтересовало последнее предложение: о каких legal reasons по отношению к C++ идет речь??

> А самый главный минус такой: подождёт Microsoft пока беззлобные > дурачки из опен-сорса распространят и внедрят mono в Linux, GNOME и > разом введёт плату за лицензирование .NET-технологии на ОС, отличных > от собственных.

> Проблема со SCO детским лепетом покажется. :-)

К вопросу о "беззлобных дурачках", 2.5 года всей командой внедряющих вражью технологию в Линух...

Особо умным предлагается прочитать ответы Мигеля де Иказа на статью - в них ясно сказано, что ECMA API (т.е. те, которые M$ открыла ради стандартизации) они реализуют, а для проприетарных - пишут свою имплементацию, так что юридически придраться не к чему или почти не к чему. Можно только затруднить им работу, изменяя свои API и ломая совместимость. Но (ИМХО) M$ этого делать не будет: ей важно пропихнуть _свою_ технологию на другие платформы - а потом продавать какой-нибудь M$ Office Linux Edition. Что у них олучится - hz.

p.s. Сам пишу на Яве, но пусть ваяют, т.к. здоровая конкуренция не помешает. Если .Net <=> .shit - все равно загнется...

Да, Вы правы. Дикий заголовок. Если учесть, что основные разработчики моно - те же люди, которые зачали гном (и совсем не собираются его бросать) - глупость какая-то. Просто однажды моно войдет в состав гнома (2.8?) как необходимый компонент (хотя бы в виде рантайма, если не в виде sdk) - и кучу софта на нем тоже станут запихивать в гном.

2 пред. anonymous:
> Но (ИМХО) M$ этого делать не будет: ей важно пропихнуть _свою_
> технологию на другие платформы - а потом продавать какой-нибудь M$ > Office Linux Edition. Что у них олучится - hz.

Насчет других платформ - наверное, правильно, но может быть
M$ больше подразумевает другие аппаратные платформы, а не программные. Ей винда деньгу приносит, и очень немаленькую, а
укреплять конкурирующую OS делая под него офисный пакет - сомнительный ход.

(Лично я KDEшник, не флеймите).

На самом деле, и с Java, и с .Net ситуация досататочно запутанная. Они несколько неудобны (IMHO, конечно) для мелких софтин вроде калькулятора. И они ощутимо тормозят для крупных софтин, вроде броузеров или текстовых процессоров.

Чего, по-моему, не хватает - так это *распространённого*, удобного и мощного скриптового языка с крепкими binding'ами к чему-то оконному. К сожалению, PerlTk, PyQt, PyGtk, и так далее, распространёнными назвать язык не очень поворачивается. Разве что TclTk, только с него уже песок сыпется.

Надеюсь, KJSEmbed займёт под KDE нишу мелких юзерских софтин. Он войдёт в штатную поставку KDE 3.2; он весьма крут и функционален; мелкие скрипты на нём можно заточить для себя "на коленке" без геморроя.

Резюмируя. Здоровая конкуренция - это хорошо для всех ;)

>p.s. Сам пишу на Яве, но пусть ваяют, т.к. здоровая конкуренция не >помешает. Если .Net <=> .shit - все равно загнется...

.NET не загнется. Даже если его не портируют на другие платформы, все равно .NET будет основным средством создания приложений в Windows.

>Меня заинтересовало последнее предложение: о каких legal reasons по отношению к C++ идет речь??

Посмотрите g++ headers - в каждом особо оговорено, что его можно инклудить и при этом не делать свою прогу lgpl'ной.

>Чего, по-моему, не хватает - так это *распространённого*, удобного и мощного скриптового языка с крепкими binding'ами к чему-то оконному. К сожалению, PerlTk, PyQt, PyGtk...

А что, wxPython вместе с installer применить не судьба?

ээ.. ну так у моего любимого Ruby и сейчас еть биндинги ко всему что движится. можеть быть еще wxWindows и qt в зачаточных стадиях, но tk, foxtk, gtk2 -- все это есть и работает. причем я все это смотрел как на линухе так и на винде. даже для ниизенького пользования winapi тулкит есть -- vruby. на слет распространенности -- на всех дистрах ruby есть. для винды примитивный и не громоздкий инсталлятор есть. в macosx -- он с операционкой идет. так что не надо :-)я сам на ruby+foxtk прожку писал, причем на линухе, а работает она на виндах.

dmiceman

тут что -- старые логины убили?

2alphex_kaanoken

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

в общем есть такая проблема - черезмерная сложность и длительность разработки софта, Java и Python как раз и поднялись из-за того, что поставили во главу упрощение и ускорение процесса разработки, пусть и за счет снижения эффективности и отказа от многих возможностей которые дают программеру классические C, C++ или Perl (в случае с питоном). Вообще интересный подход - уделить главное внимание не машинной реализации а человеческому фактору, тому как человек мыслит. Человек слаб, невнимателен и ему свойственно ошибаться. Можно это игнорировать и порицать, а можно с учетом этого создавать языки на которых писать легче и безопаснее. Чисто прагматически второй подход оказывается вгоднее, пусть это и выглядит как потакание тупости и невнимательности. Типа возмем да отменим goto и точка. Пусть goto и позволяет где то удобнее выходить из глубоких циклов и реагировать на исключения, но зная слабую грешную природу человека, на которую нельзя положиться изымем c корнем этот источник искушения, и в конечном итоге станет лучше. Точно также поступаем с вольным обращением с типами, указателями, освобождением памяти и тд.. Так что plain C иногда лучше оставить для строгих праведников, а грешникам, каковых большинство дать что-нибудь безвредное, питательное, c низким содержанием холестирина и алкоголя :)

>в общем есть такая проблема - черезмерная сложность и длительность разработки софта, Java и Python как раз и поднялись из-за того, что поставили во главу упрощение и ускорение процесса разработки, пусть и за счет снижения эффективности и отказа от многих возможностей которые дают программеру классические C, C++ или Perl (в случае с питоном). Вообще интересный подход - уделить главное внимание не машинной реализации а человеческому фактору, тому как человек мыслит. Человек слаб, невнимателен и ему свойственно ошибаться.

Обо всем этом писали еще 30-35 лет назад Дейкстра, Хоар, etc., (только в роли C/C++ тогда выступали ассемблер и фортран). И все вроде бы с этим соглашались (кроме никому тогда не известных и не нужных K&R и т.п.), и под этим знаменем были создана Ada, Modula 3, Oberon, Eiffel и др. неплохие языки. И никому они оказалось не нужны, зато торжествуют и лоснятся от счастья K&R, Страуструп и примкнувший к ним Б. Гейтс. Потому что "черезмерная сложность и длительность разработки софта", а также его чрезмерная глюкавость - как раз то, что нужно поставщикам софта, чтобы больше заработать. А нанять индусов и пр. для кодирования на C++ можно сколько угодно. А сами эти индусы и пр. ощущают профессиональную крутость именно вследствие возможности изнасиловать процессор и здравый смысл с помощью ассемблероподобных языков. А пользователя в этой отрасли никто не привык спрашивать - монополия, хавай, что дают, еще спасибо скажи.

А насчет Java и C#, может быть кто-то мне объяснит, зачем статические языки исполнять динамически? Вот например Modula 3, Oberon, Eiffel, SML/OCAML - все имеют и сборку мусора, и полиморфизм - но прекрасно компилируются в машинные команды и запускаются очень быстро. А java пока динамически скомпилирует все нужные классы - юзер успеет поседеть. Вероятно, поэтому ее и применяют в основном на серверах?

//А насчет Java и C#, может быть кто-то мне объяснит, зачем статические языки исполнять динамически? //

Жаба вышла на рынок с концепцией апплетов, где
bcode грузится по сети и интерпретируется(!) на любой платформе.
Все остальные её перевоплащения - это половые извращения.

дотнет в этом плане по-лучше, его IL изначально проектировался под быструю компиляцию.

> зачем статические языки исполнять динамически
Ну раз уж Оберон вспомнили, то должны были "Динамическая кодогенерация: ключ к разработке переносимого программного обеспечения" Франца прочитать.

>И никому они оказалось не нужны,

Ну - это конечно не так. Ada активно используется в системах высокой
надежности. Например в системах для авиации, атомной энергетике, космической, военной технике и т.д. и т.п. Кстати Ada активно использовалась и используется и в совке тоже.
Ну а насчет популярности - в то время как Гослинг выскакивает из штанов рекламирует Java, на которой сделана коммуникационная система ЦУПа для общения со Spirit, система управления rover'ом (которая работает на самом rover'е) запрограммирована на Ada. Считается что не нужды рекламировать или популяризировать Ada. За Java стоит Sun, и реклама и пропаганда Java - это реклама и пропаганда Sun. Java - это Sun, Net - это Microsoft. Не даром баталии между фанатами Java и фанатами Net - проходят в основном между фанатами Open Source и фанатами Microsoft.


Captain.

2Cipollina

Java все-таки не интерпретируемый а именно компилируемый язык. Только компилятор изготавливает бинарный код готовый не к исполнению на данной реальной платформе и процессоре, а предназначенный для некой виртуальной Java машины. В общем потери на итерпретацию этого откомпилированного абстрактного джава байткода невелики по сравнению с чисто интерпретируемыми языками высокого уровня вроде perl, php, python и тд. Сооружена такая двухступенчатая система похоже именно для универсальной переносимости готовых апплетов, которые после компиляции могут исполнятся на любой платформе внутри соответствующей выртуальной машины. Хотя Java сейчас популярна на серверах, IMHO вся эта затея с вируальными машинами изначально задумывалась именно с прицелом на разномастных клиентов и наверное так оно и будет в будущем - JVM будет идти прошитой на микросхемах вместе с самым разнообразным железом, которое в своей совокупности будет представлять среду исполнения разнообразных java аппликух, а еще в более далекой перспективе - единую распределенную вычислительную систему, которая когда-нибудь может стать глобальной :) И будет ли эта среда такой уж чисто жабной - еще вопрос, вроде бы родные распределенно вызываемые методы и классы получаются уж очень сложными и неповоротливыми, да и не всем этот новый дивный java мир по душе. Быть может из этого всего не получится эдакой всемирной Java или .NET машины, как это некоторым хотелось бы, а будет венигрет самых разномастных служб и сервисов которые тем не менее будут хорошо ладить между собой, общаясь по стандартным протоколам, например посредством XML сообщений.

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

Да нету у жабы будущего, тем более на клиенте...и не могло быть

> перловые скприпты именно компилируются на лету в памяти и затем уже быстро исполняются в бинарном виде, то есть не происходит построчной интерпретации скриптов по ходу их исполнения.

Короче, байт-код интерпретируется. Как и в Java. И в Python точно так же. А построчная интерпретация - это миф и не более того.

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

Все, для кого это актуально, давно используют mod_perl и поэтому запрягают только один раз, при рестарте апача.

> Да нету у жабы будущего, тем более на клиенте...и не могло быть

Какое содержательное высказывание. А главное, как хорошо и убедительно обосновано!

<Какое содержательное высказывание. А главное, как хорошо и убедительно обосновано!>
Какое отношение Сун, с его то рылом, имеет к десктопу?

> Какое отношение Сун, с его то рылом, имеет к десктопу?

Пусть пишется что-нибудь для внутрикорпоративного использования. Backend - J2EE. И что, frontend на чём-то кроме Java писать будут? Если это не веб-интерфейс, то наверняка фронтендом будет GUI на Java. Просто потому, что соотношение цена/качество лучше.

Вот именно, в случае Ж2ЕЕ-бэкэнда волей или неволей остается только веб-интерфейс. Это уже правило.

О чем спор то? java - такая же маркетинговая шушера, что и .НЕТ.
Только ублюдочная, как первый блин :)

> Короче, байт-код интерпретируется. Как и в Java. И в Python точно так же.

Вот насчет этого в случае перла и не уверен. Нет нужды там в каком то промежуточном байт-коде. Текст сразу компилится и линкуется в исполняемый бинарный код. Да и питону байтовые полуфабрикаты без надобности, чтобы их потом по второму разу как то интерпертировать. Не знаю как там в случае Python устроен движек разбора и интерпретации текста, но он обошел проблему скорости исполнения с другой стороны, а именно предлагает использовать модули на C/C++ для тех учаcтков где важна скорость. Перл же ориентирован на достаточно быстрое исполнение задач своими собственными силами, пусть и в ущерб читабельности и удобству, хотя в прннципе также имеет аналогичные возможности работы с программами на C. С другой стороны - что есть удобство и читабельность? Для кого то китайский язык совершенно нечитабельный и неудобный, а для кого то - родной :)

> О чем спор то? java - такая же маркетинговая шушера, что и .НЕТ.

Прошло уже время кричать что король голый :) Поначалу он ходил без штанов, но к JDK 1.4 уже прибарахлился и даже прилично выглядит.. На одних лозунгах далеко не уедешь. Жаба не прожила бы столько если бы от неё не было никакой пользы и выгоды. Это вот MS может впаривать своим друзьям и прихлебателмя что угодно, а куда им болезным деваться с подводной лодки - раз Билли так решил - значит начнется у них любовь с дотнетом :)

<Вот насчет этого в случае перла и не уверен.>
_Он_ не уверен!!! Зато кроме тебя все знают и уверены. Умник, мля.

> Вот насчет этого в случае перла и не уверен. Нет нужды там в каком то промежуточном байт-коде. Текст сразу компилится и линкуется в исполняемый бинарный код.

Как ты себе представляешь eval без интерпретатора?

Насчёт промежуточного байт-кода - там не байт-код, а "parse tree". По этому поводу см. Стаса Бекмана: http://perl.apache.org/docs/general/perl_myth/perl_myth.html#Interpreted_vs__...

Из "parse tree" при желании и некоторой удачливости можно получить байт-код (perldoc perlcompile, perldoc B, perldoc B::Bytecode), хотя это вряд ли кому надо.

> Насчёт промежуточного байт-кода - там не байт-код, а "parse tree". По этому поводу см. Стаса Бекмана: http://perl.apache.org/docs/general/perl_myth/perl_myth.html#Interpreted_vs__...

> Из "parse tree" при желании и некоторой удачливости можно получить байт-код (perldoc perlcompile, perldoc B, perldoc B::Bytecode), хотя это вряд ли кому надо.

Дело не этом.

Известное дело: 1)The Compilation Phase; 2)The Code Generation Phase (optional); 3) The Parse Tree Reconstruction Phase (optional) (а именно: "To reanimate the program, its parse tree must be reconstructed. This phase exists only if code generation occurred and you chose to generate bytecode. Perl must first reconstitute its parse trees from that bytecode sequence before the program can run. Perl does not run directly from the bytecodes; that would be slow.")

в итоге мы имеем готовый код который исполняется в 4)The Execution Phase;

Все это можно считать малоинтересующей нас внутренней кухней перл компилятора. Дело в том что на выходе мы имеем исполняемый код для PVM, которую тут можно считать аналогом JVM в случае с Java. В этом дело. А наличие или отсутсвие фаз 2) 3) несущественно.

Вообще имелось ввиду что "Perl is always in one of two modes of operation: either it is compiling your program, or it is executing it - never both at the same time. <..> A typical Perl program gets one compile phase, and then one run phase."

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

> Зато кроме тебя все знают и уверены. Умник, мля.

пошел нахер, злобный анонимус

NiKel, признайся, что познавать новое - это классно! :-P

> NiKel, признайся, что познавать новое - это классно! :-P

Не только узнавать, но иногда и разьяснять другим - тоже занятно ;) Позитивные альтруистические эмоции.. Ну сделала нас природа стадными сапенсами, чего ж тогда отказывать себе в небольшой дозе удовольствия.

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

> Ага, ещё немножко, и будешь знать, зачем на самом деле нужен mod_perl

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

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

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

> что mod_perl - больше чем кэширующий контейнер. Настолько больше, что для многих это даже и не основное его свойство :-)

То есть mod_perl имеет смысл без применения к апачу и вебу вообще?

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