Здравствуйте, iZEN, Вы писали:
ZEN>Java стала свободной. Что ждет Mono? Этот проект так и будет плестись в хвосте Microsoft?
Да параллельно это Моно... Захотят компании (точнее компания, зато какая ) кроссплатформенности дотнета — все будет, не захотят — будет жить на задворках. И GPLность Java тут абсолютно непричем... Каково количество проектов, написанных на Mono? Исключая гномовские приблуды? Флуктуации на уровне долей процентов, и 0.2% или 0.15% после открытия java думаю роли не играют
Тут на самом деле другой вопрос — не приведет ли открытие Java под GPL к уменьшению количества проектов на ее основе?
Здравствуйте, DrDred, Вы писали:
DD>Тут на самом деле другой вопрос — не приведет ли открытие Java под GPL к уменьшению количества проектов на ее основе?
С чего бы это?
Здравствуйте, DrDred, Вы писали:
DD>Тут на самом деле другой вопрос — не приведет ли открытие Java под GPL к уменьшению количества проектов на ее основе?
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, DrDred, Вы писали:
DD>>Тут на самом деле другой вопрос — не приведет ли открытие Java под GPL к уменьшению количества проектов на ее основе?
ZEN>Прокомментируйте, пожалуйста.
Я боюсь, что каждый дистрибутор Linux захочет напихать туда своих патчей (Debian тотже, RedHat, SuSE, Oracle). Все будут движимы благими намерениями, но имхо это все чревато мелкими подлыми несовместимостями, черезвычайно труднообнаружимыми. Все это имхо может подорвать доверие к данной платформе. Я в курсе, что и сейчас существует n-e количество JVM, но есть эталон. В дальнейшем же боюсь что границы эталона могут быть размыты... Надеюсь, что я ошибаюсь... Время покажет...
Здравствуйте, DrDred, Вы писали:
ZEN>>Прокомментируйте, пожалуйста. DD>Я боюсь, что каждый дистрибутор Linux захочет напихать туда своих патчей (Debian тотже, RedHat, SuSE, Oracle). Все будут движимы благими намерениями, но имхо это все чревато мелкими подлыми несовместимостями, черезвычайно труднообнаружимыми. Все это имхо может подорвать доверие к данной платформе. Я в курсе, что и сейчас существует n-e количество JVM, но есть эталон. В дальнейшем же боюсь что границы эталона могут быть размыты... Надеюсь, что я ошибаюсь... Время покажет...
Ну, динамичность процесса стандартизации в Java вроде бы внушает определенный оптимизм на эту тему. Вот, к примеру, плюсы стандартизуются слишком медленно по меркам индустрии — в итоге производители компиляторов вынуждены вносить свои нестандартные расширения для достижения прагматических целей. W3C тоже работает недостаточно шустро — в итоге мы имеем зоопарк браузеров по тем же самым причинам.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DrDred, Вы писали:
DD>Я боюсь, что каждый дистрибутор Linux захочет напихать туда своих патчей (Debian тотже, RedHat, SuSE, Oracle). Все будут движимы благими намерениями, но имхо это все чревато мелкими подлыми несовместимостями, черезвычайно труднообнаружимыми. Все это имхо может подорвать доверие к данной платформе. Я в курсе, что и сейчас существует n-e количество JVM, но есть эталон. В дальнейшем же боюсь что границы эталона могут быть размыты... Надеюсь, что я ошибаюсь... Время покажет...
гм... А кажеж это у меня ядро еще работает... кде с гтк тоже вроде работают...
Здравствуйте, Sheridan, Вы писали:
S>2. в линухе моно никому не нужен.
Мне нужен, потому что я считаю платформу .NET более продуманной чем JVM.
Другим людям нужен чтобы использовать их .NET приложения также и под Linux.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Sheridan, Вы писали:
S>>2. в линухе моно никому не нужен. АХ>Мне нужен, потому что я считаю платформу .NET более продуманной чем JVM. АХ>Другим людям нужен чтобы использовать их .NET приложения также и под Linux.
Ты случайно не в курсе, есть ли уже прецеденты подобного? Причём было бы интересней что-нибудь гуёвое, а не консольные утилитки
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Здравствуйте, Sheridan, Вы писали:
S>>>2. в линухе моно никому не нужен. АХ>>Мне нужен, потому что я считаю платформу .NET более продуманной чем JVM. АХ>>Другим людям нужен чтобы использовать их .NET приложения также и под Linux.
К>Ты случайно не в курсе, есть ли уже прецеденты подобного? Причём было бы интересней что-нибудь гуёвое, а не консольные утилитки
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Sheridan, Вы писали:
S>>2. в линухе моно никому не нужен. АХ>Мне нужен, потому что я считаю платформу .NET более продуманной чем JVM. АХ>Другим людям нужен чтобы использовать их .NET приложения также и под Linux.
Понимаеш, эти все люди, которых ты описал — работают по виндовс, и мышление виндозовское, обдотнетченое, так сказать.
Это ни в коем случае не плохо, это также и не хорошо. Это просто другое мышление.
Так вот, линуксоидам пользовать моно не с руки. Есть более нативные средства, и их хватает вполне. И объяснить почему моно слабо пойдет под линуухом, это практически тоже самое, что объяснить виндузовцам — что на серваке не должно быть графики, а только консоль.
Что я хочю сказать — вы сами творцы своего щщщастья. Хотите, чтобы моно работал — делайте чтонибудь в этом направлении. Само по себе оно долго будет подниматься.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Здравствуйте, Sheridan, Вы писали:
S>>>2. в линухе моно никому не нужен. АХ>>Мне нужен, потому что я считаю платформу .NET более продуманной чем JVM. АХ>>Другим людям нужен чтобы использовать их .NET приложения также и под Linux.
S>Понимаеш, эти все люди, которых ты описал — работают по виндовс, и мышление виндозовское, обдотнетченое, так сказать.
Ужас какой. Сидят на игле Микрософт ?
S>Это ни в коем случае не плохо, это также и не хорошо. Это просто другое мышление.
У многих из них прагматичное мышление. Они разрабатывают некий продукт, а потом к ним приходит клиент и говорит "Мы используем также и Линукс, хотим чтобы под ним тоже работало". Вот тогда им и понадобится Mono.
S>Так вот, линуксоидам пользовать моно не с руки.
Отучаемся говорить за всех. Моно начал самый что ни на есть линуксоид, основатель проекта Gnome Мигель де Иказа.
Since December 2000, we had been amazed by the .NET Framework, and when
we discussed internally at Ximian its benefits, what we initially did
was to staff the "Labs" team to work on CORBA, SOAP and Perl teams to
work on the Gnome binding infrastructure (remember: our motivation at
this point was the vision of writing APIs once, and using them in every
language).
S> Есть более нативные средства, и их хватает вполне.
Да не очень то их хватает для нормальной компонентности.
S> И объяснить почему моно слабо пойдет под линуухом, это практически тоже самое, что объяснить виндузовцам — что на серваке не должно быть графики, а только консоль.
На серваке должно быть то, чем удобно пользоваться. Лучше и то и другое.
Вот я например недавно ставил ADSL-роутер. Настройка через веб-интерфейс. Очень удобно.
Но это уже давай в КСВ, а не здесь
Здравствуйте, Андрей Хропов, Вы писали:
S>>Это ни в коем случае не плохо, это также и не хорошо. Это просто другое мышление. АХ>У многих из них прагматичное мышление. Они разрабатывают некий продукт, а потом к ним приходит клиент и говорит "Мы используем также и Линукс, хотим чтобы под ним тоже работало". Вот тогда им и понадобится Mono.
Qt?
S>>Так вот, линуксоидам пользовать моно не с руки. АХ>Отучаемся говорить за всех. Моно начал самый что ни на есть линуксоид, основатель проекта Gnome Мигель де Иказа.
Значит, ему было нужно.
S>> Есть более нативные средства, и их хватает вполне. АХ>Да не очень то их хватает для нормальной компонентности.
Чего именно не хватает? о_0
S>> И объяснить почему моно слабо пойдет под линуухом, это практически тоже самое, что объяснить виндузовцам — что на серваке не должно быть графики, а только консоль. АХ>На серваке должно быть то, чем удобно пользоваться. Лучше и то и другое.
Мне удобно пользоваться mc... Админу нашему удобно пользоваться mc. А еще ssh, telnet... Этого хватает с головой, поверь.
АХ>Вот я например недавно ставил ADSL-роутер. Настройка через веб-интерфейс. Очень удобно.
links, lynx, elinks?
АХ>Но это уже давай в КСВ, а не здесь
Модераторы, отделите ветку плиз...
[RSDN@Home][1.2.0][alpha][668]
[Мир прекрасен. Это-то и грустно. [С. Лец]]
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Мне нужен, потому что я считаю платформу .NET более продуманной чем JVM.
Так вам, батенька, надо на платформе .NET разрабатывать, а не на платформе моно. То, что они похожи — не считается.
АХ>Другим людям нужен чтобы использовать их .NET приложения также и под Linux.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>У многих из них прагматичное мышление. Они разрабатывают некий продукт, а потом к ним приходит клиент и говорит "Мы используем также и Линукс, хотим чтобы под ним тоже работало". Вот тогда им и понадобится Mono.
И потом оказывается вдруг, что сказки то и нет и моно это не .net. Кто думает, тот сразу о совместимости и кроссплатформенности. Прагматичные люди понимают, что потом это выпивает, как правило, много крови и пота.
Здравствуйте, Sheridan, Вы писали:
S>Мне удобно пользоваться mc... Админу нашему удобно пользоваться mc. А еще ssh, telnet... Этого хватает с головой, поверь.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>>У многих из них прагматичное мышление. Они разрабатывают некий продукт, а потом к ним приходит клиент и говорит "Мы используем также и Линукс, хотим чтобы под ним тоже работало". Вот тогда им и понадобится Mono.
О какой кроссплатформенности речь, господа??? Моно не соответствует даже MSFW 1.1 куда ему до, допустим, MSFW 2.0?? Да ни одно путное приложение, написанное на мелкософтовском фрэймворке не перенесешь без выкидывания половины возможностей и отказа от использования кучи объектов и их фич на моно в линукс. Личный опыт был. Вот тогда то и промелькнула мысль: "А че ж вообще теперь делать??...". Короче — надо все писать на С++ Тогда будет работать . А при обесплачивании Javы ничего особенного, я думаю, не произойдет. Поддержка будет, в том числе и от Sun. Я не думаю, что язык настолько молодой и неокрепший, т.к. сам писал на нем еще лет 7 назад — и уже тогда был доволен ее возможностями.
Здравствуйте, cjgin, Вы писали:
C> О какой кроссплатформенности речь, господа??? Моно не соответствует даже MSFW 1.1 куда ему до, допустим, MSFW 2.0?? Да ни одно путное приложение, написанное на
О чем, собственно, и речь. Платформа МОНО и платформа .НЕТ — это не идентичные понятия.
C>Вот тогда то и промелькнула мысль: "А че ж вообще теперь делать??...". Короче — надо все писать на С++ Тогда будет работать . А при обесплачивании Javы
Возвращаться на плюсы?.. Без необходимости не стоит, право. Тем более, что там тоже для кроссплатформенности многих рамок придерживаться надо.
C>ничего особенного, я думаю, не произойдет. Поддержка будет, в том числе и от Sun. Я не думаю, что язык настолько молодой и неокрепший, т.к. сам писал на нем еще лет 7 назад — и уже тогда был доволен ее возможностями.
ИМХО, будет развиваться и жаба и моно. И думаю, жаба избежит той страшной участи, которую ей пропрочат.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
C>>Вот тогда то и промелькнула мысль: "А че ж вообще теперь делать??...". Короче — надо все писать на С++ Тогда будет работать . А при обесплачивании Javы
TBG>Возвращаться на плюсы?.. Без необходимости не стоит, право. Тем более, что там тоже для кроссплатформенности многих рамок придерживаться надо.
имхо достаточно писать с Qt? и все будет замечательно.
[RSDN@Home][1.2.0][alpha][668]
[Любовь может изменить человека до неузнаваемости. [Теренций]]
Здравствуйте, Sheridan, Вы писали:
S>имхо достаточно писать с Qt? и все будет замечательно.
Программа начала состоять лишь из того, что предоставляет Qt? Да и заходить в эти рамки тоже как-то не хочется. Но во многом, согласен, довольно хороший выбор.
Turtle.BAZON.Group пишет: > Программа начала состоять лишь из того, что предоставляет Qt? Да и > заходить в эти рамки тоже как-то не хочется. Но во многом, согласен, > довольно хороший выбор.
Qt уже переросла сосотояние просто GUI бибилотеки. Сейчас это скорее
фреймворк для написания кроссплатформенных десктопных программ.
Здравствуйте, Сергей, Вы писали:
С>Qt уже переросла сосотояние просто GUI бибилотеки. Сейчас это скорее С>фреймворк для написания кроссплатформенных десктопных программ.
Пасибо, в курсе. Я ведь и не говорил, что это GUI библиотека.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>>>Просто.. Просто потрясен. S>>И всетаки?
TBG>Сожалею, но очень доходчиво это не объяснишь. Основная мысль заключается в том, что удобнее пользовать несколько иными вещами.
Мне интересно какие это некоторые другие вещи необходимы для настройки к примеру файрвола, прокси, файлового, веб, фтп, mail серваков? о_0
[RSDN@Home][1.2.0][alpha][668]
[Знать — не всегда значит помешать. [М. Пруст]]
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Сожалею, но очень доходчиво это не объяснишь. Основная мысль заключается в том, что удобнее пользовать несколько иными вещами.
Можно подробнее о других подобных MC программах под Linux? Как раз стою перед выбором. Графику не предлагать
Здравствуйте, Сергей, Вы писали:
С>Qt уже переросла сосотояние просто GUI бибилотеки. Сейчас это скорее С>фреймворк для написания кроссплатформенных десктопных программ.
Donz wrote: > TBG>Сожалею, но очень доходчиво это не объяснишь. Основная мысль > заключается в том, что удобнее пользовать несколько иными вещами. > Можно подробнее о других подобных MC программах под Linux? Как раз стою > перед выбором. Графику не предлагать
Есть gitfm (GNU Interactive Tools, a file browser/viewer and process
viewer/killer — из описания пакета в Debian). Глючит меньше чем MC, но и
возможностей меньше.
Для любителей минимализма есть еще deco (Demos Commander).
А вообще, все чего Линуксу не хватает — это замены FARа и VisualStudio
для С++
Здравствуйте, Sheridan, Вы писали:
S>Мне интересно какие это некоторые другие вещи необходимы для настройки к примеру файрвола, прокси, файлового, веб, фтп, mail серваков? о_0
Мне при моей ламеровитости в линухах для всего этого хватает bash, vim, grep.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
D>>Можно подробнее о других подобных MC программах под Linux? Как раз стою перед выбором. Графику не предлагать
TBG>Не подобные. Другие просто.
Под подобными я имел в виду возможность удобно манипулировать файлами/папками, удобное редактирование текстовых и бинарных файлов и исопльзование как FTP клиента
Здравствуйте, Сергей, Вы писали:
С>Qt уже переросла сосотояние просто GUI бибилотеки. Сейчас это скорее С>фреймворк для написания кроссплатформенных десктопных программ.
Да, но только если вы не хотите открывать исходный код своих программ под GPL вам придется выложить
немалые суммы (за весь фреймворк в Desktop edition):
One Platform — $3300
Two Platforms — $4950
Three Platforms — $6600
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Андрей Хропов, Вы писали:
S>>>Это ни в коем случае не плохо, это также и не хорошо. Это просто другое мышление. АХ>>У многих из них прагматичное мышление. Они разрабатывают некий продукт, а потом к ним приходит клиент и говорит "Мы используем также и Линукс, хотим чтобы под ним тоже работало". Вот тогда им и понадобится Mono. S>Qt?
Что Qt? У них уже есть приложение под .NET, которое хотят портировать.
Да и Qt для коммерческого применения безумно дорог — от $4950 на 1 разработчика для 2 платформ (здесь).
А чтобы разрабатывать на Qt под Windows нормально придется все равно покупать Visual Studio.
S>>>Так вот, линуксоидам пользовать моно не с руки. АХ>>Отучаемся говорить за всех. Моно начал самый что ни на есть линуксоид, основатель проекта Gnome Мигель де Иказа. S>Значит, ему было нужно.
Как видишь проект Mono не умер, а вполне себе развивается. Правда не так хорошо как хотелось бы...
S>>> Есть более нативные средства, и их хватает вполне. АХ>>Да не очень то их хватает для нормальной компонентности. S>Чего именно не хватает?
Как интегрировать в рамках, например, твоего Qt компоненты на Python и на C++?
Без дополнительных усилий, просто взял и вызвал метод.
А динамически объекты создавать можно по имени?
типа как в .NET:
// LoadInvoke loads MyAssembly.dll and lists the method
// information for each method. After compiling this class,
// run LoadInvoke.exe with the DisplayName for the assembly,
// as shown here:
// LoadInvoke MyAssemblyusing System;
using System.Reflection;
using System.Security.Permissions;
public class LoadInvoke
{
[PermissionSetAttribute(SecurityAction.Demand, Name="FullTrust")]
public static void Main(string[] args)
{
Assembly a = Assembly.Load(args[0]);
Type[] mytypes = a.GetTypes();
BindingFlags flags = (BindingFlags.NonPublic | BindingFlags.Public |
BindingFlags.Static | BindingFlags.Instance | BindingFlags.DeclaredOnly);
foreach(Type t in mytypes)
{
MethodInfo[] mi = t.GetMethods(flags);
Object obj = Activator.CreateInstance(t);foreach(MethodInfo m in mi)
{
// Instead of invoking the methods,
// it's safer to initially just list them.
Console.WriteLine(m);
}
}
}
}
А вообще как с рефлексией?
А с версионностью компонентов как?
S>о_0
Что такое o_0?
S>>> И объяснить почему моно слабо пойдет под линуухом, это практически тоже самое, что объяснить виндузовцам — что на серваке не должно быть графики, а только консоль. АХ>>На серваке должно быть то, чем удобно пользоваться. Лучше и то и другое. S>Мне удобно пользоваться mc... Админу нашему удобно пользоваться mc. А еще ssh, telnet... Этого хватает с головой, поверь.
Кому чего. Но я не админ, мне сложнее судить.
Но агитировать за технологии уровня 70-х годов...
АХ>>Но это уже давай в КСВ, а не здесь S>Модераторы, отделите ветку плиз...
да, они тут уже давно ничего не отделяют
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>>>На шарпе программить несколько приятнее, чем на яве. Хотя по сути — вырез в профиль. D>>Примеры приятностей можно?
TBG>Можно. Проперти.
ИМХО, ещё одна не очень нужная сущность. Писал на C# довольно давно, но насколько помню, для стороны, которая изменяет пропертю, в коде выглядит как обычное поле, что может сбить с толку. Также чем удобнее по сравнению с геттерами/сеттерами?
Здравствуйте, Donz, Вы писали:
TBG>>Не подобные. Другие просто. D>Под подобными я имел в виду возможность удобно манипулировать файлами/папками, удобное редактирование текстовых и бинарных файлов и исопльзование как FTP клиента
Ну тогда bash+vim+hexedit+ncftp. А под "удобными" вы какое понятие вкладываете?
Здравствуйте, Donz, Вы писали:
TBG>>Можно. Проперти. D>ИМХО, ещё одна не очень нужная сущность. Писал на C# довольно давно, но насколько помню, для стороны, которая изменяет пропертю, в коде выглядит как обычное поле, что может сбить с толку. Также чем удобнее по сравнению с геттерами/сеттерами?
Вам неудобно не значит, что и остальным неудобно. А удобнее тем, что нагляднее. А раз нагляднее, то и приятнее.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>У многих из них прагматичное мышление. Они разрабатывают некий продукт, а потом к ним приходит клиент и говорит "Мы используем также и Линукс, хотим чтобы под ним тоже работало". Вот тогда им и понадобится Mono.
TBG>И потом оказывается вдруг, что сказки то и нет и моно это не .net. Кто думает, тот сразу о совместимости и кроссплатформенности. Прагматичные люди понимают, что потом это выпивает, как правило, много крови и пота.
Ну ситуация с портированием улучшается потихоньку.
Вот выпустили Mono Migration Analyzer.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>>>Не подобные. Другие просто. D>>Под подобными я имел в виду возможность удобно манипулировать файлами/папками, удобное редактирование текстовых и бинарных файлов и исопльзование как FTP клиента
TBG>Ну тогда bash+vim+hexedit+ncftp. А под "удобными" вы какое понятие вкладываете?
Как минимум, всё перечисленное в одном флаконе. Для меня удобный файловый менеджер должен быть с двумя синими панелями Far, например, для меня очень удобен. vim, например, надо довольно долго изучать, что не очень хочется делать, если надо делать простые замены символов и т.д.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
D>>ИМХО, ещё одна не очень нужная сущность. Писал на C# довольно давно, но насколько помню, для стороны, которая изменяет пропертю, в коде выглядит как обычное поле, что может сбить с толку. Также чем удобнее по сравнению с геттерами/сеттерами?
TBG>Вам неудобно не значит, что и остальным неудобно. А удобнее тем, что нагляднее. А раз нагляднее, то и приятнее.
Чем "умное" поле нагляднее в коде, чем метод, если выглядит также, как и "неумное" поле?
Я, кстати, не говорил, что мне неудобно. Я сказал, что непонятно зачем вводить лишнюю сущность. Можете назвать принципиальное отличие свойств от геттеров/сеттеров?
Здравствуйте, Donz, Вы писали:
D>Здравствуйте, Turtle.BAZON.Group, Вы писали:
D>>>ИМХО, ещё одна не очень нужная сущность. Писал на C# довольно давно, но насколько помню, для стороны, которая изменяет пропертю, в коде выглядит как обычное поле, что может сбить с толку. Также чем удобнее по сравнению с геттерами/сеттерами?
TBG>>Вам неудобно не значит, что и остальным неудобно. А удобнее тем, что нагляднее. А раз нагляднее, то и приятнее.
D>Чем "умное" поле нагляднее в коде, чем метод, если выглядит также, как и "неумное" поле? D>Я, кстати, не говорил, что мне неудобно. Я сказал, что непонятно зачем вводить лишнюю сущность. Можете назвать принципиальное отличие свойств от геттеров/сеттеров?
Ну принципиально то, что они объединаются в одну сущность, а не 2 функции. Да, кстати — это синтаксический сахар, потом внутри MSIL они превращаются в обычные геттеры/сеттеры.
Здравствуйте, Donz, Вы писали:
TBG>>Ну тогда bash+vim+hexedit+ncftp. А под "удобными" вы какое понятие вкладываете? D>Как минимум, всё перечисленное в одном флаконе. Для меня удобный файловый менеджер должен быть с двумя синими панелями Far, например, для меня очень удобен. vim, например, надо довольно долго изучать, что не очень хочется делать, если надо делать простые замены символов и т.д.
Опять же — весьма субъективное понятие удобности. Мне, к примеру, нравится менеджер с тремя окнами. Слева большое — справа два пополам поделенные. Многие вещи МС удобнее делать с помощью консоли bash, но этого мне вам не объяснить. Посмотреть vim стоит 15 мин и вы уже будете готовы к базовым операциям и оно того стоит. Продвинутые могут и не понадобиться до конца жизни. В качестве гуя — Konqueror офигительная штука.
Здравствуйте, Donz, Вы писали:
D>Чем "умное" поле нагляднее в коде, чем метод, если выглядит также, как и "неумное" поле? D>Я, кстати, не говорил, что мне неудобно. Я сказал, что непонятно зачем вводить лишнюю сущность. Можете назвать принципиальное отличие свойств от геттеров/сеттеров?
Вам непонятно не значит, что и остальным непонятно. Принципиально отличие лишь с тем, что этим удобнее пользоваться. Потому что не надо писать кучу-кучу всего для получения и установки значения. Все проще и прозрачнее.
D>>Я, кстати, не говорил, что мне неудобно. Я сказал, что непонятно зачем вводить лишнюю сущность. Можете назвать принципиальное отличие свойств от геттеров/сеттеров?
TBG>Вам непонятно не значит, что и остальным непонятно. Принципиально отличие лишь с тем, что этим удобнее пользоваться. Потому что не надо писать кучу-кучу всего для получения и установки значения. Все проще и прозрачнее.
Опять? И так, приведи мне правила по которым ты создаёш либо свойство либо метод без параметров?
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Здравствуйте, Donz, Вы писали:
D>>Чем "умное" поле нагляднее в коде, чем метод, если выглядит также, как и "неумное" поле? D>>Я, кстати, не говорил, что мне неудобно. Я сказал, что непонятно зачем вводить лишнюю сущность. Можете назвать принципиальное отличие свойств от геттеров/сеттеров?
TBG>Вам непонятно не значит, что и остальным непонятно.
А если Вам понятно, то это не значит, что всем остальным понятно
Здравствуйте, Andrei N.Sobchuck, Вы писали:
TBG>>Вам непонятно не значит, что и остальным непонятно. Принципиально отличие лишь с тем, что этим удобнее пользоваться. Потому что не надо писать кучу-кучу всего для получения и установки значения. Все проще и прозрачнее. ANS>Опять? И так, приведи мне правила по которым ты создаёш либо свойство либо метод без параметров?
Это вы к чему? Я к тому, что эти правила гармоничнее видятся. Всем понятно, что правила одни. Удобства в восприятии и использовании роль играют.
S>>Чего именно не хватает? АХ>Как интегрировать в рамках, например, твоего Qt компоненты на Python и на C++? АХ>Без дополнительных усилий, просто взял и вызвал метод.
Ну, напрямую не знаю. Есть PyQt + кутэшники серьезно озаботились интеграцией с другими языками. Например, забайндились к Java. Что будет дальше — посмотрим.
Почти оффтоп, почти СВ. Если бы в МС сделали MFC хоть наполовину похожую на Qt, на .NET бы сейчас никто бы не переезжал, имхо
Здравствуйте, Turtle.BAZON.Group, Вы писали:
ANS>>Опять? И так, приведи мне правила по которым ты создаёш либо свойство либо метод без параметров?
TBG>Это вы к чему? Я к тому, что эти правила гармоничнее видятся. Всем понятно, что правила одни. Удобства в восприятии и использовании роль играют.
К тому, что всем понятно, что правила одни. Не понятно только какие
Здравствуйте, Andrei N.Sobchuck, Вы писали:
TBG>>Это вы к чему? Я к тому, что эти правила гармоничнее видятся. Всем понятно, что правила одни. Удобства в восприятии и использовании роль играют. ANS>К тому, что всем понятно, что правила одни. Не понятно только какие
Дыкть! Вся наша жизнь сложная штука. А если серьезно, то в шарпе много таких вот мелких фичек, вроде бы и не нужных, но которые несколько жизнь облегчают.
Здравствуйте, Cyberax, Вы писали:
C>А вообще, все чего Линуксу не хватает — это замены FARа и VisualStudio для С++
Однако samba рулит
Сижу под WinXP, а разрабатываю под линухом... использую Far и VC++8
Правда компилировать приходится через ssh кстати может кто знает как научить студию компилять через ssh и зачитывать сообщения об ошибках?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sheridan, Вы писали:
S>Понимаеш, эти все люди, которых ты описал — работают по виндовс, и мышление виндозовское, обдотнетченое, так сказать.
Очень смелое утверждение для человека который не понимает разницу между VB(не VB.NET) и .NET.
А что касается темы то виртуальная машина .NET действительно продумана много лучше чем JVM.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Ну принципиально то, что они объединаются в одну сущность, а не 2 функции. Да, кстати — это синтаксический сахар, потом внутри MSIL они превращаются в обычные геттеры/сеттеры.
Если не ошибаюсь, то можно задать только геттер или только сеттер для "умного" поля.
АХ>Ну и писать АХ>
Чую, что будет ответом от Turtle.BAZON.Group на этот пост (Вам не..., то это не значит, что остальным...) , но всё-таки. В первом случае совершенно неясно, идёт ли обычное "тупое" присваивание или же какие-то манипуляции с параметром. Во втором же случае всё понятно: вызываем метод, значит параметр теоретически может быть преобразован.
В общем, спор как таковой смысла не имеет, каждый, наверное, останавливается на своём уровне синтаксического сахара.
Здравствуйте, Mamut, Вы писали:
M>Почти оффтоп, почти СВ. Если бы в МС сделали MFC хоть наполовину похожую на Qt, на .NET бы сейчас никто бы не переезжал, имхо
Не гуем идиным... Многие вещи которые элементарно делаются под .НЕТ требуют при разработке на С++ чудовищных усилий.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Вам непонятно не значит, что и остальным непонятно. Принципиально отличие лишь с тем, что этим удобнее пользоваться. Потому что не надо писать кучу-кучу всего для получения и установки значения. Все проще и прозрачнее.
У Вас правило начинать посты с "Вам ... не значит, что и остальным..."?
Кучу чего писать? Геттер и сеттер для свойства всё равно надо описывать, присваивание тоже надо писать. Единственное отличие — это прозрачность для того, кто работает с этим свойством. Но это очень сомнительный плюс.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Да, но только если вы не хотите открывать исходный код своих программ под GPL вам придется выложить АХ>немалые суммы (за весь фреймворк в Desktop edition):
ммм... А сколько ты заплатиш на разработчика за винду, офис, студию? А кроме этого существует наверняка еще множество полезного софта. А сервак для тестов, а сервак конторы?
Это раз.
Два:
Покупая винду ты пишеш на винде под винду. Покупая только Qt ты пишеш под любой поддерживаемой осью для любой поддерживаемой оси.
Здравствуйте, Donz, Вы писали:
D>Чую, что будет ответом от Turtle.BAZON.Group на этот пост (Вам не..., то это не значит, что остальным...) , но всё-таки. В первом случае
В принципе, правильно чуете!
D>В общем, спор как таковой смысла не имеет, каждый, наверное, останавливается на своём уровне синтаксического сахара.
Вот я и говорю, что мне этот синтаксический сахар приятнее. Потому как просто я никогда не присваиваю, а городить оверхед мне как-то кисло. Но приходится..
Здравствуйте, Курилка, Вы писали:
TBG>>Вам непонятно не значит, что и остальным непонятно. К>А если Вам понятно, то это не значит, что всем остальным понятно
А так я про остальных сразу ничего не говорил. Мной было упомянуто, что на шарпе программить приятнее. Ну кто воспринял на себя — звиняйте братку.
Здравствуйте, Donz, Вы писали:
D>У Вас правило начинать посты с "Вам ... не значит, что и остальным..."?
Нет, просто посты располагают.
D>Кучу чего писать? Геттер и сеттер для свойства всё равно надо описывать, присваивание тоже надо писать. Единственное отличие — это прозрачность для того, кто работает с этим свойством. Но это очень сомнительный плюс.
Дело привычки. У нас все в жизни привычкой определяется (если судить по опыту). Конкретно по геттеру-сеттеру. Я описываю пропертю и тут же рядом описывается его геттер и сеттер, то есть поле и его мутатор и геттер связаны (сложнее сделать ошибку). Я вижу что и где. Затем обращение в коде более простое, чем get или set писать. К тому же в IDE нужно поставить нагенерить геттеры и сеттеры. В принципе, вроде бы ничего, раз IDE за меня делает, но напрягает, что геттер/сеттер с полем связан как-то постольку-поскольку. Это при просмотре чужого кода или своего через несколько месяцев можно только догадываться, кто к кому имеет отношение. Я согласен, что у каждого дело вкуса. Ну кому как нравится. Поэтому оченоь жалею, что нет (*) макросистемы в Ява. А может, и правильно, что нет, а то понаписалы бы всякие..
(*) подразумевается, что нет в том плане, что не поддерживается напрямую компилятором и IDE.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Да, но только если вы не хотите открывать исходный код своих программ под GPL вам придется выложить АХ>>немалые суммы (за весь фреймворк в Desktop edition):
S>ммм... А сколько ты заплатиш на разработчика за винду, офис, студию?
Windows — от 0 (идет в OEM-поставке) до Windows Vista Business ($299)
Офис (2003: Standard — $399, Professional — $499) — он разработчику не обязательно нужен, в случае чего и OpenOffice можно поставить.
Студия — от 0 (Express edition) — 299$ (Standard) — 799$ (Professional), еще есть более дорогая Team suite но она на всю контору берется насколько я понимаю.
Если под .NET писать можно и бесплатный SharpDevelop юзать.
Итого, даже если по максимуму брать — 299+499+799 = 1597$. В 2 раза дешевле чем Qt (к которому все это все равно понадобится, если будешь разрабатывать под Windows).
S> А кроме этого существует наверняка еще множество полезного софта.
В том числе и open source (я например довольно много Open source использую)
S> А сервак для тестов, а сервак конторы?
IIS входит в поставку Windows.
Windows Server 2003 — от $397 (Web edition) до $3999 (Enterpise edition).
S>Это раз. S>Два: S>Покупая винду ты пишеш на винде под винду.
Почему это ? Под Windows я могу писать на любом языке пользуясь кроссплатформенными библиотеками. Впрочем как и под Линукс.
S> Покупая только Qt ты пишеш под любой поддерживаемой осью для любой поддерживаемой оси.
В зависимости от количества осей, которые ты хочешь поддерживать цена очень растет как ты видишь.
Кроме того для того чтобы нормально писать в Windows под Qt студию все равно придется купить
S>Есть разница?
По цене — огромная, не в пользу Qt.
WolfHound wrote: > C>А вообще, все чего Линуксу не хватает — это замены FARа и VisualStudio > для С++ > Однако samba рулит > Сижу под WinXP, а разрабатываю под линухом... использую Far и VC++8
Я сейчас пишу на Java, использую IDEA, у которой target-path'ом стоит
samba-шара на Линуксе
> Правда компилировать приходится через ssh кстати может кто знает как > научить студию компилять через ssh и зачитывать сообщения об ошибках?
Ну.... Есть BVRDE.
Еще можно сделать в Студии makefile-проект и в опциях прописать запуск
ssh с нужными параметрами (я так и делал), причем для ssh желательно
прописать авторизацию по ключам, чтобы пароль не надо было вводить.
Правда ошибки GCC Студия не разбирает
WolfHound wrote: > S>Понимаеш, эти все люди, которых ты описал — работают по виндовс, и > мышление виндозовское, обдотнетченое, так сказать. > Очень смелое утверждение для человека который не понимает разницу между > VB(не VB.NET) и .NET. > А что касается темы то виртуальная машина .NET действительно продумана > много лучше чем JVM.
Кстати, тут можно и поспорить. В чем-то лучше .NET, а в чем-то лучше Java.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Ну принципиально то, что они объединаются в одну сущность, а не 2 функции. Да, кстати — это синтаксический сахар, потом внутри MSIL они превращаются в обычные геттеры/сеттеры.
АХ>Ну и писать АХ>
Проперти в C# — это завуалированный и неочевидный синтаксис с семантикой. Совершенно непонятно, что скрывается за простым присвоением мемберу (кстати, как отличить public-поле от свойства?) значения и получением от него значения. Вы скажете, что public-поле в ООП-приложении неприлично выставлять, но в некоторых ситуациях это сделать легче (особенно в финальных классах) для описания констант.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Андрей Хропов, Вы писали:
S>>>Это ни в коем случае не плохо, это также и не хорошо. Это просто другое мышление. АХ>>У многих из них прагматичное мышление. Они разрабатывают некий продукт, а потом к ним приходит клиент и говорит "Мы используем также и Линукс, хотим чтобы под ним тоже работало". Вот тогда им и понадобится Mono. S>Qt?
"Корпоративный" стандарт — гэпээльная GTK, а не QT.
QT выбирают эксцентричные разработчики, привыкшие к С++.
Здравствуйте, Cyberax, Вы писали:
C>Правда ошибки GCC Студия не разбирает
Тогда нет никакого смысла этим заниматься. Ибо ценно не столько сам запуск компиляции (меня не ломает переключится в консоль и написать make) сколько возможность переходить по ошибкам одним кликом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
>> А что касается темы то виртуальная машина .NET действительно продумана много лучше чем JVM. C>Кстати, тут можно и поспорить. В чем-то лучше .NET, а в чем-то лучше Java. C>Я бы сказал, что они примерно одинаковы.
А я бы сказал что можно сделать машину котороя уделает обе. Причем она будет даже проще.
Нужно просто правильные абстракции подбирать.
Но это тема отдельного флейма.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Правда ошибки GCC Студия не разбирает > Тогда нет никакого смысла этим заниматься. Ибо ценно не столько сам > запуск компиляции (меня не ломает переключится в консоль и написать > make) сколько возможность переходить по ошибкам одним кликом. http://www.xs4all.nl/~borkhuis/vxworks/gnu2msdev.cpp не пробовал
случайно? Он ставится фильтром на make/ssh и переводит ошибки в формат MSVC.
S>>Есть разница? АХ>По цене — огромная, не в пользу Qt.
Ты забыл про привычку МС периодически трусить денюжку с пользователей. Вот сейчас идет: офис2007+виста. Половина софта не заработает, придется покупать новы, окажется что железо слабое... итд. Хотя чувствую, ты все равно посчитаеш не в мою пользу.
Здравствуйте, WolfHound, Вы писали:
WH>Очень смелое утверждение для человека который не понимает разницу между VB(не VB.NET) и .NET. WH>А что касается темы то виртуальная машина .NET действительно продумана много лучше чем JVM.
Ошибаешся, понимаю. Сколько можно писать, ято я оношусь к дотнету как к ВБ?
Здравствуйте, WolfHound, Вы писали:
WH>А я бы сказал что можно сделать машину котороя уделает обе. Причем она будет даже проще.
Можно. А можно на асме написать, и уделать и дотнет, и жаву.
Выбор идет между скоростью проектирования/программирования и скоростью работы. Я выбираю скорость работы. Корпорации и компании выбирают скорость проектирования. Почемуто простые фрилансеры и мелкие конторы тянутся вслед компаниям, не замечая что заказчика можно победить не только скоростью написания софта но и тем, что этот софт будет прекрасно работать на тех машинах, которые заказчик купил 2 года назад в уцененке, да к томуже что можно установить этот софт и забыть про сервак, пока винт не посыпется.
Здравствуйте, iZEN, Вы писали:
ZEN>Проперти в C# — это завуалированный и неочевидный синтаксис с семантикой. Совершенно непонятно, что скрывается за простым присвоением мемберу (кстати, как отличить public-поле от свойства?) значения и получением от него значения.
Абсолютно верно подмечено. Иногда это конечно бывает хорошо, но чаще плохо. Приводит к трудноуловимым ошибкам оптимизации кода. Я имею ввиду ситуацию, например, когда проперти попадает в цикл, а в свою очередь в проперти туча кода.
Я к чему? была бы ф-я — глаз бы за скобки зацепился. Скобок нет — больше времени на поиск тормозов. Особенно если проект большой, и программит его не один человек.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Андрей Хропов, Вы писали:
S>>>Есть разница? АХ>>По цене — огромная, не в пользу Qt. S>Ты забыл про привычку МС периодически трусить денюжку с пользователей.
Ну я посчитал цену на новое. Апгрейд дешевле .
Здравствуйте, Sheridan, Вы писали:
S>Выбор идет между скоростью проектирования/программирования и скоростью работы. Я выбираю скорость работы.
Для десктопного не слишком навороченного ПО — это правильный выбор ИМХО.
S> Корпорации и компании выбирают скорость проектирования. Почемуто простые фрилансеры и мелкие конторы тянутся вслед компаниям, не замечая что заказчика можно победить не только скоростью написания софта но и тем, что этот софт будет прекрасно работать на тех машинах, которые заказчик купил 2 года назад в уцененке, да к томуже что можно установить этот софт и забыть про сервак, пока винт не посыпется.
Ответ на этот вопрос прост:
1) месяц работы квалифицированного программиста, который сможет написать быстрое ПО, стоит в Москве >1700-2000$ (т.к. столько надо только на зарплату), на Западе еще дороже, сервак с достаточно мощным процом и до хрена памяти можно собрать в 2 раза дешевле.
Да и в уцененке покупать может оказаться себе дороже — быстрее посыпется и гарантии нет.
2) Основные проблемы в современном бизнес-программировании — постоянно меняющиеся требования и необходимость интеграции разнородных компонентов. Чем быстрее будет прототип, тем быстрее можно будет потестировать его и понять что надо менять и модифицировать.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Sheridan, Вы писали:
S>>Ошибаешся, понимаю. Сколько можно писать, ято я оношусь к дотнету как к ВБ? АХ>
Ну, ничего другого я не ожидал...
Я не могу поверить просто что люди в восторге от подобной технологии. Обещали кроссплатформенную виртмашину типа явы. Что имеем? тормознутую переделку бэйсика на новый лад. Да, улучшили. Да, поменяли синтаксис. Да, прикрутили студию. И развели сверхмощную рекламную компанию. Про кроссплатформенность я уже и не вспоминаю. Далее, что микрософт проталкивало раньше в массы? Правильно, ВБ. А что сделает манагер из МС, если видит, что продукт непопулярен? Начнет думать, как сделать популярным, а заодно и привязать к операционке, дабы не было прецендентов отказа от использования винды. Скажеж дотнет не привязан к винде? А люди глотают полученную наживку, радуются сверхлегкости кодинга, не замечая что все меньше и меньше оставляют себе места для маневра.
[RSDN@Home][1.2.0][alpha][668]
[Кто не знает, что такое мир, не знает, где он сам... [Марк Аврелий]]
Здравствуйте, EvilChild, Вы писали:
TBG>>Ну тогда bash+vim+hexedit+ncftp. А под "удобными" вы какое понятие вкладываете? EC>Я бы вместо bash порекомендовал zsh.
Кто-то порекомендует tcsh. Дело привычки. Другие шеллы навернутее, но пока то, что мне нужно, есть в bash. Время покажет. Пока баш лет 6 держится.
Здравствуйте, Donz, Вы писали: D>Чем "умное" поле нагляднее в коде, чем метод, если выглядит также, как и "неумное" поле? D>Я, кстати, не говорил, что мне неудобно. Я сказал, что непонятно зачем вводить лишнюю сущность. Можете назвать принципиальное отличие свойств от геттеров/сеттеров?
Можно.
1. Метаданные. Я могу отличить проперть от случайно названной пары методов, в том числе и через Reflection. Я застрахован от
float getWidth();
void setWidth(int width);
2. Читаемость. Что лучше читается:
Width+=2;
setWidth(getWidth()+2)
?
В целом, существует такой Property Pattern. В джаве его приходится реализовывать руками, а в шарпе он встроен в язык. Как и еще несколько паттернов.
Впрочем, на эту тему уже очень хорошо написано. Типичный Блаб программист делит все фичи на две группы:
— фичи, которые есть в Блабе, и значит обязаны быть в любом мало-мальски полезном языке
— фичи, которых нет в Блабе, и значит они никому не нужны.
Вот типичные высказывания блаб программистов:
"Десять лет программирую без пропертей, и ни разу не замечал, что мне чего-то не хватает", "нафига вводить какой-то искусственный event, когда можно обойтись интерфейсом?", "непонятно, зачем придумывать урезанную версию оператора for", "на языке без checked exceptions невозможно писать корректные программы", "енумы легко эмулируются силед классами без методов", "yield return вообще непонятно, что делает".
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
S>Абсолютно верно подмечено. Иногда это конечно бывает хорошо, но чаще плохо. Приводит к трудноуловимым ошибкам оптимизации кода. Я имею ввиду ситуацию, например, когда проперти попадает в цикл, а в свою очередь в проперти туча кода. S>Я к чему? была бы ф-я — глаз бы за скобки зацепился. Скобок нет — больше времени на поиск тормозов. Особенно если проект большой, и программит его не один человек.
Здравствуйте, Sinclair, Вы писали:
S>Можно. S>1. Метаданные. Я могу отличить проперть от случайно названной пары методов, в том числе и через Reflection. Я застрахован от S>
Здравствуйте, prVovik, Вы писали:
V>Погугли по слову "профайлер"
Ты так часто им пользуешся?
Профайлер применяется как правило уже на заведомо тормозной машине. Он конечно выявит применение пропертя ни к месту, но ведь при отсутствии пропертей не нужно будет запускать профайлер в данном случае.
[RSDN@Home][1.2.0][alpha][668]
[Мир ловил меня, но не поймал. [Г. С. Сковорода]]
M>>Почти оффтоп, почти СВ. Если бы в МС сделали MFC хоть наполовину похожую на Qt, на .NET бы сейчас никто бы не переезжал, имхо WH>Не гуем идиным... Многие вещи которые элементарно делаются под .НЕТ требуют при разработке на С++ чудовищных усилий.
Я не спорю. Да и Qt — это уже тоже не ГУЙ един
В общем, имеем мы сейчас то, что имеем, и мучатся нам с ним, а не с тем, что могло бы быть
Здравствуйте, prVovik, Вы писали:
S>>Согласен наполовину. Во втором случае я буду видеть возможную проблему в производительности. V>Да, способности к ясновидению — это очень полезная вещь!
Ты зря убрал
Width+=2;
setWidth(getWidth()+2);
Во втором случае все намного более наглядно.
[RSDN@Home][1.2.0][alpha][668]
[Одно и то же слово и совет Hа пользу мудрецу, глупцу во вред. [аль-Хусри]]
WolfHound wrote:
> C>А вообще, все чего Линуксу не хватает — это замены FARа и VisualStudio > для С++ > Однако samba рулит > Сижу под WinXP, а разрабатываю под линухом... использую Far и VC++8 > Правда компилировать приходится через ssh кстати может кто знает как > научить студию компилять через ssh и зачитывать сообщения об ошибках?
Попробуй похимичить с plink из пакета PuTTY.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, prVovik, Вы писали:
V>>Погугли по слову "профайлер"
S>Ты так часто им пользуешся?
В последнее время да. Я сейчас не представляю, как реально можно ускорить программу без профайлера, или его ручных аналогов (оценки "не на глаз" времени выполнения определенных кусков программы).
S>Профайлер применяется как правило уже на заведомо тормозной машине.
Это еще почему?
S>Он конечно выявит применение пропертя ни к месту, но ведь при отсутствии пропертей не нужно будет запускать профайлер в данном случае.
Совершенно неверно! Определить место в программе без профайлера (или его ручных аналогов), в котором тормозит программа обычно очень трудно. И то, что вместо проперти используется функиция — аьсолютно ниочем не говорит, так как эта функция может отрабатывать мгновенно, либо вызываться редко и не влиять потому на общую производительность.
Когда я работал над последним проектом, я полностью забил поначалу на оптимизации и решил сделать все как можно быстрее, а потом профайлером обработать. В результате выяснилось, что, те места, которые я изначально предполагал оптимизировать, совершенно на нуждались в оптимизациях. А вот реально тормоза оказались в абсолютно неожиданных местах, на "ровном месте", как я предполагал изначально. Так что сам факт, что в конкретном месте программы используется функция, а не мембер еще не значит, что именно тут надо оптимизировать.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, prVovik, Вы писали:
S>>>Согласен наполовину. Во втором случае я буду видеть возможную проблему в производительности. V>>Да, способности к ясновидению — это очень полезная вещь!
S>Ты зря убрал S>
S>Width+=2;
S>setWidth(getWidth()+2);
S>
S>Во втором случае все намного более наглядно.
По приведенным данным, проблем в производительности увидеть невозможно. Даже если внутри setWidth и getWidth происходит, например, обращение к базе данных, это еще не значит, что в этом месте будут проблемы с производительностью.
Здравствуйте, Sheridan, Вы писали: S>Согласен наполовину. Во втором случае я буду видеть возможную проблему в производительности. Ты — ни в каком случае не увидишь возможную проблему в производительности. Увидеть ее может только профайлер.
Вот тебе пример. Какой из циклов выполняется быстрее?
public static int Sum(int[] array)
{
int a=0;
for(int i=0;i<array.Count;i++)
a+= array[i];
return a;
}
или
public static int Sum(int[] array)
{
int a=0;
int count = array.Count;
for(int i=0;i<count;i++)
a+= array[i];
return a;
}
Неочевидно?
Давай перепишем первый цикл так, чтобы скобочки подсказывали тебе про возможную проблему с производительностью (это конечно не шарп, но предположим мы убрали из него свойства. спеециально для тебя):
public static int Sum(int[] array)
{
int a=0;
for(int i=0;i<array.getCount();i++)
a+= array[i];
return a;
}
Бинго? Хрен, а не бинго.
Во-первых, в современных языках высокого уровня оптимизатор вполне способен сделать инлайнинг, а потом вынести инвариант за цикл. Так что для плюсов, к примеру, оба цикла семантически эквивалентны.
Во-вторых, JIT дотнета знает, что выражение (i<array.Count) проверяется на каждой итерации, так что выкинет проверки выхода за границу массива, которые присуствуют внутри цикла. В итоге вариант, за который цепляется твой соколиный глаз, выполняется быстрее, чем гладкий.
Резюме: инструмент поиска причины проблем с производительностью — не глаза, а профайлер. А ему, извини, по барабану, насколько "невинно" выглядит код.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, prVovik, Вы писали:
S>>Профайлер применяется как правило уже на заведомо тормозной машине. V>Это еще почему?
Сорри, подразумевалось на заведомо тормозном софте.
V>Когда я работал над последним проектом, я полностью забил поначалу на оптимизации и решил сделать все как можно быстрее, а потом профайлером обработать. В результате выяснилось, что, те места, которые я изначально предполагал оптимизировать, совершенно на нуждались в оптимизациях. А вот реально тормоза оказались в абсолютно неожиданных местах, на "ровном месте", как я предполагал изначально. Так что сам факт, что в конкретном месте программы используется функция, а не мембер еще не значит, что именно тут надо оптимизировать.
Согласен. Я говорил к тому, что при использовании функций часто меньше сделать тормоза, так как видно что это функция, значит будет выполняться некий код, etc.
[RSDN@Home][1.2.0][alpha][668]
[Кто молчать не умеет, тот и говорить не способен. [Сенека Младший]]
Здравствуйте, prVovik, Вы писали:
V>По приведенным данным, проблем в производительности увидеть невозможно. Даже если внутри setWidth и getWidth происходит, например, обращение к базе данных, это еще не значит, что в этом месте будут проблемы с производительностью.
Я и не говорю что будет проблема, я говорю, что проще и быстрее найти, если изначально были тормоза.
Здравствуйте, Sinclair, Вы писали:
S>Резюме: инструмент поиска причины проблем с производительностью — не глаза, а профайлер. А ему, извини, по барабану, насколько "невинно" выглядит код.
Ладно, убедил.
[RSDN@Home][1.2.0][alpha][668]
[Hе удивление, а недоумение и печаль суть начало философии. [А. Шопенгауэр]]
Здравствуйте, Sheridan, Вы писали:
S>>>Профайлер применяется как правило уже на заведомо тормозной машине. V>>Это еще почему? S>Сорри, подразумевалось на заведомо тормозном софте.
А если софт и без того летает, то зачем его еще оптимизировать?
ИМХО, оптимизации и нужны как раз на тормозном софте.
Здравствуйте, Sinclair, Вы писали:
S>Во-вторых, JIT дотнета знает, что выражение (i<array.Count) проверяется на каждой итерации, так что выкинет проверки выхода за границу массива, которые присуствуют внутри цикла.
А как он знает, что array.Count не меняется?
S>Резюме: инструмент поиска причины проблем с производительностью — не глаза, а профайлер. А ему, извини, по барабану, насколько "невинно" выглядит код.
Здравствуйте, Sheridan, Вы писали:
WH>>А я бы сказал что можно сделать машину котороя уделает обе. Причем она будет даже проще. S>Можно.
Только учитывая следующею строчку ИМХО ты даже близко не представляешь как это сделать.
S>А можно на асме написать, и уделать и дотнет, и жаву.
S>Выбор идет между скоростью проектирования/программирования и скоростью работы. Я выбираю скорость работы. Корпорации и компании выбирают скорость проектирования. Почемуто простые фрилансеры и мелкие конторы тянутся вслед компаниям, не замечая что заказчика можно победить не только скоростью написания софта но и тем, что этот софт будет прекрасно работать на тех машинах, которые заказчик купил 2 года назад в уцененке, да к томуже что можно установить этот софт и забыть про сервак, пока винт не посыпется.
Так что же ты до сих пор не уделал всяких ламеров которые пишут тормозные поделки на .НЕТ и жабе?
Тут есть две причины:
1)Это сделать просто только языком. Когда попробуешь написать на асме то что на шарпе занимает сотню тысяч строк Короче оно будет постоянно голючить и падать. Да и работать будет скорей всего сильно медленней ибо все ресурсы съест борьба с багами и на оптимизацию времени не останется.
2)Ориентироваться на жмотов которые покупают компы в уценке бесполезно ибо они всеравно софт не купят. И тем болие поддержку не закажут.
Короче окажи услугу себе и окружающим: займись собственным образованием ибо те "знания" что ты демонстрируешь в форуме просто смешны.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>А как он знает, что array.Count не меняется?
В дотнете невозможно изменить длину массива. Сделано специально, чтобы позволять подобные оптимизации.
Если вопрос о компиляторе С++ и произвольной коллекции, то у компилятора может оказаться достаточно информации о том, что происходит внутри цикла, чтобы понять, что результат Count() никогда не изменяется.
Я написал может оказаться потому, что С++, хотя и оборудован средствами коммуникации между разработчиком класса и компилятором, не требует их использовать. В частности, далеко не всегда можно заинлайнить метод Count() и далеко не всегда удастся заинлайнить обращения к коллекции внутри цикла или вывести неизменность из сигнатур используемых методов (оператору [] достаточно быть объявленным как const, чтобы компилятор имел право предполагать неизменность внутренних полей коллекции после его вызова даже без детального анализа кода). В частности, именно эту проблему решают template-based библиотеки типа STL. S>>Резюме: инструмент поиска причины проблем с производительностью — не глаза, а профайлер. А ему, извини, по барабану, насколько "невинно" выглядит код. ANS>Это бесспорно.
Ну, люди до сих пор думают, что могут определить степень влияния фрагментов кода на производительность по наличию скобочек, или легко победить back-end промышленного компилятора ассемблерными вставками. И все это духом единым, без костылей типа профайлера.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Ну принципиально то, что они объединаются в одну сущность, а не 2 функции. Да, кстати — это синтаксический сахар, потом внутри MSIL они превращаются в обычные геттеры/сеттеры.
АХ>>Ну и писать АХ>>
ZEN>Проперти в C# — это завуалированный и неочевидный синтаксис с семантикой. Совершенно непонятно, что скрывается за простым присвоением мемберу (кстати, как отличить public-поле от свойства?) значения и получением от него значения. Вы скажете, что public-поле в ООП-приложении неприлично выставлять, но в некоторых ситуациях это сделать легче (особенно в финальных классах) для описания констант.
Угу.. Вместо того, чтобы поле публичным сделать, лучше добавить еще от 3 до 6 строчек на геттер/сеттер или пропертю в шарпе.. Причем в подавляющем большинстве случаев реализация геттеров/сеттеров тривиальна...
Здравствуйте, WolfHound, Вы писали:
WH>Так что же ты до сих пор не уделал всяких ламеров которые пишут тормозные поделки на .НЕТ и жабе?
Потому что не поспею. Уж лучше я это время потрачу на изучение Qt.
Здравствуйте, Gajdalager, Вы писали:
G>Угу.. Вместо того, чтобы поле публичным сделать, лучше добавить еще от 3 до 6 строчек на геттер/сеттер или пропертю в шарпе..
Зачем такие сложности? Нажимаем шорткат и решарпер все сам за нас сделает
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, Gajdalager, Вы писали:
G>>Угу.. Вместо того, чтобы поле публичным сделать, лучше добавить еще от 3 до 6 строчек на геттер/сеттер или пропертю в шарпе.. V>Зачем такие сложности? Нажимаем шорткат и решарпер все сам за нас сделает
Зачем такие сложности? Если никаких дополнительных действий не надо — выносим поле в паблик и никому ни за кого ничего делать не придеться
Здравствуйте, xvost, Вы писали:
ANS>>А как он знает, что array.Count не меняется? X>Потому что массивы immutable
Несколько не корректно. Массивы в .НЕТ еще как mutable у них только размер immutable.
Болие того в .NET вобще нет immutable типов что ИМХО очень плохо.
Эмуляция immutable типов (например string или любой другой класс у которого нет мутирующих методов) приводит к тому что рантайму очень сложно применять агрессивные оптимизации.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gajdalager, Вы писали:
G>Угу.. Вместо того, чтобы поле публичным сделать, лучше добавить еще от 3 до 6 строчек на геттер/сеттер или пропертю в шарпе.. Причем в подавляющем большинстве случаев реализация геттеров/сеттеров тривиальна...
Если поле сделать публичным, то как можно брякнуться в отладке на попытку изменения поля ?
Или искать все строки
Здравствуйте, Sheridan, Вы писали:
WH>>Так что же ты до сих пор не уделал всяких ламеров которые пишут тормозные поделки на .НЕТ и жабе? S>Потому что не поспею. Уж лучше я это время потрачу на изучение Qt.
Qt это не то на что имеет смысл тратить время.
Все библиотечки всравно не изучишь ибо их легион, а ты один.
Болие того в них нет ничего такого что может тебе дать какие либо преимущества.
Тебе нужны фундаментальные знания, а не глупые библиотечки.
Нужно понимать что как и почему именно так устроено.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Что-то я ничего не понял. Это слово что обозначает? Употребление анаши в одиночестве? Но тогда ведь вместо второй "о" все равно останется "а", не так ли?
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, Gajdalager, Вы писали:
G>>Угу.. Вместо того, чтобы поле публичным сделать, лучше добавить еще от 3 до 6 строчек на геттер/сеттер или пропертю в шарпе.. Причем в подавляющем большинстве случаев реализация геттеров/сеттеров тривиальна... M>Если поле сделать публичным, то как можно брякнуться в отладке на попытку изменения поля ? M>Или искать все строки M>
M>myClass.myPubllicValue = XXX
M>
M>и ставить там бряки ?
В шарпе можно было бы создать одноимённую пропертю и брейк поставить в ней.. Но пропертю я бы создал, только когда нужно (в данном случае, чтобы брэйк поставить).. Остальные публичные поля так и остались бы публичными. А в Жаве пропертей нет Лично мне не хватает..
Здравствуйте, Sheridan, Вы писали:
S>>>Ошибаешся, понимаю. Сколько можно писать, ято я оношусь к дотнету как к ВБ? АХ>>
S>Ну, ничего другого я не ожидал... S>Я не могу поверить просто что люди в восторге от подобной технологии. Обещали кроссплатформенную виртмашину типа явы. Что имеем?
Мощную компонентную многоязычную платформу, технологически превосходящую JVM (в частности в плане поддержки рефлексии и динамических языков).
Кроссплатформенность — да, с этим пока похуже, но Mono развивается. FW 1.1 уже полностью поддерживают насколько я знаю.
C# 2.0 — тоже, осталось только доделать BCL 2.0.
S> тормознутую переделку бэйсика на новый лад.
1) Ну давай бенчмарки с тормозами. По моим ощущениям на большинстве невычислительных задач разница с C++ минимальна, а где-то C++ и серьезно проигрывает (особенно где много работы с памятью).
2) Под .NET полно языков, в том числе и Nemerle, который Бейсиком ну никак не назовешь
Я тоже раньше считал, что это тормоза (по сравнению с C++). Погонял бенчмарки и понял что это не так. Да собственно и неудивительно — с точным уплотняющим сборщиком мусора выделение памяти в куче практически так же дешево как не стеке, в отличие от malloc/new.
S> Да, улучшили. Да, поменяли синтаксис. Да, прикрутили студию. И развели сверхмощную рекламную компанию. Про кроссплатформенность я уже и не вспоминаю. Далее, что микрософт проталкивало раньше в массы? Правильно, ВБ.
Задумайся, почему MS отказался от уже раскрученного и весьма популярного ВБ. А ведь его упрашивали, петиции писали, чтобы он этого не делал.
S> А что сделает манагер из МС, если видит, что продукт непопулярен? Начнет думать, как сделать популярным, а заодно и привязать к операционке, дабы не было прецендентов отказа от использования винды. Скажеж дотнет не привязан к винде?
Не привязан
S> А люди глотают полученную наживку, радуются сверхлегкости кодинга, не замечая что все меньше и меньше оставляют себе места для маневра.
Сверхлегкость кодинга — за этим пожалуйста к Python и Ruby
АХ>Да собственно и неудивительно — с точным уплотняющим сборщиком мусора выделение памяти в куче практически так же дешево как не стеке, в отличие от malloc/new.
Почему-то вспомнился анекдот про студентов с финальной фразой: "... а потом начинается сессия!"
Здравствуйте, WolfHound, Вы писали:
WH>Qt это не то на что имеет смысл тратить время. WH>Все библиотечки всравно не изучишь ибо их легион, а ты один.
Мне пока Qt хватает.
WH>Болие того в них нет ничего такого что может тебе дать какие либо преимущества.
Кроссплатформенность.
WH>Тебе нужны фундаментальные знания, а не глупые библиотечки. WH>Нужно понимать что как и почему именно так устроено.
Что я не понимаю?
[RSDN@Home][1.2.0][alpha][668]
[Да не будем на авось гадать о величайшем! [Гераклит Эфесский]]
Здравствуйте, Gajdalager, Вы писали:
G>В шарпе можно было бы создать одноимённую пропертю и брейк поставить в ней.. Но пропертю я бы создал, только когда нужно (в данном случае, чтобы брэйк поставить).. Остальные публичные поля так и остались бы публичными.
Ну и зачем ? Если можно набить prop нажать Tab
и получить заглушку вида.
private int myVar;
public int MyProperty
{
get { return myVar; }
set { myVar = value; }
}
Меняем только тип(автоматически меняется и в проперте)
ну и вводим имена.
И вообще мой опыт говорит, что как только ты сделаешь поле public буквально через пару дней придется оборачивать его в пропертю.
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, Gajdalager, Вы писали:
G>>В шарпе можно было бы создать одноимённую пропертю и брейк поставить в ней.. Но пропертю я бы создал, только когда нужно (в данном случае, чтобы брэйк поставить).. Остальные публичные поля так и остались бы публичными.
M>Ну и зачем ? Если можно набить prop нажать Tab
А кода меньше будет.. В классе, допустим, 5 полей, которые по логике публичные, а строчек кода — мама дорогая! И все вида getField/setField, причем тривиальной реализаци.. Сразу и не видно, который делает чего, а который — только устанавливает.. M>И вообще мой опыт говорит, что как только ты сделаешь поле public буквально через пару дней придется оборачивать его в пропертю.
Что, прям таки все или большинство? M>И вообще прямой доступ к переменным считаю злом.
Тоже так считал.. А потом подумал, ну какая разница — задаём мы значение поля через функцию или напрямую, если функция только то и делает, что присваивает полю значение? Правильно, только в размере кода и в том, что в случае функции нам можно будет добавить дополнительную логику безболезненно.. Если в случае Жавы еще можно понять, зачем сразу геттера писать (чтобы потом не переписывать клиентский по отношению к этому классу код), то зачем в шарпе, где есть пропертя и можно подменить поле на геттер/сеттер совсем без крови и только тогда, когда понадобится?
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Кроссплатформенность — да, с этим пока похуже, но Mono развивается. FW 1.1 уже полностью поддерживают насколько я знаю.
Цена этому — грош в базарный день. Пока MS не заявит, что а) не будет предъявлять _никаких_ притензий к mono и производным продуктам, использующим её собственные технологии; б) не возьмёт mono под опеку (если не денег, то ms-labs хотябы) — доверия (массового) к моно не будет
P.S. Если "угораздит" заняться собственным портированием .net на остальной зоопарк ОС не открывая исходников — будет ещё хуже
P.P.S. БГ фиг знает когда вещал, что собирается брать деньги за сервисы (правда, не брать за программы не обещал )Что ему стоит поддержать открытые моно и немерле?
Здравствуйте, Gajdalager, Вы писали:
G>А кода меньше будет.. В классе, допустим, 5 полей, которые по логике публичные, а строчек кода — мама дорогая! И все вида getField/setField, причем тривиальной реализаци.. Сразу и не видно, который делает чего, а который — только устанавливает..
Ну для этого регионы есть M>>И вообще мой опыт говорит, что как только ты сделаешь поле public буквально через пару дней придется оборачивать его в пропертю. G>Что, прям таки все или большинство?
Наверное все же не все, но большинство. процентов 80 M>>И вообще прямой доступ к переменным считаю злом.
G>Тоже так считал.. А потом подумал, ну какая разница — задаём мы значение поля через функцию или напрямую, если функция только то и делает, что присваивает полю значение? Правильно, только в размере кода и в том, что в случае функции нам можно будет добавить дополнительную логику безболезненно..
Ну и в пропертю можно будет добавить дополнительную логику не менее безболезненно
А функций может быть несколько. А пропертя она одна.
Здравствуйте, cl-user, Вы писали:
CU>Цена этому — грош в базарный день. Пока MS не заявит, что а) не будет предъявлять _никаких_ притензий к mono и производным продуктам, использующим её собственные технологии; б) не возьмёт mono под опеку (если не денег, то ms-labs хотябы) — доверия (массового) к моно не будет
А разве не это произошло после их недавнего "брудершафта" с Новеллом?
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, Gajdalager, Вы писали:
G>>А кода меньше будет.. В классе, допустим, 5 полей, которые по логике публичные, а строчек кода — мама дорогая! И все вида getField/setField, причем тривиальной реализаци.. Сразу и не видно, который делает чего, а который — только устанавливает.. M>Ну для этого регионы есть
Ну.. это.. как бы костылем попахивает...
G>>Тоже так считал.. А потом подумал, ну какая разница — задаём мы значение поля через функцию или напрямую, если функция только то и делает, что присваивает полю значение? Правильно, только в размере кода и в том, что в случае функции нам можно будет добавить дополнительную логику безболезненно.. M>Ну и в пропертю можно будет добавить дополнительную логику не менее безболезненно
Ну я это и говорю Единственное, что я утверждаю, что ИМХО лучше вместо тривиальной проперти
private int _code;
public int code {
get {return _code}
set {_code = value}
}
писать
public int code;
А потом когда реализация проперти будет нетривиальной, развернуть ее.. .Однако это ИМХО, к тому же голословное, поскольку я работаю на Жаве, где пропертей нет и чего-то могу не замечать..
Здравствуйте, Gajdalager, Вы писали:
G>Ну.. это.. как бы костылем попахивает...
Отчего же ? Не нравится — оберни регионом, чтобы не мешало выидеть общую картину. Я ими не пользуюсь, мне не мешает.
M>>Ну и в пропертю можно будет добавить дополнительную логику не менее безболезненно
G>Ну я это и говорю Единственное, что я утверждаю, что ИМХО лучше вместо тривиальной проперти G>
G>private int _code;
G>public int code {
G>get {return _code}
G>set {_code = value}
G>}
G>
G>писать G>
G>public int code;
G>
G>А потом когда реализация проперти будет нетривиальной, развернуть ее.. .Однако это ИМХО, к тому же голословное, поскольку я работаю на Жаве, где пропертей нет и чего-то могу не замечать..
Ну да на вкус и цвет товарища нет. Но когда кто попало может изменять паблик свойства, и это не контролируется —
Много часов было в свое время потрачено на отлавливание бага, который сводился к вопросу
"Какая с*%а это изменяет"? А изменялось поле в более чем надцати местах немаленького проекта. Все усугублялось тем, что я тогда был молод и неопытен, код был не мой, и вообще
бррр.. как вспомню, так вздрогну
... << RSDN@Home 1.2.0 Deep Purple — Concert for Group & ... Mov.3 >>
Здравствуйте, cl-user, Вы писали:
CU>Цена этому — грош в базарный день. Пока MS не заявит, что а) не будет предъявлять _никаких_ притензий к mono и производным продуктам, использующим её собственные технологии; б) не возьмёт mono под опеку (если не денег, то ms-labs хотябы) — доверия (массового) к моно не будет
Какие именно технологии MS используются в Mono?
Ы или не Ы? дефиниция. Разъяснение: Mono — open-source реализация ECMA CLI Стандарт ECMA CLI открытый, и каждый вправе реализовать CLI.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>>>Вот тогда им и понадобится Mono. S>>Qt? АХ>Что Qt? У них уже есть приложение под .NET, которое хотят портировать.
Имхо лучше всетаки на кутэ пускай начинают... Ибо пока моно дождутся — уже и не надо будет. Либо, если уж так надо, пусть берутся помогать моно программить.
АХ>Да и Qt для коммерческого применения безумно дорог — от $4950 на 1 разработчика для 2 платформ (здесь).
С Qt это единовременное вложение (насколько я помню). Продукты же микрософта имеют привычку скачкообразно изменяться, требуя оплаты за новые версии.
Вдобавок, с кутэ можно вполне законно писать и тестировать первый проект на free, а при готовности продукта купить коммерческую кутэ непосредственно перед началом продаж.
АХ>А чтобы разрабатывать на Qt под Windows нормально придется все равно покупать Visual Studio.
Ну, скажу честно, редактора уровня VS под линух нет, хотя емаксовцы меня конечно щас камнями то позакидают
Кстати, очень подает надежды молодой QDevelop.
Итого — возможны вложения только в технику и в Qt.
S>>Значит, ему было нужно. АХ>Как видишь проект Mono не умер, а вполне себе развивается. Правда не так хорошо как хотелось бы...
Ну мне это, как понимаеш, не важно
S>>Чего именно не хватает? АХ>Как интегрировать в рамках, например, твоего Qt компоненты на Python и на C++? АХ>Без дополнительных усилий, просто взял и вызвал метод.
Если сможеш такое на С++, сделаеш и в Qt, но врядли будет переносимо... С помощью же кутэ такое не сделаеш.
АХ>А динамически объекты создавать можно по имени? АХ>типа как в .NET: АХ>А вообще как с рефлексией? АХ>А с версионностью компонентов как?
Объясни что это такое, и зачем оно нужно. Особенно про динамические объекты. Думал минут пять но так и не придумал куда можно их применить в реальной задаче.
Версионность то конечно еще можно понять для чего, так это имхо лучше делать на уровне проекта, а не на уровне библиотек.
АХ>Что такое o_0?
(( о_0 == 0_о ) ~= ( o0 == 0o )) ~= , но не так выражено
S>>>> И объяснить почему моно слабо пойдет под линуухом, это практически тоже самое, что объяснить виндузовцам — что на серваке не должно быть графики, а только консоль. АХ>>>На серваке должно быть то, чем удобно пользоваться. Лучше и то и другое. S>>Мне удобно пользоваться mc... Админу нашему удобно пользоваться mc. А еще ssh, telnet... Этого хватает с головой, поверь. АХ>Кому чего. Но я не админ, мне сложнее судить.
Тут все скатывается в
1. в удобство конфигурирования.
2. в дополнительной трате ресурсов графикой.
Поверь, мне тоже было удобно и приятно лпзить по менюшкам, тыкать в галочки и радиобаттоны, выбирать чтототам из списков... Но до тех пор, пока я не увидил нормальный текстовый конфиг. Например конфиг апача. Или ПХП. Да там во сто крат удобнее конфигурить.
А конфиг апитаблес взять если? Это даже не конфиг, это скрипт получается, и мне както трудно будет представить его в "терминах" пимпочек и галочек.
Трата ресурсов же — спорный на самом деле вопрос. Тестов я не проводил, но отталкиваюсь от вполне трезвой мысли — "Чем меньше ненужного запущено — тем меньше тратится ресурсов".
АХ>Но агитировать за технологии уровня 70-х годов...
Вот тут извини, но ты неправ. Наличие графики никак не влияет на современность используемых технологий. Или ты хочеш сказать что раз винду придумали в 93 (?), а ядро линуха начали писать в 70х — автоматически делает линух "устаревшей технологией"? В таком случае неправ вдвойне.
Здравствуйте, Sheridan, Вы писали:
АХ>>Кому чего. Но я не админ, мне сложнее судить. S>Тут все скатывается в S>1. в удобство конфигурирования. S>2. в дополнительной трате ресурсов графикой.
Графика больше не ресурс. И сеть тоже уже не ресурс.
S>Поверь, мне тоже было удобно и приятно лпзить по менюшкам, тыкать в галочки и радиобаттоны, выбирать чтототам из списков... Но до тех пор, пока я не увидил нормальный текстовый конфиг. Например конфиг апача. Или ПХП. Да там во сто крат удобнее конфигурить.
Каждому свое, а лысому — расческа. Bind конфигурял с его нормальным текстовым конфигом? Я к тому, что если в предметной области не сечешь, то тебе хоть текстовый, хоть 3-х мерный — толку никакого.
S>А конфиг апитаблес взять если? Это даже не конфиг, это скрипт получается, и мне както трудно будет представить его в "терминах" пимпочек и галочек.
Кому скрипт, а кому конфиг, который может быть привязан к определенному интерфейсу. А в плане конфига чистого iptables-save и iptables-restore. Правда, зависит от версии линухов, может и вообще, /ets/sysconfig/iptables получиться. Лично мне идея в скриптах иптаблеса не нравится. Может, конечно, временно такое быть, но лучше все описать декларативно.
S>Трата ресурсов же — спорный на самом деле вопрос. Тестов я не проводил, но отталкиваюсь от вполне трезвой мысли — "Чем меньше ненужного запущено — тем меньше тратится ресурсов".
А если еще процентов 95 остается?
S>Вот тут извини, но ты неправ. Наличие графики никак не влияет на современность используемых технологий. Или ты хочеш сказать что раз винду придумали в 93 (?), а ядро линуха начали писать в 70х — автоматически делает линух "устаревшей технологией"? В таком случае неправ вдвойне.
Ядро именно линуха, насколько я помню, начали в 90х писать. А по поводу графики — винда тут не пионер.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Графика больше не ресурс. И сеть тоже уже не ресурс. угу, и память — не ресурс, и винты не ресурс, и знаки тоже видимо не ресурс в итоге.
TBG>Каждому свое, а лысому — расческа. Bind конфигурял с его нормальным текстовым конфигом? Я к тому, что если в предметной области не сечешь, то тебе хоть текстовый, хоть 3-х мерный — толку никакого.
При чем тут сечеш — не сечеш? Я говорил про удобства.
TBG>Кому скрипт, а кому конфиг, который может быть привязан к определенному интерфейсу. А в плане конфига чистого iptables-save и iptables-restore. Правда, зависит от версии линухов, может и вообще, /ets/sysconfig/iptables получиться. Лично мне идея в скриптах иптаблеса не нравится. Может, конечно, временно такое быть, но лучше все описать декларативно.
Скрипт дает больше места для маневра (с)
S>>"Чем меньше ненужного запущено — тем меньше тратится ресурсов". TBG>А если еще процентов 95 остается?
А 5% значит не нужны? А если не остается? Скажем на серваке БД.
TBG>Ядро именно линуха, насколько я помню, начали в 90х писать. А по поводу графики — винда тут не пионер.
+
[RSDN@Home][1.2.0][alpha][668]
[Дороги судьбы, как правило, проселочные. [Авессалом Подводный]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Mirrorer, Вы писали:
M>>И вообще прямой доступ к переменным считаю злом.
S>Как скоро прямой доступ к пропертям начнеш считать злом?
см. Re[4]: Property Vs Public Field
Здравствуйте, Sheridan, Вы писали:
TBG>>Графика больше не ресурс. И сеть тоже уже не ресурс. S> угу, и память — не ресурс, и винты не ресурс, и знаки тоже видимо не ресурс в итоге.
К величайшемоу сожалению — да. Не за что теперь цепляться. Главно фишек быстрее накидать.
TBG>>Каждому свое, а лысому — расческа. Bind конфигурял с его нормальным текстовым конфигом? Я к тому, что если в предметной области не сечешь, то тебе хоть текстовый, хоть 3-х мерный — толку никакого. S>При чем тут сечеш — не сечеш? Я говорил про удобства.
Я про то, что удобства — это в квартире есть. А в конфиге потеряться или в менюшках и закладках — как-то неважно. Для кого-то удобнее одно, для кого-то — другое.
S>Скрипт дает больше места для маневра (с)
awk попробуйте.
TBG>>А если еще процентов 95 остается? S>А 5% значит не нужны? А если не остается? Скажем на серваке БД.
Здравствуйте, Mirrorer, Вы писали:
M>Ну да на вкус и цвет товарища нет. Но когда кто попало может изменять паблик свойства, и это не контролируется —
Действительно, спор о стиле — т.е. ни о чем.. Просто в коде
private int _code;
public int code {
get {return _code}
set {_code = value}
}
Здравствуйте, Turtle.BAZON.Group, Вы писали:
S>> угу, и память — не ресурс, и винты не ресурс, и знаки тоже видимо не ресурс в итоге. TBG>К величайшемоу сожалению — да. Не за что теперь цепляться. Главно фишек быстрее накидать.
S>>При чем тут сечеш — не сечеш? Я говорил про удобства. TBG>Я про то, что удобства — это в квартире есть. А в конфиге потеряться или в менюшках и закладках — как-то неважно. Для кого-то удобнее одно, для кого-то — другое.
Согласен.
S>>Скрипт дает больше места для маневра (с) TBG>awk попробуйте.
TBG>>>А если еще процентов 95 остается? S>>А 5% значит не нужны? А если не остается? Скажем на серваке БД. TBG>А зачем 95% простаивать?
А вот тут не понял...
Серваки они для чего покупаются? Чтобы делали нужное дело. Так зачем серваку заниматься параллельно с нужным делом еще и ерундой типа рисования красивых картинок на экране?
[RSDN@Home][1.2.0][alpha][668]
[Люди существуют друг для друга. [Марк Аврелий]]
Здравствуйте, Gajdalager, Вы писали:
G>Здравствуйте, Mirrorer, Вы писали:
M>>Ну да на вкус и цвет товарища нет. Но когда кто попало может изменять паблик свойства, и это не контролируется — G>Действительно, спор о стиле — т.е. ни о чем.. Просто в коде G>
G>private int _code;
G>public int code {
G>get {return _code}
G>set {_code = value}
G>}
G>
G>тоже ничего не контролируется
нет.
Но ничто не мешает при необходимости сделать так.
private int _code;
public int code {
get {return _code}
set {
Logger.Log(SomeContext, "Changed", value)
_code = value
}
}
И получить в логе все места где кто-то чего-то делает не того.
как такое сделать в случае
public int code;
... << RSDN@Home 1.2.0 Red Hot Chili Peppers — Deck The Halls >>
Здравствуйте, Sheridan, Вы писали:
TBG>>А зачем 95% простаивать? S>А вот тут не понял...
А зачем новый сервак покупать (а потом его настраивать), более мощный, если все равно 95% не будет использоваться?
S>Серваки они для чего покупаются? Чтобы делали нужное дело. Так зачем серваку заниматься параллельно с нужным делом еще и ерундой типа рисования красивых картинок на экране?
Ну если сервак закупался специально для обсчетов графики и отдачи на клиента, в том числе и того, что будет на экране..
Здравствуйте, Turtle.BAZON.Group, Вы писали:
M>>И получить в логе все места где кто-то чего-то делает не того. M>>как такое сделать в случае
M>>
TBG>AOP? pointcut?
Заместо добавления get/set городить AOP ?
Понятное дело, что если нам необходимо получить на шару логирование для ВСЕХ свойст, тогда АОП хорошо. Но если необходимо подсмотреть одно свойство...
... << RSDN@Home 1.2.0 Red Hot Chili Peppers — Nevermind >>
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>А зачем новый сервак покупать (а потом его настраивать), более мощный, если все равно 95% не будет использоваться?
А зачем тогда вообще сервак при таком раскладе? о_0
TBG>Ну если сервак закупался специально для обсчетов графики и отдачи на клиента,
Напомни ка мне... У 3д студии есть клиентские программки для обсчета графики. Ставиш на компы, настраиваеш студию на их использование, и они считают. Распредвычисления вбщем. Так вот, напомни мне — там разве крутится на экране то что они обсчитывают или просто иконка в трее (читай — просто процесс)?
TBG> в том числе и того, что будет на экране..
Кроме терминального сервака больше подобных задач в голову не приходит.
[RSDN@Home][1.2.0][alpha][668]
[Кот в перчатках мышь не поймает. [Б. Франклин]]
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, Gajdalager, Вы писали: M>нет. M>Но ничто не мешает при необходимости сделать так. M>
M>private int _code;
M>public int code {
M>get {return _code}
M>set {
M>Logger.Log(SomeContext, "Changed", value)
M>_code = value
M>}
M>}
M>
M>И получить в логе все места где кто-то чего-то делает не того. M>как такое сделать в случае
M>
M>public int code;
M>
Разговор по кругу Те поля, которые нужно логгировать, можно подменить на пропертю и никто снаружи ничего не узнает, после дебага сменить назад, чтобы код не засорять Хотя опять таки, с моей стороны это теоретические рассуждения, поскольку мой рабочий язык не поддерживает пропертей M>
Здравствуйте, Sheridan, Вы писали:
TBG>>А зачем новый сервак покупать (а потом его настраивать), более мощный, если все равно 95% не будет использоваться? S>А зачем тогда вообще сервак при таком раскладе? о_0
А если не видно разницы, зачем платить больше?
TBG>>Ну если сервак закупался специально для обсчетов графики и отдачи на клиента, S>Напомни ка мне... У 3д студии есть клиентские программки для обсчета графики. Ставиш на компы, настраиваеш студию на их использование, и они считают. Распредвычисления вбщем. Так вот, напомни мне — там разве крутится на экране то что они обсчитывают или просто иконка в трее (читай — просто процесс)?
И?
TBG>> в том числе и того, что будет на экране.. S>Кроме терминального сервака больше подобных задач в голову не приходит.
Например. Но если брать Х-сервер, то там сделано несколько иначе. Сам сервер установлен на клиенте и сервер выступает клиентом. Сервер же в данном случае — это то, что общается с видеоустройствами, клавиатурой, мышью.
В серверах SGI (когда-то давно) 3д считалось на сервере и отдавалось клиенту.
Здравствуйте, Mirrorer, Вы писали:
S>>собрать в Debug, выставить брэкпойнт и запустить в дебаг режиме? о_0 M>брякпоинт где ?
меню — поиск по проекту — найти имя_переменной
В итоге ошибка найдется быстрее, нежели при просмотре логфайла и попытками вспомнить что и когда использует эту пропертю, дабы попорядку вычислить место.
[RSDN@Home][1.2.0][alpha][668]
[Молчание — золото... если, конечно, не подлость. [Авессалом Подводный]]
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Здравствуйте, Sheridan, Вы писали:
TBG>>>А зачем новый сервак покупать (а потом его настраивать), более мощный, если все равно 95% не будет использоваться? S>>А зачем тогда вообще сервак при таком раскладе? о_0
TBG>А если не видно разницы, зачем платить больше?
Действительно, если сервак простаивает на 95% — то нужен ли он?
S>>Распредвычисления вбщем. Так вот, напомни мне — там разве крутится на экране то что они обсчитывают или просто иконка в трее (читай — просто процесс)? TBG>И?
Я к тому что графика прекрасно считается и без гуя.
TBG>>> в том числе и того, что будет на экране.. S>>Кроме терминального сервака больше подобных задач в голову не приходит.
TBG>Например. Но если брать Х-сервер, то там сделано несколько иначе. Сам сервер установлен на клиенте и сервер выступает клиентом. Сервер же в данном случае — это то, что общается с видеоустройствами, клавиатурой, мышью.
Экак ты загнул. Знаю я что собой иксы представляют. Видел как через ssh удаленно софт работает. Только при чем тут разделение софта на сервера и клиенты, когда разговор идет о серверах-компах?
TBG>В серверах SGI (когда-то давно) 3д считалось на сервере и отдавалось клиенту.
Опять — же это специализированные серваки, а я начинал общение с обычных серваков — шлюз, прокся, бд, апач...
[RSDN@Home][1.2.0][alpha][668]
[Hет вещи, которая могла бы возникнуть и расти одна. [Лукреций]]
Здравствуйте, Sheridan, Вы писали:
S>меню — поиск по проекту — найти имя_переменной
Вместо того чтобы поставить бряк в одном месте, а именно на set ?
S>В итоге ошибка найдется быстрее, нежели при просмотре логфайла и попытками вспомнить что и когда использует эту пропертю, дабы попорядку вычислить место.
Ну есть еще анализаторы логов в общем вместо поиска имени переменной я предпочитаю иметь set/get. Но это мои личные предпочтения
... << RSDN@Home 1.2.0 КИНО — Время есть, а денег нет >>
Здравствуйте, Sheridan, Вы писали:
TBG>>И? S>Я к тому что графика прекрасно считается и без гуя.
А я к тому, что не об этом разговариваем.
S>Экак ты загнул. Знаю я что собой иксы представляют. Видел как через ssh удаленно софт работает. Только при чем тут разделение софта на сервера и клиенты, когда разговор идет о серверах-компах?
Ну раз пошла тема — можно и порассуждать.
S>Опять — же это специализированные серваки, а я начинал общение с обычных серваков — шлюз, прокся, бд, апач...
Здравствуйте, Mirrorer, Вы писали:
M>Вместо того чтобы поставить бряк в одном месте, а именно на set ?
Ну и остановится оно внутри проперти
M>Ну есть еще анализаторы логов в общем вместо поиска имени переменной я предпочитаю иметь set/get. Но это мои личные предпочтения M>
Ну в принципе да, на вкус и цвет фломастеры разные
[RSDN@Home][1.2.0][alpha][668]
[Короли- уходят, а народы остаются. [В. Гюго]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Mirrorer, Вы писали:
M>>Вместо того чтобы поставить бряк в одном месте, а именно на set ? S>Ну и остановится оно внутри проперти
Ну в смысле бряк в одном месте, а не на месте изменений. Которых может быть много, а можно и пропустить какое-то.
Здравствуйте, Sinclair, Вы писали:
D>>Я, кстати, не говорил, что мне неудобно. Я сказал, что непонятно зачем вводить лишнюю сущность. Можете назвать принципиальное отличие свойств от геттеров/сеттеров? S>Можно. S>1. Метаданные. Я могу отличить проперть от случайно названной пары методов, в том числе и через Reflection. Я застрахован от S>
Тут согласен, плюс есть.
S>2. Читаемость. Что лучше читается: S>
S>Width+=2;
S>setWidth(getWidth()+2)
S>
S>?
Честно, мне второе, выше уже писал почему. Возможно, что сила привычки.
S>Впрочем, на эту тему уже очень хорошо написано. Типичный Блаб программист делит все фичи на две группы:
Блаб — новое кодовое название Java? S>- фичи, которые есть в Блабе, и значит обязаны быть в любом мало-мальски полезном языке S>- фичи, которых нет в Блабе, и значит они никому не нужны. S>Вот типичные высказывания блаб программистов:
Спасибо за информацию, теперь я могу определять типичных Блаб программистов , только тут речь не об этом, а о полезности конкретной фичи языка.
Здравствуйте, VladGalkin, Вы писали:
VG>Какие именно технологии MS используются в Mono?
Проблема не в реализации виртуальной машины и языка C#, а в реализации проприетарных технологий от MS что входят в BCL — ака ASP.Net, Remoting, Windows Forms, и т.д.
A>Проблема не в реализации виртуальной машины и языка C#, а в реализации проприетарных технологий от MS что входят в BCL — ака ASP.Net, Remoting, Windows Forms, и т.д.
Хм, не знаю насчет "проприетарности", но все проблемы в Mono, связанные с этими технологиями, сугубо технического плана, но не юридического.
Здравствуйте, VladGalkin, Вы писали:
A>>Проблема не в реализации виртуальной машины и языка C#, а в реализации проприетарных технологий от MS что входят в BCL — ака ASP.Net, Remoting, Windows Forms, и т.д.
VG>Хм, не знаю насчет "проприетарности", но все проблемы в Mono, связанные с этими технологиями, сугубо технического плана, но не юридического.
M$ дала гарантию (или хоть слово сказала), что не будет предъявлять претензий? Если нет — "серьёзный" бизнес не будет "садиться" в лодку, которая потенциально "дырява"
Здравствуйте, VladGalkin, Вы писали:
VG>Хм, не знаю насчет "проприетарности", но все проблемы в Mono, связанные с этими технологиями, сугубо технического плана, но не юридического.
Проприетарность под сомнением, я правильно понимаю? Может эти технологии описаны где-то в открытых стандартах? И не являются "invented by Microsoft"?
Здравствуйте, cl-user, Вы писали:
CU>M$ дала гарантию (или хоть слово сказала), что не будет предъявлять претензий? Если нет — "серьёзный" бизнес не будет "садиться" в лодку, которая потенциально "дырява"
...Особенно нравятся высказывания про "претензии" и "серьезный бизнес", хотя бы Mono FAQ и succcess stories почитать можно было.
ОФФТОП: Вот что меня не перестает удивлять, так это такое отношение к Microsoft. Что оно сделало всем эти людям?
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, VladGalkin, Вы писали:
A>>>Проблема не в реализации виртуальной машины и языка C#, а в реализации проприетарных технологий от MS что входят в BCL — ака ASP.Net, Remoting, Windows Forms, и т.д.
VG>>Хм, не знаю насчет "проприетарности", но все проблемы в Mono, связанные с этими технологиями, сугубо технического плана, но не юридического.
CU>M$ дала гарантию (или хоть слово сказала), что не будет предъявлять претензий?
VladGalkin wrote: > CU>M$ дала гарантию (или хоть слово сказала), что не будет предъявлять > претензий? Если нет — "серьёзный" бизнес не будет "садиться" в лодку, > которая потенциально "дырява" > > ...Особенно нравятся высказывания про "претензии" и "серьезный бизнес", > хотя бы Mono FAQ и succcess stories почитать можно было. > > ОФФТОП: Вот что меня не перестает удивлять, так это такое отношение к > Microsoft. Что оно сделало всем эти людям?
Из последнего — купило акции SCO в ситуации, когда единственная
возможность выживания SCO была (и остаётся сейчас) в выигрыше того
самого загадочного иска против IBM и FSF. На ведение которого полученные
деньги и пошли. После этого загадочного действия никто не верит, что MS
не имела отношения к исходной подаче иска. И никто не верит, что MS не
попытается использовать патенты на ПО в любых корыстных целях. И даже
официальным бумагам с подписью Баллмера не поверят, если останется хоть
одна оговорка.
Здравствуйте, cl-user, Вы писали:
CU>M$ дала гарантию (или хоть слово сказала), что не будет предъявлять претензий? Если нет — "серьёзный" бизнес не будет "садиться" в лодку, которая потенциально "дырява"
...Особенно нравятся высказывания про "претензии" и "серьезный бизнес", хотя бы Mono FAQ и succcess stories почитать можно было.
ОФФТОП: Вот что меня не перестает удивлять, так это такое отношение к Microsoft. Что оно сделало всем эти людям?
Здравствуйте, VladGalkin, Вы писали:
VG>ОФФТОП: Вот что меня не перестает удивлять, так это такое отношение к Microsoft. Что оно сделало всем эти людям?
Ничего. Т.е. совершенно ничего, чтобы можно было доверять этой компании в "скользких" вопросах. А использовать патентованные технологии при отсутствии гарантий со стороны птентовладелица — ходить по минному полю.
В моно есть хоть один файлик с какими-либо заявлениями от M$?
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, prVovik, Вы писали:
CU>>>M$ дала гарантию (или хоть слово сказала), что не будет предъявлять претензий?
V>>Насколько я слышал — да.
CU>Урл?
For people who need full compatibility with the Windows platform, Mono's strategy for dealing with any potential issues that might arise with ASP.NET, ADO.NET or Windows.Forms is: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless.
Здравствуйте, cl-user, Вы писали:
АХ>>Кроссплатформенность — да, с этим пока похуже, но Mono развивается. FW 1.1 уже полностью поддерживают насколько я знаю.
CU>Цена этому — грош в базарный день. Пока MS не заявит, что а) не будет предъявлять _никаких_ притензий к mono и производным продуктам, использующим её собственные технологии;
Тут есть 2 момента. CLR и C# стандаризованы ECMA и все что там запатентовано официально разрешено использовать бесплатно. Используй на здоровье, ни за что бояться не надо.
Нарушать патенты потенциально могут реализации ASP.NET, ADO.NET и Windows Forms, но:
Patents
Could patents be used to completely disable Mono?
First some background information.
The .NET Framework is divided in two parts: the ECMA/ISO covered technologies and the other technologies developed on top of it like ADO.NET, ASP.NET and Windows.Forms.
Mono implements the ECMA/ISO covered parts, as well as being a project that aims to implement the higher level blocks like ASP.NET, ADO.NET and Windows.Forms.
The Mono project has gone beyond both of those components and has developed and integrated third party class libraries, the most important being: Debugging APIs, integration with the Gnome platform (Accessibility, Pango rendering, Gdk/Gtk, Glade, GnomeUI), Mozilla, OpenGL, extensive database support (Microsoft only supports a couple of providers out of the box, while Mono has support for 11 different providers), our POSIX integration libraries and finally the embedded API (used to add scripting to applications and host the CLI, or for example as an embedded runtime in Apache).
Basically a grant is given to anyone who want to implement those components for free and for any purpose.
For people who need full compatibility with the Windows platform, Mono's strategy for dealing with any potential issues that might arise with ASP.NET, ADO.NET or Windows.Forms is: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless.
Not providing a patented capability would weaken the interoperability, but it would still provide the free software / open source software community with good development tools, which is the primary reason for developing Mono.
The patents do not apply in countries where software patents are not allowed.
For Linux server and desktop development, we only need the ECMA components, and things that we have developed (like Gtk#) or Apache integration.
CU> б) не возьмёт mono под опеку (если не денег, то ms-labs хотябы) — доверия (массового) к моно не будет
Не обращай внимания на FUD политику от MS, CLR и C# можно использовать.
1) Если страшно, для патентной чистоты достаточно не использовать ASP.NET, ADO.NET и Windows Forms. Вместо них можно использовать Gtk#, альтернативы ASP.NET да и с базами данных можно работать через Mono.Data
2) Конкуренты MS создали организацию OIN, которая держит под своим крылом Mono и владеет некоторыми патентами на Веб-сервисы. Если MS начнет рыпаться, то его этими патентами могут больно ударить в ответ.
3) Если MS начнет реально предъявлять претензии, то люди просто откажутся от ее технологий в пользу Java. Поэтому, я думаю забивать гвозди в крышку собственного гроба они не будут .
CU>Что ему стоит поддержать открытые моно
Что значит поддержать разработку Моно? Для этого надо согласиться с GPL, что противоречит философии MS на данный момент.
CU> и немерле?
Разработка Немерле частично поддерживалась грантом от MS.
А так вместо Немерле примерно в ту же нишу MS толкает F#.
По мне так он хуже, хотя бы из-за ML-синтаксиса.
Здравствуйте, VladGalkin, Вы писали:
VG>ОФФТОП: Вот что меня не перестает удивлять, так это такое отношение к Microsoft. Что оно сделало всем эти людям?
Элементарная человеческая зависть.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Тут есть 2 момента. CLR и C# стандаризованы ECMA и все что там запатентовано официально разрешено использовать бесплатно. Используй на здоровье, ни за что бояться не надо.
...и положа руку на сердце — какую часть от .NET составляют CLR и C#?
АХ>Вот что написано на сайте Mono: АХ>[q]
Читал. Лчно мне — всё равно. Но такое состояние: "туда не ходи — сюда ходи" — очков моно как мультиплатформенной системе (особенно по сравнению с JVM) не добавляет
АХ>2) Конкуренты MS создали организацию OIN, которая держит под своим крылом Mono и владеет некоторыми патентами на Веб-сервисы. Если MS начнет рыпаться, то его этими патентами могут больно ударить в ответ.
Есть у одной крупной коммерческой организации печальный опыт "грызни" с M$
АХ>3) Если MS начнет реально предъявлять претензии, то люди просто откажутся от ее технологий в пользу Java. Поэтому, я думаю забивать гвозди в крышку собственного гроба они не будут .
M$ может начать предъявлять претензии только к моно (и тому, что на нём построено). На положение моно под виндой это всё-равно влияния не окажет — его там и так считай нет
CU>>Что ему стоит поддержать открытые моно АХ>Что значит поддержать разработку Моно? Для этого надо согласиться с GPL, что противоречит философии MS на данный момент.
И я о том
АХ>Разработка Немерле частично поддерживалась грантом от MS. АХ>А так вместо Немерле примерно в ту же нишу MS толкает F#. АХ>По мне так он хуже, хотя бы из-за ML-синтаксиса.
Здравствуйте, cl-user, Вы писали:
АХ>>Тут есть 2 момента. CLR и C# стандаризованы ECMA и все что там запатентовано официально разрешено использовать бесплатно. Используй на здоровье, ни за что бояться не надо.
CU>...и положа руку на сердце — какую часть от .NET составляют CLR и C#?
Смотря что понимать под .NET...
Но вообще не исследовал этот вопрос.
CU>Читал. Лчно мне — всё равно. Но такое состояние: "туда не ходи — сюда ходи"
Ну, куда не ходить совершенно ясно .
CU> — очков моно как мультиплатформенной системе (особенно по сравнению с JVM) не добавляет
Мне JVM кажется технологически хуже (особенно в плане эффективности и поддержки динамических возможностей). Но то что она теперь под GPL — да, это хорошо. И хорошо еще и потому что это будет давить на MS в сторону либерализации ситуации с .NET.
А в Моно возможно всякие интересные вещи появятся вроде нативного GCC-бэкенда, да и mkbundle которая делает отдельные бинарники у них есть.
АХ>>2) Конкуренты MS создали организацию OIN, которая держит под своим крылом Mono и владеет некоторыми патентами на Веб-сервисы. Если MS начнет рыпаться, то его этими патентами могут больно ударить в ответ.
CU>Есть у одной крупной коммерческой организации печальный опыт "грызни" с M$
А ссылку можно?
Больше всего патентов держит IBM которая входит в OIN. С ней я бы бодаться не советовал .
АХ>>3) Если MS начнет реально предъявлять претензии, то люди просто откажутся от ее технологий в пользу Java. Поэтому, я думаю забивать гвозди в крышку собственного гроба они не будут .
CU>M$ может начать предъявлять претензии только к моно (и тому, что на нём построено). На положение моно под виндой это всё-равно влияния не окажет — его там и так считай нет
Но это очень сильное влияние на умы людей которые принимают решения на чем разрабатывать окажет. И они будут выбирать Java, которая застрахована от таких рисков. И это поставит крест на .NET как кроссплатформенном решении, а значит сильно сузит перспективы MS на самом доходном корпоративном рынке. Я думаю, MS этого не хочет.
АХ>>Разработка Немерле частично поддерживалась грантом от MS. АХ>>А так вместо Немерле примерно в ту же нишу MS толкает F#. АХ>>По мне так он хуже, хотя бы из-за ML-синтаксиса.
CU>...и относятся к нему, как мачеха к золушке
К F#?
Они вон на Channel9 о нем видео постят. И интеграцию с VS сделали.
Здравствуйте, Sheridan, Вы писали:
S>Вдобавок, с кутэ можно вполне законно писать и тестировать первый проект на free, а при готовности продукта купить коммерческую кутэ непосредственно перед началом продаж.
Can we use the Open Source Edition while developing our non-opensource application and then purchase commercial licenses when we start to sell it?
Answer:
No. Our commercial license agreements only apply to software that was developed with Qt under the commercial license agreement. They do not apply to code that was developed with the Qt Open Source Edition prior to the agreement. Any software developed with Qt without a commercial license agreement must be released as Open Source software. http://www.trolltech.com/developer/knowledgebase/182/
Здравствуйте, Андрей Хропов, Вы писали:
CU>>...и положа руку на сердце — какую часть от .NET составляют CLR и C#? АХ>Смотря что понимать под .NET... АХ>Но вообще не исследовал этот вопрос.
Т.е. дотнет "обожают" за саму платформу, ан за "туеву хучу" технологий, к ней привязанных?
АХ>Мне JVM кажется технологически хуже (особенно в плане эффективности и поддержки динамических возможностей). Но то что она теперь под GPL — да, это хорошо. И хорошо еще и потому что это будет давить на MS в сторону либерализации ситуации с .NET.
Не верю... (что M$ подвинется в этом направлении)
CU>>Есть у одной крупной коммерческой организации печальный опыт "грызни" с M$ АХ>А ссылку можно?
АХ>Больше всего патентов держит IBM которая входит в OIN. С ней я бы бодаться не советовал .
Я и имел в виду M$*IBM-OS2/WInNT Ссылок не дам
CU>>M$ может начать предъявлять претензии только к моно (и тому, что на нём построено). На положение моно под виндой это всё-равно влияния не окажет — его там и так считай нет
АХ>Но это очень сильное влияние на умы людей которые принимают решения на чем разрабатывать окажет. И они будут выбирать Java, которая застрахована от таких рисков. И это поставит крест на .NET как кроссплатформенном решении, а значит сильно сузит перспективы MS на самом доходном корпоративном рынке. Я думаю, MS этого не хочет.
Это _будет_ "влиять на умы людей" в пропорции использующих моно/M$-дотнет Ох не скоро ещё M$ начнёт озираться на этот сектор...
Здравствуйте, Андрей Хропов, Вы писали:
CU>> — очков моно как мультиплатформенной системе (особенно по сравнению с JVM) не добавляет АХ>Мне JVM кажется технологически хуже (особенно в плане эффективности и поддержки динамических возможностей). Но то что она теперь под GPL — да, это хорошо. И хорошо еще и потому что это будет давить на MS в сторону либерализации ситуации с .NET.
Мне кажется, это миф. Динамические возможности — это что? Если компиляция и загрузка классов на лету, то это давно уже есть. В Java6 (который уже практически вышел) даже включено в стандартную библиотеку классов. Про эффективность... даже незнаю что сказать, наверное, имееются в виду value типы?
Здравствуйте, cl-user, Вы писали:
CU>Т.е. дотнет "обожают" за саму платформу, ан за "туеву хучу" технологий, к ней привязанных?
Ну кто "обожает" пусть ответит.
Мне — да, мне важнее сама платформа.
АХ>>Мне JVM кажется технологически хуже (особенно в плане эффективности и поддержки динамических возможностей). Но то что она теперь под GPL — да, это хорошо. И хорошо еще и потому что это будет давить на MS в сторону либерализации ситуации с .NET.
CU>Не верю... (что M$ подвинется в этом направлении)
Дак ведь заставляют. Думаешь MS .NET в ECMA стандартизировала от хорошей жизни. Я думаю, что нет.
Да и вообще создание .NET было во многом реакцией на взрывной рост популярности Java.
АХ>>Но это очень сильное влияние на умы людей которые принимают решения на чем разрабатывать окажет. И они будут выбирать Java, которая застрахована от таких рисков. И это поставит крест на .NET как кроссплатформенном решении, а значит сильно сузит перспективы MS на самом доходном корпоративном рынке. Я думаю, MS этого не хочет.
CU>Это _будет_ "влиять на умы людей" в пропорции использующих моно/M$-дотнет Ох не скоро ещё M$ начнёт озираться на этот сектор...
Нет. Вот есть фирма, занимающаяся разработкой некоего ПО. И они (или их клиенты) заинтересованы в том чтобы это ПО работало не только под Windows, но и под Unix/Linux (что в гетерогенной корпоративной среде, да еще с legacy Unix-based ПО далеко не редкость (особенно в USA)). Что они выберут? Скорее всего J2EE.
Здравствуйте, Андрей Хропов, Вы писали:
CU>>Это _будет_ "влиять на умы людей" в пропорции использующих моно/M$-дотнет Ох не скоро ещё M$ начнёт озираться на этот сектор... АХ>Нет. Вот есть фирма, занимающаяся разработкой некоего ПО. И они (или их клиенты) заинтересованы в том чтобы это ПО работало не только под Windows, но и под Unix/Linux (что в гетерогенной корпоративной среде, да еще с legacy Unix-based ПО далеко не редкость (особенно в USA)). Что они выберут? Скорее всего J2EE.
И будут правы. На данный момент M$ глубоко пофиг те, кто не на платформе M$.
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, Андрей Хропов, Вы писали:
CU>>>Это _будет_ "влиять на умы людей" в пропорции использующих моно/M$-дотнет Ох не скоро ещё M$ начнёт озираться на этот сектор... АХ>>Нет. Вот есть фирма, занимающаяся разработкой некоего ПО. И они (или их клиенты) заинтересованы в том чтобы это ПО работало не только под Windows, но и под Unix/Linux (что в гетерогенной корпоративной среде, да еще с legacy Unix-based ПО далеко не редкость (особенно в USA)). Что они выберут? Скорее всего J2EE.
CU>И будут правы. На данный момент M$ глубоко пофиг те, кто не на платформе M$.
Вот это не совсем так, иначе бы MS с Novell не заключала соглашения.
Здравствуйте, Андрей Хропов, Вы писали:
CU>>И будут правы. На данный момент M$ глубоко пофиг те, кто не на платформе M$. АХ>Вот это не совсем так, иначе бы MS с Novell не заключала соглашения.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Здравствуйте, Андрей Хропов, Вы писали:
CU>>>И будут правы. На данный момент M$ глубоко пофиг те, кто не на платформе M$. АХ>>Вот это не совсем так, иначе бы MS с Novell не заключала соглашения.
TBG>Китайцев то много..
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Здравствуйте, Sheridan, Вы писали:
S>>>2. в линухе моно никому не нужен. АХ>>Мне нужен, потому что я считаю платформу .NET более продуманной чем JVM. АХ>>Другим людям нужен чтобы использовать их .NET приложения также и под Linux.
К>Ты случайно не в курсе, есть ли уже прецеденты подобного? Причём было бы интересней что-нибудь гуёвое, а не консольные утилитки
Один из примеров — открытая библиотека libsecondlife. Писана на шарпе, компилится как под виндой, так и под моно в линуксе. Правда гуевости там не много.
Здравствуйте, Димчанский, Вы писали:
К>>Ты случайно не в курсе, есть ли уже прецеденты подобного? Причём было бы интересней что-нибудь гуёвое, а не консольные утилитки
Д>Один из примеров — открытая библиотека libsecondlife. Писана на шарпе, компилится как под виндой, так и под моно в линуксе. Правда гуевости там не много.
Товарищи!
Причем здесь что-то гуевое, сама по себе NET не имеет ни какой ценности. Представим себе сложное
распределенное/корпоративное приложение, которое использует:
— какую-нибудь компонентную технологию распределенных компонентов (COM+)
— менеджер транзакций
— сервер БД
— веб сервер
— другие вспомогательные сервисы (BizTalk и еще какие-нибудь страшные вещи, которых я не знаю)
Проблема в том, что перед названием большинства из этих вещей стоит слово Microsoft, а само
приложение функционирует на серевер приложений "Windows" (в широком смысле).
А теперь вопрос в студию: можно ли не переписывая софтину перенести все на сервер приложений
"Linux"(Mono) (есть ли там ТОЧНО такие же сервисы).
Есть ли НЕТ — все поклонники NET могут идти в Бобруйск — ни о какой переносимости NET приложений
не может быть и речи.
А вот J2EE приложении с одного AS на такой же под другой ОС очень даже переносится
(если не использовать системно зависимые вещи, которые в большинстве случаем такому приложению не
нужны).
И между различными AS тоже (если не использовать вещи специфичные для конкретного AS — например GBean, максимум что может потребоваться это написать новый план развертывания).
Проверено на собственном более чем скромном опыте.
C>>Правда ошибки GCC Студия не разбирает WH>Тогда нет никакого смысла этим заниматься. Ибо ценно не столько сам запуск компиляции (меня не ломает переключится в консоль и написать make) сколько возможность переходить по ошибкам одним кликом.
Фильтр напиши, проще простого. На стандартном входе пусть идут сообщения одного формата, GCC например, а ты их переводи в формат VC, и сможешь ходить по файлам. Кстати, если свои какие-то пре- или пост- билдовые тулзины делаешь, то тоже придерживайся этого формата вывода сообщений, чтобы автоматически ходить по файлам.
) кроссплатформенности дотнета — все будет, не захотят — будет жить на задворках. И GPLность Java тут абсолютно непричем... Каково количество проектов, написанных на Mono? Исключая гномовские приблуды? Флуктуации на уровне долей процентов, и 0.2% или 0.15% после открытия java думаю роли не играют 
1.2.0 alpha rev. 655
. А при обесплачивании Javы ничего особенного, я думаю, не произойдет. Поддержка будет, в том числе и от Sun. Я не думаю, что язык настолько молодой и неокрепший, т.к. сам писал на нем еще лет 7 назад — и уже тогда был доволен ее возможностями.
? Под Windows я могу писать на любом языке пользуясь кроссплатформенными библиотеками. Впрочем как и под Линукс.
Короче оно будет постоянно голючить и падать. Да и работать будет скорей всего сильно медленней ибо все ресурсы съест борьба с багами и на оптимизацию времени не останется.
, но не так выражено
Если нам не помогут, то мы тоже никого не пощадим.
