Вышел MonoDevelop 0.12

> Песец, нахрена изобретать быдлокодерские велосипеды? С++\Qt рулит....

Скорей, Qt в существующем виде - это попытка сделать из плюсов яву (или даже скорее C#). Им осталось только GC прикрутить, остальное - в виде расширений языка и своей библиотеки классов, практически полностью подменяющей стандартную плюсовую - уже есть.

h8:
>Мона - свободная реализация соответсвующего стандарта, какое фтопку "подмножество"?


может быть, когда-нибудь мониты и добьются того, что любое написанное в Linux Mono приложение будет запускаться на любой винде- МС скажет им спасибо,
но того, что-бы любое написанное в Win/.Net приложение запускалось под Linux/Mono- не будет _никогда_. МS имеет желание и возможность этого не допустить- а значит не допустит.

r:
>>.НЕТ придуман, что-бы > а) безгуйные приложения легче переносились с UNIX/Linux(куда они пишутся в первую очередь) серверов на Win и

>Для этого придумали Java. Там работает. Ты не путай теплое с мелкомягким.
угу, придумали Java, а потом МС дополнила свою реализацию Java под Вин кучей специфичных функций, сделав переносимость однонаправленной, а потом Sun выиграла суд против MS, доказав, что это подрывает суть Java- и тогда MS придумал .Нет

/есть в МС умные люди- но их целью не является создание технически совершенного продукта/


>>б) чтобы с Win никуда и ничего не переносилось(.Моно всегда будет подмножеством .Нет)

>Для справки - это не подможество .NET. Посмотри что обозначает слово подмножество перед тем как кидаться им.

я знаю что такое подмножество- может, я не и вполне знаю что такое Моно- но, IMXO, это вы с h8 путаете, то чем Моно реально является и то, чем оно никогда не станет

>если уж ныне Mono идет в стандартной поставке Gnome...

И скоро будет большое число приложений на этом под гному. Мои сожаления пользователям гнома, обгоним висту по требованиям и тормозам ... Путь 4 qt, как-то больше нра.

>может быть, когда-нибудь мониты и добьются того, что любое написанное в Linux Mono приложение будет запускаться на любой винде- МС скажет им спасибо,

Если запускаешь приложение на моновской виндовой виртуальной машине (как оно и должно быть) - оно будет работать уже сейчас. МС уже сказало спасибо в виде запрета на реализацию того, что будет в висте. Проскакивали новости по этому поводу, правда довольно давно.

>но того, что-бы любое написанное в Win/.Net приложение запускалось под Linux/Mono- не будет _никогда_. МS имеет желание и возможность этого не допустить- а значит не допустит.

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

>я знаю что такое подмножество- может, я не и вполне знаю что такое Моно- но, IMXO, это вы с h8 путаете, то чем Моно реально является и то, чем оно никогда не станет

Интересно так выходит. Ты сам не вполне знаешь, а говоришь что мы неправы. Логика есть? Я себе представляю что такое Моно - свободная реализация стандарта ECMA, а не попытка сделать клон, чтоб виндовые апликухи гонять под Линуксом. Разницу чувствуешь? Почитай вот здесь: http://www.mono-project.com/FAQ:_General

Я чего-то не могу понять политику MS. .Net у них по идее платформенно-независимая штука. Сами они реализацию .Net-а под другие платформы кроме Windows не пишут (или пишут?) и други запрещают. Зачем тогда эта независимость? Не понимаю :-/

>Я чего-то не могу понять политику MS. .Net у них по идее платформенно-независимая штука. Сами они реализацию .Net-а под другие платформы кроме Windows не пишут (или пишут?) и други запрещают. Зачем тогда эта независимость? Не понимаю :-/

Да лажа это от МС. Накой оно им надо? ИМХО, они собирались/собираются сделать из .НЕТ аналог COM'у. Например, как одна из фич у них рекламировалась возможность проводить наследование от классов в IL-сборках, что ранее было ессесно невозможно. Плюс, якобы уход от dll-hell.

Да шрифты то ладно, а вот диалог сохранения файлов меня просто убивает. Хорошо что его в поздних версия вроде как починили.

Вон винда изначально ориентируется, со своимим "средствами для покалеченных" =) У них это хорошо получается, со временем у многих не "покалеченных" мозг ничего кроме МС больше не воспринимает.

ЗЫ А C# + GTK очень удобная штука. Под винду поставил тоже mono и GTK вот тебе и переносимость. Хотя java лучще. =)

qt 4.2 .zip = 2 898 444
mono 1.1.6.exe = 42 500 027
dotnetfx.exe = 24 265 736
j2re-1_4_2_05.exe = 1 418 304

> я знаю что такое подмножество- может, я не и вполне знаю что такое Моно- но, IMXO, это вы с h8 путаете, то чем Моно реально является и то, чем оно никогда не станет

Моно это кроспалтформенный platform/vm для разработки кросплатформенных приложений (как Java Platform). Это UNIX версия .NET Development Platform. Естественно он не может быть полностью совместим с MS.NET по причине невозможности кросплатформенности многих MSовски фич. С другой стороны моно имеет библиотеки, которых никогда не будет в MS.NET. Моно имеет виндовую версию, и в последнее время позиционируется не на "запуск под MS.NET приложений написанных в линуксе" а на "запуск под виндовой версией моно кросплатформенных приложений".

>Нет причин, по которым такое же нельзя сделать для Mono.

С недавнего времени - можно

gtksharp-2.7.1-win32-0.5.exe 25.0 M 2006-05-25

Это либы для МСовской машины. И что-то явавская машина маловата в размере. У меня jre-1_5_0_06-windows-i586-p.exe - 16.7 М

>может быть, когда-нибудь мониты и добьются того, что любое написанное в Linux Mono приложение будет запускаться на любой винде- МС скажет им спасибо, но того, что-бы любое написанное в Win/.Net приложение запускалось под Linux/Mono- не будет _никогда_. МS имеет желание и возможность этого не допустить- а значит не допустит.

Что значит не допустит? Приложения пишут разработчики. Им решать - писать так, чтобы работало и на моно и в винде или только под одну платформу. Никто их не заставляет завязываться на фичи, несовместимые между фреймворками.

Десктопу нужна целостность! ДОстало, что 20 языков прграммирования и во всех элементы управления выглядят по-разному. Маскарад какой то получается, а не десктоп. отвлекает и мешает работать, полэтому QT и только QT как мощный, скинабельный и удобный язык!

очепятка - web install
так что - jre-1_5_0_06-windows-i586-p.exe - 16.7 М

> Я чего-то не могу понять политику MS. .Net у них по идее платформенно-независимая штука. Сами они реализацию .Net-а под другие платформы кроме Windows не пишут (или пишут?) и други запрещают. Зачем тогда эта независимость? Не понимаю :-/

Согласен с h8. Конечно, .NET был сделан больше для самих себя. Плюс чтобы отбить поклонников Java. Например, COM имеет серьезные проблемы с безопасностью. Вот, .NET и позволяет их решить через использование дополнительного слоя - виртуальной машины по типу явовской. Кстати, одна из новых фич XAML и Vista - исполнение удаленного кода на клиентской машине примерно так, как исполняются сейчас явовские апплеты.

В общем, появились новые задачи, которые нельзя было решить _своими_ старыми средствами. Тогда придумали новое и _своё_.

2All:

Кстати, для тех кто еще не знает: архитектор .NET и Delphi - один и тот же человек, он же разработчик Turbo Pascal :)

> ДОстало, что 20 языков прграммирования и во всех элементы управления выглядят по-разному.

Чето я не понял каким боком язык программирования к Look and Feel элементов управления.

>полэтому QT и только QT как мощный, скинабельный и удобный язык!

Мощно завернул (с) Гоблин вроде... не помню. "Скинабельный язык" это да, это круто.

>QT как мощный, скинабельный и удобный язык!

бросай пить и курить всякую дрянь

А Tcl/Tk для переносимых серверных приложений не ? С Tcl ICE, напрмер. А Python ? А ведь языковые возможности (в частности метапрограммирование) у них получше чем в С#. Зачем с таким трудом пользовать сомнительное, но хорошо разрекламированное решение, даже не удосужившись сравнить его с аналогами ? Не C#'ом и Jav'ой живы едиными, просто Microsoft и Sun большие и богатые. И, я понимаю, это общее настроение ЛОРа, но что за привычка создавать бессмысленные флеймы на ровном месте ? Заранее извиняюсь, просто обсуждение меня убило...

>А Tcl/Tk для переносимых серверных приложений не?

Видать Ентерпрайз-секретарше это не поставишь, ибо "чо вы мне за гумно поставили, оно никрасииивае...". Ну а питон... Чтоб он нормально выглядел, надо ставить тот же ГТК или КуТе - енд-юзеру будет неудобно. ну а яву не освоили из-за того, что расширение не .ехе :)

> А Tcl/Tk для переносимых серверных приложений не ? С Tcl ICE, напрмер. А Python ? А ведь языковые возможности (в частности метапрограммирование) у них получше чем в С#.

Именно языковые возможности. По другому говоря, сработал человеческий фактор :) Просто, C# и Java внешне очень похожи на супер-популярный в свое время C++, что само по себе было очень важным для продвижения в широкие программерские массы. Ведь тот же Pascal по ряду технических параметров нисколько не хуже, чем язык C, но C - намного популярнее. А что могут (могли) предложить Tcl/Tk или Python?

Кстати, обсуждение в этом форуме пока еще более-менее соответствует заявленной теме ;)

>а твой qt - сам по идеалогии очень уж очень похож на винду

С этого места, пожалуйста, аргументируйте. Чем именно?

> НЕТ придуман, что-бы а) безгуйные приложения легче переносились с UNIX/Linux

"Гы, сынок, LOL" (С)

Учите матчасть

>Переход между версиями GCC бьет по моральному состояниюю когда фиксишь под него C++ приложение так, что вспоминаешь такие словечки, которые думаешь, что давно забыл.

Use the Standard, Luke...

Tcl/Tk GUI-приложения начиная с Tcl/Tk 8.14 при использовании расширения tile могут иметь практически любой внешний вид, и не так уж сложно сделать их весьма красивыми. И настраиваемыми. Проще, чем в Qt, кстати (не хочу обидеть Qt, просто в С++ это иначе тяжело сделать). Впрочем, я вёл речь о серверных приложениях, где GUI не так важен. А python может пользовать тот же Tk через Tkinter, и получить такой же замечательный интерфейс. Qt/GTK - тоже не единственные :) А вот расширение действительно будет не exe. Что поделаешь, издержки тяжкого наследия...но ведь не на ЛОРе же об этом говорить !

Tcl/Tk и Python могут предложить современный enterprise-подход. Со всеми плюсами скриптового и метапрограммирования, с очень надёжными интерпретаторами (используются в действительно критичных к надёжности областях, например в NASA). Они просты в изучении и использовании. Они замечательно интегрируются с C/C++ кодом (ну, python чуть-чуть легче). Это языки middleware, в конце концов...

>Use the Standard, Luke...

А то что стандарт меняется не заметил, Luke?

>А то что стандарт меняется не заметил, Luke?

Хм... Речь шла о переходи от версии к версии _gcc_. А в них, как правило, добавляется лишь более точное соблюдение стандарта...

>Tcl/Tk и Python могут предложить современный enterprise-подход. Со всеми плюсами скриптового и метапрограммирования, с очень надёжными интерпретаторами (используются в действительно критичных к надёжности областях, например в NASA). Они просты в изучении и использовании. Они замечательно интегрируются с C/C++ кодом (ну, python чуть-чуть легче). Это языки middleware, в конце концов...

Да я все понимаю и собственно ничего против этого не имею, но раз уж мы заговорили об энтерпрайз, то как эти интерпретируемые языки обеспечивают защиту кода? Есть аналоги обфускаторов?

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

O_o Во выясняется! Мы тут про опенсорс и GPL, а у проприетарщиков одно на уме! :-D

Имел дело как-то с одной поделкой на Tcl. Там весь тиклевский код шифровался каким-то детский XORом, а для расшифровки использовался свой мелкий модуль на C. Расковыривалось за 3 минуты. :)

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

С интерпретируемыми языками это проблема. Можно выполнить прогнать обфускатор на уровне исходного кода. Другим из вариантов будет компиляция программы в байт-код (оба языка это поддерживают).

Но сразу возникает главный вопрос: "А зачем?". И вообще мы рассматриваем FOSS или Closed/Proprietary Software?...

Если вам необходима зацита кода в Tcl/Tk приложении, то пользуйте mktclapp, переводите скрипт в немеряный сишник завёрнутый от реверсинжениринга и компилируйте. Код будет в безопасности. Только на кой чёрт это всё нужно ? Впрочем, по этому поводу уже высказались...

>Но сразу возникает главный вопрос: "А зачем?". И вообще мы рассматриваем FOSS или Closed/Proprietary Software?...

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

Предлагаю спросить у концерна BMW как это они используют скриптовый Tcl/Tk для автоматизации техпроцесса %) а у Industrial Light And Magic - про Python...

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

>А в них, как правило, добавляется лишь более точное соблюдение стандарта...

По твоему язык не менялся?

http://www.itp.ac.cn/english/itponly/wphtml/diff.html

И есть вещи которые депрекейтятся и отменяются. Посмотри changelogs gcc.

Но дело даже не в этом, а в том что человек, который утверждает что C/++ прога перекомпиляется на "многих платформах" скорее всего сам ничего подобного не пробовал. Компиляторы разные, версии разные, либы разные. Возьми какую нить фигню типа ifconfig - и посмотри какая она неодинаковая на разных платформах.

Если приложение действительно содержит модули, которые должны быть защищены от реверс-инжениринга - пишем их на С/С++ со всеми вытекающими возможностями, и подключаем как Tcl-расширение, или Python-модуль. Такое решение пойдёт ? Парафия скриптовых языков - программная логика, там они и должны использоваться...

У MonoDevelop? Жжоте

>По твоему язык не менялся?

Стандарт С++ с 98 года не менялся.

>C/++ прога перекомпиляется на "многих платформах"

Это абсолютно верно, при соблюдении 1 маленького "но": если в программе используются только те средства языка и библиотеки, которые описаны в стандарте.

>Если приложение действительно содержит модули, которые должны быть защищены от реверс-инжениринга - пишем их на С/С++ со всеми вытекающими возможностями, и подключаем как Tcl-расширение, или Python-модуль. Такое решение пойдёт ?

В принципе да, это решение. Но есть одно но - человеческий фактор. Как по вашему, что выберет среднестатистический кодер? Писать все на одной платформе/фреймворке или так?

>Стандарт С++ с 98 года не менялся.

Тогда наверное мне приснился документ INCITS/ISO/IEC 14882:2003 ?

>Это абсолютно верно, при соблюдении 1 маленького "но": если в программе используются только те средства языка и библиотеки, которые описаны в стандарте.

Про сферических коней неинтересно.

>У MonoDevelop? Жжоте

У моно.

>Как по вашему, что выберет среднестатистический кодер?

К сожалению вынужден согласиться. Потому - долой среднестатистических кодеров :) пусть каждый кодер будет уникален... Ладно, шучу. Вообще, конечно, массовое использование вряд ли возможно. Как, впрочем, и с POSIX-системами на десктопе. Будем ждать пока мир станет лучше...и будем приближать это время. Нес па ? Благодарю за обсуждение %)

>Будем ждать пока мир станет лучше...и будем приближать это время.

В последнее время это стало реально. Не везде конечно, но сфера применения расширилась очень сильно. И не в последнюю очередь благодаря таким проектам.

> Tcl/Tk и Python могут предложить современный enterprise-подход. Со всеми плюсами скриптового и метапрограммирования, с очень надёжными интерпретаторами (используются в действительно критичных к надёжности областях, например в NASA). Они просты в изучении и использовании. Они замечательно интегрируются с C/C++ кодом (ну, python чуть-чуть легче). Это языки middleware, в конце концов...

Ну, .NET - это не только middleware. Честно говоря, не настолько хорошо знаком с Tcl/Tk и Python, поэтому такой вопрос. "Безопасное" выполнение кода в .NET означает следующее.

Допустим, на сервере лежит байт-код (теперь это может быть еще и XAML-файл, который внешне похож на обычный HTML, но потом этот файл после загрузки браузером компилируется на стороне клиента в байт-код, но не суть так важно). Далее, клиент проссматривает с помощью браузера некоторую страничку в интернете, и браузер скачивает тот байт-код и запускает его на исполнение уже на _клиентской_ машине. Чтобы чужая программа ничего не напакостила, браузер выставляет достаточно жесткие "политики безопасности", например, запрещает программе чтение файлов, за исключением, скажем, только так называемого локального хранилища (local storage - aналог cookie в .NET). Это и есть сценарий _безопасного_ исполнения кода с удаленного сервера. Понятное дело, что без виртуальной машины здесь никак не обойтись.

Теперь сам вопрос. Можно ли так сделать с помощью Tcl/Tk или Python?

>Тогда наверное мне приснился документ INCITS/ISO/IEC 14882:2003 ?

Не приснился. Но! Цитирую: (http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=38110&...)

>ISO/IEC 14882:2003 specifies requirements for implementations of the C++ programming language and standard library.

Этот документ определяет стандарт на _реализацию_ языка, а не на сам язык.

>>Это абсолютно верно, при соблюдении 1 маленького "но": если в программе используются только те средства языка и библиотеки, которые описаны в стандарте.

>Про сферических коней неинтересно.

А если брать иной вариант, то я согласен - переносимость может потерятся из-за использования непереносимых функций.

>Теперь сам вопрос. Можно ли так сделать с помощью Tcl/Tk или Python?

Да. Насчёт Tcl/Tk могу сказать точно и наверняка, потому как использовал - это называется Safe Tcl/Safe Tk %) Насчёт Python гляну, не приходилось. Но думаю, что аналогичный механизм есть и там...

Спасибо, мне уже докладывали :)))

>>ISO/IEC 14882:2003 specifies requirements for implementations of the C++ programming language and standard library.

>Этот документ определяет стандарт на _реализацию_ языка, а не на сам язык.

"Интересные вы люди" (C)...

ISO/IEC 14882:1998

-1- This International Standard specifies requirements for implementations of the C++ programming language.

ISO/IEC 14882 - это ISO Стандарт для "Programming language C++".

Последний драфт - 2005 года. Называется "Working Draft, Standard for Programming Language C++". И (О Чудо!) тоже начинается словами:

This International Standard specifies requirements for implementations of the C++ programming language.

Между 1998 и 2003 - 303 страницы diff'a - в инете есть diff документ.